Debt implies someone knowingly borrowed and can repay it later. What an agent produces at volume is code nobody can explain, and that needs a name attached to it, not a refactor sprint.
By JP LeBlanc
Debt is the wrong word, and the wrong word is steering companies toward the wrong fix. Debt implies somebody knowingly took a shortcut, wrote it down, and can choose to pay it back when the time is right. What an agent produces at volume looks nothing like that. It's code that passed every check, does what it was asked to do, and has no person behind it who remembers why it's written that way. That isn't a loan. It's an orphan. The fix for a loan is a repayment plan. The fix for an orphan is a name.
For most of the last thirty years, the expensive part of a codebase wasn't the code itself. It was that when something broke at two in the morning, a person existed who could look at the offending file and say, out loud, "we did it that way because the vendor rate-limits at 200 requests a second and this was the workaround." That person was the actual asset. The code was just where their judgment happened to be stored.
Technical debt, as a metaphor, describes a specific and different failure: a person who's still around, still knows the tradeoff, and chose speed over cleanliness on purpose, with every intention of coming back to it. Ward Cunningham picked a good name for that. It tracks, it prioritizes, it gets paid down when the interest gets too high. What it was never built to describe is a codebase where the person who could explain a decision was never a person in the first place.
Agent volume doesn't accelerate technical debt. It removes the thing debt always assumed was there: somebody who knows why.
Code quality, on average, holds up fine under agent volume. Tests pass. Lint is clean. Almost nobody's complaint is that the diffs are sloppy, because usually they aren't. What breaks is the second half of a sentence every senior engineer used to finish without thinking: "ask so-and-so, they wrote that." There's no so-and-so. There's a prompt history in a tool three other people don't have access to, or there isn't even that.
On-call has always run on one rule: the people who built it carry it. That rule quietly assumes a builder who can be paged. An agent can't be. Something has to sit in that slot anyway, and if nothing does, you've reproduced the one failure every reliability practice on this site exists to prevent, just with a different cause. Ownership is the atomic unit of a working system, and an atomic unit with nothing in it is still missing, whether the gap was created by attrition or by a merge nobody attributed to anyone.
The usual first instinct is better documentation. Richer commit messages, a paragraph of context on every PR, maybe a required "why" field in the template. Not a bad idea, and I'd still tell a team to do it. But it doesn't touch the actual problem, because documentation decays exactly the way any other artifact does once nobody's job depends on keeping it current. A comment explaining a decision is only as good as the incentive to update it, and "incentive to update it" turns out to just be ownership, wearing a different hat.
I watched this get solved for real at CircleCI, where agents merged to main without human approval, ramped through 2025. Dependency bumps went first. Then docs. Then front-end code. Test changes were a target the whole way through rather than a stage. Schema changes went dead last, because a green build proves the least there. We had a dropped index reach production that year, human-authored and human-reviewed, and nothing in CI saw it, because a missing index doesn't matter at test-data volume and matters enormously at production volume.
The part that matters for this argument is who decided the order. It wasn't a governance committee stood up to arbitrate blast radius. It sat with the principal and senior staff engineers who already owned that piece of the platform, the same people who'd have owned a human's change to the same code. The org chart already had an answer for who owns what. Agent-authored code just had to be routed into it instead of around it.
Read the order that way and it stops looking like caution. Schema sitting last doesn't mean the tool isn't trusted yet. It means the people who own that surface know exactly where a green build lies to them.
The mechanism, stripped down, is this. Before an agent's change reaches main, it belongs to a tier, and the tier maps to an owner who already existed, because the owner is whoever's on call for that surface. Not a new role. Not a review board. The rota you already run. If a change doesn't have an owner it can be tiered into, that's the actual defect, and the fix is closer to boring, deliberately chosen infrastructure than to an incident review: don't ration by how novel the tooling feels, ration by whether you can name a person accountable for the result. That question was always the right filter. Agents just made it impossible to skip.
Treat an unowned merge as unmergeable, full stop, regardless of who or what authored it. That single rule does more than any amount of retrospective cleanup, because it stops the orphan from being created in the first place.
Unowned code doesn't announce itself. It sits there passing its tests, looking exactly like everything else in the repository, until the day it breaks in a way nobody anticipated and the team spends an afternoon reconstructing intent from git blame and a Slack search that turns up nothing. That reconstruction is more expensive than any technical debt sprint ever was, because debt at least tells you where to look.
Debt you can decide not to pay yet. An orphan just waits for someone to inherit it, usually at the worst possible hour, with no idea what it was for.