The demo is always the same. Someone describes a feature, a model produces a working implementation in a couple of minutes, and the room nods. The number that goes on the slide is the generation time: five minutes for something that used to take an afternoon. It is a real number, and it is the wrong one to plan around.
We have spent the last two years putting AI-assisted coding into real production work, described in our piece on why we stopped fighting vibe coding. The single most consistent thing we have learned is that the generation time is not the cost. The cost is everything that happens after the code appears: reading it, distrusting it, finding the part that is subtly wrong, and proving the rest is right. That is the debugging tax, and almost nobody puts it on the slide.
Generation got cheap, so the price of software moved. It now sits almost entirely in verification, and verification is the part that did not get faster.
The number that doesn't go on the slide
The industry data has caught up with what teams feel daily. Surveys through 2026 put AI coding adoption past 80 percent of developers, and a large majority report genuine productivity gains. The same surveys carry an uncomfortable companion figure: a similar majority report spending additional time debugging and correcting AI-generated code, and independent analyses have found measurably more security defects in AI-assisted code than in code written by hand. Both things are true at once. The output is faster and the cleanup is larger.
Treat those figures as directional rather than precise; the methodologies vary and the models move monthly. The direction is what matters. Faster generation does not imply faster delivery, because delivery includes the part where a human takes responsibility for correctness. When you only measure the generation, you book a productivity gain that the debugging column quietly spends back.
Why AI bugs are more expensive
A bug from a model is not the same animal as a bug from a tired engineer, and it costs more to catch for three specific reasons.
The first is fluency. AI-generated code reads beautifully. Variable names are sensible, structure is conventional, comments are present. A hand-written draft with a flaw usually looks like a draft with a flaw; you read it with your guard up. Generated code looks finished, and finished-looking code gets a softer review. The defect hides behind the polish.
The second is plausible wrongness. The failures are rarely loud crashes. They are an off-by-one in a boundary condition, a silently swallowed error, an assumption about input that holds in the happy path and breaks on the edge. These are exactly the defects that pass a quick read and a green test suite and surface in production a month later, which is the most expensive place to find them.
The third is missing intent. When an engineer writes code, they hold the why in their head, and that context makes the bug findable. Generated code arrives without that mental model. The reviewer has to reconstruct the intent before they can judge the implementation, and reconstruction is slow.
Where the tax is highest
The debugging tax is not uniform. It is close to zero on some work and ruinous on other work, and the whole game is knowing which is which before you delegate.
It is low on code whose correctness is cheap to verify: scaffolding, boilerplate, a data transformation with a clear before-and-after, tests for behaviour you can state precisely, a function with obvious inputs and outputs. Here the model saves real time, because the check is fast and the cost of a miss is small.
It is high wherever verification is expensive: concurrency and shared state, anything touching money or auth, security-sensitive logic, code that integrates with a system the model cannot see, and novel business logic where there is no reference implementation to compare against. On this work the verification cost can meet or exceed the cost of writing it yourself, and the productivity gain inverts. This is not a failure of the tool. It is a mismatch between the task and the tool, and recognising it is a senior skill.
How we keep the tax small
We have not found a way to abolish the debugging tax. We have found ways to keep it from eating the gain. Four practices do most of the work.
Delegate by verifiability, not by difficulty. The instinct is to hand the model the hard, tedious parts. The better filter is to hand it the parts whose output you can check quickly and cheaply. Tedious-but-verifiable is the sweet spot; hard-and-unverifiable is the trap.
Make tests the contract, not an afterthought. The fastest way to verify generated code is against tests that encode the behaviour you actually want. We often write or specify the tests first and let the model implement against them, which turns a vague review into a concrete pass-or-fail.
Review generated code like a stranger wrote it, because effectively one did. The reviewer reconstructs intent, hunts the edge case, and assumes the confident tone is hiding something. This is more tiring than reviewing a colleague, and we treat review capacity as the scarce resource it has become, a point we make in what an AI-native team actually looks like.
Keep a human who understands the whole. The debugging tax explodes when nobody on the team holds the full mental model and everyone is reviewing fragments. One person owning the architecture keeps the generated pieces accountable to a coherent design rather than a pile of locally-plausible parts.
The honest accounting
None of this is an argument against AI-assisted coding. We use it every day and we are not giving it back. It is an argument against the accounting that books the generation time as the saving and ignores the verification bill. The teams that get burned are the ones who believed the five-minute number and staffed, scheduled, and promised against it.
The teams that win treat generation as the cheap, abundant part and verification as the expensive, scarce part, and they organise around the scarce part. They delegate where the check is cheap, they invest in tests and review, and they keep someone responsible for the whole. Their output genuinely went up. They just did the maths on the whole equation, not the half that fits on a slide.