Vibe coding technical debt: why AI-written code gets harder to maintain, not easier

Vibe coding technical debt is the maintenance burden that builds up when software is written by prompting an AI model repeatedly, without the refactoring, consolidation and architectural review that normally keeps a growing codebase coherent. It looks less like a single bad decision and more like an accumulation: each new feature is added by pattern-matching against what's already there, rather than by reshaping the system to accommodate it properly. The result is a codebase that gets larger and more repetitive with every change, instead of staying stable in size while its capabilities grow.

This isn't a moral failing of the tools. It's a measurable pattern in how AI-assisted coding actually behaves once you look at the code it produces over time, rather than the demo it produces in the moment.

What the data actually shows

The most detailed evidence here comes from GitClear, a code analytics company that reviewed 211 million changed lines of code across five years (2020 to 2024), drawing on repositories from Google, Microsoft, Meta and a range of enterprise codebases. Their focus wasn't on how much code AI tools helped developers write. It was on what kind of code that turned out to be, and whether it held up.

Read those two lines together and the shape of the problem is clear. Developers used to spend a meaningful chunk of their editing time reorganising existing code: renaming things, extracting shared logic, collapsing duplication. That share has more than halved. Meanwhile the volume of code that's simply copied and pasted rather than reused through a shared function or module has grown by half again. The balance between "building on what exists" and "building next to what exists" has tipped, and it tipped during exactly the years AI coding assistants went from a novelty to a default.

Churn is a useful signal because it's a proxy for first-draft quality. Code that's right the first time doesn't need to be rewritten two weeks later. Code that was generated to satisfy a prompt, without a clear model of how it fits the rest of the system, often needs a second and third pass once its side effects become apparent. A doubling in churn means engineering teams are spending materially more time correcting recent work rather than building new work, even as more of the initial writing is delegated to a model.

Why models add code instead of reshaping it

There's a structural reason this happens, and it isn't a bug that will necessarily get patched by a better model. When you ask an AI assistant to add a feature, it's working from the file or files you've shown it, plus whatever context fits in its window. The path of least resistance, for a system built to produce a plausible next chunk of code, is to write something new that satisfies the immediate request. Reworking an existing abstraction so the new feature fits inside it cleanly requires understanding intent across a wider span of the codebase than most prompts provide, and it's a slower, less certain kind of task to generate. Adding a parallel code path is faster to produce and easier to verify against the prompt in front of it.

Multiplied across dozens of small changes, that bias compounds. Fifty prompt-driven edits don't produce a codebase shaped by one coherent design. They produce a codebase shaped by fifty separate, locally reasonable decisions, each made without full visibility into the other forty-nine. CodeRabbit's December 2025 "State of AI vs Human Code Generation" report, which reviewed 470 open-source pull requests, found AI-co-authored PRs contained roughly 1.7 times more issues overall than human-only PRs, with logic and correctness problems about 75% more common and readability issues about three times more common. That's consistent with a process that optimises for "does this satisfy the prompt" over "does this fit the system."

It's worth sitting with what Karpathy actually meant by that description, because it's often lost in how the term gets used now. He was explicit that this mode of working was for low-stakes projects and weekend prototypes, somewhere it doesn't matter if the code is a bit disposable. The problem isn't that vibe coding exists. It's that a technique designed for throwaway prototypes has become, for a lot of small teams, the entire process by which production software gets built and extended, with no second phase where someone goes back and gives the system a shape.

Why this compounds instead of levelling off

A codebase with a rising duplication rate doesn't get harder to work in at a steady pace. It gets harder at an accelerating one, because each new duplicate is itself a candidate for further copying next time a similar feature is needed. Bugs found in one copy of a pattern don't get fixed in the others, since the connection between them was never captured in a shared abstraction to begin with. The people (or models) making the next change are working against a wider and less consistent surface than the people who made the change before them, so the room for a change to introduce a new inconsistency keeps growing.

This is the mechanical reason vibe-coded projects tend to hit a wall a few months in, rather than degrading smoothly. Early on, the codebase is small enough that duplication and drift are easy to work around. Past a certain size, the accumulated inconsistency starts actively fighting new changes, because half of what looks like the "right place" to add something is actually one of several near-duplicates, and picking the wrong one adds yet another divergent copy.