Search for AI-generated code technical debt and the same two numbers come back on almost every page. Both are wrong, and checking them takes about twenty minutes. That is worth doing before you plan a budget around either one.
This post is about what the research actually supports, and what to do about it in a codebase you already own.
Two numbers everyone quotes
| The claim as it circulates | What the source actually says |
|---|---|
| "AI-generated code contains 1.7 times more issues than human code" | The study it is attributed to states that it made no comparison against human-written code at all |
| "Developers are 19% slower when they use AI" | The team that measured it reported in February 2026 that the finding is outdated and speedups now seem likely |
The comparison that was never made
The largest study of AI-authored code in production is Debt Behind the AI Boom, published by Liu and colleagues in 2026. It examined 302,600 verified AI-authored commits across 6,299 GitHub repositories, covering five widely used assistants, and catalogued 484,366 distinct issues.
It is a serious piece of work. It also says, in its own limitations, that it does not compare AI-authored commits against a clean baseline of human-written ones. The authors explain why: developers use AI constantly without leaving any trace in version control, so a trustworthy human control group cannot be assembled from public repositories.
The multiplier is not a finding in the paper. It appears to have been produced downstream, by writers who needed a comparison the study declined to make.
The slowdown its own authors retired
In July 2025, METR ran a randomised controlled trial on 16 experienced open-source developers across 246 real tasks. The repositories averaged more than 22,000 stars and a million lines of code. Developers predicted AI would make them 24% faster. Afterwards they estimated it had made them 20% faster. Measured, they were 19% slower.
That gap between perception and measurement is a genuinely useful result, and it is the reason the number travelled so far.
In February 2026, METR published an update. They changed the experiment design, described the earlier finding as outdated, and said speedups now seem likely with later tooling. They were also candid that their newer data is unreliable, because a significant number of developers declined to take part in a study that required working without AI.
A superseded result is science working correctly, not a scandal. But a 2025 measurement of 2025 tools cannot be quoted as the current state of 2026 tooling, and it constantly is.
What the evidence does support
Strip out the borrowed comparisons and one finding from Liu and colleagues survives, unambiguous and more awkward than the headlines.
Of the 484,366 issues found in AI-authored commits, 89.3% were code smells. Runtime bugs and security vulnerabilities together made up a small minority. More than 15% of commits from every assistant studied introduced at least one issue, and 22.7% of tracked issues were still present at the latest version of the repository.
That is a worse planning problem than "AI writes buggy code" would have been.
The debt that never triggers a cleanup
A bug announces itself. Something fails, someone is paged, a ticket is opened and the work gets scheduled. The feedback loop that keeps a codebase honest is built entirely out of things going visibly wrong.
A code smell announces nothing. It compiles, it passes review, it ships, and it sits there. No incident routes it to anyone. No alert fires. No test goes red. The 22.7% survival figure is not evidence that teams are careless. It is what happens when a category of problem has no mechanism attached to it.
This is also why machine-authored debt is harder to spot than the hand-written kind. Bad human code usually looks bad. It has inconsistent naming, odd formatting, a comment that gives up halfway. Generated code is fluent, conventionally formatted and plausibly structured. It reads like something a competent engineer wrote on a good day. It passes the glance test that most code review actually is.
Who ends up paying for it
The second useful study is by Xu and colleagues, first published in 2025 and finalised in January 2026. It looked at open-source projects before and after GitHub Copilot arrived.
Aggregate productivity did rise. But the gains were not evenly held. They concentrated among less-experienced contributors, while experienced developers' production of original code fell by 19%, and core developers reviewed 6.5% more code than before.
The work did not disappear. It moved, from writing to reviewing, and it moved onto the people you have fewest of.
One caution, since these two studies are routinely merged: this 19% and METR's 19% are unrelated. Xu measured a decline in original code written by senior contributors. METR measured task completion time. They are different quantities from different studies that happen to share a number.
What it looks like in a codebase
Research gives you the shape of the problem. Finding it in your own repository is a different job. These are the recurring patterns, and we are describing them from review work rather than citing a study, because no study measures them.
- Four near-identical helpers where one belongs. Each was generated in a separate session, each solves the same problem, and each differs slightly. Fixing a bug in one fixes it in none of the others.
- Errors that are caught, logged, and dropped. The block looks defensive and responsible. It converts a loud failure into a silent one.
- Tests that assert the implementation. They restate what the function does line by line, so they pass forever and catch nothing. Rewrite the function correctly and they fail.
- Comments describing intent the code does not implement. The comment is what was asked for. The code is what was produced. Reviewers read the comment.
- Null checks for states that cannot occur. Defensive scaffolding around impossible cases, while the reachable edge case goes unhandled.
Every one of these reads as careful engineering. That is precisely the property that gets them merged.
A method for finding and retiring it
| Step | What to do | Why this order |
|---|---|---|
| 1 | Date the boundary: find the commit range where assistants entered the repository | Everything after is suspect, everything before is a control |
| 2 | Measure duplication before defects | Smells are the 89%, and duplication is the cheapest smell to detect mechanically |
| 3 | Read the tests before the code | Tests that assert implementation tell you which areas were never really reviewed |
| 4 | Search for caught-and-logged errors | Fastest route to the failures you do not currently know about |
| 5 | Rank by blast radius, not by count | A hundred smells in a config loader matter less than three in billing |
| 6 | Retire in small reviewed batches | Bulk automated cleanup of generated code reintroduces the original problem |
Step 6 is the one teams skip. Handing the cleanup back to an assistant, in bulk, without review, produces exactly the same category of change that created the work. Retiring this debt is review work. There is no version of it that is not.
What we are not claiming
We do not have a figure for what this costs you per year, and we are not going to borrow one. The published cost multipliers in circulation trace back to vendor blogs rather than to primary research. That is the same failure that produced the two numbers at the top of this post.
What we will say is narrower and better supported. A substantial share of what assistants introduce is invisible to every mechanism your team currently uses to find problems. Roughly a quarter of it is still there at the latest commit. How much of that sits in your codebase is a measurement, not an estimate. It is worth doing before anyone quotes you a number.
If the code came out of an AI builder rather than an assistant, the gap is wider than debt alone. We covered what production-readiness actually requires in finishing what the AI builder started. For how we handle code ownership, review and confidentiality on this kind of work, see our security and IP position, or what we build and maintain.
Common questions
Nobody has properly measured that yet. The largest study of AI-authored code in production, published by Liu and colleagues in 2026, states plainly that it did not compare its findings against a human baseline, because developers use AI without leaving traces in version control. Claims of a specific multiplier over human code are not supported by the study they are usually attributed to.
That finding is out of date. METR measured a 19% slowdown among experienced open-source developers in a 2025 randomised controlled trial, then reported in February 2026 that the result no longer holds and that speedups now seem likely. Quoting the slowdown as current evidence in 2026 misrepresents the research.
Overwhelmingly code smells rather than outright failures. Across 484,366 issues found in AI-authored commits, Liu and colleagues classified 89.3% as code smells, not runtime bugs or security vulnerabilities. That matters for planning, because a smell produces no incident, no failing test and no alert, so nothing ever schedules the cleanup.
Start by dating the boundary, meaning the commit range where assistants entered the repository, then look for duplication rather than defects. Near-identical helpers, tests that assert the implementation instead of the behaviour, and errors that are caught and logged but never propagated are the recurring shapes. Rank what you find by blast radius, not by count.