Konstantin Semenenko
July 17, 2026
4
minutes read
More AI automation is not always more productivity. A 2025 controlled study found experienced developers about 19% slower using AI on codebases they knew well, even though they felt faster. Over-automation adds hidden costs: reviewing plausible-but-wrong output, context-switching between agents, and cleanup of code that looked done and wasn't. AI helps most on unfamiliar boilerplate and can be a net drag on complex work an expert already understands. Automate selectively and measure real outcomes (cost per accepted result), not generation speed.
Over-automation, pushing AI into work where it does not actually help, can make a team slower, not faster, and the evidence is more concrete than most people expect. A 2025 randomized controlled trial (METR) found experienced developers were roughly 19% slower when using AI on codebases they knew well, and, tellingly, they believed they were faster. That gap between felt speed and real speed is the whole problem: AI generates output quickly, which feels like progress, while the review, correction, and cleanup it creates quietly costs more than it saved. AI genuinely helps on some work (unfamiliar boilerplate, scaffolding, repetitive translation) and genuinely hurts on other work (complex code an expert already holds in their head). The mistake is automating everything and measuring the generation speed instead of the real outcome. This explains where over-automation costs you and how to avoid it.
We measure AI on cost per accepted result rather than raw output, so this is a practitioner's view of when automation turns negative and how to keep it positive.
The METR result is worth sitting with because it inverts the intuition. In a controlled trial, experienced open-source developers working on repositories they knew well completed tasks about 19% slower with AI assistance than without, and their self-estimates went the other way, they thought AI had sped them up. Both halves matter. The slowdown shows automation is not free even when it produces working code; the misperception shows why teams over-automate anyway, it feels productive, so nobody questions it.
The mechanism is straightforward once named. On familiar code, an expert already knows what to write, so the bottleneck was never typing, it was thinking, and AI does not remove that. What AI adds is a new step: read the generated output, verify it is correct, correct it where it is not, and integrate it. On unfamiliar boilerplate that step is cheap relative to the time saved. On complex, familiar code it can cost more than just writing the thing directly, because verifying someone else's plausible-looking solution to a problem you already understand is slower than solving it yourself. Automation helps when generation-plus-verification is faster than doing it directly, and hurts when it is not, and teams that automate by default stop checking which case they are in.
Over-automation's costs are real but invisible on a generation-speed dashboard, which is exactly why they accumulate. The main ones:
None of these show up if you measure "how fast did the AI generate code." All of them show up in how long the work actually took to reach a state you trust. That measurement gap is where over-automation hides.
The instinct that more automation is always better comes from domains where automation is deterministic, a script that runs is pure gain. AI automation is different, because its output is probabilistic and needs verification, so each automated step carries a verification cost that has to be weighed against the time it saves. When the verification cost is low (unfamiliar, routine, easily checked work), automate freely. When it is high (complex, familiar, hard-to-verify, high-stakes work), automation can cost more than it saves, and the right move is to do it directly or keep a human firmly in the loop.
This is the same calibration senior engineers apply instinctively, covered in why senior engineers don't automate everything: automate where verification is cheap, stay hands-on where it is not. "Automate everything" ignores the verification cost entirely, which is why it produces the felt-faster-actually-slower result. The goal is not maximum automation, it is optimal automation, the amount that actually reduces total time to a trusted result, and past that point every additional automated step is net negative.
Keeping AI on the productive side of the line is a measurement-and-selection discipline:
Do this and AI stays a genuine accelerator on the work it suits. Skip it and you get the worst outcome: a team that feels more productive, costs more, and ships no faster.
Over-automation makes teams slower, not faster, when AI is pushed into work where verifying its output costs more than the time it saves, a 2025 trial found experienced developers 19% slower with AI on familiar code, while feeling faster. The hidden costs, verification, correction, context-switching, cleanup debt, and runaway loops, are invisible on a generation-speed dashboard and real in actual cycle time. "Automate everything" is the wrong default because AI output is probabilistic and carries a verification cost; the right default is optimal automation, aimed at work where checking is cheap, and measured on cost per accepted result rather than how productive it feels. More automation is not the goal; net-faster-to-a-trusted-result is.
If you want AI deployed where it actually speeds you up, measured on real outcomes rather than generation speed, that is where our AI Dev Team work starts.
Can AI make developers slower? Yes. A 2025 randomized controlled trial (METR) found experienced developers about 19% slower using AI on codebases they knew well, largely because reviewing and correcting AI output cost more than writing the familiar code directly. Notably, the developers felt faster even as they were slower.
Why does AI sometimes reduce productivity? Because its output is probabilistic and must be verified. On unfamiliar or routine work, verification is cheap relative to time saved, so AI helps. On complex, familiar work, verifying a plausible-but-possibly-wrong solution can take longer than solving it directly, so automation becomes a net drag.
What are the hidden costs of AI automation? Reviewing and correcting plausible-but-wrong output, context-switching from managing AI agents, cleanup debt when code that looked done wasn't, and runaway loops in agentic setups. None appear on a generation-speed dashboard, but all show up in the real time to reach a trusted, shipped result.
How do I know if I'm over-automating with AI? Measure cost per accepted result and cycle time to a shipped result, not how fast AI generates drafts. If the team feels faster but cycle times haven't improved, that is the felt-faster-actually-slower gap, a sign AI is being applied where its verification cost outweighs its benefit.
Should I automate everything with AI? No. Automate work where verifying the output is cheap (boilerplate, unfamiliar scaffolding, repetitive tasks) and be selective on complex, familiar, or high-stakes work where verification is expensive. The goal is optimal automation that reduces total time to a trusted result, not maximum automation.
