The vibe-coding hangover: what AI-generated code actually costs three months later

Every team we talk to now uses an AI coding assistant for something. That's not really a debate anymore — adoption is past 80% across the industry, and most of it happened in the last eighteen months. The debate that actually matters is what happens to a codebase after six months of a team writing code this way without changing anything else about how they review, test, or refactor it.

The honest answer, backed by more than one large empirical study of AI-assisted repositories, isn't flattering. Technical debt in heavily AI-assisted codebases has been measured rising 30 to 40% compared to the same team's prior baseline. Code duplication climbs — an agent that doesn't know a helper function already exists just writes a new one, and it does this constantly. Refactoring activity drops, because refactoring requires understanding what's actually there, and when large chunks of a codebase were generated in an afternoon rather than written and reasoned through, understanding it is exactly the thing nobody has time for. Pull requests containing AI-generated code have been measured with close to twice the issue rate of hand-written ones, and a meaningful share carry a real, exploitable security vulnerability.

None of that means the tools are the problem. It means the tools removed a constraint — typing speed — that used to accidentally enforce a bit of discipline. Writing code slowly by hand forces you to think about the function you're duplicating, notice the pattern you're repeating for the fourth time, question the approach halfway through. Generating the same code in four seconds skips all of that thinking, and if nothing replaces it, the debt just accumulates invisibly until a quarter or two in, when velocity has quietly cratered and nobody can quite explain why.

The duplication problem compounds faster than it looks like it should, because an AI assistant has no persistent memory of what it wrote in a different file, a different session, or even ten minutes ago in the same file once that context scrolls out of its window. Ask it to add input validation twice in the same week and you'll likely get two different validation functions, doing roughly the same thing in slightly different ways, neither aware the other exists. Multiply that across a team of six engineers each generating code independently, and a codebase can accumulate dozens of near-duplicate utilities in a few months — the kind of thing a human team would have caught in code review eventually, except the review is happening at a volume and speed that makes catching it materially harder than it used to be.

The teams that catch this early are the ones actually measuring for it, rather than waiting until it's obvious. A few signals are worth watching on a monthly cadence: average pull request size (a steady climb usually means less decomposition, more "just generate the whole feature" requests), a duplicate-code scanner run against the whole repo rather than just new PRs, and review turnaround time (debt-heavy code takes measurably longer to review carefully, and teams under deadline pressure start reviewing it less carefully instead — which is exactly backwards). None of these require new tooling most teams don't already have access to. They require someone actually looking at the trend line instead of assuming shipped-fast means fine.

Beyond the review and refactoring changes already mentioned, a few smaller habits make a real difference: running a duplicate-detection pass before a sprint closes rather than after a quarter's worth has piled up; requiring a one-line justification in the pull request description for why an AI-generated approach was chosen over an existing pattern, which turns out to be enough friction to make an engineer actually check whether a pattern already exists; and treating any AI-generated file over a certain size as an automatic candidate for a closer second read, since size correlates strongly with the kind of sprawling, under-reasoned output that's hardest to review carefully at normal speed.

The natural pushback is that all of this — deeper review, budgeted refactoring time, a justification note on every PR — sounds like it cancels out the speed AI tools were supposed to buy in the first place. In our experience it doesn't, but it does change what the speed gets spent on. The time saved on typing and boilerplate doesn't have to convert one-to-one into more features shipped per week. Some of it should convert into the review and refactoring time that used to happen implicitly, as a side effect of writing code more slowly. Teams that try to bank all of the speed as pure output are the ones we see hit a wall two or three quarters in, when the accumulated debt finally slows everything down anyway — just later, and with less warning.

What we've found actually works is boring: the review bar goes up, not down, the faster code gets generated. Every AI-assisted change goes through the same senior review, the same security scan, and the same "does this duplicate something we already have" check that hand-written code gets — with someone explicitly responsible for asking that last question, because nothing in the tooling asks it for you. We budget real refactoring time into every sprint rather than treating it as cleanup work for later, specifically because "later" is where AI-generated debt goes to compound. And we treat a first AI-generated draft as exactly that — a draft, not a merge candidate — the same way you'd treat a junior engineer's first pass at something, except this junior engineer produces a pull request every four minutes.

The teams heading for a real crisis in the next year aren't the ones using AI coding tools. It's the ones who adopted the speed and never adjusted the process around it — same review depth, same refactoring budget, same testing discipline as before, applied to a volume of code generation that's three or four times what it used to be. The tools didn't create a technical debt problem. They just made an existing one compound a lot faster, for teams that didn't change anything else.

One more thing worth saying plainly: none of this is an argument against using the tools aggressively. We use AI coding assistants on nearly everything we build now, including this website. The difference is procedural, not philosophical — every AI-assisted pull request on our own projects carries the same review checklist a hand-written one does, plus one extra question about duplication, and every sprint has refactoring time budgeted as a real line item rather than something that happens if there's time left over. That's a small process change. It's also the entire difference between the debt numbers the industry is currently measuring and a team that's actually capturing the speed these tools offer without quietly paying it back with interest six months later.