What is vibe coding? Definition and meaning
Vibe coding describes a way of working in which software is created in conversation with an AI model. You describe in plain language what the program should do. The model produces the code. You try the result out, describe what is not right yet and have it revised.
The difference from classic programming lies less in the tool than in the checking. Anyone who programs themselves understands every line they write. With vibe coding, you judge the result by whether it behaves correctly, not by how it is built. That is exactly what the name alludes to: you go by the impression.
Where the term comes from
It was coined by Andrej Karpathy, co-founder of OpenAI and formerly head of AI at Tesla, in early 2025 in a short post about his own way of working. The expression spread within a few weeks.
What was new was not the thing itself: AI-assisted code suggestions already existed before. What was new was that the models became good enough to produce whole small programs instead of individual lines, and that this allowed people without programming training to arrive at usable results.
How vibe coding works in practice
The process resembles a conversation rather than a blueprint.
It begins with a description of what is to be created: which data comes in, what is to happen with it, what comes out at the end. From this the model produces a first draft. That draft is tried out, and whatever does not fit is described, not as an error report in technical language but in ordinary words. The model revises, you try again.
The quality of the result depends less on how the instructions are worded than on the clarity of the environment. A model that knows how the data source is structured, which fields exist and in what format they arrive delivers usable code. A model that has to guess delivers code that looks plausible and does not work.
What the approach is suited to
Best of all for things that are small, have a clear purpose and do not have to be run for years.
Typical cases are reports that answer a particular question and for which no ready-made report exists. Likewise small helper programs that take over a recurring manual step: reshaping data, reconciling lists, renaming files. And prototypes that show whether an idea holds up before anyone invests seriously.
What these cases have in common: the damage stays manageable if the result is wrong, and the mistake is noticed quickly.
Limits and criticism
The objections are directed less against the way of working than against the expectation that it replaces programming.
Code that nobody has reviewed can work and still be wrong, for example because it overlooks a special case that only comes up in three months’ time. Mistakes you did not make yourself are also harder to find, because the structure is unfamiliar. And what came about in twenty minutes today still has to be understood, adapted and operated in two years’ time.
Added to this are the points that apply to every piece of software and are easily overlooked when something comes about quickly: who may access which data, how access is secured, what happens in the event of an error.
The practical conclusion is not to do without the approach, but to treat the result like any other software. Whatever goes into productive operation is reviewed, gets its own access with as few rights as possible and has someone answerable for it. That way the time gained is preserved without it later turning into a legacy burden.