What is vibe coding, and where does it leak?

Vibe coding is building software by describing what you want instead of writing it. It works better than most people expect, and it fails in predictable places: access rules, secrets left in the source, and input nobody checks. Those are not teething problems that the next model release fixes. That is the pattern.

Where did the term come from?

It was coined in 2025 to describe a way of working that had already arrived: you describe the thing, the tool produces it, you look at whether it does what you wanted rather than at the code, and you iterate by describing the difference.

The word carries a sneer for some people and a flag for others, which is a shame, because the underlying shift is real and worth being precise about. Something genuinely changed: for a certain size of software, the writing stopped being the hard part.

What can you actually build this way?

More than sceptics claim and less than the demos suggest.

Works well: internal tools, dashboards, forms that write to a database, landing pages, small utilities, a first version of an idea you want to show somebody, anything where you are the only user.

Works badly: anything where the details of the behaviour matter more than the shape of it, anything that must integrate precisely with something that already exists, and anything where being 90% right is the same as being wrong.

The dividing line is not complexity, it is how expensive a wrong answer is. A dashboard that renders the wrong chart wastes a minute. A checkout that charges the wrong amount is a different category of problem, and that is a judgement about consequences, not about difficulty.

The tools sort along the same line. Lovable, Bolt, v0, Replit, Base44, Appy Pie and Emergent all take a description and give you something working in a browser — compared side by side in which AI app builder. Claude Code and Cursor work on an existing project instead, and expect you to read what changed.

Where does it leak?

Three places, over and over.

Access rules that were never written

The single most common one. The app has users, each user has data, and nothing actually enforces that one user cannot read another's.

This happens because the rule lives somewhere invisible. The screen only shows you your own data, so the app looks correct — but the screen is not the thing that enforces it. The database is, and if nobody told the database, then anyone who asks it directly gets everything.

This is not theoretical: CVE-2025-48757 was issued for exactly this class of problem in applications generated by an AI builder, where row-level access rules were absent by default. It carried a critical severity score. If your app has users and a database, this is the first thing to check, and you should check it yourself rather than assume your builder handled it.

Secrets in code the browser can see

An API key gets used in code that runs in the visitor's browser. It works perfectly, and anyone who opens the developer tools can read it.

The confusion is understandable — the code you wrote and the code that runs on your visitor's laptop look identical in the editor. The rule is simple once you know it: anything the browser runs is public, including any key in it. Keys belong on the server or in environment variables.

Input that is passed on unchecked

Whatever a user types ends up somewhere — a database query, a page, a command. If it goes there as-is, a user can type something that changes what that instruction does.

In the Veracode testing described below, cross-site scripting and log injection were the two worst-performing categories by a wide margin: roughly 15% and 13% pass rates. Those are both this problem.

Why the same three, every time?

Because of what the model is optimising for and what it is not being asked.

You ask for a page that shows a user's orders. It produces a page that shows a user's orders. It has done exactly what you asked. Nobody asked what happens when a different user requests that page directly, because you did not think of it — and the model, absent an instruction, produces the working version rather than the hardened one.

Security is mostly the absence of something happening, and an absence is hard to notice in a demo. That is why these three keep recurring and why "it works" is such a misleading test.

How bad is it, measured?

Testing across more than 150 models and 80 coding tasks found generated code was syntactically correct more than 95% of the time, and passed security checks about 55% of the time when the prompt contained no security instruction. Newer models moved that second number far less than people expect.

I have written that up properly, with the failure categories and where the figures come from, in what AI coding agents get wrong, measured. It is the piece to read if you want the numbers rather than the summary.

How do you make it safe enough to publish?

A checklist that takes about fifteen minutes and catches most of it:

1. Ask for it. Put security in the instruction. "Add row-level access rules so a user can only read their own rows" produces a different result than not saying it. The measured gap between prompts that ask and prompts that do not is large.
2. Test as a second user. Make two accounts. Log in as the second and try to reach the first one's data by changing an id in the address bar. This single test catches the most common failure.
3. Search the browser code for keys. Look for anything that resembles a secret in anything the browser downloads. If it is there, it is public.
4. Try some rude input. Put a quote mark, a bracket and a script tag into every field. Then look at whether it appears on the page as text or as behaviour.
5. Check what the database allows. Not the screen — the database. In Supabase that means row-level security; in whatever you use, it means the equivalent.
6. Put it in version control before you start changing things, so that a bad change is one command away from undone.

None of that requires writing code. All of it requires being willing to look.

Is vibe coding a real skill or a phase?

The name will age badly. The practice will not.

What is actually happening is that the expensive part of software moved. Producing code is close to solved for small applications. Deciding what to build, judging whether the result is right, and knowing what questions were never asked — none of that moved at all, and all of it is now a larger share of the job than it was.

Which points at the honest answer to the question people really mean: you still need to read code, and you need to write much less of it. Reading is what lets you judge, and judging is the remaining work. Somebody who can read code and describe well is in an extremely good position right now. Somebody who can only describe is producing software they cannot evaluate — and the three leaks above are what that costs.