Engineers using AI tools now ship around ten pull requests a week, each larger in scope than before. The demo looks incredible. The bug tracker three months later tells a different story.
A recent Forbes piece named the tension precisely, faster code, harder debugging. It is the most honest description of AI productivity I have read this year, because it refuses to stop counting at the part that looks good.
The Cost Did Not Disappear, It Moved
AI-generated code is excellent at the common case. It has seen a million examples of the standard pattern, so it reproduces the standard pattern well. That is genuine value and I use it every day.
The trouble starts at the edges. Edge cases, security-sensitive logic, and system-level context do not follow the patterns in the training data. That is exactly where generated code gets thin, and exactly where production breaks.
Then comes the second-order cost. When code you did not write breaks, you debug it without the mental model you would have built by writing it yourself. Root-cause analysis takes longer, precisely when the pressure is highest.
So the velocity is real and the debugging tax is also real. The mistake is celebrating the first number and never booking the second. Ten pull requests a week is a throughput metric, not an outcome.
Put a number on it to feel the trap. If AI helps a team ship twice the code but each production incident in generated code takes forty percent longer to resolve, the net gain depends entirely on your defect rate. Ship enough unreviewed volume and the debugging line eats the velocity you were proud of. The math only balances if you count both sides.
The security dimension deserves its own flag. Generated code is confident on the happy path and quietly weak on the security-sensitive logic that never appears cleanly in training data. That is not a bug you catch in a demo. It is the kind you meet in an incident report, which is the most expensive place to meet anything.
This Is a Systems Problem, Not a Coding Problem
The pattern generalizes far past engineering. Any function where AI compresses the doing while leaving the understanding to a human inherits this shape. Fast to produce, slow to unpick when it goes wrong.
I see it in marketing already. AI drafts fifty ad variants in a minute, then someone spends a day working out why the account is underperforming across creative nobody consciously chose. The generation was cheap, the diagnosis was not.
The Forbes argument is that better results come from investing in the planning and specification phase, defining edge cases and non-obvious requirements before the AI generates anything. That maps onto a point I made in evals are the new product spec. The thinking moves upstream, to the brief, because the model will faithfully build whatever ambiguity you hand it.
There is a scaling trap hiding here too. As your user base grows, more edge cases surface in production, which multiplies exactly the debugging sessions that are already the expensive part. The cost curve bends the wrong way at the worst time.
How to Actually Capture the Gain
First, measure the full cycle, not the fast half. Pull request count and cycle time flatter AI adoption. Track time-to-resolution on production issues and the share of incidents in AI-generated code, because that is where the hidden cost lives.
Second, spend the time you saved on specification. If AI removed an hour of typing, put twenty minutes of it into defining the edge cases and constraints up front. That is not bureaucracy, it is the highest-value work left for a human.
Third, decide deliberately where human expertise applies. The teams getting durable gains are not the ones generating the most code, they are the ones who chose which parts a person must still own. Intercom did a version of this well, which I covered in how Intercom doubled engineering output, and the lesson was process design, not raw generation.
Keep a human close to the security-sensitive and system-level parts specifically. That is where generated code is weakest and where a mistake costs the most, so it is the last place to remove the person who understands the whole picture. Speed at the edges is exactly the speed you cannot afford.
The teams handling this well treat AI output like a contribution from a fast, junior, tireless colleague who never remembers context. You would review that person work carefully, especially at the edges. The error is treating the same output as if a senior engineer stood behind every line.
The wrong conclusion is to slow down or avoid AI. The output gains are real and they compound. The right conclusion is to stop pretending the work vanished when it only changed shape.
Speed you cannot debug is not productivity, it is deferred cost with a nicer dashboard. Book the whole ledger, then the gain is yours to keep.