Vibe coding is real, and it is not what you think

Andrej Karpathy coined "vibe coding" in February to describe a mode of working where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." It was a half-joke about weekend projects. It has since become a job description, a marketing category, and an argument.

Having spent a few months doing it deliberately, here is what I think is actually going on.

the honest version of the workflow#

You describe what you want. The agent writes it. You run it. If it works, you describe the next thing. If it does not, you paste the error and say "fix it." You do not read the diff.

For a certain class of work this is genuinely, dramatically faster. Specifically:

• Throwaway tools. A script to reshape a CSV. A one-off migration. A visualization you will look at once.
• Prototypes where the question is "is this idea any good." The code is scaffolding for a decision, not an asset.
• Unfamiliar territory. A language you do not know, an API you have never used. The agent's median output in an unfamiliar domain is better than your first attempt, and reading its output teaches you the idioms.

For that work, reading every line is not diligence, it is waste. Nobody reviews the assembly their compiler emits.

where it goes wrong#

The failure is not "the AI writes bad code." The AI writes plausible code, which is worse.

The failure is accumulated unexamined state. Every unread diff adds assumptions to the system that exist in the code and not in your head. For the first hour this costs nothing. Around hour three you hit a bug that requires understanding the whole system, and you do not understand the whole system, because you never read it.

At that point you have two options: read everything now, in one large expensive gulp, at the worst possible moment; or keep asking the agent to fix it, which works about half the time and slowly turns the codebase into sediment.

The gradient is invisible while you are on it. That is the trap.

the discipline that makes it work#

I have converged on three rules and they have held up.

1. Draw the line at persistence. Anything that touches a database, a filesystem outside a scratch directory, a payment, or another human's data gets read. Everything else can be vibes. The line is not about code quality, it is about whether a mistake is reversible.

2. Keep the blast radius small and the loop tight. Commit constantly. Small commits, in a branch, with a working tree you can git reset --hard back to. The cost of a bad agent turn should be thirty seconds, not an afternoon.

3. Maintain a written spec, not a chat history. The chat scrolls away. Keep a file — NOTES.md, whatever — that states what the system does and what the constraints are. Feed it back in. The agent's context is not memory, and yours is not either after a week away.

the part that bothers me#

Vibe coding is very good at producing something that works and very bad at producing something you can change.

Software's cost is not in writing it. It is in the years afterward, when someone needs to modify it and has to first reconstruct what it does and why. Code that was never understood by anyone is code with no design rationale to recover.

Comments do not fix this, because the agent will happily write comments describing what it believes the code does. Tests help more, because tests encode intent in an executable form. If you vibe code, vibe code the tests first and read those.

the honest bottom line#

This is a real technique with a real domain of validity. Treating it as either "the future of all programming" or "juniors will never learn anything" is substituting a slogan for a judgment call about which work is which.

The skill is knowing which mode you are in. That skill is not new — it is the same one that tells you when to write a bash script and when to write a service — and it is still the thing that separates good engineers from fast ones.