Technical Debt Accumulation in AI-Assisted Codebases

AI-generated code has stopped being a curiosity and become the default. Stack Overflow's Developer Survey found 84% of developers now use or plan to use AI tools, up from 76% the year before, and Sonar's State of Code survey puts AI's share of committed code at 42% today, headed for 65% by 2027. Google and Microsoft both said in 2025 that AI writes more than a fifth of their new code, and GitHub logged over 1.1 million public repositories using AI coding tools between 2024 and 2025. At that scale, even a small defect rate in AI output turns into a debt problem sitting across millions of live repositories, and the argument about code quality stops being academic.

Why AI-generated debt differs from familiar technical debt

Ward Cunningham coined "technical debt" in 1992 to describe a trade a human engineer makes on purpose, shipping the quick version now, paying down the shortcut later, and knowing the whole time which corner got cut. That's a choice with a name attached to it. Someone can point to the line, explain why it's there, and put it on a list to fix.

AI-generated debt skips the part where anyone chooses anything. A large language model writes inside a narrow context window with no memory of the system it's joining, no sense of the team's conventions, no awareness of the invariants some other engineer built the architecture around three years ago. It optimizes for answering the prompt in front of it, not for fitting into the codebase around it. The output looks right. It reads clean, follows familiar patterns, and often runs on the first try. But nobody made a trade-off, because the model is weighing only how to answer the prompt in front of it." It's just producing the most plausible next chunk of code given the prompt, and plausibility is not the same thing as fit.

Some researchers working on technical debt in AI-assisted development have proposed a distinct category for debt that comes not from a deliberate shortcut but from genuine uncertainty about whether AI-generated code behaves the way it looks like it behaves. That's a meaningfully different animal from what Cunningham described, and the field is only now building out the vocabulary to talk about it properly.

The empirical record: what large-scale studies find when AI code enters production

The most complete look at this so far comes from a study called "Debt Behind the AI Boom," which tracked 304,362 verified AI-authored commits across 6,275 public GitHub repositories, spanning five assistants: GitHub Copilot, Claude, Cursor, Gemini, and Devin. It follows issues from the moment they enter a codebase all the way to the repository's latest revision, rather than just snapshotting a single point in time.

The study identified 484,606 distinct issues. Of the AI-introduced ones tracked over time, 22.7% were still present at the latest revision. That's not a bug that got introduced and then cleaned up on the next pass. That's a defect that survived ordinary maintenance, code review, and however many subsequent commits touched the surrounding code. The survival rate is the number that matters here, because it says the debt doesn't wash out on its own. It sits there.

LinearB's 2026 Software Engineering Benchmarks Report backs this up from a different angle, pulling from 8.1 million pull requests across 4,800 teams. AI-generated code carries 1.7 times more issues than human-written code, and teams see technical debt climb 30 to 41% after adopting AI tools. Pull request volume goes up. So does the incident rate. Teams are shipping faster and breaking more, at the same time, as the same trend.

The specific debt types AI assistants introduce and how each behaves over time

Maintainability debt

This is the biggest bucket by far. In the "Debt Behind the AI Boom" dataset, 89.3% of all AI-introduced issues are code smells: structural problems that don't crash anything today but make the code miserable to touch six months from now. Bare-except blocks that swallow errors silently. File opens with no explicit encoding set. Calls to functions that are already deprecated. Variables declared and never used again.

One commit from the dataset, a Claude Code change to the ArchiveBox project (27,000-plus GitHub stars), updated the metadata loading logic correctly, in the sense that it worked, while introducing structural issues of exactly the kind the dataset flags most often. Nothing failed. The debt just sat there, waiting.

GitClear's analysis of 211 million changed lines found something closely related: duplicated code blocks jumped eightfold in 2024, landing at a rate ten times higher than two years earlier, while refactoring activity fell over the same stretch. For what GitClear says is the first time in the history of software development, the number of cloned lines outran the number of refactored lines. Code smells don't set off alarms. They pass through the same review process that let them in to begin with, and they just keep piling up.

Security debt

Veracode tested more than 100 large language models across 80 coding tasks in 2025 and found AI-generated code introduced a security vulnerability 45% of the time, with failure rates above 70% for Java specifically. Veracode's follow-up 2026 GenAI Code Security Report found the number barely moved: about 44% of tasks introduced a risky vulnerability, with an overall pass rate of 56%. That's essentially flat year over year, which means the problem isn't correcting itself as the models improve.

The 2025 CVE-2025-48757 incident on the Lovable platform put a real face on this. Applications built on the platform shipped with Postgres row-level security policies either absent or misconfigured, and 10.3% of the deployments analyzed leaked PII, financial records, and hardcoded API keys to anyone who appended ?select=* to the right endpoint. Across the Veracode studies, roughly 44 to 45% of AI code generation tasks introduced a risky security vulnerability.

Correctness debt

The "Debt Behind the AI Boom" dataset turned up tens of thousands of functional bugs, and one recurring pattern was the undefined variable. A Devin agent, working on the firecrawl repository (98,000-plus stars), committed code that passed cache=cache as a parameter, except the variable it was referencing had never been defined anywhere, a runtime failure waiting in production.

What makes this category dangerous isn't that the code crashes right away. Most of it doesn't. It compiles, it passes the happy-path test the same model wrote for it, it reads like idiomatic code a competent engineer would write, and it's subtly wrong in a way that becomes visible only months later as an incident nobody can trace back to its source.

Comprehension debt

Addy Osmani, an engineering leader at Google, named this category in a blog post published in March 2026 that O'Reilly Radar reposted the following month. Comprehension debt is the growing gap between how much code exists in a system and how much of it anyone still genuinely understands. Traditional technical debt announces itself: things get slower, friction builds, people complain. Comprehension debt doesn't. It breeds false confidence instead, because the code is there, it runs, and it looks fine.

The mechanism is production volume. AI tools generate somewhere between 140 and 200 lines of meaningful code in the time a focused human developer produces 20 to 40. That's a five-to-sevenfold gap, and it outpaces what any team can actually absorb and understand as it comes in.

An internal Anthropic study found developers who mostly used AI for generation scored 50% on comprehension assessments of their own codebase, against 67% for developers who wrote more of the code by hand themselves. That's a 17-point gap, and it held across experience levels, including among senior engineers who, in theory, should know better.

Research into AI-assisted development has found the same pattern from another direction. Developers who used AI without restriction built features faster than control groups. But when AI access was removed for subsequent maintenance tasks, heavy users struggled significantly more than those who had used AI more sparingly. High output was masking low understanding the whole time.

Why code review fails to catch AI-introduced debt

Code review, as a practice, was built to catch human failure modes: logic errors, style drift, a missed edge case. It works because a reviewer knows, roughly, what mistakes a human engineer tends to make and reads the diff looking for those specific things.

AI-generated code fails differently. The assumptions baked into it are invisible in a diff, because there's no comment explaining the model's reasoning, just the output. Structural problems look fine in isolation and only become visible when a module interacts with some other part of the system weeks later. None of that is what a reviewer's eye is trained to catch.

There's also a trust problem layered on top of the structural one. Prior research on developer behavior has found people are more likely to over-trust AI suggestions, which pushes acceptance rates up even when the code contains real issues. The review process, mismatched to the failure mode, is also psychologically compromised, because the reviewer's guard is lower for code that looks machine-generated and therefore "probably fine." It's psychologically compromised too, because the reviewer's guard is lower for code that looks machine-generated and therefore "probably fine."

A volume problem compounds both of those: junior developers using AI assistants can produce code faster than senior developers can read it closely enough to catch what's wrong. Junior developers using AI assistants can produce code faster than senior developers can read it closely enough to catch what's wrong. The peer review bottleneck used to be an inconvenience. Without anyone really designing it that way, the peer review bottleneck also functioned as a quality gate. That gate doesn't hold anymore once one side of the review is producing at machine speed and the other side is still reading at human speed.

How the debt compounds over an 18-month adoption arc

This shape shows up consistently enough across teams to walk through as a rough timeline.

Months one through three feel great. Features that used to take days now ship in hours, and the code looks correct, so review processes feel like they're keeping up even when they aren't really testing for the new failure modes.

Months four through nine are the plateau. Integration problems start surfacing, changes break things in ways nobody predicted, and this is roughly where the 66% of developers who report spending more time fixing "almost-right" AI code are living. The code was never wrong enough to reject at review. It was just wrong enough to cost time later.

Months ten through fifteen are where the early debt turns load-bearing. New features now require digging through AI-generated components from months back, components that were never really understood in the first place, and touching them gets expensive precisely because nobody can say with confidence what else depends on them.

Months sixteen through eighteen are where delivery slows down for real. Comprehension debt has made the codebase genuinely opaque to the people who are supposed to own it, and teams start losing the confidence to navigate systems they built themselves.

The large share of developers who say they don't fully trust AI-generated code are probably somewhere past month nine on this timeline, watching the trust gap widen in real time as the debt becomes visible in maintenance costs. Left unmanaged, the compounding debt documented across these studies translates into maintenance burdens that grow substantially faster than teams anticipate. IBM's Think Insights research puts a number on the executive view of all this: 81% of executives say technical debt is already constraining what their organizations can do with AI. The tools bought to speed things up are the same tools now slowing them down.

What managing this debt requires and where current practice falls short

Fixing this starts with naming it correctly. A code smell caused by a model with no architectural memory is not the same problem as a shortcut a human engineer took under deadline pressure, and treating both with the same review checklist misses the specific failure modes each one produces. Teams need review practices built around what AI actually gets wrong: unencoded file operations, bare-except blocks, undefined variables passed as parameters, missing row-level security on generated database access. Those are known, recurring patterns, not hypothetical risks, and a checklist tuned to catch them would close a real gap in most current review processes.

Comprehension debt asks for something review can't provide at all, because the problem isn't in the code, it's in the gap between the code and the people responsible for it. Osmani's own diagnosis points toward deliberately slowing generation down to match the pace at which a team can actually absorb and understand what's being written, rather than letting output run ahead of comprehension indefinitely. That runs against the entire economic case most organizations made for adopting AI coding tools in the first place, which is why so few teams have done it.

The volume mismatch between how fast AI produces code and how fast a senior engineer can meaningfully audit it is a structural constraint that hiring more reviewers cannot solve. It's a structural constraint, and it means some organizations will need to accept slower shipping in exchange for code they still understand eighteen months out. Given that 81% of executives already say debt is constraining what AI can deliver for them, that's not a hypothetical bill. It's one that's already arrived and is currently being paid, mostly in the form of maintenance cycles nobody budgeted for.