Vibe coding describes a way of working in which software emerges mostly through description in plain language: you say what the program should do, a language model writes the code, you look at the result and describe the next change. The source is not read line by line and understood, it is judged by its behaviour. The AI researcher Andrej Karpathy coined the term in early 2025, half in jest, for an approach where you “give in to the vibes” and forget that there is code at all.
Within a year the joke turned into a term that developers, founders and business departments all use. What exactly it means depends heavily on who is saying it.
Where the term comes from
In February 2025 Karpathy described on X how he builds small throwaway projects: talking instead of typing, pasting error messages back into the model unread, accepting suggestions without checking the diff. For a weekend project, he said, this is great. That qualifier is what usually got lost as the term spread.
Today “vibe coding” is used in at least three senses:
| Usage | What is meant | Does it hold up? |
|---|---|---|
| Literally, as Karpathy meant it | Code appears without anyone reading it | For throwaway projects yes, otherwise no |
| As a synonym for AI-assisted development | Developers work with assistants but review every change | Yes, that is everyday practice now |
| As a marketing phrase | “Software without developers” | No |
This blurriness explains why judgements about the method differ so much. The people arguing are often talking about different things.
How it runs in practice
The process resembles a conversation. You describe a goal, get a working version, try it out and describe what is off. Instead of a specification up front, clarity emerges along the way.
A typical round
- State the requirement in a sentence or two, for example “a page where customers can book appointments and cancel them again”.
- The model produces a data model, an interface and the basic functions.
- You click through it and find the parts that do not fit.
- You describe the change, not the solution: “cancelling should only be possible up to 24 hours beforehand”.
- Repeat until the behaviour is right.
The decisive difference from classic work sits in step four. Dictate the solution and you are using the model as a typist. Describe the behaviour you want and you let it find the solution.
What people work with
Common choices are editors with built-in model access such as Cursor, command line tools such as Claude Code, and builders that turn a description into a whole application. The tools differ less in the model than in how much context they can read from the project on their own.
Where the method holds up
Vibe coding is strong wherever speed matters more than durability.
- Prototypes: an idea becomes something clickable within hours. A sketch is hard to argue about, a working interface is not.
- Internal tools: a small reporting script, a form for twelve colleagues, an import helper. When a mistake is annoying rather than dangerous, the method fits.
- Unfamiliar ground: trying out a foreign interface, getting to know a library, checking whether an idea is feasible at all.
- Drafts for the business side: people who cannot write a requirement down can often show it. A rough click dummy saves a lot of meetings.
Where it breaks
The line does not run between large and small, it runs between disposable and durable.
As soon as real data, real users or real liability are involved, the arithmetic changes. Generated code looks tidy even when it contains a reasoning error: neatly formatted, sensibly named, properly commented. That is what makes it harder to review than badly written code, where you can see the problem.
Three points tend to get lost in the enthusiasm:
- Security: credentials in the source, missing permission checks, unfiltered input. A model produces what looks customary, not what is safe.
- Maintainability: anyone who never read the code cannot repair it when it fails. A prototype nobody understands any more is a liability.
- Data protection: whatever goes to an external model leaves the building. With customer data that is a question for the start of a project, not for the handover.
For these cases the usual rules still apply: read it, test it, understand it. AI may write large parts, but somebody carries the responsibility for them.
Vibe coding and prototyping
The two terms often get mixed up but mean different things. Prototyping is a project step with a purpose, namely to test an assumption. Vibe coding is a way of working that makes this step much faster today.
In practice: a prototype takes hours instead of days. Whatever goes into production afterwards is rebuilt properly on that basis. The prototype is the answer to a question, not the beginning of the product.
That is exactly what our MVP workshop is built on: in a single day we build a clickable prototype together with you, and the line to production code is agreed beforehand rather than argued about afterwards.
Frequently asked questions about vibe coding
Does vibe coding replace developers? No, it shifts their work. Writing code loses weight, describing requirements and reviewing results gain it. Both demand exactly the understanding you build up by typing code yourself.
Can I build an app this way without being a developer? Getting something that runs is realistic. Running it safely, maintaining it and fixing it when it breaks is not. For internal use with uncritical data that can still be enough.
How do I tell whether generated code is any good? Most reliably through tests that describe the behaviour you want, and by looking at the critical spots: who is allowed to do what, what happens on bad input, where the credentials live. If you cannot judge that, ask somebody who can.
Is the term serious or just a buzzword? Both. The way of working it describes is real and widespread. The term itself is vague and gets stretched in marketing. When in doubt, ask what exactly is meant.
Conclusion
Vibe coding has changed the early phase of software projects. What used to be discussed as a wireframe can now be tried out within hours, which brings misunderstandings to the surface sooner. The method replaces neither architecture nor review nor responsibility: between “it runs in the meeting” and “it runs in production” sits the larger part of the work. How we build software, and where we use AI while doing it, is described on our page about custom software development, and how we use the method in a client session is on the MVP workshop page. We went into more detail in the article AI in software development, and for anything beyond that there is a free consultation.