Vibe coding, in the original sense, means giving in to the flow: describe what you want, accept what the assistant writes, run it, describe the next thing. It is a real and useful way to build a first version. The product exists by Sunday night. Then, somewhere around month four, the same assistant that shipped the MVP takes an afternoon to add a button, and nobody on the team can say why.
This is a map of the debt vibe coding leaves behind, why it bites late instead of early, and a repayment plan that does not require stopping to rewrite anything.
What vibe coding actually produces
Every prompt answers exactly the question it was asked. "Show each order with the customer name" produces a loop that works. "Charge the card" produces a call that works. What no prompt asks is the second question: what happens when this fails, what happens when there are ten thousand of these, who is allowed to call this. The generated code is not wrong. It is unfinished in a way that looks finished.
The output is also plausible by design. It is formatted, commented, and structured like production code, which makes it far easier to merge without reading than a junior developer's first draft would be.
Why the bill arrives in month four
Three effects compound quietly until they do not.
- Context pollution. Each session starts fresh, so the assistant re-solves problems it already solved. By month three there are three date helpers and two HTTP clients. By month four the assistant reads its own duplicates as context, gets slower and gets worse, and every new feature costs more than the last.
- The stranger problem. Nobody remembers writing the code, because in a sense nobody did. The assumptions inside a file are invisible to the team, so every change is a small archaeology project.
- Silent failures wait for traffic. Swallowed exceptions, missing timeouts and queries inside loops are harmless at ten users. They show up together on the first busy day, which is usually the day you least wanted them to.
The debt, specifically
Scan enough vibe-coded repositories and the same findings appear in nearly all of them: queries inside loops, swallowed exceptions and hardcoded secrets, followed closely by endpoints that never check who is calling, payment code with no tests, and runtimes that were never pinned. None of these are exotic. All of them are cheap to fix one at a time and expensive to discover in production.
How to pay it down without stopping
- Measure first. Run a baseline over the whole repository and get a single number you can track. You cannot pay down what you have not counted, and a number turns an argument about "quality" into a trend line.
- Security this week, everything else later. Leaked keys, endpoints without authentication and SQL built from strings go first, before any cleanup, because they are the only findings that can end the company.
- Pin behavior before you change it. For any file with no tests, write a characterization test that records what the code does today. Only then refactor. This is slower by one commit and it is the whole difference between a safe refactor and a hopeful one.
- Small batches, one pull request each. Eight findings, under 300 lines, reviewable over coffee, revertible in one click. Why the giant cleanup pull request never merges is a post of its own.
- Rescan on every merge. The score should move every week. If it does not, the batches are too big or the wrong things are in them.
- Change the prompts. Add the second question to every feature request. "And handle the failure case." "And this list can be large." "And only the owner can see it." The assistant will do it if asked. It will not do it unasked.
When not to pay it down
A prototype you will throw away, a feature about to be deleted, a product that is one pivot from a rewrite: these do not deserve a refactor. Pay the security debt and nothing else. Technical debt is only a problem when you plan to keep the code, and the honest answer to that question is sometimes no.
Keep the speed
None of this is an argument against vibe coding. The speed was real and the product exists because of it. The mistake is treating the output as finished. Treat it as a very fast first draft, measure what it left behind, and pay the bill in installments while you keep shipping.