Is Vibe Coding Bad? A Balanced, Honest Answer

What is vibe coding, and who coined it?

Vibe coding is AI-assisted development where you describe a task in plain language, let a large language model generate the code, and accept it without a line-by-line review — leaning on testing and follow-up prompts instead. Andrej Karpathy, an OpenAI co-founder, named it in February 2025; by late 2025 it was in Merriam-Webster and was Collins Dictionary's Word of the Year.

There is an important line drawn inside the term itself. As engineer Simon Willison put it, if an LLM wrote every line of your code but you reviewed, tested, and understood all of it, that is not vibe coding — that is using the model as a typing assistant. Real vibe coding is the part where you stop reading. That single distinction is the whole story of when the practice is safe and when it is not.

Is vibe coding bad for production apps?

For production, the honest answer is: risky, not evil. The same speed that makes vibe coding brilliant for a demo works against you when the app holds real user data. Independent 2025 code analyses found AI-generated code carried noticeably more major defects and security issues than human-written code, and a documented May 2025 review of Lovable-built apps found a subset that exposed personal data.

The reason is structural. You cannot debug or secure code you never read, and vibe coding is defined by not reading it. On a prototype that is a fair trade — nothing is at stake. On a public app it means auth gaps, database permission bugs, and leaked keys ship silently, because the person who would have caught them delegated that job to a model that does not know your threat model.

When should you stop prompting and bring in engineers?

Stop prompting the moment you cross from building something new into protecting something real — or the moment the AI stops making progress. Concretely: when the same error survives two fix attempts, when you can no longer say what a file does, when the app has real users, or when it touches money or personal data. Those are the signals to bring in an engineer who actually reads code.

1. The same bug reappears after two AI fix attempts — the problem is structural, not a prompt away.
2. You can no longer explain what a given file or function does — you have lost a mental model the AI never gave you.
3. The app is about to get real users, logins, or a custom domain — the stakes just changed.
4. It handles payments, personal data, or anything regulated — unreviewed AI code is a liability there.
5. You are spending more time re-prompting than you would spend reading the diff — that is the tipping point.

How do you fix a vibe-coded app without starting over?

You almost never need to rebuild. A vibe-coded app is usually mostly fine with a handful of landmines — the fix is to find and defuse the landmines, not burn the house down. An engineer reads the generated code, hardens the auth and database rules, strips the duplicated and dead code the AI accumulated, adds the tests that were never written, and hands you a base you can keep shipping on.

1. Freeze new features and get the current code into version control so nothing else changes under you.
2. Audit the security surface first — authentication, Row Level Security, exposed API keys, and payment webhooks.
3. Delete the duplication and dead code the AI piled up; consolidate repeated logic into shared functions.
4. Add tests around the paths that touch money and user data so future prompts cannot silently break them.
5. Only then resume feature work — now on a base a human has actually read.

Related: Lovable code cleanup · Lovable app rescue