What Is Vibe Coding, and Why It's Risky?

"Vibe coding" started as a joke and stuck as a description. It means telling an AI tool what you want in plain English, letting it write the code, and shipping whatever comes out without anyone who deeply understands code reading it first.

The tools are genuinely impressive. Claude, Cursor, v0, Lovable and the rest can go from a paragraph of description to a working page faster than a developer can open their editor. We use them every day. The risk isn't the AI. It's the second half of that definition, the part where nobody reviews the output.

What it's genuinely good at

• Prototypes. If you want to see your idea as a clickable thing before deciding whether it deserves real money, this is the cheapest way to find out that has ever existed.
• Internal tools. A dashboard three people use behind a login, where the worst case of a bug is mild annoyance on a Tuesday.
• Working out what you want. Generating five versions of a layout in an hour is a fast way to discover what you were asking for.
• Contained pieces of a bigger build, produced by someone who can read the output and tell whether it's right.

If your project is on that list, vibe code it. Everything below is about the moment a project stops being an experiment and starts taking money and data from strangers.

Security holes nobody is looking for

AI models produce code that looks correct, because looking correct is what they were trained to do. Looking correct and being safe are separate properties. The problems we find most often when someone hands us a vibe-coded site are the same four every time.

• API keys sitting in front-end code. Your payment provider's key or your email service's key, in a file any visitor can read by opening browser developer tools. Someone will find it, because bots scan for exactly this all day.
• Forms that trust whatever gets sent to them. The validation lives in the browser, where it's a convenience, and nowhere on the server, where it would be the actual defence. Anyone can bypass it in about a minute.
• Database queries assembled by gluing user input into a string. That's SQL injection, it has been the same bug for twenty-five years, and models still write it when nobody thinks to ask them not to.
• No rate limiting anywhere. Your contact form becomes a spam relay, or the one endpoint that costs you money per call becomes somebody else's free service.

None of these break the demo. That's precisely the problem. The site works perfectly right up until it doesn't, and the failure is usually discovered by somebody other than you.

It holds up until real traffic arrives

Generated code is written for the happy path: the visitor who fills the form in correctly, on a good connection, in a normal browser. Real traffic is mostly edge cases. Two people submit in the same second. Someone pastes an emoji into a name field. The payment provider times out halfway through. A crawler requests a page with a malformed URL and gets a stack trace instead of a 404.

A developer anticipates these because they have been burned by all of them. An AI handles them only if you knew to ask, and if you knew to ask, you probably didn't need to vibe code it. When something does break, the diagnosis is the expensive part. There's a codebase nobody wrote, following patterns nobody chose, and whoever is fixing it starts by reading it for the first time under pressure.

The bill that arrives six months later

The quieter risk is maintenance. The person who vibe coded it has moved on, or genuinely cannot remember what the tool did. There's no documentation, because nobody wrote any. There are no tests, because the AI wasn't asked for them, so nobody can change one thing without wondering what else just broke. And the codebase is often three times larger than it needed to be, with four slightly different ways of doing the same job, because it was generated across sessions that knew nothing about each other.

You feel this the first time you need a change. A ten-minute edit on a well-built site turns into a day of reading, or a quote to rebuild the whole thing properly. That second quote is usually larger than the original build would have been.

The problem was never that AI wrote the code. It's that nobody who could tell working code from good code ever read it.

The version of this that works

We build fast, and AI is part of how. The difference is entirely in what happens between generation and launch.

• Someone decides the architecture before anything is generated: how data moves, what lives where, where the boundaries sit. AI is excellent at filling in a structure and poor at choosing one.
• Generated code gets reviewed by an engineer who could have written it. It receives the same scrutiny as code from a new hire, which is the appropriate amount.
• Secrets stay in environment variables on the server, never in anything a browser downloads, and every form is validated server-side regardless of what the browser already checked.
• The site is tested against the unhappy paths, on real devices, before it handles a single genuine submission.

The useful line to draw isn't between AI-written and human-written code. It's between code someone is accountable for and code nobody is. If you've built something with an AI tool and it works, that's a real head start, and it's worth having an engineer read it before it starts handling a customer's card details or a customer's data. A review costs a fraction of a rebuild, and it's the difference between a website you got quickly and a website you can keep.