Is vibe coding safe?

The short answer

Vibe coding is safe to the extent that somebody verifies the result. The code an assistant produces usually works, which is exactly what makes it hard to review — there is no failing test to prompt a second look. The failures that follow are concentrated in a few predictable places, none of them raises an error, and all of them are checkable in minutes if you look at the deployed application rather than the source.

That is the whole answer. Everything below is the detail behind it.

What actually goes wrong?

Not what people expect. The characteristic failures of AI-assisted development are not exotic exploits — they are configuration failures, and they cluster in three places.

• A credential that belongs on a server ends up in the JavaScript you serve. The assistant was asked to make a query return rows. The elevated key made it return rows. To be reachable from the browser it needed a build-time prefix, and the build wrote the literal value into a file your CDN now hands to every visitor.
• A database table is reachable by anyone holding a public key. The schema was generated. The access rules were a separate job that nobody asked for. The table looks protected in the dashboard and returns every row to an anonymous request.
• Money moves one way and not the other. A refund is issued, the customer is satisfied, and the transfer that sent the seller their share is never reversed. The platform absorbs the difference silently.

What these have in common is not a technology. It is a shape: something that reports success while doing the wrong thing, and that exists only in the running system.

Why does nothing warn me?

Because from every tool's point of view, nothing went wrong.

The build succeeded — inlining a prefixed environment variable into the client bundle is documented, intended behaviour. The query returned rows, which is what a query is supposed to do. The refund completed, and a refund without a transfer reversal is a valid instruction that a payments API will execute without commentary.

Build completed in 42s
Deployed to production

There is no error, so there is no alert, so there is no ticket. This is the uncomfortable part: errors are the failures that get fixed, precisely because something noticed them. The failures worth worrying about here are the ones where every system involved reports success.

The build succeeded. That is not the same as the build being safe.

Your existing tooling is not failing at this. A repository scanner that reports nothing is usually correct — the secret it cannot see did not exist until the build created it. Tests that pass are telling you the truth about intent. Neither is designed to answer the question "what is my deployed application actually handing to a stranger right now", and that is the question that matters here.

What should I check first?

Three checks, in this order. Each takes minutes, none needs an account with anyone, and you can do all three this afternoon.

• Open your production JavaScript and search it. View source on your deployed site, open one of the chunk files, and search for eyJ (the start of every JWT), sk_live_, sk-proj- and AKIA. Not every hit is a problem — publishable keys are designed to be public — but you should be able to say what each one is.
• Ask your database what it returns without a login. If a browser-reachable database such as Supabase holds your data, confirm that row-level security is enabled on every table and that no policy evaluates to true unconditionally. Then make an anonymous request and see what comes back, because a policy's text and a policy's behaviour are different things.
• Reconcile a handful of refunds. If you move money on behalf of other accounts, take a sample of recent refunds and check that each one has a corresponding transfer reversal. If it does not, you paid for that refund yourself.

If all three come back clean, you have learned something real about today. Redeploy tomorrow and you have a new artifact, which is a separate question — but today is a genuine answer, which is more than an unchecked deploy gives you.

Do I need a security review before launch?

Not necessarily, and it would be dishonest to tell you otherwise. A full security review is a different exercise with a different cost, and for a small product with a handful of users it is often the wrong thing to buy first.

What you do need is to have looked. The three checks above are not a substitute for a review — they will not find business-logic flaws, they will not tell you anything about your authentication design, and they will not assess whether your data model is appropriate for the obligations you have taken on. What they will do is close the gap between what you intended to deploy and what you actually deployed, which is where the AI-assisted failures live.

The thing to avoid is the default position: shipping quickly, reviewing selectively, and never once looking at the served result. That is not a discipline problem. It is a structural one — output has outgrown review across the whole industry, and the tooling has not caught up. Looking at what shipped is the cheapest correction available.

Each of the three checks above corresponds to one of ours, which exists because doing it by hand once tells you about one day.

See the three products