Post
JA EN

AI Is Increasing Code Duplication While Changing What Sharing Means: Rereading DRY at the Source

Posted
By
16 min read
AI Is Increasing Code Duplication While Changing What Sharing Means: Rereading DRY at the Source
  • Target audience: Software engineers, tech leads, and developers who use AI coding tools daily
  • Prerequisites: Basic familiarity with the DRY principle and refactoring, hands-on experience with AI coding agents (Claude Code, Cursor, etc.)
  • Reading time: 15 minutes

Overview

“If I can just tell an AI to apply this change everywhere, doesn’t that make sharing code pointless in the first place?” Anyone who uses an AI coding agent day to day hits this thought sooner or later. If the cost of fixing duplicate code drops, at least part of the case for DRY (Don’t Repeat Yourself) seems to disappear with it.

The data tells a more tangled story. GitClear’s 2025 analysis of 211 million lines of code changes found that after AI adoption, the share of copy-pasted lines rose from 8.3% to 12.3%, and blocks of five or more duplicated lines quadrupled1. A 2026 academic study independently confirmed the same pattern: AI-generated pull requests reuse less code and duplicate more than human-written ones2. AI, in other words, is pushing duplication up, not down.

At the same time, AI coding agents have made sweeping, cross-cutting changes dramatically cheaper. In a monorepo, renaming a field shared by five services is something an agent can finish in a single pass, seeing every consumer at once3. That undercuts the classic justification for DRY, the sheer tedium of writing the same fix in N places, at least in some settings.

AI is simultaneously a source of duplication and a force that makes fixing duplication cheap. How do you square that?

The answer comes into focus when you go back to what DRY originally meant. Andy Hunt and Dave Thomas’s actual formulation was never “don’t let code look duplicated.” It was “don’t let knowledge be duplicated”4. That distinction splits the value of sharing code into two separate things: cutting the effort of writing and maintaining the same logic in multiple places, and keeping a single, authoritative answer for a given piece of knowledge or behavior somewhere in the system. AI is mostly changing the first. The second stays exactly as important as it always was, and given AI’s own blind spots, arguably matters more now.

This piece works through that asymmetry, using both the empirical data and the design principle’s own source material.

Why AI Tends to Duplicate Code

Several independent studies point the same way

GitClear’s 2025 report analyzed 211 million lines of code changes across five years (2020 to 2024) in repositories from Google, Microsoft, Meta, and other large organizations1. Copy-pasted lines rose from 8.3% to 12.3% of all changes (roughly a 50% increase), and blocks of five or more duplicated lines quadrupled. Over the same window, changes classified as “refactoring” fell from 25% of all changes in 2021 to under 10% by 2024, a 60% drop. That timeline roughly tracks the spread of AI coding assistants.

A single study like that deserves caution, but there’s corroboration from an independent method. A 2026 paper presented at MSR (Mining Software Repositories), titled “More Code, Less Reuse,” used code clone detection and cyclomatic complexity metrics and found that AI-generated pull requests carry more code and less reuse than human-written ones2.

There’s a more specific data point too. In May 2026, a report ran the copy-paste detector jscpd against 49 GitHub projects tagged as “vibe-coded,” totaling 7.2 million lines, and found an average duplication rate of 7.98%5. What stands out is that the projects with the highest duplication weren’t AI applications themselves, but skill libraries written for AI agents (agent-skills came in at 37.48%, second overall). Skill definitions do tend toward a templated structure to begin with, but it’s plausible that the kind of boilerplate config and instructions written to steer an AI is exactly the kind of thing AI itself is good at copying and lightly tweaking.

The root cause: it can’t see what it can’t see

Why does AI produce so much duplicate code? The simple reason is that an AI agent often generates code without knowing about implementations that live outside the files and directories it’s currently reading. Code quality platform Qodo.ai found that 65% of developers say AI tools frequently miss relevant context during refactoring or review6. The same piece splits duplication into exact, near (same logic, different variable names or branch order), and semantic (different code, same behavior), and notes that AI-generated code in particular tends to regenerate existing logic without knowing a shared library already covers it. Where a human engineer might pause and think “didn’t I write this somewhere before,” AI simply doesn’t see what’s sitting outside its context window.

This is less a limitation of skill than of visibility. As the next section shows, once that visibility is widened, the same AI can just as easily work on the side of reducing duplication.

At the Same Time, AI Makes Cross-Cutting Changes Dramatically Cheaper

This is where the earlier contradiction starts to make sense. Engineer Francis Eytan Dortort argues that the classic monorepo-versus-multi-repo debate is being reshaped by AI coding agents, at the level of what criteria even matter3.

That choice used to be about optimizing for human work units. Multi-repo made ownership boundaries between teams clear, at the cost of coordination across repositories every time a shared interface changed: updating the library, opening pull requests against every consumer, sequencing merges, managing a compatibility window. Monorepo avoided that coordination cost, at the price of investing in dedicated build tooling (Bazel, Nx, and similar).

Dortort’s example makes the point concretely. Renaming a protobuf field consumed by five services: in a monorepo, an agent can see the field definition, the generated bindings, and every consumer’s code at once, and complete the change atomically. In a multi-repo setup, the agent only sees the schema repository; each downstream service breaks on its next build, and a human has to coordinate the fix across all of them.

Which means whether “AI can fix duplication in one pass” is true isn’t really a question of AI capability. It’s a question of how much of the codebase the AI has been placed in a position to see at once. The same model, the same agent, becomes either a duplication machine or a cheap consolidator depending entirely on where the boundaries are drawn. The rise in duplication that GitClear and Qodo observed reflects, in many organizations, AI still not being given that vantage point (or boundaries being drawn deliberately for other reasons).

Back to the Source: DRY Was About Knowledge, Not Appearance

Going back to how DRY was originally defined gives us an axis to make sense of this contradiction. In their 1999 book The Pragmatic Programmer, Andy Hunt and Dave Thomas put it this way:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.4

That principle was never scoped to surface-level code duplication. It was meant to cover database schemas, test plans, build configuration, and documentation, the duplication of knowledge in general7.

That distinction matters for sorting out the AI-era debate. What GitClear and the vibe-coding study measure is, at bottom, duplication as text, the kind a copy-paste detector can flag. That isn’t the same thing DRY was actually about. Two blocks of similar-looking code can represent genuinely different knowledge (say, the accidental result of avoiding what Sandi Metz calls the wrong abstraction), in which case there’s no DRY violation at all. Conversely, two blocks of very different-looking code can encode the exact same business rule in two places, which is a real DRY violation, and one that no amount of cheap AI-driven bulk editing resolves on its own.

So the observation that “surface-level duplication has gone up” doesn’t, by itself, support the conclusion that “the AI era has stopped caring about sharing code.” The real question is whether that duplication carries duplicated knowledge with it.

Splitting the Value of Sharing Code in Two

Once you draw that line back to the source material, the value that sharing code used to provide splits into two distinct axes.

The first is what we can call Axis A, the cost of writing and maintaining code. It’s about not wanting to write the same logic twice, not wanting to chase down N call sites when something needs fixing, and AI has made that lighter. Writing the logic is something AI can take off your hands, and in a sufficiently visible environment like a well-organized monorepo, so is the bulk-fix work later.

The second is Axis B, keeping knowledge in a single source. It’s about making sure a given specification, rule, or contract has exactly one authoritative answer somewhere in the system, and that has nothing to do with what AI is good or bad at. If anything, given AI’s tendency to miss implementations outside its context and produce semantic duplicates (the Qodo finding above), the risk of knowledge being scattered may matter more now than before. A human engineer’s vague sense of “I feel like I’ve seen this before” used to act as a loose safety net; AI only has whatever it can currently see.

Sharing that existed purely to satisfy Axis A, the “I extracted this into a function because typing it twice was annoying” kind, loses much of its justification under AI. Sharing that exists to satisfy Axis B, authentication logic, pricing calculations, type definitions and contracts, anything where a mismatched interpretation causes real incidents, stays just as important regardless of what AI can do.

Premature Abstraction Is a Bigger Risk in the AI Era, Not a Smaller One

There’s a second axis to the sharing decision, distinct from DRY itself: premature abstraction. In her RailsConf 2014 talk, Sandi Metz argued for preferring duplication over the wrong abstraction, and later wrote it up as a blog post8.

The pattern Metz describes goes like this. A programmer spots duplication and extracts it into a function. Later, a requirement shows up that’s almost, but not quite, what the abstraction handles, and the next person, feeling obligated to preserve the existing abstraction, bolts on a parameter and a conditional. Repeat this a few times and what was once a simple abstraction degrades into an unreadable tangle of branches8. Metz traces this to sunk cost bias: the more complicated and unreadable code gets, the more psychological pressure there is to assume it must be important, precisely because so much effort clearly went into it.

Kent C. Dodds builds on this with a middle path he calls AHA (Avoid Hasty Abstractions), refusing to be dogmatic about either DRY or WET (the tolerate-duplication camp)9. Don’t fear duplication; wait until the same code is running in several places before letting the commonality argue its own case for an abstraction.

This pattern has a real chance of accelerating in a world where AI agents write code all day. Step six in Metz’s sequence, adding a parameter out of obligation to preserve an existing abstraction, was originally driven by a human engineer’s sunk cost psychology. Ask an AI agent to “add this feature to the existing function,” and it will dutifully do exactly that: add a parameter, add a branch. Minimizing the change by respecting the existing structure reads as the “safe” move to most agents, safer than proposing a different design and replacing the old code outright. Where a human might hesitate, an agent just executes, which means the rate at which conditionals pile up could move faster than it did under mostly human-driven development.

Worth flagging clearly: from here, this isn’t backed by rigorous empirical data, it’s an inference, mapping the psychological pattern Metz described in humans onto AI agents’ known behavioral tendencies. On the surface, AI’s tendency to write duplicate code (the data above) and its tendency to abstract too early look contradictory. But if both come from the same root, an agent responding to whatever’s asked of it right now by the shortest path available, they’re not actually in tension. Solving the immediate task takes priority, and the question of which design ages better gets deferred.

If that’s right, the AHA principle’s core advice, don’t rush to abstract, wait until several real cases exist, becomes something humans need to deliberately bring to the table in the AI era. AI is good at implementing whatever abstraction it’s told to build. Knowing when not to abstract yet is, at least for now, not something it’s good at.

How to Decide in Practice

Given all this, the question of whether to share code shifts its weight compared to before AI.

One question you no longer need to labor over: should I share this code to save myself the effort of writing or fixing it in multiple places? In an environment where AI has made cross-cutting changes cheap (a well-organized monorepo, or an agent given enough context), tolerating some duplication and consolidating it later in bulk is a realistic option.

One question that still needs asking: does this piece of code represent knowledge that should have exactly one home in the system? In domains like authentication, billing, or permission checks, where a mismatched interpretation causes real incidents, the design decision to maintain a single source of knowledge doesn’t change regardless of whether the code happens to look duplicated. That’s a judgment call that belongs to a human, not something to hand off to AI.

One question that’s newly important: is this codebase actually visible to the AI agent working in it? How multi-repo boundaries and service boundaries are drawn directly affects whether AI misses semantic duplicates and multiplies them. Setting up an environment where AI can correctly support that judgment is itself becoming a new design concern, separate from the sharing decision itself (a deeper dive into that layer is linked at the end of this piece).

And one thing worth deliberately not rushing: is this particular duplication still too early to abstract? Whether to push back when AI proposes an abstraction too soon remains, per the AHA principle, a human’s job.

Conclusion

The question “does sharing code stop mattering in the AI era” doesn’t have a simple yes-or-no answer. The data shows two things holding true at once: AI is increasing code duplication, and AI is lowering the cost of cross-cutting changes. That contradiction resolves once you go back to DRY’s original meaning and split the value of sharing code into two things: reducing the cost of writing and maintaining code, and keeping knowledge in a single source. The first is genuinely less pressing now that AI can shoulder some of the duplication and clean it up later in bulk. The second hasn’t moved, and given AI’s blind spot for implementations outside its context, deliberately protecting it may matter more than it used to.

The same goes for staying wary of premature abstraction, the AHA principle Sandi Metz and Kent C. Dodds have been making the case for. AI agents respond to instructions by the shortest path available. That’s exactly why the job of hitting the brakes with “it’s not time to abstract this yet” has, if anything, ended up more squarely in human hands than before, at least based on what the evidence here suggests. Writing less code hasn’t meant making fewer judgment calls.

Want to go deeper? The more concrete organizational and architectural question, at which layer should single-sourced knowledge actually live, is covered in Multi-Tier Harness Engineering. This piece sits one step before that: what sharing code was even for in the first place, and which part of that AI has actually changed.

The other side of this argument: This piece concluded that tolerating some duplication and letting AI consolidate it in bulk later is a reasonable stance. The companion piece If AI Is Increasing Duplication, DRY Should Be Enforced More Strictly reaches the opposite practical conclusion from the same AI-era data: in domains like security and authentication, where a mismatched interpretation causes real incidents, DRY should be enforced more strictly, not less. Which stance fits your team depends on what the duplicated knowledge actually is. Worth reading both before deciding.

You might also find these articles relevant:

References

Numbered citations in the text correspond to the sources below, listed in order.

Additional sources (referenced but not numbered in text)

  • AHA Programming, citing Conlin Durbin’s definition of WET - Conlin Durbin (2019). 【Reliability: Medium】

  1. AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones - GitClear (2025). 【Reliability: Medium-High】 ↩︎ ↩︎2

  2. More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-generated Pull Requests - MSR ‘26 conference paper (2026). 【Reliability: Medium-High】 ↩︎ ↩︎2

  3. Monorepo vs Multi-Repo: Why AI Agents Tip the Scale - Francis Eytan Dortort. 【Reliability: Medium】 ↩︎ ↩︎2

  4. The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition - David Thomas, Andrew Hunt, Addison-Wesley Professional (2019, original edition 1999). 【Reliability: High】 ↩︎ ↩︎2

  5. Copy/Paste Detection Report: Vibe-Coded Projects Analysis - jscpd analysis of 49 projects (2026). 【Reliability: Medium-High】 ↩︎

  6. How to Catch Code Duplication Across 100 Repositories - Nnenna Ndukwe, Qodo.ai (2026). 【Reliability: Medium】 ↩︎

  7. Don’t repeat yourself - Wikipedia. 【Reliability: Medium】 ↩︎

  8. The Wrong Abstraction - Sandi Metz (2016, adapted from a RailsConf 2014 talk). 【Reliability: Medium-High】 ↩︎ ↩︎2

  9. AHA Programming - Kent C. Dodds (2020). 【Reliability: Medium-High】 ↩︎

Software Design
DRY Principle Software Design AI Coding Refactoring Claude Code Technical Debt
This post is licensed under CC BY 4.0 by the author.