The Hidden Debt in AI-Generated Code

A patch can take minutes to generate and leave years of maintenance behind it.

That does not make AI-generated code uniquely bad. Human-written code can leave the same mess. But if we measure the benefit of a coding agent only by how quickly it produces a patch, we stop counting before review, integration, and maintenance have happened.

There is public evidence that some issues introduced in AI-attributed commits persist. There is also a lot of scope for misreading that evidence. A static-analysis finding, a review comment, and an hour of engineering work are different things. Putting them into one comparison does not make them interchangeable.

What the large commit study actually counted

In Debt Behind the AI Boom, Yue Liu and colleagues analysed about 302,600 AI-attributed commits across 6,299 public GitHub repositories. Their 2026 arXiv preprint covers five coding assistants and changes to Python, JavaScript, and TypeScript source files. Attribution relied on repository and commit metadata, including signals identifying AI tools. [1]

For each analysed change, the researchers ran static analysis before and after it to identify newly introduced findings. They then tracked findings to a later repository snapshot. This is a study of code-level issues detected by a particular analysis pipeline, not a measurement of every kind of technical debt.

Two reported results are worth separating:

• 89.3% of the detected introduced issues were code smells. That is a share of findings, not a percentage of commits, and not a count of production failures.
• 22.7% of the tracked introduced issues remained at the latest snapshots examined. The lifecycle analysis reports 105,364 surviving findings out of 464,900 tracked findings. This includes more than code smells.

Those findings support a limited but useful conclusion: problems associated with these changes did not all disappear quickly after introduction. They do not tell us how much each problem cost, whether reviewers noticed it, or whether keeping it was an explicit tradeoff.

There are reasons to be cautious about the precision, too. Static analysis can produce false positives, and issue matching across revisions can make mistakes. The paper's manual validation found errors in both detection and lifecycle classification. An issue disappearing from a later snapshot also does not necessarily mean someone deliberately repaired it; the relevant code may have been removed or replaced.

I would not turn this study into a claim that AI code has a fixed multiple of the debt in human code. Its described analysis does not provide the matched human-commit baseline needed for that comparison. Its per-commit incidence figures also need clarification: the results overview reports issues in 9.1% of analysed commits, while the abstract and tool comparison say more than 15% for each assistant. I am not using either rate as a headline statistic.

The persistence result is a reason to inspect what remains in a codebase. It is not an invoice for the cost of AI.

The pull-request comparison is a different study

CodeRabbit's public report examined 470 open-source pull requests: 320 classified as AI-co-authored and 150 classified as human-only. Using its issue taxonomy, the vendor reported an average of 10.83 findings per AI-co-authored PR versus 6.45 per human-only PR, approximately 1.7 times as many. [2]

That is a much smaller, separate dataset. It should not be presented as another result from the 302,600-commit study.

The vendor also acknowledges an attribution limitation: it treated PRs without detected AI signals as human-authored, but could not guarantee that they were. And findings per PR do not by themselves control for the size or difficulty of a change. The result is useful evidence about the sampled PRs and the review system used, not a universal defect multiplier for AI.

Nor does a count of findings measure review time. A naming inconsistency and a broken transaction boundary can demand very different amounts of work. Time waiting in a review queue is different again. If a team wants to know whether its coding agents save engineering time overall, it needs to measure that directly.

A patch can pass while the design drifts

The harder problem is that some maintenance costs will not appear in a lint report.

Matteo Casserini and colleagues use the term "agentic entropy" for divergence between an agent's actions and architectural intent. Their CHI 2026 workshop position paper proposes making the agent's process more visible alongside the code diff. [3] This is a proposed framework, not a measured law that every AI change makes the next change worse.

Consider a hypothetical client library. The project already has a shared retry policy. Asked to make one operation more resilient, an agent adds a second retry loop inside that operation. The tests cover successful responses and a transient failure, so the patch passes.

The maintenance question is now broader than whether the new loop works. Can the two retry policies run together? Which one owns the timeout budget? What happens when someone changes the shared policy next month?

This example is illustrative, not an account of a Microsoft system. It is also a mistake a human developer could make. Faster generation changes how many such decisions a reviewer may need to examine; it does not change the need to examine them.

A reviewer can spot that conflict in a diff if they know the design. An automated rule can catch it if the relevant constraint is encoded. Neither mechanism is guaranteed to catch it, and neither should be dismissed.

Give reviewers less mechanical work and better context

My starting point would be to separate enforceable rules from decisions that still require judgement.

Use automation for the rules you can state precisely: permitted dependency directions, required validation paths, type constraints, and known unsafe patterns. Static analysis, dependency checks, and architecture tests can examine more than the lines in the current patch. Whole-repository scans can also track older findings. Passing ordinary unit tests is useful, but it does not imply that these other checks ran.

Then make the design decision easy to find. For a change that crosses a module boundary, the PR should say which boundary changes and why. Link the relevant design rule, show the actual affected code, and identify the tests that exercise the new behaviour. An agent's explanation can help a reviewer navigate, but the explanation itself is not proof that the implementation respects the rule.

Keep generated changes small enough to review as decisions, rather than treating a large diff as one approval. In the retry example, that means deciding whether to extend the shared policy before accepting another independent mechanism.

These are engineering recommendations, not interventions whose effectiveness these papers establish.

Follow the change after merge

If I were evaluating a coding-agent rollout, I would track the work beyond generation: active review effort, rework before acceptance, and later repairs associated with the change. I would record waiting time separately, so a busy reviewer queue did not masquerade as slow code comprehension.

For static-analysis findings, I would distinguish newly introduced findings from the existing baseline and inspect severity, false positives, and age. Comparing a recent patch with one that has had months of maintenance is not a fair persistence comparison. PR size, task type, and repository context matter when comparing assisted and unassisted work.

Some AI-generated changes will save time even after all of that is counted. Others will move work from the author to the reviewer or the next maintainer. The useful result is finding out which is happening, not assuming either outcome.

Before merging a generated patch, I want an answer to one question: what will the next person need to understand to change this safely?