Build · founder · 8 min read

Your AI Never Cleans Up After Itself. Here's the Bill.

Two large 2026 studies measured what AI-written code leaves behind. The number founders should care about isn't bugs — it's that nothing gets refactored.

Published September 20, 2026 ·

technical debt maintenance code quality founder advice research

Two big studies landed in 2026, and neither one is about vibe coding. One looked at 8.1 million pull requests from 4,800 engineering teams. The other looked at 302,600 commits written by AI assistants across 6,299 public repositories.

Both were measuring professional engineering teams, not founders building alone. But between them they put numbers on something you are accumulating right now whether you can see it or not, and one of those numbers should change how you build.

The number: your AI writes new code and almost never fixes old code

LinearB’s 2026 Engineering Benchmarks Report tracked something called refactor rate — the share of a change that modifies existing code rather than adding new code.

For changes written by humans without AI, that rate sits around 37%. Better than a third of the work is going back into code that already exists: tidying it, correcting it, consolidating it.

For AI-assisted changes, the refactor rate is close to zero.

Read that as a behavioural fact rather than a quality one. Your AI is not bad at cleaning up. It does not clean up. Asked to add a feature, it adds a feature — a fresh implementation, often duplicating something that exists three files away, often ignoring the pattern you and it established last week.

The same report found AI-assisted changes run about two and a half times larger than human ones: over 400 lines versus 157 at the 75th percentile. More code, faster, with none of the corresponding cleanup.

That’s the shape of the bill. Not “the code is bad.” The code is fine, there is a great deal more of it than there needs to be, and it gets less coherent every week.

About a quarter of what it breaks never gets fixed

The second study — Debt Behind the AI Boom, from Singapore Management University and Huazhong University of Science and Technology — took a different approach. The researchers found commits that AI assistants had verifiably authored, ran static analysis before and after each one, then tracked every problem the AI introduced to see whether anyone ever fixed it.

Two findings matter to you.

First: more than 15% of commits from every assistant they tested introduced at least one new problem, ranging from 17.4% to 29.1% across tools. Call it one commit in four or five.

Second, and this is the one: 22.7% of the problems AI introduced were still sitting in the codebase at the latest version. Not in abandoned side projects — in repositories with 100+ stars and active maintainers, including projects run by Microsoft and Intel. Nearly 5,000 of those had been introduced more than nine months earlier and were still there. The authors note this probably undercounts, because when a file gets deleted or rewritten their method scores the problem “resolved” even though nobody deliberately fixed anything.

There’s a revealing asymmetry underneath. Across the whole dataset, AI commits fixed slightly more cosmetic messiness than they created — a small net improvement in tidiness. On correctness and security they went the other way, and AI introduced roughly 1.5 times as many security problems as it fixed.

That’s the pattern to hold onto: competent at the surface layer, unreliable at the layer where consequences live.

Switching tools will not get you out of this

The obvious founder reaction is to go shopping. It doesn’t work. The study covered GitHub Copilot, Claude, Cursor, Gemini and Devin, and all five produced the same pattern of problems in roughly the same proportions. The authors say it plainly: technical debt cannot be solved by switching between AI coding tools.

The most common defect they found across all of them is worth naming, because it is exactly the kind you cannot see. It’s overly broad error handling — code written so that when something goes wrong, the failure is swallowed silently instead of reported. Over 41,000 instances. Your app doesn’t crash. It just quietly stops doing one thing correctly, and you find out from a customer.

For the JavaScript and TypeScript apps that tools like Lovable, Bolt and v0 generate, the leading security pattern was path traversal through file-path handling — 8,677 cases. Unglamorous, well-understood, entirely preventable by an automated check, and invisible in a working preview.

Where these studies do not describe your situation

Being honest about the limits matters more than the headline, so:

Neither study has a clean human baseline. The arXiv authors say so explicitly — they deliberately did not compare AI commits to human-only commits, because constructing a fair comparison is hard and a bad one would mislead. So “AI introduces problems at rate X” is not the same claim as “AI is worse than you would have been.” You might well have written worse.

The samples are not you. The arXiv study covers public repositories with 100+ stars in Python, JavaScript and TypeScript. LinearB’s teams are companies with code review processes, reviewers and standards.

And that last point cuts both ways. LinearB found AI-generated pull requests wait more than 16 hours before anyone even starts reviewing them, against roughly 200 minutes for human ones, and that only 32.7% of them ever merge, versus 84.5% for human-written changes. You have none of that friction. Nothing sits in a queue, everything merges instantly, and you ship faster than any of those teams.

You also have nobody catching anything. Every filter those numbers describe is a filter you do not have.

What to actually do about it

The arXiv authors’ recommendation is mechanical and cheap, which is good news: static analysis, tests and security checks as part of the normal workflow, and review that continues after the merge. Translated for someone who is not going to run a code review process:

1. Turn on automated checks and let them block you. Most builders will wire up a linter and a security scanner if you ask in plain language. Ask for it once, early. These tools catch the two specific things above — swallowed errors and path traversal — without you understanding either.

2. Ask for the existing thing before the new thing. “Is there already a function that does this? Use it” is a one-line prompt habit that works directly against the zero-refactor behaviour. It will not fix the pattern, but it dents it.

3. Budget a periodic cleanup pass. Once a month, ask your tool to find duplicated logic and consolidate it. Nothing else in your workflow will ever do this, because the AI will not volunteer it.

4. Never accept silent error handling. When you see the AI wrap something in a catch-all, ask where the failure gets reported. This is the single highest-value question a non-technical founder can ask about their own codebase.

5. Price one real review before you take money. Not an ongoing engineer — one paid pass over the security-sensitive parts before real customer data arrives. That’s the 1.5x security asymmetry, bought off cheaply. Hiring a vibe coder covers what that engagement looks like.

The bottom line

The case for building this way hasn’t changed and these numbers don’t undo it. Shipping and validating in a fortnight still beats six months of careful engineering on a product nobody wanted. That trade is still right.

What the 2026 data adds is precision about the invoice. It isn’t a bug count. It’s that your codebase gets bigger and never gets tidier, and about a quarter of the specific things that break stay broken because no process exists to notice them. For a prototype, irrelevant. For something with paying customers, it’s the reason month six is harder than month one — and none of the five habits above requires you to learn to code. They’re things you say out loud to a tool you already pay for.

Read next: the real cost of vibe coding for the subscription side of the ledger, and the AI code security crisis for what happens when that security asymmetry becomes someone’s incident report.