What vibe coding really is and when to use it
Vibe coding is a way of working in which you describe to a language model what you want to achieve, and it writes the code. You judge the result, run it and ask for fixes, often without reading every line.
Where the term came from
The expression was popularized by Andrej Karpathy, a co-founder of OpenAI and earlier head of the AI team at Tesla. He described an approach in which the programmer stops digging into the details of the code and instead goes by a general feeling of whether the app does what is expected. The name caught on quickly because it aptly named something many people were already doing.
Vibe coding versus programming with an assistant
The boundary is blurry, but it is worth understanding. In classic work with an AI assistant, you read the proposed code, understand it and take responsibility for it. In vibe coding, you accept changes mostly because the program works. These are two ends of the same scale, and most real projects sit somewhere in the middle.
Where it works well
- Prototypes and quick experiments meant to answer the question "does this even make sense?"
- Tools for your own use: scripts that tidy up files, simple dashboards, data converters.
- Learning a new language or library by watching how a model solves a task you already know.
- Sites and apps where a mistake costs little and is easy to undo.
Where to be careful
The more is at stake, the less sense it makes to write "by feel". This applies to payments, personal data, authentication, medical systems and anything that will run for a long time and be maintained by someone other than the author. Code that nobody understands is a debt, not a time saver. We write about this at more length in the text on the risks of AI-generated code.
How to start sensibly
- Pick a small project that you can check in a few minutes.
- Work in a repository with a change history so you can go back at any moment.
- Ask for small steps instead of a whole app at once. How to do that is described in the guide on writing prompts for code.
- Run and test after every change, not after ten.
