In October 2026, a developer published an essay titled “AI Makes Me Sad” at 2:00 AM. He was not a skeptic on the outside looking in. He could walk into OpenAI tomorrow, like the teaching assistants he overheard discussing $500k salaries. He turned it down because the work “sounds like a loss of craft, a loss of control, a loss of creativity.” He compared it to Charlie Chaplin getting pulled into the gears in Modern Times.

Your most experienced quality engineer feels a version of this, even if she never writes it down. AI fatigue is not a morale issue to be handled by HR. It is the reason your pilot stalls at 40% adoption while the business case assumed 90%. Here is what it actually costs you, and how to run implementation around it.

Your Best Engineers Are Quietly Grieving, Not Resisting

Read the essay closely and the line that should worry you is not about sadness. It is this: “I don’t want to prompt Codex for a living, or Claude for that matter.” That is not fear of the technology. That is someone who knows exactly what good work feels like and refuses to trade it for supervising output he didn’t make.

It sounds like people around me are throwing themselves at the machine, volunteering to make themselves obsolete for $500k a year.

Most rollout plans assume two reactions: indifference or fear of job loss. Neither describes your strongest people. They are skilled, they are respected for that skill, and they sense it being quietly reclassified as overhead.

Grief does not show up on an engagement survey. It shows up as licenses nobody opens, pilots that stall at week six, and the old spreadsheet still running in parallel.

What the Essay Actually Says, and Why It Resonated Far Beyond Developers

Strip out the 2 AM mood and the argument is structural. The author’s complaint is that the category of work he trained for has been collapsed into a single interface. He writes that startups no longer exist as such:

Now there’s no such thing as a startup, there are only “AI startups”, where you build a company that somebody else can write a prompt for in 30 seconds.

Swap “prompt” for “review the AI-flagged defects” and you have the conversation happening in quality departments right now. Same shape, different shop floor.

The craft argument: competence that took a decade to build, reduced to supervision

He lists what he can do: web, Rust, even OS work. That is a decade of accumulated skill, and his objection is that none of it is the thing being asked for anymore. The ask is judgment on output someone else generated.

Your senior inspector has the same inventory. She knows which supplier’s parts drift in humidity, which operator rushes the last hour of shift, what a bad weld sounds like before it fails test. Tell her the model now flags the defects and she confirms them, and you have not given her a better tool. You have told her the part she was proud of is now a checkbox.

The futility argument: ‘it feels like there’s no way to stop it’

The second half of the essay is heavier than the first. He describes the weight as “so stifling” and admits he cannot see a way out, because every institution he might appeal to is already being flooded. That is not resistance. Resistance assumes you think you can win.

This is the version that destroys manufacturing AI adoption, and it is nearly invisible in a survey. People who believe the outcome is fixed stop arguing in meetings. They attend the training, nod at the dashboard, and quietly keep their own spreadsheet because that is where their actual expertise still lives. Your adoption metrics look fine. Your model never sees the data that matters.

The Hidden Cost of AI Fatigue on Implementation ROI

Pilots almost never die from model accuracy. They die from usage rates that nobody puts on the status report. A deviation-triage assistant used by 3 of 11 quality engineers delivers roughly a quarter of its business case while the licence invoice arrives in full.

Three failure modes show up again and again on the floor:

• Shadow spreadsheets: the old tracker stays alive “just in case”, so every record gets entered twice and the time saving evaporates.
• Rubber-stamping: output approved without review, which is worse than no AI because you have added a layer of false confidence to your release decisions.
• The quiet abstainer: the senior inspector who never opens the tool and is also the person everyone walks over to when something looks wrong.

Adoption rate is the variable that moves your payback period most

Most business cases are modelled on hours saved per user per week multiplied by headcount. That second number is the one people treat as fixed. It isn’t. It’s a behavioural variable, and it swings wider than any accuracy improvement your vendor can ship.

Improving model performance from good to excellent moves your return by a few percent. Moving adoption from 30% to 80% roughly doubles or triples it, at zero extra licence cost. That’s where the engineering effort belongs, and almost nobody spends it there.

Why sceptics hide their non-use instead of reporting it

Nobody tells their operations director that the tool makes them feel obsolete. They say it’s “a bit slow” or they’re “still getting used to it”, then go back to the method that lets them do the job they’re proud of. Saying the real thing out loud sounds like a career risk.

The source essay names the actual objection better than any survey will: the work “sounds like a loss of craft, a loss of control, a loss of creativity.” On your dashboard that registers as a technology problem. It’s a trust and identity problem, and it will not be fixed by another training session.

Designing AI Rollouts That Give Craft Back Instead of Taking It

Automate the administration, not the expertise

Start with the work nobody puts on their CV. Transcribing handwritten inspection notes into the QMS. Chasing the fourth signature on a CAPA that closed three weeks ago. Reformatting the same evidence pack for a customer audit, an ISO audit, and a notified body, each in a different template. No quality engineer has ever described that as the reason she took the job.

Judgement stays human by design, not by policy memo. The model proposes a root cause category, a risk ranking, a disposition. The engineer accepts, edits, or rejects, and the system records which. Those overrides are the most valuable data you will generate in year one, so treat them as a quality signal rather than a nuisance to be trained away.

The author of the essay feared becoming Charlie Chaplin pulled into the gears. A reviewer with no authority to reject output is exactly that job. If your approval button has only one realistic answer, you have built a conveyor belt with a human bolted to it.

Reinvest freed hours in work people are proud of

Freed capacity that goes unnamed gets absorbed into more of the same backlog, and your team concludes the AI simply raised the quota. Commit the hours before the tool goes live, in writing. Six hours a week on real root-cause investigation. A supplier development visit that has been postponed twice. The process capability study nobody has had time to run since the new line went in.

Then show one person’s week, not a department average. Before: Monday and Tuesday on data entry and signature chasing, Wednesday on the audit pack, two days left for actual engineering. After: the admin collapses into a few hours of review, and three full days open up for problems that need a brain.

That comparison does more for AI adoption resistance than any town hall. People believe a calendar they recognise as their own.

The Rebuild Case: Why the Essay’s Optimistic Ending Applies to Your Plant

The essay turns at the end, and the turn is the useful part. The author decides that rebuilding institutions “doesn’t sound that hard.” His reasoning is almost rude in its simplicity: Twitter is only 20 years old, LinkedIn is 23, and “most of these were in need of a refresh anyway.”

Honestly, though, it doesn’t sound that hard to rebuild all our institutions.

Run that logic against your own plant. Your deviation workflow was probably designed around a document control system someone bought in 2011. Your audit prep is a habit, not an architecture. Your inspection documentation exists in its current form because a customer asked for a specific template once and nobody ever revisited it.

None of that is sacred. The teams pulling real value out of AI in 2026 are not the ones with the largest model budget. They are the ones who reopened a process that had quietly calcified and let the people who run it hold the pen while it was redrawn.

A 30-day starting point for one process and one team

Pick one process. Not a portfolio, not a roadmap. One process with a clear owner, a measurable cycle time, and enough volume that a change shows up in the numbers within a quarter.

Then ask the people who do that work a single question: which part of your job would you defend if someone tried to take it? You will get specific answers. Reading a trend before it breaches a limit. Judging whether an operator’s explanation holds up. Deciding what a finding actually means for the customer.

Write those answers down and treat them as design constraints, not preferences. Everything surrounding them, the retyping, the chasing, the reformatting, is fair game for automation. Thirty days is enough to map the process, protect the craft inside it, and ship one change. It is not enough to run a steering committee, which is the point.

Source: mondobe.com