2026-07-25 · 5 min read

Technical debt is sneaking in through AI-generated code

Earlier this month LeadDev's Bill Doerrfeld pulled together the evidence that the AI coding era has a maintainability problem, and the centerpiece is hard to argue with: GitClear's analysis of 623 million code changes from 2023 to 2026. Code duplication is up 81%. Refactoring is down 70% against the 2022 baseline. Error masking, code that silently swallows failures instead of surfacing them, is up 47%. Here's the part that should bother reviewers specifically: not one of those numbers comes from code that failed. It all compiled, passed its tests, and got approved by a human.

What the numbers actually measure

These aren't vibes about "AI slop", they're operations counted across real commits. Duplication means a new block that repeats logic which already exists somewhere in the repo. The collapse in refactoring and in "move" operations means code stopped being consolidated: GitClear's CEO Bill Harding describes the end state as realizing "you have five different implementations of the same thing that are similar yet different." And error masking is the quiet one: wrapping a call so its failure disappears, which reads as defensive programming right up until an incident is untraceable. Harding's explanation for why models do this is blunt: "AI strongly prefers to write code that won't be labeled as a defect." Hiding the error is the shortest path to looking correct.

The costs are already measurable downstream. Google's DORA research found that every 25% increase in AI usage brings roughly 7% more delivery instability. GitClear's own research roundup adds the paradox on top: heavy AI users produce more durable code per hour and also 9x more churn. The code arrives faster, and it also gets rewritten faster, because nobody consolidated it the first time.

Why review waves it through

Every gate in the pipeline before the reviewer checks one question: does this code work? The compiler checks it, the tests check it, CI checks it. Maintainability is invisible to all of them, and it's nearly invisible in the diff view too. A duplicated helper doesn't look like duplication in the diff, it looks like a tidy new function, because the diff shows you what was added and not the three existing implementations it ignores. A swallowed exception looks like caution. A new dependency for something the repo already does looks like initiative. The only checkpoint in the whole pipeline that can ask "should this exist in this shape at all?" is the human reading the diff, and that human is busier than ever.

This is worth saying plainly: approving working code is how debt gets in. Nobody merges a broken build into main. The 81% duplication surge went through thousands of reviews where the code did exactly what the ticket asked, and the reviewer had no cheap way to see what it was doing to the repo.

Three review habits the numbers argue for

• For every new helper, ask where its siblings live. A thirty-second repo search for the function's key phrase before approving. If it's the second implementation, ask for a reuse; if it's the fifth, ask for a consolidation. Thirty seconds of searching against the 81% duplication trend is the best trade on this list.
• Treat swallowed errors as findings, not style. A catch block that logs nothing and rethrows nothing is a bug that hasn't happened yet, and it deserves a request-changes even when every test is green. The 47% masking growth exists because this pattern reads as harmless.
• Ask what the diff should have deleted. AI-written changes add and almost never remove: the 74% drop in legacy maintenance means the tending work has to be explicitly requested now. "This replaces the old path, so remove the old path" is a legitimate review comment.

The skill is rejecting code that works

None of this is about catching bugs in the classic sense, and that's what makes it hard. Saying no to a diff that compiles, passes tests, and satisfies the ticket takes a specific kind of confidence, and it atrophies if you never practice it. On DiffDojo that judgment is part of the curriculum: over-engineering is one of the nine planted-bug categories, some PRs in the library are deliberately working code that still deserves a request-changes, and the grading compares your verdict against a canonical review that explains why. Today's PR is free, no signup. The maintainability numbers say the industry approves too easily; the fix starts with reviewers who can articulate why "it works" isn't the bar.

Read next: Engineering leaders should check AI-generated code more than ever