What Is Vibe Coding? Where It Shines and Where It Breaks

Vibe coding is building software by describing what you want to an AI in plain language and judging the result by how the app behaves, without reading the code it writes. It's the fastest way I know to turn an idea into something people can click on, and the risk starts the moment real users, personal data or payments get involved.

Full disclosure: I'm a freelance developer, and part of my work is getting AI-built apps ready for production. I still think vibe coding is one of the best things to happen to founders without a development budget, as long as you know where the line is.

The short answer: when is it enough?

My rule of thumb: vibe coding is fine as long as a bug only costs you time. Once a bug can cost someone else their data, their money or their trust in you, someone needs to be able to explain what the code does.

If you already have users, skip ahead to my guide on taking a vibe-coded app to production. This post covers what comes before that: what vibe coding is and how to get the most out of it.

Where the term comes from, and what it means today

The phrase comes from AI researcher Andrej Karpathy. In February 2025 he described a style of coding where he accepted every change the AI proposed without reading the diffs, and let himself "forget that the code even exists". The term caught on quickly, and Collins Dictionary made it its Word of the Year for 2025.

It now gets used in two ways. The broad sense, which is how Collins defines it, covers any programming where an AI writes the code from natural-language prompts. The narrow sense, which was Karpathy's point, is building with AI without reviewing what it writes.

Developer Simon Willison has made a clear case for the narrow meaning. If a developer uses AI to write code but reads, tests and understands it, he calls that AI-assisted programming, not vibe coding. I'll use the narrow meaning here, because not reading the code is exactly what makes vibe coding both fast and risky.

In practice, a lot of vibe coding happens in browser tools like Lovable (from Sweden), Bolt, v0 and Replit, where you chat on one side and watch the app take shape on the other. Others work in AI code editors like Cursor, where the AI edits project files directly. I've put the browser tools side by side in Lovable vs Bolt vs v0 vs Replit.

What it's genuinely good for

The big shift is who gets to build something clickable. That's a real gain, and it matters most early on, when learning fast is worth more than anything else.

Prototypes people can actually use

A working prototype beats a pitch deck. With a tool like Lovable you can have screens, forms and a complete flow in a day or two, something a customer can try on their own phone. That used to mean a designer and a developer for several weeks, which is why so many ideas never got tested at all.

Checking demand before you spend

The most expensive mistake in software is building something nobody wants. A prototype lets you test the idea on potential customers before you commit a serious budget. Watch what people do rather than what they say. If they click around and ask when they can have it, that's a signal. If they don't, you've saved months and money, which is also a useful result.

A sharper brief for your developer

For a developer, a prototype is often more precise than ten pages of text. It shows which fields a form has, what happens when you hit save and in which order things happen. It doesn't replace a proper requirements document, because it says nothing about security, data or what should happen when something fails. It does make that document shorter and the first conversation far more concrete.

Small tools for your own use

A script that cleans up a CSV export, a dashboard for your own numbers, an internal form. If you're the only user and a bug costs nothing but time, vibe coding is a great fit. Just keep a copy of whatever data the tool touches.

Where the risk starts

The problem isn't that AI always writes bad code. Plenty of it is fine. The problem is that nobody knows which parts aren't, because nobody has read them. In a prototype that doesn't matter. Once other people rely on the app, it matters a lot.

Working code isn't the same as safe code

Security company Veracode tested code from more than 100 language models and found that 45% of the samples introduced security flaws from the OWASP Top 10, a widely used list of the most common web app vulnerabilities. The code did the job. It just wasn't secure.

A concrete case: in 2025 two security researchers scanned 1,645 apps from Lovable's own showcase and found that about 170 of them exposed data to anyone who asked, including email addresses, phone numbers and API keys. The cause was missing or wrong access rules in the database. The apps looked fine from the outside, and their owners had no way to spot the flaw without reading the code. I cover the usual suspects in the most common vibe coding security issues.

The fix-one-break-two loop

As the app grows, something shifts. The first days feel like magic, but later every prompt seems to break something somewhere else. The AI doesn't see the whole app at once and nobody designed the overall structure, so the same logic ends up copied in several slightly different versions. If you spend more time fixing than building, that's one of the signs it's time to hire a developer for your AI-built app.

The parts a demo never shows

Payments, failed payments, VAT, user roles, backups, monitoring and updates are invisible when you click through a prototype. They're also what costs the most when they're missing. An AI can write the code for a checkout, but it doesn't know what your accountant needs, how VAT works when you sell to businesses and consumers in different EU countries, or what should happen when a card is declined. I go through this for subscription products in can you build a SaaS with AI alone?

Feeling fast isn't being fast

In a study by METR, 16 experienced developers worked through 246 tasks in codebases they knew well, and with AI tools they took 19% longer, even though they believed they'd been about 20% faster. The study is about experienced developers, not prototypes, and the researchers stress it doesn't generalize to all software work. The takeaway is that gut feeling isn't a measurement. Judge progress by whether users can use the app, not by how many prompts you got through.

Six steps to test an idea with AI

These steps are for founders who want to test an idea quickly without creating problems for later.

1. Write down what you want to learn

Before the first prompt, write one sentence: who is this for, and what should they be able to do? Then decide what counts as success, for example five out of ten potential customers saying they'd pay for a finished version. Without a goal, the prototype keeps growing and you end up with a half-built app instead of an answer.

2. Build one flow and nothing else

Skip login, settings, admin screens and emails unless they're what you're testing. One path through the app, from the start to the moment the user gets something out of it, is enough. The less there is, the easier it is to throw away or hand over.

3. Use fake data

Don't load real customer details into a prototype. If your test users are in the EU, their personal data falls under GDPR whether it sits in a prototype or a finished product. Made-up names and numbers show the idea just as well and do no harm if they leak.

4. Keep secrets and real payments out

Don't paste secret API keys into the chat or the code, and use your payment provider's test mode if you're demoing a checkout. A key that ends up in the code the browser downloads is visible to anyone. If the prototype calls a paid service, set a low spending cap with the provider.

5. Push the code to GitHub from day one

Connect the project to GitHub straight away. You get a history you can roll back to when the AI breaks something, and a developer can look at the code without logging into your account. It also makes you less dependent on a single tool.

6. Decide before your first real user

When the test is done, you have three options. If the idea didn't hold up, delete the prototype and be glad it was cheap. If it's a tool just for you, keep building. If other people will log in, pay or store data, get the code reviewed before launch, not after the first incident.

When you don't need a developer yet

I sell exactly this kind of help, so I'll say it plainly: often you shouldn't hire anyone yet. A developer is money wasted if

• you haven't tested the idea on anyone who might pay for it,
• only you or a couple of colleagues use the app, and a bug only costs time,
• the prototype is for one meeting or one demo and can be thrown away afterwards,
• you're still changing direction every week.

Paying someone to polish a prototype nobody has tried is the most expensive way to use AI. Use the tools to learn, and bring in help when there's something worth protecting.

Next steps

If you have a prototype that works, the question isn't whether vibe coding was a mistake. It probably wasn't. The question is whether the app is ready for what it has to do next.

If you can't tick every box, that's not a disaster, but it is your to-do list before launch. If you'd like help with it, here's how I work on taking an AI-built app from prototype to production. I'm based in Denmark, so EU rules like GDPR apply to my own work too. I start with a paid, fixed-price discovery phase so you know what needs doing, and you own the code from day one.

Frequently asked questions

Do I need to know how to code to vibe code?+

No, you can build a working prototype without writing code yourself. It helps a lot to understand a few basics, though: the difference between frontend and backend, what a database and an API key are, and why secrets must never live in the browser. With that knowledge you'll write better prompts and catch the most obvious problems before they get expensive.

How much does vibe coding cost?+

Getting started is cheap. Lovable, Bolt, v0 and Replit all have free plans, and their cheapest paid plans ran from about $20 to $30 a month on their own pricing pages in October 2026. The bill grows with credit usage as the app gets bigger. The real cost usually comes later, if the prototype has to be made ready for real users.

Is vibe coding the same as no-code?+

No. No-code tools like Bubble let you build with visual blocks inside the platform, and you usually can't take the code with you. With vibe coding the AI writes real code, often React, which you can push to GitHub and hand to a developer later. The trade-off is that keeping that code secure and running is more clearly your responsibility.

Who owns the code I build with Lovable or Bolt?+

It depends on each tool's terms, so read them before you build anything business-critical. In practice the more important question is whether you can get your code and data out. The main tools connect to GitHub, so the code is easy to move, while data stored in the tool's own database may need a manual migration. Check this early, while the app is small.

Will vibe coding replace developers?+

I don't think so, but the work is shifting. Less time goes into writing boilerplate and more into architecture, security, review and operations. At the same time, more prototypes mean more apps that need to be made ready for real users. Typing code quickly is becoming less valuable. Knowing which code will hold up is becoming more valuable.