Short answer: yes, AI-written code builds up debt, and it's a recognisable kind. Code gets copied instead of reused, errors get swallowed instead of raised, changes get bigger and keys end up in the history. None of it shows in a demo. All of it can be measured in your own repository in an afternoon, with free tools.
Technical debt used to come from shortcuts people knew they were taking. The new kind is quieter. The code reads cleanly, follows the style guide and passes the tests, and nobody on the team remembers writing it, because nobody did.
This note goes through what the 2025–2026 data says that debt looks like, and then six checks you can run on your own code.
What does the data say AI-written code leaves behind?
GitClear, 2026. Across 623 million code changes, moved lines (their measure of refactoring) fell from 13% of changes in 2023 to 3.8% in 2026, while copy-pasted lines rose from 9.4% in 2022 to 15.7%. Duplicated blocks are up 81% on 2023, and code that swallows errors is up 47%.
CodeRabbit, December 2025. In 470 open-source pull requests, the ones co-written with AI had 10.83 issues each against 6.45 for human-only ones. Logic and correctness problems were 75% more common, and gaps in error handling nearly twice as common.
Faros AI, July 2025. On teams with high AI adoption, pull requests got 154% larger and review time rose 91%.
Veracode, July 2026. AI-generated code passed security tests 56% of the time, about the same as a year before.
GitGuardian, 2026. Commits co-authored with Claude Code leaked a secret 3.2% of the time, against 1.5% across all public GitHub commits.
A caution before reading further: each of these companies sells a tool for the problem it measured. CodeRabbit sells code review, GitGuardian sells secret scanning, GitClear sells code analytics. The numbers point the same way, which helps, but nobody independent has checked them.
Why is AI debt harder to notice?
Because it doesn't look like debt.
Old-fashioned debt announces itself: a TODO, a function four hundred lines long, a hack with an apology in the comment. AI-written code tends to be tidy. It's formatted, named sensibly and often commented. What's wrong with it sits one level up, in how it relates to everything else.
Three patterns come up again and again in the reports above.
The first is copying instead of reuse. A model asked for a date formatter writes one, even if the codebase already has three. Each copy works. Then a bug is fixed in one of them, and the other two keep it.
The second is errors that go quiet. A try block that catches everything and carries on keeps the demo running and hides the failure from whoever is on call. GitClear's 47% rise in error-masking code is the number to remember here.
The third is size. When writing code is cheap, changes grow, and a reviewer facing a 900-line pull request approves more than they read. That's how the first two patterns get merged.
There's a fourth, which no tool measures: nobody owns the code. When a person writes a module, someone on the team knows why it's shaped the way it is. When an assistant writes it and a busy reviewer approves it, that knowledge was never in anyone's head — and the first person to find out is the one fixing it at night.
How do you see it in your own repository?
Six checks, all free, most of them one command. Run them once to get a baseline, then monthly, and watch which way the numbers move.
Duplication
npx jscpd ./src prints the share of your code that's duplicated, and where. A rising share across months is the copy-instead-of-reuse pattern in your own numbers. SonarQube reports the same figure, if you already run it.
Is anything being cleaned up?
A codebase where nobody refactors only grows. Compare lines added with lines deleted over the last six months: git log --since="6 months ago" --numstat --format= | awk '{a+=$1; d+=$2} END {print a, d}'. It's a rough proxy, not GitClear's measure. But if deletions have dropped to a small fraction of additions since the team adopted AI, cleanup has stopped happening.
Where the churn is
git log --since="3 months ago" --name-only --format= | sort | uniq -c | sort -rn | head -20 lists the files changed most often. Files that get rewritten every week are usually the ones nobody understands. Those are where duplicated and swallowed-error code tends to collect.
Pull request size
With the GitHub CLI, gh pr list --state merged --limit 100 --json number,additions,deletions gives the size of the last hundred merged changes. If the median has doubled since last year, review has stopped being a real check.
Swallowed errors
Linters already know this one. In JavaScript and TypeScript, ESLint's no-empty rule flags empty catch blocks. In Python, ruff check --select E722,S110 . finds bare except: and try–except–pass. Count the hits; don't fix them all at once.
Keys in the history
Run a secret scanner over the whole history, including files that have since been deleted: gitleaks git ., or GitGuardian's ggshield. A key that was committed and then deleted is still in the history, and should be treated as leaked and replaced.
What does a first month look like?
Smaller than a clean-up project, and mostly measuring.
In the first week, run the six checks and write the numbers down. Don't fix anything yet. The point is a baseline you can compare against, and a list of the ten files that change most often.
In the second week, pick one of those files and read it properly, with the assistant explaining it and a person correcting the explanation. Most teams find a duplicate or a swallowed error within the first hour. Fix that one, with a test.
In the third week, turn on the two lint rules and the secret scan in CI, as warnings first. Count what they flag.
In the fourth, run the checks again. If duplication and pull request size have stopped growing, the habits are working. If they haven't, the next step is a review rule, not another tool.
What should a team change?
Less than it fears. The debt comes from how AI is used, not from using it.
Cap the size of a change. A limit of a few hundred lines per pull request is blunt, and it works, because a reviewer can still read what they approve.
Ask one extra question in review: does this already exist somewhere? It's the cheapest defence against duplication, and models answer it well when asked.
Make error-swallowing a failing check. The two lint rules above, set to error in CI, stop the pattern at the door.
Give refactoring a budget. If cleanup no longer happens as a side effect, schedule it. Pointing the assistant at a known duplicate is work these tools do well.
Scan every commit for secrets, before it's pushed, not once a year.
Keep measuring. The six numbers above, once a month, tell you whether the debt is growing faster than the team pays it down. This is the part teams with AI tools that ship no faster usually skip, and it's where we start when we work alongside them.
None of this is new engineering. It's the old discipline, applied to code that arrives faster than it used to. We looked at where that speed goes in Is AI making developers faster?
Common questions
Is AI-generated code worse than code written by people?
Not line by line. CodeRabbit found people made more spelling mistakes and more testability problems than AI did. The trouble is volume and fit: more code, written faster, with less regard for what's already there.
Can AI pay technical debt down as well?
Yes, and it's one of its better uses. Large, repetitive clean-ups with a clear target are where models do well, as the migrations at Airbnb and Google showed. We went through those in AI legacy code modernization.
How do you measure technical debt?
There's no single number — SonarQube's technical debt ratio, the estimated cost of fixing the issues it finds divided by the cost of writing the code, is the best-known one. The six checks above are cruder and more specific to AI: they show whether the patterns AI tends to add are growing in your code.
Do AI code review tools solve this?
They help with the change in front of them: a missing check, a risky pattern, a bug in the diff. Debt is mostly about the code around the change, the three other date formatters and the error that should have been raised two calls up. Even CodeRabbit's own advice starts with giving the model the context of the repository and enforcing style as policy, which is a repository-level job.
Should we stop using AI to write code?
No. The same reports that measure the debt also measure the speed, and the speed is real. Keep the tools and add the checks.
