GitClear has been mining git history since before ChatGPT existed, and its January 2026 report, built from 623 million analyzed code changes between 2023 and the first half of 2026, found that genuine refactoring fell from 21% of changed lines in 2022 to 3.8% year-to-date. Over the same stretch, duplicated code blocks per million changed lines rose 81%. Teams are shipping more than ever. What they're shipping is quietly getting harder to touch a second time, and the dashboard that tracks velocity doesn't show it.
Refactoring nearly disappeared from the average commit
GitClear's numbers trace a specific collapse, not a vague impression. The share of changed lines that count as "moved" code, meaning a developer consolidated or relocated existing logic rather than writing something new next to it, ran at 21% in 2022, dropped to 13% in 2023, and fell to 3.8% year-to-date in 2026. Within-commit copy and paste moved the opposite direction, climbing from 9.4% in 2022 to 15.7% in the first half of 2026. GitClear's own 2023 research, Coding on Copilot, had found developers preferring refactor over redundant code by roughly 2 to 1 back in 2022. By the newest report, that preference has flipped to roughly 5 to 1 in favor of redundant.
So what does that mean for a VP of Engineering reading a sprint velocity chart. Tickets close faster because the fastest way to close one is to write a new, self-contained version of something that already exists elsewhere in the codebase, rather than spend the extra hour finding and extending the old one. That's a rational choice for an individual developer under a deadline. It's also exactly how a codebase accumulates four slightly different implementations of the same rule, none of which get updated together when one of them needs to change.
The debt shows up in structure before it shows up in an incident
Two other signals in GitClear's data point the same direction. Cross-file function connectivity, how often new code calls into an existing function elsewhere in the codebase rather than standing alone, fell 35% since 2023, from 343 calls per thousand changed lines to 223. And "long-term update percent," the share of changes that touch code untouched for over a year, fell 74%, from 1.7% in 2023 to 0.46% year-to-date. GitClear's own framing for that second number is blunt: legacy code isn't being retired or consolidated, it's being left frozen while the codebase grows outward around it.
This is a slower-moving cousin of the tradeoff DORA's 2025 AI amplifier research measured through developer self-report: AI adoption raising throughput and delivery instability together. GitClear's data shows the same tradeoff from the structure side, months or years before it becomes an incident. A codebase where new code stops connecting to old code and old code stops getting revisited is a codebase where the next senior hire spends their first quarter discovering how many versions of "the same thing" actually exist before they can safely change any of them.
Why a duplicated block is the signal worth watching first
GitClear defines a duplicated block as five or more consecutive, meaningfully repeated lines of code, and its measurement of that specific signal, 40.3 occurrences per million changed lines in 2023 rising to 73.0 year-to-date in 2026, is the one its own report singles out as most directly tied to defects in the academic literature it cites, putting duplicated code at 15% to 50% more defect-prone than non-duplicated code. GitClear's earlier February 2025 report, based on 211 million analyzed lines, found 2024 was the first year on record where within-commit copy and paste exceeded genuinely moved code, with commits containing a duplicated block rising roughly tenfold over the two prior years.
The mechanism is what GitClear calls a propagation tax. Change one copy of a duplicated block and you've taken on an unstated obligation to find every sibling copy across files and domains you may not know about, and decide whether the fix needs to travel there too. A code reviewer looking at a single pull request has no way to see that obligation. It shows up later, as a bug that was fixed once and still live everywhere else.
A worked example
Picture a 55-person Series B product company two years into an AI-assisted coding rollout, with a velocity chart leadership is genuinely proud of: story points up, cycle time down, the roadmap ahead of where it was a year ago. A new staff engineer joins to own the authentication layer and starts by tracing every place rate limiting gets enforced, expecting one shared module. Instead there are four separate implementations, written by different engineers (and their AI assistants) at different points over eighteen months, each one solving the immediate ticket in front of it rather than extending what already existed.
Three of the four got hardened after a security review flagged a bypass six months earlier. The fourth, added later by someone who didn't know the other three existed, never did. Nothing in code review caught it, because the pull request that added it looked clean on its own. The gap only surfaces when someone deliberately goes looking for every sibling copy, which is precisely the work GitClear's data shows collapsing across the industry at the same time shipping speed climbs.
What actually closes the gap, and what doesn't
GitClear's report recommends five concrete moves: budget dedicated time for refactoring and legacy maintenance rather than treating it as whatever's left over, put a review tripwire on duplicate blocks specifically, review explicitly for error-masking constructs (which the same report found up 47% over the window), coach the developers whose judgment on this is thinnest, and measure structure, not just throughput. None of that is exotic. What it requires is someone whose job includes doing it, on a codebase where the existing team's calendar is already full of the roadmap that got them praised for velocity in the first place.
That's a real gap staff augmentation closes well: a senior engineer brought in through build-your-team, specifically tasked with the consolidation and review discipline a fast-moving team hasn't had slack to build, the same discipline our piece on whether AI actually makes developers faster argues has to be measured rather than assumed. It's a weaker fit when the real blocker is a prioritization decision rather than a headcount one: if leadership hasn't decided that refactoring time is allowed to compete with the next feature on the roadmap, adding an engineer doesn't fix that, because the same pressure that produced the debt will absorb the new hire's time too. That call belongs to whoever owns the roadmap, not to a contractor brought in to execute it.
If your velocity chart looks great and nobody's traced how many parallel versions of your core logic actually exist, our Silicon Valley team will look at the specific parts of your stack where that's most likely to be true before it turns into an incident. Tell us what you're building and we'll scope it as what it actually is: a code-quality audit, not an open-ended retainer, and one worth pairing with the production discipline in our guide to building an eval harness before you trust a model's output at scale.
Sources
- GitClear: The Maintainability Gap: AI Code Quality in 2026 (published January 2026; 623 million analyzed code changes, 2023 through H1 2026)
- GitClear: AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones (published February 2025; 211 million analyzed lines)
- GitClear: AI Coding Tools Attract Top Performers, But Do They Create Them? (published January 2026; 2,172 developer-weeks of correlation analysis)