Short answer
The main quality problem with AI-generated code is duplication, not syntax. GitClear found moved (refactored) lines fell from 25% of changes in 2021 to under 10% in 2024, while copy-pasted lines rose to 12.3%. Agents duplicate because writing new code is cheaper for them than finding old code. Duplication checks and refactoring tasks fix it.
The feature works. The tests pass. But in review you notice the agent wrote a fresh date-formatting helper, and you are fairly sure there are already three of them in the codebase. A month later a bug gets fixed in one of those helpers and stays alive in the other three.
That is the quality problem with AI code that people feel before they can name it. It is rarely broken syntax. It is code that works today and makes the codebase worse to change tomorrow. GitClear has been measuring exactly this for several years, and the trend is clear enough to act on.
What GitClear measured
GitClear classifies every changed line in a large set of repositories by what kind of change it was: added, deleted, updated, moved, copy-pasted, and so on. Moved lines are the interesting signal. When a developer pulls repeated logic into a shared function or relocates code into a better module, the lines show up as moved. It is the fingerprint of refactoring.
Their 2025 report covered 211 million changed lines written between January 2020 and December 2024. Moved lines fell from 25% of changes in 2021 to under 10% in 2024. Copy-pasted lines rose from 8.3% to 12.3% over the same period. In 2024, for the first time in their data, copy-pasted lines outnumbered moved lines. Duplicated blocks of five or more lines rose about eightfold during 2024.
A follow-up report in June 2026, “The Maintainability Gap”, looked at 623 million changes from 2023 to 2026 and found the trend continuing. Its figures extend the picture.
Refactoring is falling, copy-paste is rising
Share of changed lines, GitClear
- Moved (refactoring)
- Copy-pasted
Data as a table
| Moved (refactoring) | Copy-pasted | |
|---|---|---|
| 2021 | 25% | 8.3% |
| 2022 | 21% | 9.4% |
| 2023 | 13% | — |
| 2024 | — | 12.3% |
| 2026 H1 | 3.8% | 15.7% |
The two reports use different samples, so treat the line as a direction rather than a precise series. GitClear’s own summaries of these studies also quote slightly different numbers in different places, so I have used only the figures stated on each report’s page. The direction is not in doubt.
The 2026 report also tracked other signals, and they point the same way: less reuse, more risk.
Two of those deserve attention. Cross-file function calls down 35% means new code calls existing code less and reimplements more. Error-masking constructs up 47% means more catch blocks that swallow failures, the kind of code that makes a test pass and a bug invisible.
Why agents copy instead of reuse
GitClear’s data is correlational: these trends line up with the spread of AI assistants, but the reports can’t prove AI caused every line of it. The mechanism, though, is not mysterious if you have watched an agent work.
For a person, writing new code is expensive and searching is cheap-ish, so reuse wins often enough. For a model, it is the other way round. Generating a fresh 20-line helper costs almost nothing. Finding the existing helper means searching a codebase it can’t see all at once, reading the candidates, judging whether they fit, and possibly changing a shared function that other code depends on. The model’s incentive, if you can call it that, is to write.
Three more things push in the same direction:
- Context is limited. The agent sees the files it opened. The utility module three folders away doesn’t exist for it unless it looks.
- The task is scoped to the feature. “Add CSV export” rarely says “and consolidate the four existing CSV writers”. Agents do what the ticket says.
- Refactoring is risky for the agent. Changing a shared function can break callers it hasn’t read. Copying is locally safe. A cautious agent copies.
And review doesn’t catch it. Faros AI’s data on about 10,000 developers shows PRs on high-AI teams growing 154% in size. A reviewer skimming a large diff checks whether the new code works, not whether it duplicates something elsewhere. Duplication is invisible inside a single diff. You only see it across the codebase.
What duplication costs you later
Duplicated code is cheap on the day it’s written and expensive every day after. The costs are well known; AI just produces more of them, faster.
| Cost | How it shows up |
|---|---|
| Bugs fixed in one copy only | The same defect resurfaces from a sibling copy weeks later |
| Inconsistent behaviour | Two date formatters, two rounding rules, two error messages for the same failure |
| Slower changes | A rule change needs edits in five places, and someone misses one |
| Bigger context for the next agent | More code to read, more near-identical candidates, more chance it copies the wrong one |
| Harder review | Larger diffs, more surface, less attention per line |
The fourth row is the one specific to AI teams. Duplication compounds. A codebase with four near-identical helpers is harder for the next agent to reuse correctly, so it is more likely to write a fifth. DORA’s 2025 report describes AI as an amplifier of whatever an organisation already does well or badly. Codebase structure is a good example: a clean codebase gets reused, a messy one gets copied.
How to make agents reuse code
Telling the agent “please don’t duplicate code” in a prompt helps a little and decays fast. Things that work better are structural.
- Run a duplication detector in CI and fail on new clones. Tools like jscpd or PMD’s CPD find copy-pasted blocks across files. Don’t fail on existing debt; fail when a change adds a new duplicated block above a size threshold. The agent sees the failure and fixes it in the same loop, like a type error.
- Make search part of the task. Before writing a helper, the agent searches for existing ones and says what it found. “No existing helper; searched
utils/,shared/and forformatDate” is a claim a reviewer can check. - Give the reviewer a reuse criterion. An independent reviewer model can look beyond the diff. Ask it explicitly: does this change add logic that already exists elsewhere? It has the time to grep that a human reviewer doesn’t. See the writer can’t be the reviewer for why the second model should be a different one.
- Keep diffs small. Duplication hides best in big changes. Small diffs make it visible.
- Schedule refactoring as its own work. This is the part teams skip. Give agents dedicated tasks: consolidate the CSV writers, remove dead code in this module, replace these three formatters with one. Refactoring tasks have a great property for automation: the existing tests define success, and behaviour must not change.
- Track the trend. Measure duplicated lines and net lines per change monthly. If duplication climbs, it will show up there before it shows up as bugs.
The bad approaches: banning AI-generated code in core modules (unenforceable and it wastes the tool), relying on reviewers to remember every helper in a large codebase, or letting the debt pile up until a big rewrite. That last one is how teams end up with a “cleanup quarter” that never quite happens.
The bold part: agents can make refactoring cheap
Here is where I think GitClear’s trend can reverse. The reason teams under-refactor has always been cost. Refactoring takes human hours, carries risk, and ships no visible feature, so it loses every prioritisation meeting.
Agents change that arithmetic. A consolidation task with good tests is close to ideal agent work: the goal is precise, the acceptance criteria already exist as the test suite, and the review question is narrow (“did behaviour change?”). If refactoring becomes something that runs overnight as a queue of small, checked tasks, it stops competing with features for people’s time.
The assumption is that you have tests you trust and a review step independent of the writer. Without those, an agent refactoring shared code is a risk, which is exactly why agents copy today. With them, the same tool that pushed duplication up can pull it down. Most teams are using agents to write features and leaving cleanup to people. I would flip a share of that: let agents do the cleanup, because cleanup is where their tirelessness and the existing tests line up best.
Questions
What are the main quality issues with AI-generated code?
The biggest measured issue is duplication: AI-assisted code tends to copy and reimplement logic instead of reusing it. GitClear found refactoring (moved lines) fell from 25% to under 10% of changes between 2021 and 2024, while copy-pasted code rose. Swallowed errors and larger, harder-to-review changes are close behind.
Does AI-generated code increase technical debt?
The data points that way. GitClear’s 2026 report found code block duplication up 81% and refactoring line moves down 70% against its baseline, which is technical debt by most definitions. Whether it grows in your codebase depends on whether you check for it.
Why do AI coding agents duplicate code?
Writing new code is cheap for a model, while finding and safely reusing existing code requires searching a codebase it can’t see all at once. Tasks are usually scoped to one feature, and copying feels locally safer than changing a shared function.
How do you reduce duplication in AI-generated code?
Fail CI when a change adds a new duplicated block, require the agent to search for existing helpers before writing one, give the reviewer an explicit reuse check, and schedule regular refactoring tasks that agents can do against the existing tests.