Vibe coding: what it is, where it breaks, and how to ship it safely

Vibe coding is building software by describing what you want to an AI and accepting the code it writes, without reading it line by line. It is the fastest way yet to get from an idea to a working prototype, and the code still needs an engineer’s eyes before real people, real data and real money touch it.

I ship with AI at every step, and I built a live app on my own with AI doing the typing. This is what I have learned about the gap between the vibe and production.

What is vibe coding?

Andrej Karpathy coined the term in a post on 2 February 2025: a new kind of coding where you “forget that the code even exists”. He accepted every change without reading the diffs, pasted error messages straight back to the AI, and said it was fine for throwaway weekend projects. Nine months later, Collins named vibe coding its Word of the Year 2025.

Most professional developers keep their distance. In the Stack Overflow 2025 Developer Survey (July 2025), 72% of respondents said vibe coding is not part of their professional development work and another 5% said so emphatically, while 84% use or plan to use AI tools. The difference is ownership: AI-assisted engineering means someone reads the code, tests it and answers for it. Vibe coding means nobody does.

What tools do people use for vibe coding?

Two kinds, and many people use both.

• App builders in the browser. Lovable, Bolt, Replit and v0. You describe the app in a chat and get a running app, often with hosting and a database wired in.
• AI code editors and coding agents. Cursor, Claude Code, Codex, Gemini CLI and GitHub Copilot. They work in a real code repository on your machine and can run commands.

Underneath, most vibe-coded apps land on the same few services: a hosted database such as Supabase or Firebase, a host such as Vercel or Netlify, and Stripe for payments. That matters, because those services are where the production rules live.

What is vibe coding good for?

• Prototypes that customers or investors can press and break, in days.
• Internal tools for a handful of people you trust.
• One-off apps for an event, where the stakes and the lifetime are short.
• Testing a product idea before you spend on a team.

I built Laqtaa, a shared wedding photo app, on my own for a friend’s wedding: one shared camera for your event. About 100 guests used it on the day and nothing broke. Before any code I wrote a 780-line brief with a hard deadline. Even so, on the first day, a couple of hours after 6 milestones were built and deployed in 53 minutes, the next commit read “resolve all critical runtime bugs”. Over 5 weeks it took 188 commits, 93 of them fixes. The full story is in can one person with AI do a whole team’s work.

Where do vibe-coded apps break in production?

In the parts a demo never touches: other people, other people’s data and money.

• Sign-in and roles. The login works, but the check for who is staff sits in the browser or reads a field users can edit.
• Data rules. The database answers anyone holding the public key. In Supabase that means Row Level Security is off or too loose; my Supabase security checklist has the SQL.
• Secrets. A secret key ends up in the JavaScript every visitor downloads, or in git history. The vibe coding security checklist covers secrets and the other 12 checks to run before launch.
• Payments. The app marks an order paid when the customer lands on the “thank you” page, or trusts any message sent to its payment webhook. Stripe warns that without signature verification “an attacker could send fake webhook events” to trigger actions like fulfilling orders, and that endpoints can receive the same event more than once (Stripe webhooks).
• Scale. Ten testers work fine. Two hundred people at your busiest moment run out of database connections, and two of them book the same table. Supabase tells you to use its transaction mode pooler for serverless functions, which “open many short-lived connections” (Supabase docs).
• Nobody understands the code. Karpathy wrote that his code grew beyond his usual comprehension. With no tests and no notes, each new prompt fixes one thing and breaks another, and nobody can say why.
• The agent itself. The AI that wrote the app has a shell and your keys. It can delete your database.

The payment fix is short once you know it. Verify the signature on the raw body, and skip events you have already handled:

// app/api/stripe-webhook/route.ts (Next.js)
import Stripe from 'stripe';
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export async function POST(req: Request) {
  const body = await req.text();   // the raw body, not parsed JSON
  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(
      body, req.headers.get('stripe-signature')!, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return new Response('bad signature', { status: 400 });
  }
  // store event.id; if you have seen it before, return 200 and do nothing
  return new Response('ok');
}

And the double booking is one line of SQL, so the database refuses the second guest whatever the browser thinks:

alter table bookings
  add constraint one_booking_per_slot unique (table_id, slot_start);

What stands between a prototype and production?

Gates. Below is a release pipeline for a made-up restaurant booking app, built over a weekend with an AI app builder. Each gate runs a real kind of check and fails the way vibe-coded apps fail. Pick a fix and re-run the gate: some fixes look right and still fail. The last three gates are where an engineer earns their fee.

How do you take a vibe-coded app to production?

This is the order I work in when I take a prototype to production as a forward deployed engineer. I come from coding and design, and I use AI at every step; the steps are what the AI does not do on its own.

1. Write down what the prototype does. The three or four flows that matter, who uses them and what must never happen. The prototype is now the spec.
2. Get the code into a repository you own, with separate development and production databases and keys.
3. Run the security pass. The 13 checks take an afternoon for a small app.
4. Rebuild the risky paths properly: sign-in, payments and anything that writes data, each with tests.
5. Load test your busiest moment, then fix what falls over, in the database, not the browser.
6. Put a guard on the coding agent. I built GVNR, a free and source-available guard that runs on your own machine and works with Claude Code, Cursor, Codex, Gemini CLI and any MCP client. Before each action it decides allow, deny or ask a person, and it keeps a hash-chained record of every decision.
7. Ship with a way back: a backup you have restored once, the previous release ready to roll back to, and alerts when errors spike.
8. Name an owner, with a one-page note on how the app runs and deploys.

When should you bring in an engineer?

Before the app does any of these:

• Takes money, including deposits and subscriptions.
• Stores other people’s personal data, or anything regulated such as health or financial records.
• Opens to people you do not know, at a launch, a sale or a busy hour.
• Breaks somewhere new every time you fix something.

You do not need a team for this. You need one person who reads the code, hardens the parts that carry risk and hands it back with tests and notes. That is the work I do as a fractional CPO and forward deployed engineer: prototypes in days, then the hardening that gets them to production.

Questions people ask

Who coined the term vibe coding?

Andrej Karpathy, a founding member of OpenAI and former Director of AI at Tesla, in a post on X on 2 February 2025. Collins Dictionary named it Word of the Year 2025.

Is vibe coding bad?

No. It is the fastest way to a working prototype. It becomes a problem when a prototype goes live with real users, data or payments and nobody has read the code.

Can a vibe-coded app go to production?

Yes, after it passes the gates: secrets, sign-in and data rules, payments, load and handover. Keep what works, rebuild only what fails.

Do I need to know how to code to vibe code?

Not to build a prototype. To ship it safely, someone on the project needs to read code, or you need to bring that person in before launch.

What is the difference between vibe coding and AI-assisted coding?

Who owns the code. In AI-assisted coding a person reads, tests and answers for every change. In vibe coding the AI’s output goes in unread.

If you have a vibe-coded app that needs to reach production, write to me at m@tawfik.tv.