You’ve probably scrolled past it without registering what it was: the same fifteen lines of validation logic, pasted into three different files, each copy patched by hand with a slightly different fix. A human engineer would eventually extract that into a shared function, mostly out of pride. An AI coding agent has no pride, and increasingly no need to bother — it just needs the pull request to pass. That distinction sits at the center of “The Maintainability Gap” , a July 2026 study from developer-analytics firm GitClear and GitKraken , built on 623 million real-world code changes tracked between 2023 and 2026. Yesterday’s headline number, Microsoft’s durable 24% lift in merged pull requests , told the upside of AI-assisted development. This report is the same ledger’s other column, and it argues that throughput gain is being financed on credit that someone, eventually, has to repay.
The debt shows up as duplication, not defects
The report’s numbers describe a codebase growing faster and tidying itself less. Within-commit copy-paste — the same block typed or pasted twice inside one change — is up 41%. Duplicated blocks, meaning five or more consecutive lines repeated near-verbatim elsewhere in the codebase, are up 81%. Error-masking constructs, the defensive try/catch and null-check wrappers that swallow a problem instead of fixing its cause, are up 47%. Meanwhile the un-glamorous work that keeps old code alive is quietly disappearing: cross-file function reuse is down 35%, the “Move” refactors that relocate logic into a shared, sensible home are down 70%, and legacy-code maintenance overall is down 74% since 2023. GitClear’s CEO, Bill Harding, frames it plainly in the LeadDev write-up
: “It’s not just duplication, it’s about not tending to legacy code.” The same piece cites production-database incidents at Replit and PocketOS as evidence the gap isn’t abstract — it eventually shows up as an outage, not a lint warning.
| Category | % change since 2023 |
|---|---|
| Within-commit copy-paste | 41 |
| Duplicated blocks | 81 |
| Error-masking constructs | 47 |
| Cross-file function reuse | -35 |
| Move refactors | -70 |
| Legacy-code maintenance | -74 |
What makes this more than a hygiene complaint is where the incentive sits. A coding agent — and, just as often, the developer accepting its suggestions under deadline — is judged on whether the diff resolves the ticket and clears review, not on whether the codebase it leaves behind is easier to touch next quarter. Extracting a shared function, walking through a legacy module nobody wants to own, letting an error surface instead of catching and hiding it: none of that helps a pull request merge faster, so it’s the first thing skipped once speed is the metric being watched.
Agents are graded on whether the pull request merges, not on the codebase it leaves behind.
A rival study finds no such churn, and the alarm has a seller
The honest complication is that this narrative is genuinely contested, and the loudest voice making it has a stake in the answer. A peer-reviewed longitudinal analysis of 151 open-source repositories with self-admitted GenAI usage , revised in April 2026, tracked code churn across those projects and found “no general increase, contradicting popular narratives” — if anything, a decreasing trend. GitClear, meanwhile, is a commercial developer-analytics and technical-debt-monitoring vendor; a “maintainability is collapsing” story is also, not incidentally, a pitch for exactly the dashboards GitClear sells. Even Harding hedges his own numbers, conceding that “some signals seem to be flattening.” The two studies aren’t strictly comparable — GitClear scanned 623 million changes across a broad commercial and open-source mix, while the arXiv sample is 151 repositories whose maintainers had explicitly disclosed AI use — so neither cleanly overrules the other. What they jointly suggest is that the picture is younger and shakier than either camp’s confidence implies, and GitClear’s steepest percentages are worth holding a little more loosely than the report’s own framing invites.
The tab doesn’t split evenly across a team
That uncertainty doesn’t erase the mechanism, though — it just means the size of the bill is contested, not its existence. And the bill, where it’s real, doesn’t land evenly. A team’s most experienced engineers tend to be the ones who notice duplication, who still do the legacy-module reading nobody assigns, who catch the error-masking wrapper before it ships — meaning the maintenance work AI throughput is deferring concentrates on precisely the people least likely to show up in a PR-volume chart. It’s the same blind spot that surfaced when Amazon and Meta scrapped internal AI-usage leaderboards because a metric optimized in isolation stopped describing anything the companies actually wanted, and it echoes FrontierCode’s finding that even the best models clear only a small share of genuinely hard, mergeable-quality tasks : the easy majority of a pull request is not evidence about the hard remainder, and a rising merge count is not evidence about the codebase underneath it.
None of this argues AI-assisted coding is a bad trade — a durable 24% lift in shipped work is not nothing, and the churn data isn’t settled either. It argues that most teams are pricing only one side of a trade with two. Throughput gets dashboarded, reviewed in standups, celebrated in rollout decks. Maintainability is the slower number nobody screenshots — the photocopier still running after the meeting that needed the handout has ended, quietly producing more of something that already existed.



