You're Paying Twice for the Same Code

Two pull requests merge into the same service in the same sprint. Both add retry handling around the same flaky downstream call, written two different ways. Neither author saw the other's work. Neither one is wrong.

A year ago that was a code review catch, because the reviewer had read the other PR on Tuesday. Now both changes came from agents, there are nine more like them in the queue, and the reviewer is approving at a rate that doesn't leave room to remember Tuesday.

The duplication data is worse than the velocity data is good

GitClear and GitKraken published research this year called the Maintainability Gap, drawn from 623 million analyzed code changes between 2023 and 2026 across eight code-quality signals. Four of those signals are worth your attention.

Block duplication, which they define as regions of five or more consecutive repeated meaningful lines, rose from 40.3 duplicated lines per million changed lines in 2023 to 73.0 in 2026 year to date. That's the 81% increase you may have seen quoted, and it's the highest level in their record.

Moved code, their proxy for refactoring, fell from 21% of changed lines in 2022 to 13% in 2023 to 3.8% for the first half of 2026. Over the same span, copy and paste went from 9.4% of changed lines to 15.7%. GitClear says the 2022 data showed roughly a 2x preference for refactoring over redundant code; by 2026, it measured roughly 5x greater prevalence for copy/paste."

Cross-file connectivity fell 35%, from 343 method calls per thousand changed lines in 2023 to 223 today. New code calls existing code less than it used to.

And the share of changes that update or remove code last touched more than twelve months ago fell from 1.7% to 0.46%, a 74% drop. Old code is being left alone at a rate that has nothing to do with it being correct.

One number that gets attached to this research doesn't belong to it. The widely quoted "25% more output" figure comes from a separate January 2026 study, and it measures heavy AI users against their own pre-AI baseline, not against anyone else. A different comparison in that same study puts heavy AI users at four to ten times the output of non-users, mostly because they were already high performers. If you cite the 25% and the 81% in the same breath, you're pairing two datasets and a careful reader will find the seam. Cite them separately or skip the velocity number, because the duplication trend stands on its own.

Those numbers describe your codebase, not your developers

The obvious reading is that AI made engineers lazy. Convenient, moralizing, and not much use to anyone trying to fix it.

Here's the mechanism instead. Refactoring requires knowing that a better home for this logic already exists. That knowledge has always lived in two places: the parts of the codebase a developer happens to have read, and the colleague who says "we already have a client for that, it's in the shared package." Both of those are human memory, and neither one is available to an agent working from a ticket and a repository.

So the agent does the reasonable thing. It writes a correct retry wrapper. It has no way to know that three exist, that one of them is the sanctioned one, or that the sanctioned one handles the timeout case yours doesn't. In this scenario, duplication can be a retrieval failure that looks like a judgment failure in the diff.

Call it the invisible abstraction. The shared component exists, it's tested, someone maintains it, and it's discoverable only by asking a person. For a human joining your team, that costs a few weeks of asking around. For an agent running forty times a day, it costs a new copy every time, and the copies compound because each one is now something the next agent might find and imitate.

The timing is consistent with a mechanism worth testing: as agent volume rises, reuse becomes harder to preserve when the existing abstraction isn't machine-discoverable. You didn't change how reuse gets discovered. You added an actor that may not be able to use the discovery mechanisms your human developers rely on.

Automated ambiguity finally has a number attached

We've written about this failure pattern before under the name automated ambiguity: a strong platform pointed at weak specifications, producing work that's individually defensible and collectively inconsistent. The tell we described was rework rate rather than throughput.

The GitClear data is that tell measured at industry scale, and it sharpens the diagnosis in a useful way. Ambiguity in your written specs is only half of it. The other half is ambiguity in your codebase about what the right answer already is. An agent reads both, and the codebase is the larger document.

Which means the fix isn't only upstream in how you write tickets. It's in whether your platform can answer "what should I reuse here" without a human in the loop.

Duplication is a platform problem before it's a discipline problem

Three things make reuse visible to a non-human actor, and you probably have partial versions of all three.

A service catalog that an agent can query is the first. Not a wiki page listing your shared libraries, which is a document about the catalog rather than the catalog itself. A developer portal with a machine-readable inventory of components, owners, and intended use is the thing an agent can actually consult before writing its own version.

Second, golden paths that encode the sanctioned way to do a common thing. A golden path for "call an internal service with retries and circuit breaking" removes the decision entirely. There's nothing to duplicate because there's nothing to invent. The same templates that stop human teams from solving the same problem eleven different ways do the same work for agents, and Synchrony's platform team built exactly that foundation with pre-approved infrastructure-as-code templates before agents were part of the conversation.

Third, duplication detection in the pipeline rather than in a quarterly report. If a change introduces a block that already exists elsewhere, that's a CI signal with a name and a threshold, the same way coverage or vulnerability scanning is. Automated feedback gives an agent an explicit signal it can act on; an unwritten convention gives it nothing comparable. A rule that runs is a rule an agent learns.

None of this is new platform work. It's the work you'd do for agent-ready platform engineering anyway, arriving with a cost justification it didn't have last year.

Acceptance rate is the wrong number to be proud of

Most teams measuring AI adoption are counting suggestions accepted, pull requests opened, or seats active. All three go up whether your codebase is getting better or worse, which makes them useless for the decision you actually face.

Four measures that move in the right direction only when something real improves:

Duplicated blocks introduced per thousand changed lines, trended monthly. Absolute duplication in a growing codebase tells you nothing. The rate at which you're adding it tells you whether agent volume is compounding or not.

Share of changes that touch code older than twelve months. GitClear's 74% decline is particularly worth examining in regulated environments, where organizations may need evidence that older code remains subject to appropriate review, maintenance, and control processes.

Catalog hit rate: how often a change uses an existing catalogued component versus introducing a new implementation of the same capability. This one is only measurable if you have the catalog, which is part of the point.

Rework rate on agent-authored changes, meaning the share that come back within two sprints. This is the direct measure of whether speed is real. Throughput plus rising rework is the signature of automated ambiguity, and the two numbers together say something neither says alone.

Cost per merged change is tempting as a fifth, and it's the one to be careful with. It falls when you get faster and also when you ship more duplication, so on its own it rewards the behavior you're trying to catch. Pair it with the duplication rate or leave it out. If you're working the cost angle seriously, attribution matters more than the unit price, and that's FinOps work rather than engineering-metrics work. We went through the project-level version of this math in what agentic development actually costs.

Three holes in the data, and you should name them before someone else does

The research is directional, not settled, and pretending otherwise costs more credibility than admitting it.

Because the metrics are normalized by changed lines, a shift in the composition of work toward routine or agent-generated changes could affect the observed rates. The research does not establish how much of the movement is attributable to changes in work mix versus changes in coding behavior. If agents produce a higher volume of routine code, duplication per million changed lines can rise without any individual developer or agent behaving worse than before. GitClear doesn't test that, and it's the first objection a good engineer will raise.

Moved lines are a proxy for refactoring, and proxy measures depend on how the underlying tooling classifies changes. Some restructuring may therefore be invisible to this particular signal. A large agent-assisted restructuring may not register as one, which would show up in this data as refactoring collapsing whether or not it did.

And the report discloses no repository selection method, no confidence intervals, and no stated limitations. GitClear is also a commercial provider of code-quality analytics, so readers should treat the findings as vendor-produced research and consider the methodology alongside independent research. 

What survives all three objections is the mechanism, not the trend line. Agents inherit whatever your codebase teaches them about how work gets done here, and a codebase where reuse is undiscoverable teaches copying. That's true at 40.3 duplicated lines per million and at 73.0. The data made it visible. It didn't make it true.

Fix the discovery problem before you buy more capacity

If you're expanding an agent program right now, the question worth answering first isn't how many more seats or which model. It's whether an agent working in your largest repo can determine what to reuse without asking anyone.

Pick one service. Look at the last thirty merged changes and count how many introduced an implementation of something that already existed somewhere in your estate. Set your own threshold based on the baseline you establish in that repo rather than importing a universal number. More agent capacity buys you more copies, and the duplication shows up on your maintenance budget in eighteen months rather than on this quarter's velocity chart.

Then start narrow. One workflow, one repo, a catalog an agent can query, and a duplication check that fails a build. That's the minimum viable slice approach applied to code quality rather than to delivery, and it produces evidence instead of an argument.

Our agentic engineering maturity assessment scores platform engineering, the SDLC operating model, and business intent separately, and the distance between them tells you which one is capping the other two. When duplication repeatedly results from agents or developers failing to discover existing capabilities, the platform pillar is one of the first places to investigate.

Go count the copies in one repo. The number will tell you what to build next.