AI code without tech debt: your review has to change
When the agent writes 200 lines in 20 seconds, you can't read line by line anymore. Review has to move from reading to interrogating.
by
Classic line-by-line review was built for a world where code was expensive to produce; an agent writing 200 lines in 20 seconds breaks that model. AI code is convincing but hides subtle bugs — silent assumptions, swallowed edge cases, security holes, invented dependencies. Review has to shift from reading to interrogating: question assumptions, demand independent tests, check system fit, and verify maintainability.
There's a moment everyone who works with agents now knows: you type a sentence, hit enter, and 200 lines of code appear. They look good. They even run. And that's exactly where the problem starts.
Classic code review was built for a world where code was expensive to produce. A human wrote it slowly, another read it slowly. Both had context. That world is over. When production becomes nearly free, the entire bottleneck shifts to review — and the old model doesn't scale with it.
The problem: plausible isn't correct
AI code has a dangerous property: it's convincing. It follows conventions, uses sensible variable names, looks like it came from a senior. That lowers your guard at the exact moment you need it most.
The bugs aren't the obvious syntax errors of old. They're subtler:
- an assumption that holds in 95% of cases
- an edge case that gets swallowed silently
- a security hole that never shows up in the demo
- a dependency the agent invented or pulled in outdated
Reading line by line no longer helps — the volume is too high. You need a different procedure.
From reading to interrogating
I changed my review. Not "did I read every line?" but "can I distrust this code and convict it?". Four questions, in this order:
1. What did the agent assume?
Every generation makes silent assumptions. Ask them explicitly: which inputs does it treat as guaranteed? What happens on null, empty, negative, huge? The interesting bugs live in the assumptions, not the code.
2. Where's the test that proves it?
No test, no merge. But careful: don't let the same agent write the test in the same run — then it tests its own assumption against itself. Write the critical tests yourself, or in a separate step.
3. Does it fit the system — or just the file?
The agent sees the local slice. You see the architecture. Is it duplicating logic that already exists? Breaking a layer boundary? Introducing a third pattern for something that already has two?
4. Would I understand this in six months?
Maintainability isn't a luxury. If you only half-understand the code today, you won't understand it at all in a quarter — and the agent that wrote it remembers nothing.
Keep the speed, keep the discipline
This sounds like more work. It isn't — it's relocated work. You save the 80% of typing and invest part of it into a sharper review — the last 20% were always the real job anyway. On balance you're still dramatically faster. Just without the bill that arrives six months later.
That's exactly what I mean when I say: AI builds fast — I make sure it holds. Not by slowing the agent down. By interrogating it before its code reaches production.
Frequently asked questions
How do you review AI-generated code effectively?
Stop reading line by line — the volume is too high. Instead, interrogate the code with four questions in order: what did the agent silently assume (nulls, empty inputs, extremes); where is the test that proves it; does it fit the system architecture or just the local file; and would you still understand it in six months. The goal is to distrust the code and convict it.
Why is AI-generated code risky even when it looks correct?
Because plausible is not correct. AI code follows conventions, uses sensible variable names, and looks senior-written — which lowers your guard exactly when you need it. The bugs are subtle: an assumption that holds in 95 percent of cases, an edge case swallowed silently, a security hole that never shows in the demo, or a dependency the agent invented or pulled in outdated.
Should the AI write the tests for its own code?
Not in the same run. If the same agent writes code and tests together, it tests its own assumptions against itself and proves nothing. Write the critical tests yourself, or generate them in a separate step. The baseline rule stays: no test, no merge.
Does rigorous review cancel out the speed gains from AI coding?
No — the work is relocated, not added. You save roughly the 80 percent of effort that was typing and invest part of it into a sharper review. On balance you are still dramatically faster than before, but without the technical-debt bill that otherwise arrives six months later.