AI Is Writing More of Your Codebase. Is It Making the Codebase Worse?
If your team ships with Copilot, Cursor, Claude, or any of the dozen other AI coding assistants now embedded in daily workflows, you already know AI-generated code makes up a real chunk of your commits. What’s less clear is what that code looks like six months after it merges.
A new research report from GitClear, published July 7, 2026, tries to answer that question with the largest dataset yet assembled on the topic: 623 million real-world code changes tracked from 2023 through 2026. The findings, first reported by LeadDev, suggest that as AI-assisted commits have scaled up, several long-standing indicators of codebase health have moved in the wrong direction — at the same time.
This isn’t a hit piece on AI tooling, and it shouldn’t be read as one. It’s a data point worth taking seriously, alongside other 2026 research showing genuine productivity gains from the same tools. The interesting part isn’t “AI bad” — it’s why these specific patterns are showing up, and what engineering teams can do about it without giving up the tools that are now part of how software gets built.
What GitClear’s 623-Million-Commit Study Found
GitClear tracked eight distinct code-quality signals across the four-year window, comparing pre-AI-adoption baselines to 2026 behavior. The headline numbers:
Rising risk signals: – Code duplication is up 81% — from roughly 40 to 73 duplicated blocks per million changed lines – Within-commit copy/paste is up 41% – Error-masking constructs are up 47% — catch/rescue blocks and safe-navigation operators that swallow exceptions without addressing the underlying cause – Two-week code churn (code rewritten or deleted shortly after being written) is up 15%
Declining reuse signals: – Cross-file function calls (a proxy for functional connectivity) are down 35% — from 343 to 223 calls per thousand lines – Refactoring line-moves are down 70% – Legacy code maintenance is down 74%, and the share of commits classified as genuine refactoring fell from roughly 21% in 2022 to under 4% in 2026
Put simply: developers using AI assistance are now roughly five times more likely to copy-paste a block of logic than to extract it into a reusable function — a near-total reversal of the pattern GitClear observed before AI coding tools were widespread.
GitClear CEO Bill Harding framed the underlying dynamic bluntly: “Every time you want something, AI creates a new package for it.” The consequence, he says, is codebases with “all sorts of consequences” down the line — “you realize you have five different implementations of the same thing that are similar yet different.” He also pointed to a structural incentive baked into how these models are trained: “AI strongly prefers to write code that won’t be labeled as a defect,” which helps explain the rise in error-masking patterns — a try/catch that silently swallows an exception looks “resolved” to an automated eval, even though the root cause is untouched.
Reportedly, AI-assisted commits now account for roughly a quarter of all commits in the datasets GitClear analyzed — a share that’s grown steadily since 2023 and shows no sign of plateauing.
This Isn’t the Whole Picture
It’s worth putting GitClear’s findings next to other credible 2026 research, because the story gets more nuanced — not less concerning, but more useful.
Sonar’s 2026 State of Code Developer Survey found that AI now accounts for 42% of committed code industry-wide (expected to hit 65% by 2027), and that 72% of developers who try AI tools end up using them daily. But the same survey surfaced what Sonar calls a “verification gap”: 96% of developers say they don’t fully trust AI-generated code to be functionally correct, yet only 48% say they always check it before committing. Notably, 88% of respondents cited negative technical-debt effects — most commonly unreliable-looking code (53%) and duplicative code (40%) — which lines up closely with what GitClear measured independently in production repositories rather than self-reported surveys.
On the productivity side, the picture is mixed rather than uniformly bad. A METR randomized controlled trial found that experienced open-source developers using AI tools on unfamiliar, mature codebases were actually 19% slower than working unassisted — even though they believed, both before and after, that AI had sped them up. That’s a useful check on the assumption that “more AI usage” automatically equals “more output.” At the same time, plenty of teams report real, measurable gains on greenfield work, boilerplate, test scaffolding, and documentation — Sonar’s own data shows 93% of respondents citing at least some positive effect, including better documentation and improved test coverage.
The honest synthesis: AI coding assistants are genuinely useful for velocity on well-scoped tasks, and genuinely risky for long-term codebase health when adopted without changes to review discipline. Both things are true simultaneously, and the GitClear data is really measuring the second half of that equation.
Why This Happens: The Incentive Problem, Not a Model Problem
It’s tempting to treat this as an “AI writes bad code” story, but the more accurate framing is an incentive and workflow story:
- Generation is now nearly free; consolidation still isn’t. Writing a new helper function costs a developer a prompt. Noticing that four near-identical helpers already exist, and merging them, still costs real cognitive effort — so it gets skipped.
- AI models optimize for “looks correct” and “doesn’t throw,” not “fits the existing architecture.” A model with no persistent memory of your codebase’s conventions will default to writing something new and self-contained rather than threading a change through existing abstractions.
- Catching an exception silences the symptom fastest. If the implicit success metric is “no unhandled error,” a broad catch block scores well even when it hides a bug.
- Review capacity hasn’t scaled with commit volume. If a quarter of commits are AI-assisted and reviewers are still applying the same skim-level scrutiny they used pre-AI, duplication and shallow error handling will sail through.
None of this is inherent to the technology. It’s a description of what happens when a fast code-generation tool is dropped into a review and refactoring process built for a slower, more deliberate era of hand-written code.
Practical Guidance: Using AI Coding Tools Without the Debt
Teams that are avoiding this pattern tend to treat AI output the way they’d treat a capable but unfamiliar junior engineer’s pull request — genuinely useful, but not something you merge on trust.
- Review AI-generated PRs like any other PR, not faster. Sonar’s data shows 38% of developers already find AI code review more effortful than peer review — budget time accordingly rather than rubber-stamping because “the AI probably got it right.”
- Add a duplication check to CI. Static analysis and code-clone detection (SonarQube, GitClear itself, or similar tooling) can flag near-duplicate blocks before they merge, catching what a human skim will miss.
- Ban blind catch-alls in linting rules. Require that every caught exception either re-throws, logs with context, or has an explicit comment justifying suppression — this directly targets the error-masking pattern.
- Schedule refactoring time deliberately. If AI usage is pushing refactoring commits toward zero, don’t rely on it happening organically — put “reduce duplication in module X” on the sprint board like any other ticket.
- Ask AI assistants to search the codebase before generating. Many tools support codebase-aware prompting or RAG-style context injection; use it. A prompt like “check if a similar utility already exists before writing a new one” measurably reduces redundant output.
- Track functional connectivity, not just velocity. Commit count and lines shipped are vanity metrics if cross-file reuse is quietly cratering. Add duplication rate and refactor percentage to your engineering health dashboard.
- Don’t ban the tools — instrument the workflow. The METR and Sonar data both suggest the problem is usage patterns and review gaps, not the models themselves. Fixing the process captures the productivity upside while limiting the debt.
The Bottom Line
GitClear’s 623-million-commit dataset is the most rigorous look yet at what AI-assisted coding is doing to real, shipped codebases — and the direction of travel on duplication, reuse, and error handling is consistent and concerning. But it’s a call to adjust engineering process, not a case for abandoning AI tooling that a majority of developers now use daily and, per Sonar’s data, find genuinely valuable for parts of their job.
The teams that come out ahead won’t be the ones that ban Copilot or the ones that accept every suggestion unreviewed. They’ll be the ones that keep human judgment — code review, refactoring cadence, and architectural ownership — firmly in the loop while letting AI handle what it’s actually good at: fast, well-scoped generation inside a process designed to catch what it misses.