Duplicate-block detectors are not new. Tools like PMD's CPD and jscpd, two open-source duplicate-code scanners, have caught copy-pasted code for over a decade. What changed is that two numbers started moving in opposite directions.

The code-analytics vendor GitClear scanned 623 million real code changes made between 2023 and 2026. Block duplication is now running at the highest rate GitClear has ever recorded, up 81%, from 40.3 to 73.0 duplicated blocks per million changed lines. The work that undoes duplication, moving code into a shared function during a cleanup pass, reduced significantly over the same stretch. It dropped from 21% of changed lines in 2022 to 3.8% year to date in 2026.

I read those two numbers together as the real indicator, more than the 81% headline alone. Code is forking faster, and it is being merged back together far less.

If AI agent-written code already makes up a quarter or more of what your team ships, this indicator is very relevant for you. It is an important requirement your continuous integration (CI) pipeline does not have yet.

GitClear's chief executive, Bill Harding, told LeadDev, an engineering-leadership publication, why the number moves this way. Every time someone wants a new capability, he said, "AI creates a new package for it." The cost comes later: "when you realize you have five different implementations of the same thing that are similar yet different."

Every duplicate is a fork of business logic, and forks drift apart until someone patches a bug in one copy without knowing the other three exist.

That matches a pattern I have grown skeptical of over the years: fast tools ship before their guardrails do.

What the evidence says

• Code duplication in AI-assisted codebases is up 81% since AI coding tools went mainstream, according to GitClear's analysis of 623 million commits.
• Error-masking code, the kind that quietly swallows a failure/exception instead of raising it, is up 47%.
• AI does not create sloppy code on its own. Google's DevOps Research and Assessment team, known as DORA, found it amplifies whatever discipline, or dysfunction, a team already had.
• Your cheapest first move is introducing a CI check for duplication and error-masking. A bigger budget request or an architecture rewrite can be the fast-follow.
• Watch the override rate: how often someone ships a flagged pattern anyway. That number tells you whether the gate is working. Do not just measure the trip count, how often the check fires, etc., because they do not tell you anything.

Who this decision is for, and what it leaves open

This is for a team where agent-written commits already sit at-least a quarter of the total. Someone on that team needs to be able to change what CI runs this coming sprint and what the next planning cycle can prioritize. For teams with no significant agentic coding in production yet, this is still important, but you have some time to decide this before it comes back to bite you.

There is a debate whether the check mentioned above belongs in a pre-commit hook or a server-side CI gate. That boundary is genuinely contested, and I explain why further down.

I also do not claim that scaffolding like standing repo instructions will reverse a documented AI-driven problem. That reversal is a plausible hypothesis, and no one has tested it yet. I am flagging it as a hypothesis here instead of settling it.

One more limit sits in the evidence itself. GitClear's numbers come from one vendor's aggregate dataset, not a controlled experiment, and GitClear sells tooling adjacent to the problem it measures. The direction across every metric is consistent enough to act on, but the exact percentages are not guaranteed to hold a year from now.

The decision: what goes into CI first, once agents write a quarter of your commits

Four moves are on the table once agent-written code stops being a novelty and becomes at-least a quarter of your commit history. You can install a CI tripwire that flags duplicate blocks and error-masking patterns. You can extend that same gate to log override rate: how often a flagged pattern gets shipped anyway. You can defend a refactoring budget as a line item in the next planning cycle.

Or you can adopt a zero-cost habit. Have a second, fresh-context pass review each diff before it is proposed, catching near-duplicate work before it ever becomes a pull request.

None of these four moves is wrong, and I think that most teams eventually will run every one of them. The real question is sequencing. Which move goes in first? Which goes second? What has to be true before the third and fourth can even work?

Four ways to spend the first week, and what each one actually buys

The four moves differ sharply in cost, approval, and how fast each one produces a number you can act on. The table below lays out the comparison. Two details do not fit neatly into a row.

The CI tripwire needs no budget approval, only a team's own decision to turn it on, which is why it belongs in week one regardless of anything else here.

The fourth option is the adversarial-review habit that Anthropic's engineering documentation recommends for coding agents. It is the only one that produces no aggregate number for a dashboard. A second, fresh-context review pass catches a near-duplicate before a diff even exists, but nothing forces anyone to run it.

The criteria that actually decide it, scored side by side

Where the answer flips: how far away your next planning cycle is

Get the tripwire running regardless of the calendar. What changes is what you lead with when the budget conversation comes up. If your next planning cycle is a quarter or more away, run the gate. Let override rate bake for four to six sprints, then walk into that meeting with your own team's number.

A sprint's worth of local data beats a stronger argument built on someone else's aggregate.

The first objection any industry statistic gets in a budget meeting is that your team is different. A screenshot of your own dashboard closes that objection.

If the planning cycle is only weeks out, that calculus does not hold. A gate installed yesterday has not had time to produce a trend, and a number that only just started existing is not yet an argument. In that narrower case, open with GitClear's aggregate now. It is the only evidence available to you. True your own figure up against it the next time the budget comes up for review, which it will.

What a CI tripwire does not fix

A tripwire only gates code that has not been written yet. The 73 duplicated blocks per million changed lines, and the elevated error-masking constructs, already sit in last quarter's merges. Someone still has to go find them. That is a refactoring-budget problem rather than a CI problem.

A mechanical check is also only as good as the test suite it runs against. An error-masking construct is, by definition, a catch block hiding a failure nobody wrote a test for. The engineer Charity Majors drew this line years before coding agents existed: testing catches known-unknowns, the failures you already expected and tested for. Observability catches the failure nobody thought to check for, and a duplicate-block scanner inherits the same blind spot.

It cannot flag a masked failure that never shows up as a duplicate pattern

The newsletter Awaiting Input has described the resulting handoff well. The person who originally developed/prompted/vibe coded a system using AI native SDLC moves on. Then whoever inherits the bug ticket, finds a service that he/she struggles to find someone still left fully understands. That handoff is exactly why the CI check and the refactoring budget belong in two separate line items.

When this recommendation stops holding - watch out for these

A check enforced only as a pre-commit hook is one --no-verify flag away from not being enforced at all. A client-side version, editable by whoever set it up, is not the same control as a server-side gate nobody can quietly skip. Treat the two as different tools with different guarantees.

If more than one team runs its own version with a different threshold, the override-rate numbers stop meaning the same thing across the organization. The fix is one centrally-owned, versioned check with a documented default, rather than many local variants.

Standing instruction files like AGENTS.md have a shelf life of their own. AGENTS.md is a shared spec that agents read before writing any code, and, it gets adopted across thousands of repositories.

Another important issue (general issue, not just specific to this discussion): A file describing an architecture from two reorganizations ago still gets followed anyway, with the same unearned confidence that Microsoft Research found people extend to AI output generally.

That same study, covering 319 knowledge workers across 936 AI-assisted tasks, found that higher confidence in a tool's output tracked with less critical-thinking effort. Higher confidence in one's own skill tracked with more. Fifty-eight of those workers said, in open-ended answers recorded in the study's published proceedings, that they lacked the domain knowledge to check what the tool gave them.

Nobody has named who owns keeping a shared instruction file current, which makes it the kind of artifact a stale runbook already is.

One more boundary belongs here. A controlled study by the AI-evaluations research group METR found experienced developers were 19% slower with AI assistance. They believed they had been 20% faster. The study used tooling two model generations old, with testers who had up to about 50 hours of experience with it.

Whether AGENTS.md-style scaffolding actually reverses that slowdown with current tooling has not been tested. I would treat it as a hypothesis with good priors rather than a result to plan a budget around.

The one rule to apply this sprint

Install the mechanical check this week no matter what the calendar looks like. It costs a day in every scenario, and it targets the two numbers moving fastest. Let the calendar, not preference, decide what you lead with in the budget conversation. Use your own override-rate data if the next planning cycle is a quarter or more away. Use GitClear's aggregate if it is only weeks out. Either way, true your own number up against that aggregate the next time the budget comes up.

What I want to see in the comments

If you install this check this week, come back in a sprint and tell me your override rate. How many times did a flagged duplicate or a masked error ship anyway? That number, not the trip count, is the one that tells you whether the gate is doing anything or just adding jazz to a dashboard nobody cares about :-).

Citations & Further Reading

• The Maintainability Gap: 2026 AI Code Quality Research (GitClear)
• Code maintainability plummets in the AI coding era (LeadDev)
• Slop-Creep: When Building Gets Cheaper Than Thinking (Awaiting Input)
• The Impact of Generative AI on Critical Thinking (Microsoft Research)
• The Impact of Generative AI on Critical Thinking (ACM CHI 2025 proceedings)
• 2025 DORA AI Capabilities Model (Google Cloud)
• Observability is a Many-Splendored Thing (Charity Majors)
• METR: Early 2025 AI Experienced OS Dev Study
• AGENTS.md open standard
• Claude Code docs, "Best practices for Claude Code"