What is vibe coding, and what it is not
Vibe coding is building by describing in plain language what you want, accepting what the AI makes of it, and steering by what you see instead of by what is in the code. The term is Andrej Karpathy’s, from February 2025, and he meant something light by it: you give in to the flow and forget that the code exists. For a prototype that is exactly right. For something people are going to use, it is half the work.
This article explains what the term means, where it comes from and why it works so well for a first version. After that: what the criticism is, where it is right, and how you go from accepting to understanding without becoming a programmer.
What does vibe coding mean?
Vibe coding means that you tell an AI model what you want, take the result without reading the code, and carry on working from what you see on the screen. If it does not work, you describe the problem again and accept the next version. You steer by behaviour, not by text. The code is an intermediate product that you do not open.
The difference with programming is not that an AI takes part. Programmers use the same models. The difference is what you do with what comes back. A programmer reads the change, understands why it works and decides whether it stays. A vibe coder checks whether the screen does what they meant. Both are legitimate; they are just for different moments.
Whoever builds this way gets surprisingly far. A working form, a list with filters, a page that looks good: that is an evening of work without reading a line of code. The point of this article is not that this is wrong. The point is that you need to know when it stops being enough.
- Describe, accept, look, describe again.
- Steer by what the screen does, not by what the code says.
- The same tools as programmers, a different way of dealing with the result.
Where does the term come from?
From Andrej Karpathy, one of the best-known researchers in the field. In February 2025 he described in a post how he now built small projects: going fully with the flow, forgetting the code, pasting the text of an error message into the model and seeing what happens. He called it vibe coding, and the term caught on because it named exactly what many people were already doing without having a word for it.
The word spread fast. Merriam-Webster added it as trending in March 2025, and Collins chose it as word of the year at the end of 2025. That says something about how many people were suddenly building who could not a year earlier, and that is the core of what has changed: the threshold for making something that works has disappeared.
Karpathy himself added that it was suitable for throwaway weekend projects. That caveat was largely lost as the term spread, and that is where the tension comes from that the rest of this article describes.
- Andrej Karpathy, February 2025: going with the flow, forgetting the code.
- Merriam-Webster (March 2025) and Collins (word of the year 2025) added it.
- His own caveat: for throwaway projects. That part did not travel with it.
Why does it work so well for a prototype?
Because a prototype only has to answer one question: is the idea right? For that, the code does not have to be pretty, secure or maintainable. It has to do what you meant, long enough to show it to someone. Vibe coding is the fastest route there has ever been, because every step between idea and screen has disappeared.
It also works because your mistakes are cheap. A prototype that goes wrong you throw away and start again; there is no data that gets lost, no visitors who notice anything, no bill that keeps running. In that environment not reading is not a risk but a time saving. Every minute you spend on code you throw away tomorrow is a minute you do not spend on the idea.
And it works because the tools are built for it. Lovable, Bolt, v0, Replit and their kind give you an environment where the result runs immediately, with a database to try things and an address to share. They are made for this pace. What they do not do is tell you when the pace has to change.
- A prototype answers one question: is the idea right.
- Mistakes cost nothing as long as there is no data, no visitors and no bills.
- The build tools are made for this pace; the moment to switch is not built in.
What is the criticism, and is it right?
The criticism comes down to three things: you do not understand what is there, what is there is more often insecure, and what is there is harder to maintain. The first is true by definition; not reading is the starting point. The second and third have been researched. An analysis by CodeRabbit from December 2025 found more logic errors and more security problems in code written together with an AI than in code by humans alone. GitClear saw less clean-up work and more copied code in repositories over 2025 than in the years before. The exact figures are in the source at the bottom; they depend on how you measure.
Is the criticism right? For a prototype it is not, because there maintenance and security are not goals. For something that is live it is, and then completely. A form that works but does not check its input, a password in the code because that was faster, a database anyone can read: those are not theoretical risks but the standard mistakes of code nobody has read.
So the criticism is not about the method but about the moment. Vibe coding is not bad. Vibe coding on a project with real people in it is a gamble you only lose when it is too late to start reading.
- Three objections: understanding, security, maintenance. The first is true by definition.
- Studies by CodeRabbit (2025) and GitClear (2025) find more errors and more copying; the measure differs per study.
- For a prototype it does not matter. For something that is live it matters completely.
What is vibe coding not?
It is not a synonym for building with AI. Someone who has a model write and reads every change is doing something else, even if they use the same tool and the same prompts. It is also not a synonym for bad work: there are excellent prototypes nobody has read, and that is their strength. And it is not a skill you need to unlearn. It is a mode you switch on and off.
It is not free either. Whoever builds this way uses tokens, and the bill for them keeps running whether you read the code or not. A model that tries three times because the description was vague costs three times as much. The article on what a million tokens cost is about that.
And it is not finished when it works. A prototype that works is the start of a list the build tool does not make for you: ownership of the code, an address, data that stays put, keys outside the code. That list is called the cliff, and it is the place where vibe coding turns into something else.
- Not the same as building with AI: the difference is whether you read.
- Not bad, not something to unlearn; a mode you choose deliberately.
- Not free, and not finished when it works.
How do you go from accepting to understanding?
Not by learning to program. By three habits a non-programmer picks up in a week. The first: after every change, ask the model what it changed and why, in plain language, and do read that answer. You do not need to understand the code to grasp that there is now a password in it, or that the form lets through everything you type.
The second: put your project in version control, so that every change has a before and an after. Then you see not only that it works differently, but which lines are different, and you can go back if it went wrong. Five concepts are enough; they are in the article on Git and GitHub.
The third: decide the moment at which you switch. A good rule is the first stranger. As long as only you use it, anything goes. As soon as someone else enters data, you read what happens to that data, and you go through the security checklist. That is not a different trade. It is the same tool, with a second track underneath.
- After every change: have the model explain what changed, and read it.
- Version control: every change a before and an after.
- Switching moment: the first stranger who enters data.
Sources
Checked on 5 September 2026. The studies by CodeRabbit and GitClear are cited through the encyclopaedia article and were not retrieved separately; that is why their figures are not given here.
Further reading
Three places that connect to this.
From first prompt to tax return.
The platform opens later. Questions or comments can be sent to info@basestep.io.