Vibe Coding Builds Fast, But Can You Explain It Later?

There is a particular kind of magic in describing what you want and watching an assistant produce working code in minutes. Andrej Karpathy gave this way of working a name in early 2025, calling it vibe coding: you lean into the flow, describe the outcome in plain language, accept what the model returns, and keep moving. For prototypes and throwaway scripts it feels like a superpower. The trouble starts when that code quietly becomes the thing your business depends on.

The speed is real, and so is the bill

Generation has never been faster. What has not kept pace is our confidence that the result will hold up. Teams are shipping more code than ever while feeling less sure it is safe to change. That gap has a familiar root. Back in 1992, Ward Cunningham described technical debt as shipping code that is not quite right and borrowing against future productivity. You pay the interest later, in slower delivery, more bugs, and harder maintenance. AI does not erase that debt. It just lets you take on far more of it, far faster.

Why AI debt compounds differently

When a model fills a gap, it makes a decision. It picks a data shape, an error path, a default. Those decisions are rarely written down, and they are almost invisible in review because the code reads cleanly and the tests go green. Multiply that by the sheer volume of code these tools produce, and you get a system built on hundreds of choices no human ever consciously made. Human debt is usually a shortcut someone remembers taking. AI debt is a set of assumptions nobody knew were there.

A chart showing output speed rising quickly while understanding of the code declines over the following months. — Output speed climbs the moment you start. Understanding tends to fall the longer review is skipped, and the bill often lands around months 12 to 18.

The six month problem

Here is the line that stuck with me: a tool can build your pipeline today and leave you unable to explain it six months later. When an incident wakes you at 2am, "the AI wrote it" is not an answer. If no one on the team can sketch the data flow on a whiteboard, you do not really own the system. You are renting it, and the rent comes due at the worst possible time.

Treat generated code like any other code

The fix is not to stop using AI. It is to stop treating its output as finished.

Read what you merge. If you would not accept it from a junior engineer without review, do not accept it from a model.
Write the intent down. A short spec or architecture note per feature captures the reasoning the model will never volunteer.
Keep tests you actually understand. Verify by reasoning about behavior, not by running it once and trusting a green checkmark.
Refactor on purpose. Left alone, generated code duplicates and drifts. Schedule cleanup the way you schedule features.
Keep a human architect. Someone has to hold the shape of the system in their head.

You can outsource the typing. You cannot outsource the understanding.

Where this leaves me

I still reach for AI every day. It is the fastest pair programmer I have ever had. What changed is how I treat the output: as a strong first draft that needs an owner, not a final answer. Speed is only a win if the thing you shipped is still legible when you come back to it.