Your AI coding agent doubled output, and now your bug count is climbing. The usual conclusion is that AI writes worse code. Engineering leader Iouri Khramtsov argues the opposite: blind merging of AI-generated PRs exposes a quality process that was always thin, and a layered defense can hold bugs steady or even reduce them while output roughly doubles. If code review was your only real checkpoint, AI just made that obvious.

The fix looks less like new tooling and more like stacking defenses at each stage. AI reviewing requirements for gaps and edge cases before a line is written. Test cases defined from requirements, then implementation, then coverage above 95%. Manual testing that no agent replaces. Here is how those layers fit together, and what each one actually catches.

More code, more bugs: the complaint that blames the wrong thing

The objection comes up in every engineering review: “Sure, AI helps you output more code, but won’t the quality suffer?” Khramtsov’s answer is blunt. It will, if you blindly merge the PRs and send them off to prod. That is a process choice, not a property of the technology.

Run it the other way, with defenses stacked at each stage, and the numbers move in your favor. Khramtsov reports keeping bug counts stable or actually reducing them while output climbs. The volume went up. The defect rate did not.

So the honest diagnosis is uncomfortable. Most teams had one functioning checkpoint, a human reading a diff, and it worked because throughput was low enough to hide the gap. Double the volume and that single reviewer becomes the bottleneck and the blind spot at once.

The layered defense model: catch defects before, during, and after generation

Three checkpoints, placed at different moments in the work. Requirements review before anything gets written. Unit tests at above 95% coverage during implementation. A human actually clicking through the feature after. Each one catches a defect class the others structurally cannot see.

Which layers are old practice made affordable, and which are genuinely new

Most of this stack predates coding agents entirely. Khramtsov is direct about it: many of these defensive layers are “pretty much the same as before Claude/Copilot/Codex/etc.” Test-driven development, spec reviews, manual QA. Nobody invented these in 2025.

What changed is cost. Writing tests to near-universal coverage used to be a budget conversation. Now the agent writes them, and Khramtsov’s position is that there is “no excuse not to shoot for near-universal coverage.” The genuinely new layer is having AI audit the requirements or tech design for gaps and edge cases before development starts. That step had no affordable equivalent before.

Why one strong review step fails the moment throughput doubles

If code review was your only real gate, it worked because volume was low enough for a human to hold the whole change in their head. Double the output and that gate becomes a queue. Reviewers skim. Approval turns into a formality.

Layering fixes this by splitting the load across stages that scale differently. Requirements review runs before code exists, so it never queues behind a backlog. Automated coverage scales with the agent. Manual testing stays human, but it only has to catch what survived two prior filters. No single layer survives 2x throughput. Three overlapping ones do.

Layer 1: have the AI attack your requirements before anyone writes code

This is the layer Khramtsov found most surprising, and it is the cheapest one to add. Before writing anything, hand the requirements or tech design to the agent and tell it to hunt for gaps, edge cases, and unexpected interactions with the existing codebase. Bugs in freshly written code dropped sharply once he did this. Not every teammate saw the same drop, which tells you the step needs discipline, not just access to a model.

The prize is measured in rework. Teams routinely burned up to a third of total feature effort on post-development “polishing,” meaning finding and fixing defects that should never have existed. Some of those bugs escaped anyway and landed in production.

The three defect sources spec review eliminates: missed edge cases, fatigue, and incomplete PM thinking

Those polishing bugs trace back to three causes. Nobody foresaw a particular interaction or edge case. The developer was tired that day and did not put in enough thought. Or the designer or PM never worked through a scenario in the first place.

All three are human attention problems, and all three are exactly what a machine handles well. The AI does not get tired, and when prompted properly it will not give up hunting for issues halfway through the list.

Reviewing the reviewer: filtering out invented problems from an overzealous agent

The failure mode runs the other direction. Khramtsov notes the agent can be overzealous, inventing problems that are not actually there.

So a human reviews every proposed edit to the requirements before it becomes scope. Treat the output as a list of candidates, not a verdict. Cheap to check, expensive to skip.

Layers 2 and 3: near-total test coverage plus a human who actually uses the feature

Test cases before implementation: the sequence that stops agents validating their own bugs

Coding agents make test-driven development trivial, which is exactly why teams get it wrong. Point an agent at finished code and ask for tests, and it will write tests that pass against whatever logic is sitting there, including the broken logic. The tests go green. The bug ships.

Khramtsov describes the order that works: have the agent reason through test scenarios and cases from the requirements, write the test cases, write the implementation, run the implementation against those cases and fix what breaks, then backfill remaining coverage gaps with the requirements still in hand. The requirements are the anchor at both ends. Skip that and you are measuring the code against itself.

Above 95% coverage stops being an aspiration once the agent is doing the typing. There is, in his words, “no excuse not to shoot for near-universal coverage or to wait on backfilling any missing unit tests.” The old objection was cost. That objection is gone.

What manual testing catches that 95% coverage never will

Coverage tells you which lines executed. It says nothing about whether the feature makes sense to the person using it. A workflow can be fully covered and still take six clicks where two would do, or surface an error message nobody can act on.

So Layer 3 stays human. You, QA, or the PM actually opens the thing and uses it the way a real operator would. It takes minutes and it catches the defect class that requirements review and unit tests are structurally blind to.

Where this breaks: the failure modes that put bugs back in production

Three ways this stack fails in practice. Coverage becomes a number people chase instead of a signal, and you end up with 96% coverage over tests that assert nothing meaningful. The agent invents requirement problems that were never there, which is why Khramtsov warns it “can sometimes be overzealous” and says he reviews its proposed edits carefully. And teams bolt on the layers while keeping the blind-merge habit intact, so the defenses exist on paper and nobody enforces them at the gate.

Then there is cost. All three layers front-load effort into requirements and test design, work that used to happen later or not at all. You are trading that against the polishing phase, the stretch after development where bugs get discovered and fixed. If your team never tracked how much of a feature’s total effort went into polishing, you will feel the new cost and miss the saving entirely.

Why the same process produces different results across developers on one team

Khramtsov saw the bug drop in his own code and in some, but not all, of his teammates. Same process, same tools, different outcomes. The people who got the result treated the requirements review as real work: reading the agent’s findings, arguing with them, rejecting the invented ones. The people who did not treat it as a formality and pasted the output through.

That variance is a management problem, not a tooling problem, and it will not resolve itself with a better model. Make the review artifact visible in the PR. Ask which edge cases the agent flagged and what the developer decided about each one. Inconsistent adoption is measurable the moment you require evidence of the step rather than its completion.

Designing quality systems for a workflow that produces twice as much

The lesson generalises past software. Any process where AI multiplies output moves its bottleneck from production to verification. Inspection reports, CAPA drafts, supplier assessments, work instructions, deviation write-ups: the drafting cost collapses, the checking cost does not. One reviewer who was already at capacity now faces double the volume, and that single checkpoint becomes the defect.

Mapping the layered model onto non-engineering AI workflows

The three placements transfer directly. Before generation, have the model interrogate the input for gaps, the same move Khramtsov used on requirements. A CAPA scope, a supplier questionnaire, an inspection protocol: ask what is missing, ambiguous, or contradicted elsewhere before anything gets drafted.

During generation, build the equivalent of test cases. Define the acceptance criteria for a compliant document first, then generate against them, then check the output against those criteria. After generation, keep a human in the loop who actually uses the artefact, not one who skims it. Khramtsov is clear there is “no substitute for a human actually trying out the feature.”

The audit question: where does your process still rely on a single reviewer?

The ROI sits in two places. First, the rework tax. Khramtsov’s teams spent up to a third of total feature effort on post-development polishing, bug discovery and fixing, much of it caused by requirement gaps nobody caught early. Front-loading that review removes most of it. Second, defect volume holds flat or falls while throughput roughly doubles.

Pick your highest-volume AI-assisted process and trace it. Count the human checkpoints. If there is exactly one, and it sits at the end, you have a review queue, not a quality system. Add the pre-generation gap check first. It costs a prompt and catches the defects that are most expensive later.

Source: i-kh.net