Most explanations of vibe coding skip the part that makes the term useful. So let me start with what was actually said.
What Karpathy actually wrote
Andrej Karpathy coined the phrase in a tweet in February 2025. The definition people quote is the opening line, about giving in to the vibes and forgetting the code exists. The line people skip is near the end:
It's not too bad for throwaway weekend projects.
He also described the workflow precisely: seeing stuff, saying stuff, running stuff, pasting stuff, and accepting diffs without reading them. When something broke, he pasted the error back in without trying to understand it. He was explicit that this works because the models got good enough to make the loop tolerable, not because the output is correct.
That is a much narrower claim than the one the term now carries. Within a year "vibe coding" had stretched to cover roughly any use of an AI coding tool, and Collins Dictionary made it their word of the year for 2025. Somewhere in that expansion, the "throwaway weekend projects" clause fell off.
The actual dividing line
Here is the distinction I think is worth keeping, and it is not "AI versus no AI."
The variable is whether you are accountable for code you have not read.
That framing does real work. It explains why the same tool, the same prompt, and the same output can be completely fine in one context and reckless in another. A weekend project where nobody's data is at stake and the worst outcome is that you delete the folder? Read nothing. Genuinely. That is what the tools are extraordinary at, and being precious about it is a waste of the moment we are in.
The same loop, running against a table with other people's rows in it, is a different activity wearing the same clothes. Not because AI code is worse than human code, but because nobody has checked whether it does what you think it does, and you have committed to strangers that it will.
Most of the vibe coding discourse is people arguing past each other because one side is describing the first situation and the other side is describing the second.
What it is genuinely excellent at
I do not want to bury this under caveats, because the upside is real and specific.
Exploring an unfamiliar framework is the clearest win. You learn faster by having something running and poking at it than by reading documentation cold, and being able to ask "why did that work" against your own running code is a better tutorial than most tutorials.
Throwing away three approaches to a UI in an afternoon is another. The cost of abandoning a direction has collapsed, which means you can afford to be wrong more often. That changes what is worth trying.
Getting past a blank file is underrated. A mediocre first version you can react to beats an empty editor, and reacting is easier than creating.
And prototypes meant to answer one question, then die, are exactly the case Karpathy described. If the prototype has done its job the moment you have the answer, the code quality was never the point.
Where it turns on you
The failures are boringly consistent, and none of them are the model being bad at code.
Output drifts between prompts. Ask for the same kind of thing twice and you get two architectures, because each generation is a fresh conversation with no memory of the last one. Three buttons, three styling approaches, three sets of default behaviour.
Duplication accumulates quietly. This one is measurable rather than anecdotal: GitClear's analysis of over 150 million changed lines found duplicated blocks rising while refactoring activity fell. More code arriving, less of it being consolidated.
Failure paths go missing. Models default to the happy path unless told otherwise, partly because most of the tutorials they trained on skip error handling too. The login form works. The login form with a rate limit, a disabled account, and a dead network does not exist.
Review stops scaling before generation does. You can produce twenty files in a session. You cannot meaningfully review twenty files in that same session, and the gap is where the trouble lives. Google's DORA 2024 report found AI adoption associated with reduced delivery stability, which is at least consistent with this being the real bottleneck.
None of this is the AI failing at its task. It did what was asked. The prompt just never said what "right" meant.
How to tell which mode you are in
Two questions, and they are not about the tool.
Will anyone other than me have data in this? If yes, you are past vibe coding in Karpathy's sense, whatever your workflow feels like.
Would I be able to explain what this code does if it broke at 2am? If no, and the answer to the first question was yes, that is the gap to close.
Reining it in without killing the speed
The goal is not to go back to writing specs for everything. Most of what makes vibe coding good is worth keeping. The parts worth adding back are narrow.
Fix the data model before you generate against it. Code regenerates in seconds. Rows with real users behind them do not, and that asymmetry is the single most reliable predictor of which mistakes will hurt.
Declare your shared components up front. The tool cannot know that page A and page B want the same button unless you tell it. Naming eight of them costs a minute and removes the most common source of drift.
Write down what done means for anything with branches in it. Auth, payments, permissions, anything with a state machine hiding inside. Given, when, then is enough. This is where unstated requirements turn into confident wrong guesses.
Leave everything else alone. Layout, copy, styling, one-off scripts. Planning those is procrastination with better branding.
The takeaway
Vibe coding is a good technique with a name that outgrew its definition. Used the way it was described, for throwaway work where you are the only one exposed, it is close to unbeatable. Used as a description of how to build a product people pay for, it quietly commits you to shipping code nobody has read.
You do not have to pick a side. You do have to know which one you are doing.
Related reading
- Why AI-generated code breaks in production, with the specific failure modes and real code examples.
- From user stories to database schema, the one step worth doing deliberately.
- VibeMap vs Bolt.new and VibeMap vs ChatGPT, two honest comparisons including when the simpler option is enough.
If you want to try the structured version on one feature, the User Story Generator turns a plain-English feature description into INVEST-format stories with acceptance criteria. Free, no signup.
Sources and further reading
- Andrej Karpathy, the original vibe coding tweet, February 2025.
- GitClear, Coding on Copilot: duplication and refactoring trends in AI-assisted codebases.
- Google, DORA 2024 State of DevOps Report: AI adoption measured against delivery throughput and stability.
- Stack Overflow, 2024 Developer Survey, AI section: adoption and trust data.
