Duplicate code is a maintenance problem. Every duplicated block of logic is a future decision about whether to update one instance or both, a future bug that appears in one place but not the other, and a future refactor that’s harder than it should be because the codebase has diverged from itself.
GitClear’s research attributes a 4× increase in duplicate code blocks to AI assistance. That figure deserves unpacking, because the downstream consequences are more serious than the headline number suggests.
Why AI produces duplicate code
AI coding tools are optimised for local correctness. Given a prompt and some context, they produce code that solves the stated problem. They don’t have reliable visibility into the broader codebase — into whether similar logic already exists somewhere, whether there’s an abstraction that should be extended rather than reimplemented, or whether a function that looks new is actually a variation on something that already exists.
The result: AI assistance tends to produce self-contained solutions. These work. They also accumulate into a codebase where the same logic appears in multiple places, implemented slightly differently, maintained independently.
A developer writing code manually is more likely to pause and ask whether something like this already exists. AI assistance bypasses that pause. Speed is part of the value proposition. The duplication is a side effect of the same mechanism.
The compounding problem
Duplicate code doesn’t stay at 4×. Each new AI-assisted contribution that replicates existing logic increases the total. Over time, the codebase develops what amounts to a shadow architecture: parallel implementations of similar functionality, maintained independently, diverging gradually.
The maintenance cost of this isn’t linear. Each time logic needs to change, the question becomes: how many places does this exist? Finding them all takes time. Missing one creates inconsistent behaviour. Fixing all of them creates more surface area for error.
This problem is hard to see in the short term. A single AI-assisted commit that introduces a duplicated function looks fine in review. The maintenance debt accrues slowly, across many commits, and becomes visible when something needs to change and the change is unexpectedly difficult.
What teams can do about it
The practical responses fall into two categories: detection and process.
Detection means measuring duplication rates as a leading indicator. A codebase where AI-assisted commits are producing significantly more duplicate code than human-authored commits is telling you something about how AI assistance is being used and reviewed. That signal is available in git history, but only if someone is looking for it.
Process means building duplication awareness into code review for AI-assisted work. Reviewers looking at AI-assisted diffs should be asking whether the logic being added already exists somewhere in the codebase, and whether the right response is to abstract rather than add. This takes longer than approving the diff. It’s worth the time.
Neither of these responses requires rejecting AI assistance or slowing down adoption. They require treating duplication as a metric worth watching, not an acceptable cost of using the tools.
The long view
The 4× figure will look manageable in month one and serious in month twelve. Duplicate code accumulates. Codebases that are accruing it faster than they’re eliminating it are building a maintenance debt that will become visible at the worst time: when something important needs to change quickly and the codebase makes that harder than it should be.
Teams that are watching duplication rates can catch the trajectory before it compounds. Teams that aren’t will discover it later.
Scryable tracks duplicate code patterns and churn rates across your git history, with comparisons to your pre-AI baseline. Get early access.