The Hidden Cost of "Vibe Coding": Is Your AI-Generated App Actually Safe to Deploy?

The Moltbook Disaster

We are living in the golden age of vibe coding. Tools like Cursor, Bolt, Lovable, and Claude Code can get a founder from zero to a working product in hours. But that speed comes with a hidden cost: working code is not the same thing as deploy-safe code.

Recent security research on LLM-generated code suggests the gap is not small. When an AI has a choice between a secure and insecure implementation path, it still lands on the insecure option far too often. The result is a growing class of apps that look production-ready while carrying obvious secrets, weak auth, exposed databases, and missing guardrails.

The Moltbook incident made that risk concrete. It was a viral social product built entirely through vibe coding, and it reportedly shipped with a misconfigured Supabase backend and missing Row-Level Security protections. The app worked. The security model did not.

That is the pattern ShipSafe is built for. Not theoretical security theater, but the review layer between 'the app runs on localhost' and 'this should be allowed anywhere near production'.

A completely misconfigured Supabase backend with missing Row-Level Security policies left the database open — exposing API tokens, user data, and private messages.

The "80/20 Wall"

Every vibe coder eventually hits the same wall. AI gets you through the first 80% fast: UI, routing, data fetching, happy-path CRUD, and polished screens. The final 20% is where production quality actually lives: auth enforcement, ownership checks, input validation, rate limiting, secret management, error boundaries, and deployment safety.

That last 20% is also where the breaches happen. AI agents optimize for removing runtime friction and getting the feature to work. They do not optimize for preserving a trustworthy security model. If removing a validation step makes the error go away, the model often treats that as success.

That is why so many AI-built apps look finished while still leaking secrets, trusting getSession() for authorization, or exposing broad select('*') queries without ownership filters.

Introducing ShipSafe

ShipSafe is a local security review layer for AI-built repositories. It runs where the code lives, integrates into Claude Code or Codex CLI workflows, and combines deterministic scanning with agent-led reasoning where the dangerous logic bugs usually hide.

The goal is not to replace a real pentest for a high-stakes fintech or healthcare system. The goal is to catch the predictable, repeated security mistakes that AI editors keep generating before those mistakes become a live incident.

Phase 1 — Deterministic Scan

The first layer is intentionally boring in the best possible way: deterministic scanning. It catches concrete patterns instantly, without spending tokens and without shipping your code to a third party.

That includes hardcoded secret detection, .env and .gitignore checks, dangerous public env usage, wildcard CORS, missing security headers, production console.log, select('*') overfetching, and exposed source-map style config.

This matters because many of the easiest-to-avoid production leaks are not subtle. They are just repetitive. A reliable scanner should catch them before the repo ever gets deployed.

Phase 2 — Agent-Led Review

The harder issues are not regex problems. They are flow problems. The agent review traces request-to-auth-to-data-access paths and looks for logic that feels valid in a demo but fails in production.

This is the layer where ShipSafe looks for the auth and access-control bugs that usually survive casual review.

• getSession() used for auth decisions instead of server-validated getUser().
• API routes with no authentication or ownership check at all.
• Supabase tables with RLS disabled or effectively public policies.
• User A able to access User B data through route params or weak filters.
• Service-role clients reachable from request handlers or client-exposed paths.
• Old API handlers still deployed after UI rewrites and no longer protected.

Example: What a ShipSafe Report Looks Like

The output is meant to be directly actionable: one score, ordered severity, file references, and a clear separation between safe auto-fixes and issues that should be escalated instead of patched blindly.

ShipSafe Report — Score: 47/100

CRITICAL
  [secrets] Hardcoded Stripe key found
    -> src/lib/payments.ts:12
    -> sk_live_AbCd...WxYz

  [secrets] Supabase service role in NEXT_PUBLIC_
    -> src/lib/supabase.ts:3
    -> client-exposed secret

  [security] RLS disabled on "profiles" table
    -> supabase/migrations/002_profiles.sql

WARNING
  [config] .env not in .gitignore
  [security] CORS allows all origins
    -> src/app/api/webhook/route.ts:4
  [readiness] 23 console.log statements in production code

AUTO-FIXED
  [config] Created .env.example
  [security] Tightened CORS scaffold
  [readiness] Removed debug logs

What the AI Gets Wrong — A Real Before / After

The dangerous problems often look tiny in diff form. But tiny auth mistakes are enough to make an app exploitable. A typical example is using getSession() as an authorization decision, then pairing it with select('*') and no ownership filter.

That code will absolutely work. It is just not safe.

const { data: { session } } =
  await supabase.auth.getSession()

const { data } = await supabase
  .from('posts')
  .select('*')

// No RLS. No validation.
// No ownership check.

const { data: { user } } =
  await supabase.auth.getUser()

const { data } = await supabase
  .from('posts')
  .select('id, title')
  .eq('user_id', user.id)

// RLS enforced. Scoped.

Install in 2 Minutes

ShipSafe runs locally and fits directly into the AI CLI workflows you already use. No SaaS account, no code upload, no external review queue.

git clone https://github.com/Marinou92/shipsafe.git ~/.claude/skills/shipsafe

git clone https://github.com/Marinou92/shipsafe.git ~/.codex/skills/shipsafe

Who This Is For

ShipSafe is useful whenever AI accelerated delivery faster than your review process kept up.

• Founders who vibe-coded an MVP and need a pre-launch sanity check.
• Developers reviewing giant AI-generated pull requests.
• Freelancers auditing client apps built with Lovable, Bolt, Cursor, or Claude Code.
• Teams that want a repeatable security gate for AI-generated code.

FAQ

Stop Hoping Your Code Is Secure

The point is simple: if AI got you to shipping speed, you also need something that gets you back to production discipline. ShipSafe is that checkpoint.