Vibe coding is describing what you want in plain language and letting a model write the code, without reading most of it. You steer by the result: run it, see if it feels right, ask for changes, run it again. The code is a means, the behavior is the point, and you mostly do not look under the hood.
Andrej Karpathy named the thing in early 2025, describing a way of working where you “fully give in to the vibes” and forget the code even exists. He meant it partly as a joke about weekend projects. The term stuck because it described something a lot of people were already doing and did not have a word for.
It is worth defining plainly, because the term now gets used two ways: as a badge by people shipping real things fast, and as an insult by people who think all of it is reckless. Both are missing the actual line.
What vibe coding actually is
Strip away the mystique and it is a loop:
- Describe a change or a feature in natural language.
- An agent writes or edits the code.
- You run it and look at the result, not the diff.
- You describe what is wrong or what is next.
- Repeat.
The defining trait is step 3. In classic development you read the code to know it is right. In vibe coding you read the behavior. That single substitution is what makes it fast, and it is also the entire source of its limits.
This is different from AI-assisted engineering, where you still read and own the diff and the model is an accelerator. Vibe coding hands the reading over too. The distinction is not snobbery, it decides what the output is safe for.
What it is genuinely good at
I am not here to sneer at it. The technique is real and it earns its place:
Prototypes. When the goal is to see if an idea feels right, vibe coding gets you a clickable answer in an afternoon instead of a week. That is a legitimate superpower.
Throwaway tools. A script you will run once, an internal utility for yourself, a thing that does not need to survive contact with other people. Correctness that expires tomorrow is fine when you are done today.
Learning by seeing. Watching an idea become a working screen teaches you more about whether it is worth building than any amount of planning.
The first draft of something real. Even things that will become products often start here, and should. The mistake is not starting with vibe coding. It is not noticing when you left its territory.
Where it stops working
The edge is not a difficulty level. It is a change in what you need from the output. Vibe coding stops working the moment the code has to survive things a demo never tests:
When it has to keep working while you change it. A prototype’s behaviors worked once. A product’s behaviors have to keep working through every future change, which means something has to catch it when a change breaks them. Vibe coding produces no such net.
When someone else depends on it. The moment a real user’s money, data, or time rides on the app, “it worked when I clicked it” stops being enough. You need to know it works, not feel it. A green build is not a correct feature, and “it ran on my screen” is even weaker than a green build.
When it grows past what you can hold in your head. Below some size you can keep the whole app in memory and steer by vibes. Past it, you cannot, and because you never read the code, you now own software you cannot navigate. That is the reckoning most vibe-coded apps hit around month 3.
When features start colliding. Each feature was generated assuming the rest of the app holds still. Add enough of them and new features start breaking old ones, because nothing enforced the assumption.
None of these mean the technique failed. They mean the prototype succeeded so well that it stopped being a prototype. That is the good problem, and it has a name: the prototype became the product, and it happened before you decided to let it.
Why the confusion is worth clearing up
The reason this matters is that people argue about vibe coding as if it were one thing that is either good or bad. It is not. It is a tool with a shape, and the shape is exactly this: it converts natural language into working behavior extremely fast, at the cost of you not knowing how that behavior is held together.
For a prototype, that trade is a bargain. You want speed and you do not care about the internals, because the prototype’s whole job is to answer a question and then get out of the way. For a product, the same trade is a slow-acting poison. You still get the speed up front, but now the internals you never looked at are the thing you have to maintain, and you cannot maintain what you never saw.
So the technique is not good or bad. It is correctly or incorrectly applied. Applied to a throwaway, it is close to magic. Applied to something people depend on, without ever adding the structure back, it is a loan at high interest that comes due, reliably, a couple of months in.
What “past the line” looks like in practice
Concretely, you know you have crossed the line when your relationship to the code changes. In prototype territory, you ask for a change and you accept whatever comes back, because the only test is whether it looks right when you run it. Past the line, you start needing to know things you cannot see: did this change break the thing I shipped last week, is this number correct or just plausible, why did it do it this way. The questions the code cannot answer are the sign that vibe coding has taken you as far as it can.
That is not a failure and it is not a reason to feel foolish. It is the predictable result of the technique working. The mistake is only in not noticing, and continuing to add features by vibe on top of a base nobody understands, which is how a fast start turns into an app that is impossible to change around month 3.
The line, in one sentence
Vibe coding is right up until something has to be true about your code that you cannot personally verify by clicking. At that line, you do not need to abandon the app or rewrite it. You need to add back the structure a prototype skips: a readable map, a written spec, a safety net. That crossing is a whole discipline of its own, and I lay out the full route in from vibe coding to production.
Use vibe coding for what it is good at without apology. Just watch for the line, because it arrives quietly, and the cost of missing it is paid later, with interest.
FAQ
Who coined the term vibe coding? Andrej Karpathy, in early 2025, describing a way of building where you lean on the model and stop tracking the code itself. It named a practice many people were already doing.
Is vibe coding bad? No. It is excellent for prototypes, throwaway tools, and first drafts. It becomes a problem only when its output is used as if it were production software, without the structure that production requires.
What is the difference between vibe coding and AI-assisted engineering? In vibe coding you steer by the behavior and do not read the code. In AI-assisted engineering you still read and own the diff. The difference decides whether the output is safe to depend on.