{"id":5829,"date":"2026-10-09T06:03:07","date_gmt":"2026-10-09T06:03:07","guid":{"rendered":"https:\/\/falcoxai.com\/main\/ai-coding-resistance-objections\/"},"modified":"2026-10-09T06:03:07","modified_gmt":"2026-10-09T06:03:07","slug":"ai-coding-resistance-objections","status":"publish","type":"post","link":"https:\/\/falcoxai.com\/main\/ai-coding-resistance-objections\/","title":{"rendered":"AI Coding Resistance: What the Objections Get Right"},"content":{"rendered":"

In October 2026, software writer Graham Lee published a catalogue of reasons people dislike AI coding: code as art, AI as employment thief, humans reduced to “meat proxies” feeding prompts into a machine, software engineering as a body of sacred rules. Read that list with your plant floor in mind and it gets uncomfortably familiar. Your most experienced quality engineer saying inspection judgement can’t be codified. Your line supervisors worried about headcount. Your process owners insisting the standard work exists for good reasons.<\/p>\n

AI coding resistance and factory floor resistance are the same four objections wearing different uniforms. Each one contains something true, which is why dismissing them backfires. Below, we map Lee’s four arguments onto the pushback you actually hear, and what answers them.<\/p>\n

Your Team Isn’t Arguing About AI Accuracy, They’re Arguing About Craft<\/h2>\n

Look closely at Lee’s four objections. Not one of them is about whether the generated code works. They are arguments about identity, ownership, and what the job actually is. His own rebuttal to the employment argument gets at it: the job “was never to type code, it was to deliver valuable software.”<\/p>\n

The same gap shows up when you pitch AI for inspection write-ups or deviation triage. Almost nobody says the model is wrong. They say the model doesn’t understand this line, or that a deviation report needs a person who has walked the floor. That is a claim about craft, not accuracy.<\/p>\n

Answering an accuracy objection with validation data when the real objection is craft gets you nowhere. Name the actual argument first.<\/p>\n

\"Developers<\/figure>\n

The Four Objections, Translated Out of Software and Into Operations<\/h2>\n

Lee’s four categories map onto the plant floor with almost no translation loss. Code as art becomes the veteran inspector whose judgement “can’t be written down.” AI as employment thief becomes the shift supervisor counting heads. Humans as meat proxies becomes the process engineer who now reviews machine-generated deviation drafts instead of writing them. Software engineering as rules becomes the ISO-trained quality manager defending the methodology itself.<\/p>\n

Craft and judgement: when expertise feels like art<\/h3>\n

The artistic objection in software says generated code “doesn’t have the creative ineffability that’s a sign of true art.” On the floor, that becomes the inspector who can hear a bearing going bad, or the operator who knows which torque readings to distrust. That knowledge is real. It is also, in most plants, undocumented and sitting with three people who are within a decade of retirement.<\/p>\n

Lee’s counter is blunt and it carries over: the people buying software “aren’t paying for artworks, they’re paying for outcomes.” Your customers are paying for conforming parts, not for the experience of a skilled human producing them. Treat the craft argument as a sourcing problem, not a philosophical one. If judgement matters that much, capture it before it walks out the door.<\/p>\n

Rules and methodology: when the process is the identity<\/h3>\n

Bertrand Meyer’s AI for Smarties<\/em> prompts Lee’s fourth category: the belief that engineering quality comes from careful application of rules like SOLID or “prefer composition over inheritance.” Quality has its own version. Eight disciplines. Five whys. The control plan format that has not changed since 2011. People who built careers on mastering those frameworks hear “AI-assisted root cause” as a demotion.<\/p>\n

The frameworks were never the point. They were scaffolding to force consistent thinking when consistency was expensive. AI makes some of that scaffolding cheap, which exposes which parts carried real value and which were ritual. Expect that distinction to be the hardest conversation you have, because it decides whose expertise still counts.<\/p>\n

Outcomes vs Artefacts: The Argument That Actually Lands<\/h2>\n

Lee gives one counter that holds up under pressure, and it is worth quoting directly:<\/p>\n

the people who want software typically aren’t paying for artworks, they’re paying for outcomes. And the outcomes of using a given artefact are the same regardless of how the artefact is made.<\/p><\/blockquote>\n

Swap “software” for “quality documentation” and the argument survives intact. Your customer cares about parts per million defective. Your notified body cares about whether the record is complete, traceable, and consistent with the batch history. Nobody on either side of that transaction has ever asked who typed the summary.<\/p>\n

This is the sharpest response to craft-based objections because it does not dispute the craft. A veteran inspector’s judgement is real and valuable. The question is what portion of their week is actually judgement, and what portion is transcription of judgement already made. Those are different activities and only one of them is worth protecting.<\/p>\n

The second rebuttal carries over just as cleanly. Lee’s point about employment is that the job “was never to type code, it was to deliver valuable software.” On the floor: the job was never to fill in the form, it was to prevent the escape. If a model drafts the 8D narrative and your engineer spends the recovered hours at the line finding the actual root cause, the outcome improved. The artefact changed. Nobody paying you noticed or cared.<\/p>\n

Where this argument fails is when leaders use it to dodge the accountability question. Outcomes-not-artefacts does not mean outcomes-without-owners. Someone still signs the deviation. Someone still owns the CAPA closure. Make that explicit early, because the moment your quality manager suspects the argument is a route to unattributed decisions, you have lost them, and they are right to push back.<\/p>\n

Run the test on every process you are considering: name the outcome, name who is accountable for it, then ask whether the current artefact is the only way to get there. Usually it is not.<\/p>\n

\"Split<\/figure>\n

Where the Objections Are Right and You Should Slow Down<\/h2>\n

Lee is honest about the limits of his own rebuttals. On the art objection he concedes there is no argument against it if you accept its axioms. The same honesty is owed to your team. Some of what they are defending is worth defending, and the “meat proxies” worry is the one to take seriously: a skilled engineer reduced to what Marx called a conscious linkage in an automatic system of machinery.<\/p>\n

That is not a philosophical complaint. It is a retention and capability problem that shows up eighteen months later, when the people who could have caught the model’s mistake have stopped paying attention.<\/p>\n

Tasks where full automation damages capability<\/h3>\n

Automate fully where the output is checkable against an objective record: dimensional data against spec, batch records against the master, document formatting against a template. If a second system can verify the result, no human skill decays when the human stops doing it.<\/p>\n

Keep humans in the loop where the task is how judgement gets built. Root cause investigation is the clearest case. An engineer who has never worked through a messy five-why with contradictory evidence cannot review an AI-generated one. The same goes for first-article inspection on a new process and any deviation that touches patient or operator safety. Generate the draft, but the human has to do the thinking, not just the signing.<\/p>\n

Redesigning the role before deploying the tool<\/h3>\n

Most rollouts fail here. The tool arrives, the typing disappears, and nobody rewrites the job description. The engineer’s week now contains the same volume of work with the interesting third removed, and they notice immediately.<\/p>\n

Decide what the role becomes before procurement, not after. If the AI drafts deviation reports, the engineer’s new work is trend analysis across deviations, supplier escalation, and process redesign. Write that into the objectives and the review cycle. Then measure whether it actually happened, because freed-up hours that silently refill with more drafting will confirm every objection your team raised.<\/p>\n

\n

Ready to find AI opportunities in your business?<\/strong>
\nBook a Free AI Opportunity Audit<\/a>. It is a 30-minute call where we map the highest-value automations in your operation.<\/p>\n<\/div>\n

Making Demand Growth, Not Headcount Cuts, Your Deployment Story<\/h2>\n

Lee’s answer to the jobs objection is the one worth stealing: “demand only increases as application becomes more efficient.” Every operations leader already has proof of this sitting in a backlog. Supplier audits that slipped two quarters. Root cause investigations closed with a containment action and nothing else. Process capability studies nobody has run since the line was requalified.<\/p>\n

So do not open with cost per report. Open with the list of improvement work your team has not had time to touch, and name which items the freed hours are going to. If you cannot name them, you are not ready to deploy, because the default assumption on the floor will be that the savings go to headcount. That assumption is reasonable and you earn your way out of it with specifics, not reassurance.<\/p>\n

What to measure so freed capacity is visible<\/h3>\n

Pick a small set of numbers before go-live and publish them monthly to the same people who were sceptical. Two of them track the automation. The rest track where the time went.<\/p>\n