What Is AI Code Bloat? How to Measure and Manage It

What is AI code bloat, and how do you measure and manage it?

AI code bloat is a real, measurable problem, not a vibe. It shows up as more duplicated code, less reused code, and more defensive error-handling that hides bugs instead of fixing them. The fix isn't slower AI. It's tracking the right numbers and gating merges on them, the same way teams already gate on test coverage.

Is AI code bloat actually a problem, or just a vibe?

Ask most engineering leaders whether AI coding assistants are a net win and you'll get a fast yes. Ship velocity is up. Pull requests close faster. The code runs. But ask the same leaders whether their codebase is easier to maintain than it was two years ago, and the answer gets quieter.

That gap between "it works" and "it's maintainable" is the whole story. AI coding tools are optimized, explicitly or by training incentive, to produce code that passes a test or satisfies a prompt. Nothing in that loop rewards writing less code, reusing existing code, or leaving a codebase easier to read than it was found. The result is a quantifiable shift in how code gets written, not just a feeling that something's off.

GitClear's analysis of 623 million code changes between 2023 and 2026 put a number on that shift: code block duplication, meaning five or more repeated lines, rose 81% versus 2023 levels, hitting 73.0 duplicated lines per million changed lines in 2026, the highest figure the firm has recorded. That's not a rounding error. It's a structural change in how code gets written when the author is a model instead of a person.

What does "AI code bloat" actually mean?

"Bloat" used to mean one thing: too many lines. In the AI era it means something more specific, and more diagnosable. Four failure modes show up consistently across the data.

• Duplication over reuse. Instead of calling an existing function, AI assistants frequently write a new, similar block from scratch. GitClear found that "moved" or refactored code fell from 21% of changed lines in 2022 to just 3.8% in 2026, while copy-paste code rose to 15.7% of changes, a roughly 5x preference for duplication over refactoring, compared to a 2x preference for refactoring in the pre-AI year of 2022.
• Falling code reuse. Cross-file function connectivity, a proxy for how much new code calls into existing code rather than reinventing it, dropped 35% since 2023.
• Abandoned legacy code. Updates to code untouched for 12+ months, the normal signal of a team maintaining its own history, fell 74% since 2023. AI-era codebases increasingly look like layers of new, isolated code stacked on top of old code nobody goes back to touch.
• Error-masking instead of error-handling. GitClear also measured a 47% increase in "obfuscation," meaning broad catch blocks and stubbed methods that silently swallow unexpected inputs instead of addressing their root cause. GitClear's CEO frames this plainly: whatever gets swallowed today becomes technical debt for whoever maintains the code later.

Put together, these four patterns describe a codebase that grows but doesn't consolidate. Volume goes up. Integration goes down.

What did large-scale studies actually find?

GitClear's dataset is the biggest single source here, but it isn't the only one, and the fact that independent studies land on the same conclusion through completely different methods matters.

A large-scale academic study tracked 302,579 AI-authored commits across 6,299 real-world GitHub repositories and found 484,366 distinct introduced issues. Of those, code smells, meaning maintainability problems rather than outright bugs, accounted for 89.3% of all AI-introduced technical debt, versus 6.0% correctness issues and 4.7% security issues. More than 15% of commits from every one of five major AI assistants studied (GitHub Copilot, Claude, Cursor, Gemini, and Devin) introduced at least one quality issue, and 22.7% of all tracked issues were still present in the latest version of the repository, meaning the debt usually doesn't get fixed. It just accumulates.

A causal difference-in-differences study of Cursor adoption across real GitHub projects found a 3-5x transient spike in lines added in the first month that faded within two months, while static analysis warnings rose 29.7% and code complexity rose 40.7%, persistently. The researchers found that accumulated complexity subsequently reduced future development velocity, a self-reinforcing cycle where today's speed becomes tomorrow's drag.

Google's 2024 DORA report found the same pattern at the organizational level: a 25% increase in AI adoption is associated with a 7.2% decrease in software delivery stability and a 1.5% decrease in delivery throughput. DORA's explanation is that AI lets developers generate code faster, which produces larger batch sizes that are slower to review and more prone to destabilizing the system.

CodeRabbit's review of 470 real-world GitHub pull requests quantified the review burden directly: AI-generated code produced roughly 1.7x more review issues than human-written code, 10.83 versus 6.45 per PR on average, widening to 26 versus 12.3 at the 90th percentile. Logic and correctness errors were 75% more common, and security vulnerabilities were up to 2.74x higher. A separate survey of 31 professional developers found that integration difficulty, technical debt accumulation, and hard-to-follow logic were the most common complaints, with "comprehension burden" emerging as a distinct failure mode: developers accept AI code faster than they can build an actual mental model of it. That gap between acceptance speed and comprehension speed is where most of this bloat quietly lives, and our sloppiness measurement framework goes deeper into how to catch it before merge.

Why don't benchmarks catch AI code bloat?

Here's the uncomfortable part: none of this shows up on the leaderboards most teams use to pick a model. Benchmarks like SWE-bench measure whether a patch solves a task and how expensive it was to run. They do not measure how much code the model added to get there, how much of that code duplicates something already in the repo, or how many of its branches are defensive error-swallowing dressed up as handling.

That means a model that solves a bug by adding forty lines and a model that solves the same bug by adding four score identically, as long as both pass the test suite. Solve rate rewards the destination, not the mess left on the way there. Our Taste-Tester Protocol exists precisely because teams kept finding that benchmark-topping models still produced code a human reviewer wouldn't sign off on.

How does Parsimony score models by how little code they need?

A newer open-source benchmark called Parsimony tries to close that gap directly. Instead of counting lines, it counts "coding units," meaning individual syntax elements like statements, function calls, comparisons, variable names, and literals. It then computes a net score: units added minus units removed. That design choice matters for two reasons. It stops models from gaming line-count metrics by cramming multiple statements onto a single line, and it gives credit for deletions, which almost no other benchmark does.

Parsimony's own data is honest about the tradeoff involved. Across more than 26 models, there's a positive correlation, Spearman coefficients between 0.33 and 0.60 depending on the leaderboard, between how much code a model writes and how often it solves the task. In other words, parsimony and capability pull against each other, at least somewhat. There's no free lunch where the leanest model is automatically the most correct one.

Still, the spread is informative. On Parsimony's DeepSWE Python leaderboard, net code added across top models for solved tasks ranges from roughly 1,480 to over 2,500 coding units per task, meaning the most verbose model in the comparison added roughly 1.7x more code than the most parsimonious one to solve comparable problems. That's a real, measurable difference in how much maintenance burden two models leave behind for the same correct outcome, and it's exactly the kind of number a procurement decision should weigh alongside solve rate.

How do you govern AI code bloat at the source-control layer?

Benchmarks help you pick a model. They don't govern what a team actually ships. For that, the leverage point is the pull request, because it's the one place every AI-authored change has to pass through regardless of which tool wrote it.

Practical governance now centers on a few concrete mechanisms:

1. Branch protection and required checks. No AI-authored diff merges without passing the same CI gates a human-authored diff would face.
2. Policy-as-code. Path-based review rules apply automatically, so a change to a payments module gets stricter scrutiny than a change to a style sheet, regardless of authorship.
3. Duplicate-block tripwires. Automated checks flag new code blocks that closely match existing ones, catching the copy-paste pattern GitClear measured before it ships.
4. Codeowner approval. A human with context on the affected system signs off, not just a passing test suite.
5. Audit trails. A record connects the task, the agent's identity, the policy version in force, the resulting commit, test results, review findings, and the human approval, which matters most in regulated environments where you need to reconstruct who approved what and why.

None of this is exotic. It's the same discipline mature teams already apply to human-written code, applied without exception to AI-written code. The teams struggling most are the ones that quietly carved out an "it's just AI code, ship it" exception. Clear specs upstream reduce how much defensive, bloated code an agent writes in the first place, which is cheaper than catching it downstream.

Which metrics should you track to manage AI code bloat?

If solve rate and test pass rate are the only numbers your team watches, you're measuring correctness and ignoring cost. A practical scorecard adds:

• Net code added. Lines or coding units added minus removed, tracked per merged PR, not just per commit.
• Duplication rate. The frequency of five-plus-line repeated blocks, the exact metric GitClear tracks at scale.
• Refactor-vs-paste ratio. How often changed code moves and consolidates existing logic versus pasting new logic alongside it.
• Function connectivity. How much new code actually calls into existing functions rather than reimplementing them.
• Error-masking density. The rate of broad catch blocks, stubbed methods, and other constructs that suppress rather than resolve unexpected input.
• Legacy touch rate. How often code older than 12 months gets revisited and updated versus left to rot untouched.

None of these require exotic tooling. Most can be derived from existing git history and static analysis output. The point isn't perfection on any single number. It's having a baseline, so a 40% jump in duplication rate after adopting a new agent gets caught in a sprint retro instead of three years later during a painful rewrite.

What does this mean for build vs. buy, and for owning your software?

This matters most for teams that build their own internal software instead of renting SaaS, because that's exactly the software most likely to be AI-authored and least likely to get traditional code review rigor. An internal tool thrown together by a non-engineer with an AI assistant can absolutely work on day one and still be an unmaintainable mess by month six, full of duplicated logic and silent error-swallowing nobody budgeted time to find. That's not an argument against building your own tools. It's an argument for treating code volume as a cost line, not a side effect, when you decide whether owning a piece of software is actually cheaper than renting it. Ownership only pays off if the thing you own stays maintainable. The same logic applies to non-engineers building their own internal tools: speed without a maintainability metric isn't a win, it's a loan against your future engineering time, and the data above suggests that loan comes with a higher interest rate than most teams assume.

The AI didn't make your code worse at running. It made your code bigger, more duplicated, and better at hiding its own mistakes. Managing that isn't a benchmark problem anymore. It's a governance problem, and governance only works when you're measuring the thing you're trying to control.