On this page
Andrej Karpathy, a co-founder of OpenAI, named it in a post in early February 2025: you fully give in to the vibes and forget the code even exists. Within weeks Merriam-Webster listed it as a trending slang term, and Collins made it its word of the year for 2025. What separates it from a developer using an AI assistant is that one detail: in vibe coding nobody reads the code the large language model wrote. You judge only whether the screen does what you asked.
How vibe coding works, and what it builds in an afternoon
That is its strength. With Lovable, Bolt, v0 or a coding assistant you describe a booking form, a dashboard or a small shop in a handful of prompts, and an hour later you are clicking through it. For an idea you want to show an investor or a first customer, that is gold: a proof of concept that used to take a week is there by the evening.
The trouble starts when the prototype quietly becomes the product. Real users sign up, real customer data goes in, real payments come through. What the model wrote works in the demo, but nobody knows what it does when someone tries something unexpected.
Five places a vibe-coded app breaks in production
Time savedRisk
- 01Idea on a screen
- 02Prototype for an investor
- 03First users with a loginBreaks here: Sign-in and permissions
- 04Customer data in the databaseBreaks here: Secrets and outside input
- 05PaymentsBreaks here: Payment status from the browser
Up to the prototype vibe coding wins almost everything. From the first login on, someone has to read the code.
| Breaking point | What goes wrong | What it takes |
|---|---|---|
| Sign-in | A login checked only in the browser; through the back end anyone gets in | Checks on the server, sessions you can revoke, two factor authentication |
| Permissions | User A sees user B's data by changing a number in the address bar | Every database request checked against who asks |
| Secrets | An API key or database password readable in the code sent to the browser | Keys on the server only, rotated once anyone has seen them |
| Payments | A price or payment status the browser passes on, so it can be faked | The payment provider confirms to the server, not to the screen |
| Outside input | A form or chatbot passing text to a model or database unchecked | Validation, and defences against prompt injection |
A second lock at sign-in is two factor authentication; text that makes a model do something it should not is prompt injection. None of the five shows up in a demo. They surface when someone goes looking, and then your customers pay for it. How one popular tool fares is covered in is Lovable good.
Vibe coding vs low-code vs a developer with AI
| Vibe coding | Low-code | Developer with AI | |
|---|---|---|---|
| Who reads the code | Nobody | Little code; the platform owns it | The developer, line by line |
| Time to a prototype | Hours | Days | Days |
| Ready for customer data | Only after review and rewrites | Within the platform's limits | Yes, with tests |
| Where it stops | At what the model understands | At what the platform allows | At what you want to build |
Low-code is a different thing: you build inside a managed platform with fixed blocks, and the platform handles security for you within its limits. Vibe coding hands you a full codebase you do not know. What that costs in three years is called technical debt: every quick choice nobody understands is repaid later with interest. For websites only, AI website builders compares the options, and Lovable vs WordPress the two names that come up most.
Vibe coding vs prompt engineering, since the two get mixed up: prompt engineering is the craft of writing instructions a model follows well. Vibe coding uses prompts too, but the point is what happens after: nobody checks the result below the surface.
What we leave to a model, and what we do not
Jesper builds with AI agents himself, so this is no case against AI. At VBS a model writes code, tests and documentation. What we do not leave to it: how sign-in and permissions work, the review of every line that touches money, personal data or access, and the decision that something goes live. Tests that try to break in are part of it: the management platform we built for Business Centrum runs 65 abuse tests on every change, checking that no user can see or do what is not theirs.
Before customers use a vibe-coded app
- Someone who reads code has checked sign-in, permissions and payments.
- No key or password sits in the code that reaches the browser.
- User A cannot see user B's data, not even through the address bar.
- There is a database backup, and you know how to restore it.
- You know who maintains it when the model breaks something in the next change.
Short questions on vibe coding
Can a vibe-coded MVP take paying customers?
Only after someone has reviewed sign-in, permissions, secrets and payments. Sometimes a few fixes do it, sometimes rebuilding on the same screens is faster.
Which vibe coding tools are there?
Lovable, Bolt and v0 build a full app from a chat in the browser. Cursor, Claude Code and GitHub Copilot work inside the code and are used more by developers.
Is vibe coding the same as coding with ChatGPT?
Not always. A developer who lets ChatGPT or Claude suggest code and reviews it is coding with AI. It becomes vibe coding when nobody reads the code anymore.