Why Technical Debt Rose 30-41% After Teams Adopted AI Coding Tools

Ask most engineering leaders what AI coding tools did to their team's output and you'll hear some version of "we ship faster." Ask what it did to their technical debt and the answer, for a lot of teams, is a number they'd rather not look at. A large-scale analysis of 8.1 million pull requests found technical debt rising 30–41% in the period after teams adopted AI coding tools. That's not a rounding error. That's a third to nearly half more debt accumulating, in the same codebases, under the same engineers, with the primary variable being what wrote the first draft.

The instinct is to read that number as evidence that AI-generated code is simply lower quality — sloppier logic, worse naming, more duplication. Some of that is real. But it's not the dominant mechanism, and treating it as the dominant mechanism leads to the wrong fix (better prompting, better models) instead of the right one (matching review capacity to code volume). The 8.1-million-PR study is best read as a story about throughput outrunning oversight, not about AI writing categorically worse code than humans do.

The mechanism, stated plainly

Before AI-assisted development, the rate at which code entered a codebase was bounded by typing speed and thinking speed, and those two were roughly matched — a developer thinking through a problem and a developer typing the solution moved at similar paces, so review capacity (which scales with headcount and calendar time) could mostly keep up with generation capacity (which scaled with the same things).

AI coding tools broke that coupling. Generation speed jumped by multiples — a competent engineer with an AI assistant can produce in an hour what used to take a day. Review capacity didn't jump with it, because review capacity is still bounded by the same human attention it always was. A senior engineer can review roughly the same number of thoughtful pull requests per week whether or not the code in front of them was AI-generated. The result is a widening gap: more code entering the system than the team has bandwidth to scrutinize, and the overflow doesn't disappear — it becomes debt.

What "technical debt" actually captures here

It's worth being precise about what's rising, because "technical debt" gets used loosely. In this context it means the accumulating gap between what the codebase looks like and what it should look like for the team to move at speed later: duplicated logic that should have been a shared function, abstractions that don't match how the code is actually used, error handling copied-and-pasted instead of centralized, tests that assert the code runs rather than that it's correct. None of these are dramatic failures on day one. They're the things that make month six slower than month one, and month twelve slower still.

AI-generated code is particularly prone to a specific flavor of this: it's very good at producing a locally correct, plausible-looking solution to the prompt in front of it, and much less good at knowing that a nearly identical solution already exists three files over, or that the codebase has a convention this new code doesn't follow. A human working slowly tends to notice these things by osmosis, because slowness comes with more exposure to the surrounding code. Speed removes that exposure.

Why this connects to the security numbers

This is the same underlying dynamic that shows up in the security research — the 65% of scanned production apps with security issues and the doubled secret-leak rate aren't separate phenomena from the technical debt numbers. They're the same root cause — volume exceeding review capacity — showing up in different measurements. Security issues are the acute version (a specific exploitable flaw). Technical debt is the chronic version (a thousand small decisions nobody had time to question). Both come from the same gap.

That's actually useful news, because it means you don't need three separate initiatives to address three separate metrics. You need one thing: a review process that scales with generation volume instead of assuming it will keep up on its own.

Why teams don't notice until it's expensive

Debt is insidious specifically because it doesn't show up in the metrics teams watch day to day. Velocity looks great. Feature output looks great. The dashboard that would show the problem — code review thoroughness per line shipped, or duplication rate, or time-to-onboard-a-new-engineer — usually doesn't exist, because nobody built it before AI coding tools made it necessary. Teams find out they have a debt problem the way most organizations find out: months later, when a routine feature that should take two days takes two weeks, and nobody can quite explain why except "the codebase got messy."

The 30–41% figure is the debt that's already accumulated by the time someone thinks to measure it — which means the real number, for a team that hasn't been watching, is probably still climbing.

What actually closes the gap

The fix isn't slowing down code generation — that throws away the actual advantage AI coding tools provide. The fix is treating review capacity as a resource that needs deliberate investment, the same way teams already invest in CI infrastructure or testing tooling:

• Automated linting and static analysis tuned to catch duplication and convention drift, not just syntax errors — this is where machines can absorb some of the load that used to fall on human reviewers doing careful reads.
• A explicit norm that AI-generated PRs get the same scrutiny as human-written ones, not a lighter pass because "it's probably fine." This is a culture decision more than a tooling one, and it's the one teams skip most often because it's the one that feels like it's slowing things down.
• Smaller, more frequent PRs even when AI could generate a larger one in one pass — review quality degrades sharply with PR size regardless of who wrote it, and AI's tendency to generate large, complete-feeling solutions in one shot works against this unless someone deliberately breaks it up.
• Periodic debt audits treated as a real deliverable, not an afterthought — scheduled time to go find and pay down the duplication and drift that accumulated, rather than assuming it'll get cleaned up "eventually."

None of these require distrusting the tools. They require accepting that a tool that changed one side of an equation — generation speed — needs the other side, review capacity, deliberately rebalanced, because it will not rebalance itself.

Faster code generation was never the risk. A review process sized for the old velocity, quietly falling further behind every sprint, is the risk — and it's invisible until someone finally measures it.

The next piece in this series puts a dollar figure on what happens when that gap goes unaddressed long enough — what the maintenance bill actually looks like once debt this size compounds.

Part of the "From Vibe Coding to Production" series on aiskill.market.