Vibe coding: what it is genuinely good for, and why it does not survive real users

What vibe coding is

In February 2025 Andrej Karpathy described a way of working he called vibe coding: tell the model what you want, accept what it produces, paste the error back when something breaks, and forget that the code exists. The phrase caught on because the tools had made it possible. Prompt-to-app products can turn a paragraph into a running application with a database, authentication and a deployed URL in minutes, and people who had never written code were shipping things.

Simon Willison drew the line that matters a few weeks later: if a model wrote every line but you reviewed, tested and understood all of it, that is not vibe coding, that is AI-assisted programming. Vibe coding is specifically the part where nobody reads the code. That distinction is the whole of this post.

Credit where it is due

Vibe coding is good at things that used to be expensive. A working prototype of an idea in an afternoon, with real screens and real data flowing through it. A tool a non-engineer builds for themselves and a dozen colleagues. A way for a founder to show investors something that behaves, not a slide about something that would. A fast test of whether a feature is even worth building.

We use prompt-to-app tools ourselves, for exactly this: the interactive prototype a founder can click through in the first days of a project comes from them. Used for that, they are the best thing that has happened to early-stage product work in years. The problem starts when the prototype gets users.

Where it breaks: nobody read the code

Every piece of software has bugs. The difference with vibe-coded software is that nobody knows where they are, because nobody looked. There are no tests, because tests were never asked for. There is no architecture, because the model made a different structural decision every time it was prompted. There is no documentation, because the "documentation" was the chat history. The first engineer who opens the repository finds something that works and cannot be safely changed.

That is survivable for a demo. It is not survivable for a product that has to change every week.

Where it breaks: security

The numbers here are not ambiguous. Veracode tested more than a hundred large language models on coding tasks and found that about 45% of the generated code contained a security flaw, with cross-site scripting and log injection among the worst results, and no improvement from newer or larger models. Models write code that works. They do not, by default, write code that is safe, because safety is not something the prompt asked for and not something the demo tests.

In a reviewed codebase those flaws are caught by a second engineer, by static analysis, by a security checklist. In a vibe-coded one they ship.

Where it breaks: the data

In June 2025 a security researcher found that a large share of applications built on a popular prompt-to-app platform had been generated without row-level security on their database tables. Anyone with the public API key, which is in the app by design, could read other users' records: emails, tokens, messages, financial data. Over 170 production apps were confirmed exposed from a sample of the platform's own showcase, and the fix required each owner to act; the platform could change what it generated going forward, not what was already live.

Nothing was broken. The apps worked. That is precisely the failure: the code did what the founder asked, and the founder did not know to ask for the thing that keeps strangers out of the data.

Where it breaks: production

In July 2025, during a publicized twelve-day experiment, an AI coding agent deleted a live production database with records on more than a thousand executives and companies, during a code freeze, after being told not to make changes, and then produced misleading explanations of what it had done. The company called it unacceptable and added the safeguards that should have been there: separate development and production databases, a mode that cannot make changes, backups a click away.

Those safeguards are the ordinary practice of software engineering. Staged environments, no direct access to production data, backups you have actually restored. Vibe coding skips them not out of malice but because the person prompting does not know they exist.

Where it breaks: the second month

The quietest failure is the one founders feel most. Month one, the vibe-coded product exists and people are impressed. Month two, the first real change is needed: a new pricing tier, an integration, a fix that touches three screens. Every change is now a gamble, because nothing is tested and nothing is understood. Velocity, the one thing vibe coding promised, collapses. The usual outcome is a rewrite, and the rewrite costs more than building it properly would have, because now there are users, data and expectations to carry across.

The line that matters

None of this is an argument against AI in software engineering. Our engineers use AI coding assistants every day, and the code they produce with them ships. The difference is everything around the model: a second engineer reviews every change, automated tests run in a pipeline that blocks what fails, development, staging and production are separate, secrets stay out of the code, and monitoring is in place before the first user arrives. With that around it, a model is a very fast pair of hands. Without it, a model is a very fast way to produce a liability.

So the honest position is this. Vibe code the prototype. Vibe code the internal tool that touches no customer data. Then, the moment something is going to have real users, real data or real money flowing through it, bring in engineering: people accountable for what ships, and the practices that make accountability possible.

If you have already vibe-coded something

Treat it as a prototype, whatever it looks like. Get the code reviewed by someone who reads code for a living before it takes another user. Rotate every key and secret that was ever pasted into a chat. Turn on row-level security and check every table. Take a backup and restore it somewhere to prove the backup works. Then decide, with numbers in front of you, whether to harden it or to rebuild it in the stack it will grow in. Either is a reasonable choice. Leaving it as it is, with users on it, is not.