I came across a survey this week that made me laugh out loud, and then made me want to write a blog post, which is usually a sign it touched a nerve. Coleman Parkes asked 300 senior engineering leaders (on behalf of Undo, who make debugging tools, so bear that in mind) how AI coding agents are working out for them. 79% of them said the agents generate code significantly faster. And the same leaders said the release cycle is “no faster than before”.

Wooow! What gives?

The rest of the numbers explain it pretty well. Their teams spend on average 9.8 hours a week producing code and 16.9 hours debugging it. And 35% of the generated code reaches production before the team has fully understood it. Meanwhile, Stack Overflow’s 2026 developer survey says 73% of the developers who use AI coding tools use them every day, and BairesDev’s latest barometer has 42% of developers saying AI writes at least half of their code (up from 12% a year ago). So the code is pouring in, and the releases are coming out at the same speed. Can you see the problem here?

Typing Was Never the Bottleneck

Let me explain. If you’ve ever looked at where the time goes in an engineering team, writing the code was always the smaller part of the job. Understanding what the code should do, how it fits with what’s already there, reviewing it, testing it, debugging it at 2am when it does something nobody expected: that’s where the weeks go. Speed up the typing tenfold and you’ve sped up maybe a quarter of the work (any engineer who remembers Amdahl’s law from university is nodding right now). Worse, you’ve just poured a lot more code into the slow part of the pipeline, so the queue in front of review and debugging gets longer, not shorter.

And as such, every line of code is a liability before it’s an asset. More lines produced faster just means more liability, unless something on the other end of the pipe can absorb it.

What It Looks Like From Where I Sit

Don’t get me wrong, I’m not one of the sceptics here. I build Calendrz with Claude Code nowadays, most changes are written by the agent, and I wouldn’t go back. But I can tell you exactly where my time goes now: reviewing.

A recent example: a change to the API behind Calendrz’s AI scheduling assistant added a new field to the response for when the assistant starts a meeting poll. The field was declared, documented in the API contract, the tests were green… and nothing in the code actually set it. Neat, huh? It got caught in the second round of review. Another one, a few days later: an endpoint answered 401 instead of 403 when asked about the wrong profile, and since both the web app and the mobile apps read a 401 as “your session has ended”, it would sign people out. That one got caught when the iOS app started using the generated API client.

Neither of these would show up in a chart about “AI writes buggy code”. The code compiled, the tests passed, it looked perfectly reasonable. Greg Law, Undo’s CEO, describes it as code that’s “almost, but not quite right”, and to be honest I can’t think of a better description. That’s the expensive kind of bug, because it survives right up until a real user finds it.

So What Would I Do About It?

If I was sat in front of an engineering team on Monday morning wondering why all this AI hasn’t moved the release date, here’s what I’d look at:

• Measure the whole pipe. Lead time from idea to production and how often a release breaks something, never lines of code or the number of pull requests. The agents will win the latter every time, and it means nothing.
• Treat review as the constraint, because it is. Keep changes small, and budget reviewing time as real work rather than something squeezed in between meetings.
• Let machines check machines. In my case, a committed API contract with generated clients caught things that a human eye skimmed over. Contract tests, types, property tests, a second agent doing the review: the more the agent’s output gets checked automatically, the less your senior engineers become a very expensive linter.
• You merge it, you own it. If nobody on the team can explain what a change does, it doesn’t ship. That 35% figure should scare any CTO.
• Point the agents at understanding, not just at writing. The survey says about a third of teams only use agents for debugging and comprehension in the simple codebases, which is exactly backwards: the gnarly legacy code is where a tireless reader helps the most.

I suspect the teams that pull ahead over the next year or so will be the ones who rebuilt their review and verification around a simple fact: code is now cheap, and understanding it isn’t.

Moral of the story: the agent made the typing free. Nobody said anything about the thinking 😉