Agent debt: when generation outpaces review

Every team we talk to describes the same sequence. An AI coding agent starts handling routine work, then a growing share of it, then most of it. Pull requests get bigger and arrive faster. Review, done the way it was done a year ago, one engineer reading a diff line by line, cannot keep up, so it becomes smaller without anyone saying so. Nobody decided that reviews would get shallower. It happened because the volume grew past what a person can read carefully in the time available, and the alternative to shallow review looked like slowing the team down.

That gap, between how fast code is generated and how fast anything actually checks it, is what a 2026 New Relic survey of 200 US technology decision-makers at mid-market and enterprise companies calls agent debt: the fast build-up of unchecked logic that a team takes on without noticing, while agent-generated code looks fine at review time [1].

What the data shows

The pattern in that survey is specific enough to be useful. Ninety-four percent of leaders rated AI-generated code as higher quality than human-written code at the point of review. At the same time, seventy-eight percent reported that AI-generated code has increased production incidents after deployment [1]. Those two numbers describe the same code at two different moments, and the gap between them is agent debt.

The scale makes the gap matter more each quarter. Sixty-seven percent of technology leaders said AI generates or significantly refactors more than half of their weekly code output [1]. Eighty-two percent had at least one production failure tied to AI-generated code in the prior six months, seventy-four percent said at least a quarter of AI-produced code needs significant rework, and eighty-six percent reported more senior engineering time going into fixing it after the fact [1]. Only nineteen percent reported no AI-related code challenges at all.

Put together: most teams now produce most of their new code with an agent, that code looks better than human-written code at review time, and it is producing more incidents anyway. The two results fit together. An agent's output tends to be syntactically clean, consistently styled, and locally sensible, which is exactly what a fast read at review time notices. What a fast read does not catch is whether the change fits the system it was added to, whether it handles the input nobody tested, or whether it duplicates, without notice, logic that already existed three files away. Those are structural properties, and they appear in production rather than in a diff.

Why review, done the old way, cannot remove this gap

The instinct when incidents rise is to ask for more careful review. That instinct assumes review capacity is the constraint, and for a team generating a small fraction of its code with AI, it might be. It stops being the constraint once generation volume passes what a person can read as carefully as they used to read a tenth as much code.

This is the same problem covered on the verification gap in AI coding: AI made writing code cheap and left checking it exactly as expensive as it always was. Agent debt is what that gap looks like once it has been growing for a few quarters instead of a few weeks. It is a structural mismatch between two rates, generation and verification, and a short burst of extra review cannot clear it. Asking people to read faster does not change the rate at which either one grows.

What actually removes the gap

Slowing generation down and adding more human reviewers both leave the ratio the same. The fix is making verification a function of the system rather than of a person's reading speed, which is the entire argument for an eval suite covered across this guide: a check derived from the specification, run automatically on every change, catches the property a fast human read misses, at a speed that scales with generation instead of competing with it.

Concretely, the checks this guide describes are the only way the ratio between generation and verification stays manageable once an agent is producing most of the code. A team with negative-case coverage, checks for the inputs that get refused or handled as errors, catches the almost-right-but-not-quite failures that a quick review reads as fine. A team with evals running in CI catches a regression the moment it is introduced, rather than six months later when it reaches production and somebody has to reconstruct which of several hundred AI-generated commits caused it.

The teams in the survey reporting no AI-related challenges are, by the logic of the data, the ones whose verification kept up with their generation, whatever amount of code they generate with AI. That is a design choice about the pipeline, and hiring more careful reviewers does not achieve it.

How agent debt accumulates without a single bad decision

The pattern is worth walking through in order, because at no single point does anyone choose to lower the bar. A team adopts a coding agent for a narrow, low-risk task: generating boilerplate, writing a first draft of a data migration script, filling in a repetitive pattern across many files. Review of that first batch is thorough, because the team does not yet trust the tool and reads every line.

The code is fine. It usually is, for narrow, low-risk tasks. Trust rises, appropriately. The scope of what the agent is asked to do widens, and the volume of generated code rises with it. Review effort per pull request does not rise to match, because nobody scheduled more reviewer time, and the code still reads as competent, so the shorter review still feels adequate. This continues for months. Each individual review decision, taken on its own, looks reasonable: the diff in front of the reviewer today looks fine, in isolation, the same way every diff before it did.

What nobody sees is the aggregate: the total amount of unverified logic sitting in production has grown steadily the entire time, and it grew exactly as fast as trust grew, which is to say faster than review depth did. The first sign is usually not a single dramatic incident. It is a slow rise in the background rate of confusing, hard-to-reproduce bugs that nobody can pin to a specific change, because by the time the bug surfaces, dozens of AI-assisted pull requests have merged on top of the one that caused it.

Why this differs from a team simply moving too fast

It is tempting to describe agent debt as a speed problem, solvable by asking the team to slow its release cadence. The New Relic data argues against that framing directly: the problem is not the speed of releases, it is the mismatch between two speeds, generation and verification, that used to move together and now do not. A team that halves its release frequency while still reviewing at the same shallow depth relative to volume has not closed the gap. It has only made the gap show up less often, which delays the reckoning without preventing it.

Compare that to a team whose code volume has not changed but whose review has become genuinely shallow due to headcount pressure or turnover. That is an old, familiar problem with a known fix: hire, or slow down, or both. Agent debt is a newer variant where the volume side of the equation moved on its own, driven by tooling rather than by headcount, and the review side stayed anchored to a headcount-based capacity that no longer matches what is being asked of it.

What this looks like inside a specific incident

Consider a concrete shape the New Relic pattern takes in practice. An agent is asked to add a new field to a customer record and update every place that record is serialized. It does this correctly in the fourteen places a grep finds, and also, without being asked, adjusts a caching layer that had been silently relying on the old record shape, because the agent noticed the cache would otherwise return stale data and judged the fix to be in scope. The change to the cache is reasonable on its own terms and was never in the original request. A reviewer scanning the diff for the field addition, which is what the pull request title says it is about, is unlikely to give the cache change the same scrutiny as the change they were expecting to review, because it arrived disguised as a side effect of a task that looked routine.

Three months later the cache begins returning incorrect data for a small subset of customers under a load pattern nobody tested for, and the team spends a day tracing it back through dozens of merged changes before finding the one that touched the cache logic, buried inside a pull request titled for something else entirely. No single reviewer failed here in any way that would show up in a performance review. The system that was supposed to catch this, careful human reading of diffs, was never going to scale to catching an unrequested change buried inside a requested one, at the volume this team was merging.

Why an eval suite catches what review structurally cannot

An eval derived from the specification, run on every change regardless of what the pull request claims to be about, would have caught the cache regression the moment it was introduced, because the check does not care what the commit message says the change is for. It asserts that cached records match the current schema, and it either holds or it does not, on every single merge, without needing a human to correctly guess that this particular diff deserved extra attention. That is the structural advantage covered in evals in CI for coding agents: the check runs regardless of how the change is framed, disguised, or bundled, which is precisely the property a title-based review process cannot have.

If your team has reached the point where nobody can say with confidence what an incident's root change was, that is agent debt showing up as a symptom, and it is worth talking to us about removing the gap before the next one. Get in touch.