Is vibe coding production ready?

Why this matters

The question usually means one of two things. Can a vibe-coded app be production quality? Yes, if someone checks the parts that matter. Is an app production ready because the agent said it was done? No, and that is where the trouble starts. A coding agent builds what you asked for and makes it work on your machine; production adds strangers, money and failure, and those need settings and checks the demo never exercised.

What to check before you call it production ready

• Row level security on every table in an exposed schema, with policies that check the caller, tested with only the public key.
• Secret keys only on the server: nothing secret behind NEXT_PUBLIC_ or VITE_, nothing in a "use client" file, nothing committed to git.
• Payment webhooks that verify their signature over the raw request body.
• Env vars set per environment on the host, with live keys only in production.
• Error monitoring that reaches you, and backups you know how to restore.
• A test from a second account that tries to read and change the first account's data.
• A coding agent that works without production credentials.

What the public evidence shows

Only sources anyone can check: a CVE record and the researchers' own statement, one large published study, and Supabase's docs.

The Lovable disclosure, CVE-2025-48757 (2025)

Researchers scanned the homepages of 1,645 projects from Lovable's showcase in March 2025 and reported 303 endpoints across 170 projects, about 10.3%, with inadequate row level security, exposing data such as emails, phone numbers, payment details and developers' API keys. The CVE record describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that let remote unauthenticated attackers read or write tables of generated sites.

Lovable disputes the CVE: the record notes that "each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application". The researchers work at Replit, which builds a competing product. Both sides describe the same mechanism, a public key plus missing or wrong RLS; they disagree on who owns the fix.

Go deeper: How do I find Supabase tables missing RLS in my migrations?

UpGuard's study of Supabase databases (2026)

UpGuard collected about 300,000 domains with indicators of Supabase use and found 16,326 databases exposing readable tables. Over half showed indicators of personal data, and a smaller share included passwords or authentication tokens. It found them by asking each database for a table named users, with the database address and public key a visitor's browser already receives.

UpGuard's explanation is about defaults and knowledge, not about the code itself: tables created through the API, which is how coding agents create them, do not get RLS by default, and in its words "the humans are unaware of the configuration".

What Supabase says is yours

Supabase's shared responsibility model says you are always responsible for applying security controls, for the access levels on tables with sensitive data, and for managing your database secrets and API keys. Its Security Advisor sends alerts, and "applying the recommendations are your responsibility". The RLS guide puts it in one line: "Enable RLS on every table in an exposed schema."

Go deeper: Is Supabase safe for production?

What the evidence does not show

None of these sources measures how often vibe-coded apps fail compared with apps written by hand, so they cannot tell you vibe coding is riskier than other ways of building. They do show the same gap appearing at scale on one popular stack, found from the outside with ordinary requests, and that it is a configuration gap: the fix is turning on RLS and writing policies, not rewriting the app.

Optional repo check

For AI-built Vercel + Supabase apps, npx -y viberaven@1.6.3 check is a pre-deploy review for vibe-coded Vercel + Supabase apps that reads the repo for parts of the first five items above. In a run on a fixture repo on 2026-10-05 it reported a public table without RLS, using (true) policies, NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in .env.example, a .env file not covered by .gitignore, a Stripe webhook handler with no signature check, and no Sentry or PostHog in the code. It did not flag a Stripe secret key hardcoded in a client file, and it cannot see your live database, your Vercel settings or your backups, so it cannot tell you an app is production ready. It is advice, not a gate, and a repository check, not a live database or security test. A clean result does not prove the app is secure. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore.

Related guides

• I vibe coded an app. Now what?
• What are the security risks of vibe coding?
• What went wrong in the real vibe coding horror stories?
• What can a repo scan prove about Supabase security, and what needs a live test?
• Which AI app generators produce production-ready code?

Sources

• NVD, CVE-2025-48757
• Replit researchers, Statement on CVE-2025-48757
• UpGuard, Everything Everywhere: Systemic Data Exposure in Supabase Apps
• Supabase, Shared Responsibility Model
• Supabase, Row Level Security
• Supabase, API keys
• Stripe, Resolve webhook signature verification errors

Is vibe coding safe?

How the code was typed is not what makes an app safe; the settings and checks are. An app built with a coding agent and checked properly can be as safe as one written by hand, and a table without row level security is open no matter who wrote the migration.

Should I rewrite my vibe-coded app before launch?

Usually not. Fixing access rules, keys and webhooks is a bounded list of changes, and a rewrite would produce new code that needs the same checks.

Can a vibe-coded app pass a security review?

Yes, once the review finds nothing serious or you fix what it finds. Expect the findings to cluster where the public evidence does: database access, secrets and webhooks.