By the end of this post you will know what vibe coding is, where the phrase came from, who it works for, and the specific point at which it stops working. None of it requires a programming background.
The plain definition
Vibe coding is building software by describing what you want to an AI in ordinary language and letting the AI write the code. You do not read the code line by line. You run the result, look at what it does, and describe the next change. The loop is: ask, run, look, ask again.
The word "vibe" is doing real work in that name. It means you are steering by feel rather than by understanding the code. If the game runs and the character jumps the way you imagined, that is the test. You are not checking the logic. You are checking the experience.
That is a genuine way to make things. It is also different from programming as it has traditionally been taught, and the difference matters when something goes wrong.
Where the term came from
The phrase was popularised in early 2025 by Andrej Karpathy, a well-known figure in AI research, in a short social media post. He described a way of working where you "fully give in to the vibes", accept whatever the AI suggests, and stop reading the changes. He was describing throwaway weekend projects, not a professional practice, and he said so.
The name stuck because it described something a lot of people were already doing. AI coding tools had become good enough that a person with no training could get a working game, a small website or a tool for their own use in an afternoon. The term gave that activity a name.
Who it suits
Vibe coding suits a specific kind of person and a specific kind of project.
It suits people who know what they want to see. A hobbyist with a clear picture of a game in their head can describe it well, and description is the whole skill. It suits solo projects, where nobody else has to read or maintain the code. It suits work where the cost of being wrong is low: a personal tool, a prototype, a game for friends, a thing you are making to find out whether the idea is any good.
Who it does not suit
It does not suit anyone whose project must keep working under pressure. Software that handles money, personal data, or other people's livelihoods needs someone who can read the code and stand behind it. Vibe coding by definition means nobody is doing that.
It does not suit projects that will grow large. Code written by an AI across many sessions, with nobody keeping track of the overall shape, tends to accumulate contradictions. Two parts of the game may handle the same thing in two different ways because they were written on different days. A person can live with that in a small project. In a large one it becomes the main source of bugs.
It does not suit people who need to hand the work to someone else. If a friend or a contractor later has to take over, they will ask what each part does and why. If the answer is "the AI did it", the handover is going to be hard.
What it is genuinely good at
The honest strengths are real and worth stating plainly.
It gets a first version running fast. Going from nothing to a playable prototype used to take weeks of learning before the first line worked. Now it takes an evening.
It handles boilerplate well. Boilerplate is the repetitive setup code that every project needs and nobody enjoys writing: reading a file, drawing a window, wiring up a button. The AI is reliable at this because it has seen the same patterns many times.
It lowers the barrier to trying ideas. If a mechanic sounds fun, you can find out in an hour rather than deciding it is not worth the effort of learning how.
Where it reliably falls down
The failure has a consistent shape, and it is worth knowing before it happens to you.
The project works. You ask for one more thing. The AI makes the change, and in doing so it alters something else you did not ask about. It reports success. You run the game and something that worked yesterday no longer does. You ask the AI what it changed and it cannot tell you, because it does not carry memory from one session to the next. You did not write it down, because the AI wrote the code and you were steering by feel.
At that point you have three options. You can describe the broken thing and hope the AI can repair it. You can go back to an older copy, if you kept one. Or you can rebuild the feature from scratch.
None of these is a disaster on a small project. On a project that took three months, the lost afternoon becomes a lost week, and the lost week is when people give up.
What to take from this
Vibe coding is a real and useful way to build small things. It is fastest at the start and slowest at the point where the project has become something you care about. The skill that separates people who finish from people who abandon is not coding ability. It is the habit of keeping a record of what worked, in words a person can read, before asking for the next change.
That habit can be a notebook, a text file, or a tool built for the purpose. The form matters less than doing it before the working version is gone.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila