Vibe Coding Debt Is the New Technical Debt

Watch a team that has adopted AI coding for a few weeks and you will see a strange thing happen. The velocity numbers climb, the backlog drains, and everyone is happy. Then, around the same time every time, a different number starts climbing too: the amount of code in the repository that nobody on the team can explain.

This is not a rant about AI code being bad. A lot of it is genuinely good. The problem is not the code, it is the pace. We are generating lines faster than we can trace them, and production runs on the ones we never looked at. That gap is the new technical debt, and it is worse than the old kind because it is invisible until the moment it is very expensive.

The old debt was visible

Technical debt used to have a shape. A junior engineer ship a quick fix to meet a deadline, someone left a TODO that outlived its author, an architecture decision made before we knew better. You could walk the codebase and point at the debt. It had symptoms, smells, a code review transcript. When it came due, you knew roughly what you were paying for.

Vibe coding debt has no such shape. The code is clean enough to pass review, it is well formatted, it matches the surrounding style, and nobody can tell you how it works, because nobody wrote it and nobody read more than the diff. The TODO says nothing. The architecture decision was made by a model that does not remember making it. The debt is not in the code, it is in the absence around it: the understanding that used to live inside the notes and the heads of the people who shipped the thing.

What you are actually building up

When the understanding is gone, the cost does not show on any dashboard. It shows up in the behaviors that every team starts to recognize.

The first is the hand-off tax. When a feature needs to change, someone has to reconstruct how it works before they can touch it. With human code, that reconstruction is shared memory, a conversation, a write up. With generated code, there is nothing to reconstruct from except the code itself, and the previous author is a model that will happily tell you a confident, wrong story about what it meant. Every change becomes archaeology.

The second is the fix compounding. Nobody dares refactor a black box, so when something in it misbehaves, the fix is a patch on the outside. Each patch adds a new assumption no one verified. The box gets bigger, more entangled, and less safe to approach, and every week the reason to leave it alone gets a little stronger. This is the classic death spiral of debt, just delivered faster.

The third is the blame problem. When a human wrote the code, there was an author to ask, a context to recover, a Why that could be reconstructed from the conversation. When the code is generated, the Why is gone. The most important question in maintenance, why does this exist, has no answer in the repository and no person who knows it. That is when code stops being something you own and becomes something you merely host.

The root cause is not the model

Here is where the root cause thinking comes in, because it is tempting to blame the tool. If we stop the vibe coding, the debt stops, right?

No. The tool is the surface. The cause sits one layer down, and it is the same cause behind every other maintenance problem we chase. The team shipped output without tracing it. The model did not stop you from understanding the code. The workflow simply did not require understanding before that code was allowed to matter, and a workflow that never requires understanding will accumulate ignorance no matter who or what is typing.

Look at it as a chain, the way we trace every bug.

Symptom:   a generated module cannot be safely changed
     why
Surface:   nobody can reconstruct how it works
     why
Layer 2:   the code was reviewed as a diff, not understood as a system
     why
Origin:    the workflow shipped output without requiring it be traced

That last sentence is the cause, and it is a process problem, not a technology problem. Change the tool and the process survives. Change the process and any tool becomes safe. Which is why the fix is not to ban vibe coding, it is to add the one step that makes it survivable: trace it before it is load bearing.

What we actually do about it

We did not decide this from theory. We hit it, and we built the practice that lets us keep the speed and lose the debt. It is not glamorous and it does not show on a velocity chart, but it holds.

One. Nothing is load bearing until it is traced. A generated function can sit in the codebase, can even ship, as long as nothing critical hangs on it. The moment a feature, a payment, a migration, a contract depends on a piece of code, that code has to be traceable before it becomes load bearing. Speed is fine. Blind trust is not. It is a one line rule: you may build fast, but you may not depend on what you do not understand.

Two. The diff is not the review. Reviewing generated code by reading the diff is expecting the code to explain itself, and it will not. The review has to be a trace: what does this block depend on, what assumption would break it, how does it behave at the edges nobody showed you. We review the reasoning as much as the code, because with generated code the reasoning is the part the author forgot to include.

Three. The author must leave a Why. Human authors leave one naturally, in comments and conversations and the memory of a shared table. Generated code comes with none of that, so we write it down. Every load bearing piece of generated code gets one paragraph that says what it assumes, what it does not do, and what would break it. Not documentation theater. One honest paragraph that means the next person does not have to do archaeology.

Four. Replay before rebuild. When a generated block fails and nobody understands it, the instinct is to delete and regenerate, to let the model take another shot at a moving target. We trace it instead. We capture what the code actually did and walk the failure backward to the cause, the same five step trace we run on everything else. Rebuilding from scratch is a symptom fix: it changes the output, not the understanding, and it can turn one surprise into two.

The speed, kept

The point of all this is not to slow teams down. It is the opposite. The teams that add the trace step are the only ones that get to keep the speed, because they are the only ones whose generated code stays safe to touch. The teams that skip it get the velocity for a quarter and then spend a year paying for code they cannot change, and the velocity was never really theirs, it was debt that had not been billed yet.

There is a strange shorthand for all of this, and we give it to every team we work with. Code you did not trace is code you do not own. The moment you can trace a line to its cause, you own it. The moment you cannot, the model owns it, and the model will not be there when it breaks.

That is the difference. We build with these tools, every day, and we keep the speed because we keep the understanding. The tool is not the risk. Untraced dependency is the risk, and it always was. Vibe coding just made it easy to run up a bill you cannot see.

Try it on your own tree

Pick the most load bearing piece of generated code in your repository, the one your product would notice if it broke. Sit with it and ask three questions. What does it assume, what would break it, and if it failed right now, would you be able to explain why to a customer within an hour?

If you answered the third question with a pause, you have found your balance. The good news is the cure is not to delete anything. It is to trace it, once, honestly, and write down the paragraph so the next person does not have to. Do that and you can keep shipping at full speed to your heart's content. You will just finally own what you ship.

If you would rather hand us the tree, that works too. Finding the cause is our daily work.

Related reading: Trace First, Then Automate covers why AI belongs downstream of understanding. The Agent Did Something Wrong walks the full trace of an AI failure.