Developer resistance to AI tools, and what it means
Stefan-Iulian Tesoi · · 6 min read
Most of it is a specific objection wearing a general one. The three that come up are review load nobody budgeted for, work arriving faster than anyone can judge it, and a suspicion that the tool is there to measure people rather than to help them. Each needs a different answer, and none of them is answered by enthusiasm.
Developer resistance to AI tools is read as a culture problem more often than it deserves. Treated as a culture problem it gets a culture response — a talk, a mandate, a champion — and the specific thing that got worse for a specific person stays exactly as it was.
What is developer resistance to AI tools actually about?
Something concrete that changed in someone's week. The general statement is a summary, and summaries are what people offer when nobody has asked for the detail.
The useful question is not "what do you think of the tool" but "what is worse now than it was a month ago". That question has answers. It also has the property that a bad rollout and a good one produce visibly different ones, which makes it a diagnostic rather than a temperature check.
"I don't think these tools are ready" is almost never a claim about model capability. It is usually a claim about what the speaker is now spending their afternoons doing, and they are usually right about that.
Four objections, and what each one means
Each of these is worth taking at face value first and translating second, because sometimes the face value is the whole of it.
| What is said | What it usually means | What actually answers it |
|---|---|---|
| "The code it writes is bad" | "I review more than I write now" | Review capacity, not model choice |
| "It doesn't understand our codebase" | "The backlog items don't say what it would need" | Acceptance criteria that can be checked |
| "This is a productivity metric in disguise" | Often exactly that | Say what is measured, and what is not |
| "It will stop juniors learning" | A real long-term worry | A training answer, not a tooling one |
The first row is the one that matters most and gets dismissed most. When an agent produces work faster than before, the review queue grows, and reviewing is slower and less satisfying than writing. A team that was balanced becomes a team of reviewers, and nobody agreed to that. What changes about the reading itself is in code review when an agent wrote the code.
The third row deserves more honesty than it usually gets. If usage is being tracked per person, say so and say why. Team buy-in AI tools conversations die quietly the moment people suspect the dashboard exists and nobody will confirm it.
When is resistance the correct response?
When the constraint the tool addresses is not the constraint the team has. That happens often enough to be worth checking before treating disagreement as obstruction.
Two cases are genuinely reasonable. The first is a team where review is already the bottleneck: pull requests sit for days, and a faster source of pull requests makes the queue longer rather than the team faster. Google's own engineering guidance treats review speed as a first-order concern for exactly this reason — a slow review loop degrades everything downstream of it, and adding volume to a slow loop is not an improvement.
The second is work whose requirement is discovered by building it. Research, prototypes, anything where the specification is the output rather than the input. An engineer saying "I cannot write the item until I have tried three things" is describing their work accurately, not resisting.
Engineers refuse to use AI is a headline. Engineers declining to use a tool on work it does not suit is ordinary judgement, and a rollout that cannot tell those apart will spend its credibility arguing with the second.
What changes a mind, and what hardens one?
One thing changes minds reliably: a person running their own item through and reading what comes back. Everything else is argument.
That works because the result is not about the tool, and because trust in a claim somebody tested themselves is a different quantity from trust in a claim they were told. An item that comes back wrong is a measurement of the item, and it is the author's own, so there is no one to disagree with. An item that comes back right removes the abstract objection without anyone having to concede anything. It takes twenty minutes and it is the cheapest thing on this list.
What hardens a position, in rough order of damage:
- Mandating use. Converts a technical disagreement into a question of authority, which is a fight you win at a cost you keep paying.
- Measuring individuals. A per-person usage number makes the tool an assessment instrument, and people manage assessment instruments rather than use tools.
- Dismissing the review cost. The load is real and arithmetical. Telling someone it is not makes every later claim suspect.
- Shipping the enthusiasm before the plumbing. A rollout whose test suite does not run produces work nobody can accept, and the first month of that is what people remember.
The honest framing for a rollout is narrow. A coding agent connected over MCP reaches In Review and no tool takes it further, so what a team is being asked to absorb is specification work up front and judgement at the end. Laimonade exists for the first of those and checks the second against criteria written in advance — which is a claim about where the work moves, not about how much of it disappears. What that looks like for whoever holds the team is in Laimonade for engineering leaders, and where a rollout puts it in the calendar is in coding agent rollout.
Resistance that arrives in month two rather than week one is usually a different animal, and the reasons are in why agent adoption stalls after the first month.
Frequently asked questions
Should agent use be mandatory?
No, and mandates are expensive in a specific way: they remove the information you would otherwise get. A team that can decline tells you which work the tool does not suit, which is exactly what a rollout needs to learn. Make it available, make the expectation about outcomes rather than tool use, and watch where it is picked up voluntarily.
What if a senior engineer refuses outright?
Find out what they are refusing. Senior engineers are usually the ones carrying the review load and the codebase knowledge, so their objection is often the review-capacity one stated in stronger terms. If the objection survives a twenty-minute test on their own item, it is probably about your work rather than about tools, and worth listening to.
Does resistance predict a failed rollout?
Not on its own, and its absence is not a good sign either. A team with no scepticism is a team where nobody has looked closely enough to have an objection. What predicts failure is resistance nobody can name — a general reluctance with no specific complaint attached, which usually means the real problem has not surfaced yet.
Is this just change management engineering teams already know?
Partly, and the difference is worth naming. Ordinary change management assumes the new tool does the same work differently. Here the work moves: less typing, more specifying and judging. That is a change in what the job consists of, not in how a task is performed, and it deserves to be discussed as one.