Ninety-four percent of leaders rate AI-generated code as higher quality than human-authored code at review, and yet 82% of them hit at least one production failure tied to that code 1. That gap is the whole story, and I think most teams read it exactly backwards. The reflex is to treat agent debt as a code-quality problem and answer it with stricter review or an AI reviewer bolted onto the diff. In my experience that is the wrong lever: review-time quality is decoupled from runtime reliability, so agent debt turns out to be a verification-placement problem. The fix is to move the trust boundary from review to runtime.
The review gate grades the wrong exam
A review gate measures one thing: whether a diff reads as correct to someone who cannot run it against production. On AI-generated code that measurement looks great. Leaders rate it higher quality than what their own engineers write, and 62% ship it without line-by-line manual verification 1. It is tempting to file that 62% under laxity, teams cutting corners, and conclude they should simply review harder.
Read it the other way. Sixty-two percent skipping verification is not carelessness so much as a revealed preference: teams already trust the review signal enough to act on it. The signal feels strong, the diff looks clean, so the manual pass seems redundant. The effort is there; it is aimed at a signal that has not earned it. The interesting question is not whether teams review enough. It is whether the thing review measures predicts the thing they actually care about, and the production numbers say it does not.
Why review-time quality doesn’t predict runtime reliability
A static diff exposes a bounded set of properties: readability, plausible structure, adherence to a style, whether the change compiles and passes the tests that exist. Those are real, and for human-written code they correlate reasonably well with how the code behaves, because a human author carries an implicit model of the running system into the diff. Agent-generated code breaks that correlation. The agent optimizes for a plausible-looking artifact, and plausibility is exactly the axis review scores.
What review cannot see is what production exercises: state that only accumulates under real traffic, load that changes timing, integration with services the diff never mentions, and behavior that drifts over time. Consider a concrete failure mode. An agent writes a cache-warming routine that passes review cleanly, reads well, has tests, and is structurally sound. It also assumes the downstream service returns results in insertion order, an invariant that holds in the test fixture and holds under light load and silently breaks under production concurrency. No amount of staring at that diff surfaces the defect, because the information that would expose it, the downstream service’s actual ordering guarantee under load, is not in the artifact being reviewed. You cannot inspect out of a diff a failure the diff does not contain.
The bill comes due at runtime
Here is the number that separates review-strictness from the outcome. Lightrun, polling a different population of 200 SREs and DevOps leaders, found that 43% of AI-generated code still needs manual debugging in production after passing QA or staging 2. That code cleared a gate, ran the tests, moved through staging, and broke anyway.
That reframes the whole debate. If the failures were confined to code that skipped review, the pro-review reading would win: apply the gate you were skipping. But the defect surfaces on the far side of a passing gate, which means the gate was never measuring the property that failed. And runtime is where verification actually costs. Confirming a single AI-suggested fix takes an average of three manual redeploy cycles, with 88% of companies needing two to three cycles just to establish that a fix works 2. Verification did not disappear when review waved the code through; it moved to production and got more expensive.
”Just review harder, or add an AI reviewer”
The strongest objection concedes none of this and points at the 62% figure. If most teams ship without line-by-line verification, then review is not saturated, it is under-applied. The production failures could just be the predictable result of lax review, and the honest inference is the trite one: people who skip careful review get burned, so review harder. The perception numbers seem to compound the point, since 94% rating and 82% failure are population-level percentages, not paired measurements of the same reviewed code, so on their own they do not prove decoupling. Stated at full strength, this is the reading that a careful skeptic should reach for first.
It loses to a single number. The 43% that still needs production debugging did so after passing QA or staging 2. That is the paired evidence the objection says is missing: code that demonstrably cleared a gate, on the very population where review was applied, still fails at runtime. A second static pass, whether a stricter human reviewer or an AI reviewer, re-measures the same decoupled signal over the same artifact. It cannot recover information the artifact does not carry. The failure mode is placement, not rigor, and more rigor at the wrong location buys a bounded, and often trivial, return.
Move the trust boundary from review to runtime
If review cannot certify runtime behavior, stop asking it to. The real gate is the place the failing behavior is observable: runtime. That means canaries that expose the change to real traffic before it owns all of it, observability that watches the integration points a diff never showed, and redeploy-and-verify loops treated as the certification step rather than a cost to minimize. Those three redeploy cycles are not waste to be optimized away; they are verification finally happening where the evidence lives.
New Relic supplies the mechanism under its own name. It calls the accumulation “agent debt,” the buildup of unvetted architectural logic that review praises for velocity 1. Take that definition at face value and the placement thesis is already inside it: the logic is unvetted even though people looked, because the surface they looked at, the diff, does not expose architectural and integration behavior. The debt is verification pointed at the wrong artifact.
Better models and better reviewers will keep arriving, and they are worth having. But neither closes a gap that lives in where you place the check rather than how hard you push it. Move the boundary to runtime, and the review you already trust can go back to doing the bounded thing it is actually good at.