What is vibe coding, and where does it break down?

Where the term came from

Andrej Karpathy coined it in early 2025, describing a way of working where you "fully give in to the vibes" and stop reading the diffs. It spread because it named something people were already doing and felt slightly guilty about.

It deserved a name because it is a legitimate technique. For a weekend project, an internal tool used by four people, or a prototype that exists to answer one question, reading the code adds cost and very little value. The output either does the thing or it does not, and you can tell by looking at it.

Where it breaks down

Not where people expect. The failure is not that models write bad code.

Unread code compounds. By the tenth prompt you have a codebase nobody has read, including you. Each new change is made against assumptions nobody verified. The tenth change is riskier than the first not because the model got worse but because the surface it is changing got larger and less understood.

Nothing establishes that it still works. If you are not reading and nothing is checking, then "it works" means "it looked fine when I clicked the one page I happened to open". Breakage elsewhere is invisible until someone finds it, and that someone is often a user.

The things you cannot see are the things that matter. A page rendering correctly tells you nothing about whether a permission check exists, whether the price calculation rounds the way your accountant expects, or whether a form is storing personal data somewhere it should not be.

Recovery gets harder. When something does go wrong, the fix requires understanding a system nobody understands. This is the point at which vibe-coded projects are usually abandoned rather than repaired.

What makes it work anyway

Verification is the natural complement to vibe coding, not its opposite. If you have decided not to read the code — a legitimate decision — then something else has to establish that it runs. A typecheck, the tests, a production build, a smoke test. Not because a machine is smarter than you, but because it is tireless and you have already opted out of looking.

Two other things help disproportionately:

Start from a real application. Vibe coding on top of a tested scaffold is a fundamentally safer activity than vibe coding into an empty folder, because the parts you are least equipped to judge were designed by people and are covered by tests.

Keep every version. If each build is an immutable, content-hashed artifact, then "go back to the one that worked" is a reliable operation rather than a negotiation with a model.

The line worth drawing

Vibe code the parts where being wrong is cheap: layout, copy, internal tools, prototypes, anything you can throw away.

Read the parts where being wrong is expensive: authentication, permission checks, payment logic, anything touching personal data, anything that sends email to customers. That is usually a small fraction of the code, and the point of verification, scaffolds and immutable versions is that it stays a small fraction — the part you actually have to think about.

Vibe coding responsibly, in five habits

Ship small changes. One request, one verified version. A change you can describe in a sentence is a change you can undo without understanding it.

Look at the result properly. Not the one page you asked about — click the three things you did not ask about, because that is where breakage lands.

Keep a version you trust. Know which build was the last good one, and know how to get back to it. If your tool makes that a pointer change, use it freely.

Read the four dangerous files. Auth, permissions, payments, personal data. Nothing else.

Notice when you stop understanding your own app. That feeling is data. It usually arrives a few prompts before the thing becomes hard to repair, and it is the right moment to slow down, not to prompt harder.