The Vibe Coder Fallacy

The Best Demo Anyone Had Ever Seen

Vibe coding is a way of building software by describing what you want to an AI in plain English, rather than writing code yourself. The term was coined by Andrej Karpathy (a researcher who co-founded OpenAI and previously led AI at Tesla) in early 2025. You tell the model what you want, it writes the code, and you refine by describing problems rather than fixing them line by line. The model types. You provide the vision.

It works. Brilliantly. For the first layer.

There is a moment in every demo room, physical or digital, where something clicks.

The product loads. It responds. Someone types something and it does the right thing. Faces change. The questions stop. Somebody says “when can we have this?” and everybody else is already nodding.

That moment happened millions of times in 2025 and 2026. It happened with unprecedented frequency because anyone could now create a working, responsive, convincing product in an afternoon.

In February 2026, a man called Moltbook into existence this way. An AI social network (a place for AI agents to interact and post) built without a single line of human-written code. The founder said so publicly. Karpathy praised it. The internet arrived. It loaded. It animated. It responded.

By every measure a normal person would use, it looked completely finished. This is not a new gap. Every industry has this story: what people see and what exists are rarely the same thing. In software, for the first time, that gap just became invisible.

Three days later, a security firm called Wiz (a US cybersecurity company) opened the JavaScript that Moltbook’s server sent to every visitor’s browser. Inside it: a database key (a password to the entire database) sitting in plain view. Moltbook was built on Supabase (a popular cloud database service), which requires Row Level Security (the policy that controls which users can read which rows) to be explicitly switched on. It had not been. Default: everything open to anyone with the key. The key was in the code every visitor downloaded automatically.

A researcher exploited the full breach in under three minutes.

Behind those rows: 4.75 million records. One and a half million API keys (passwords to other connected services). Thirty thousand email addresses. Thousands of private messages (Wiz, 2026).

Three days from launch. Under three minutes to exploit.

The demo had been perfect. The product had never existed.

That gap has a name. And it is not a bug in the tools.

Frontend and Backend Is Not Full-Stack

The misconception at the centre of almost every vibe coding failure is not about the tools.

When a non-technical founder, product manager, or first-time builder thinks “full-stack” (the complete thing, front to back) they picture two layers: the interface the user sees, and the server that powers it. Frontend and backend. The AI builds both. The prototype demonstrates both.

A production-ready product requires all thirteen. Auth & Permissions (controlling who can access what). Security & RLS (the policies that enforce those controls at the database level). Rate Limiting (stopping a single user from overwhelming the system). CI/CD & Version Control (a pipeline of automated steps for updating the product safely without breaking what already works). Error Tracking & Logs (knowing when something fails, how, and why). Availability & Recovery (continuing to run, and returning to normal, when it does not).

None of these appear in a demo. The demo is a performance of layers one and two. The other eleven have no role in it.

And the diagram does not show everything. It shows the technical stack. What it does not show is the design layer (the discipline that determines whether anyone actually wants to use what you built).

A vibe-coded interface assembles functional elements without a design intention running through them. It is like a room furnished from eleven different houses. The chair came from a kitchen, the desk from a bedroom, and the light was designed for a hallway. Each piece works on its own. The room never does. This is not a cosmetic problem. It shows up in conversion rates, churn, and the gut feeling every user has that something is slightly off, before they can name it.

In an audit of twelve production-ready vibe-coded apps, four had live payment credentials or database master keys shipped directly in the front-end JavaScript, visible to anyone who opens the browser’s built-in inspection panel (getautonoma.com, 2026).

These are not edge cases from one bad actor. Moltbook was not even the worst of them.

The PM Trap

Moltbook is the story everyone cites. The Quittr story is the one that matters more.

In September 2025, a habit-tracking app called Quittr launched with AI coding tools. Within ten days it reached one million dollars in revenue. Oprah Winfrey mentioned it. It was the kind of launch that makes investors reach for their phones at midnight.

What no one knew was that Quittr’s Firebase database (the cloud service where it stored all its user data) was publicly readable. Any logged-in user could access the full backend, where the records of more than 600,000 people were stored openly. The records included ages, triggers for behavioural habits, and personal confessions about users’ struggles (Cybernews, 2026).

A security researcher found it and contacted Alex Slater, Quittr’s co-founder, on 10 September 2025. Slater’s response: he would fix it “in the next hour.”

He did not fix it for months.

This is the product manager trap. As of May 2026, 63% of the people building applications with vibe coding tools have no coding background (TechTimes, 2026). The majority of people making build-and-ship decisions about AI-generated products cannot see the eleven layers that are missing. Not because they are careless. Because they have no frame for what is behind the wall.

The same blindspot hides design failures. A product manager without design experience cannot see that the first few screens of the app are losing most users before they ever reach the product. They cannot see that error messages are written in developer shorthand that no user understands. They cannot see that the mobile layout is technically responsive but requires a precision of thumb movement real users do not have.

A building inspector knows what to look for behind the wall. A designer knows what to look for in a user’s first sixty seconds. Someone who has only ever toured the show home sees neither.

Not a Freak Event

If Moltbook and Quittr were isolated incidents, you could call them bad luck.

In late 2025, Enrichlead (a software product sold on subscription) watched users find a complete paywall bypass within 72 hours of launch, by changing one value in a hidden developer panel built into every web browser. The check that verified whether a user had paid existed only in the front end (the layer the user controls). Anyone could simply remove it (getautonoma.com, 2026).

Also in 2025, Lovable’s AI generated access control logic across 170 production applications (the rules that decide who can touch what) and got it backwards. Users who had logged in were blocked. Everyone else had open access. The AI had implemented the security layer. It had simply inverted it (CVE-2025-48757, a formally recorded software vulnerability).

Amazon’s internal teams, deploying vibe coding tools with experienced engineers, produced four Sev-1 failures (the most critical level of production incident) in ninety days, including a six-hour outage.

And in April 2026, Lovable the platform (used by eight million people, valued at $6.6 billion) ran for forty-eight days with a broken authorisation flaw. Every user’s source code, database credentials, and AI chat histories were readable by any other logged-in user. A bug report was filed. Lovable’s team reviewed it, marked it “intentional behavior,” and closed it without escalation. They fixed it in two hours once the story went public (The Next Web, 2026).

Across independent security testing: 62% of AI-generated code ships with at least one vulnerability (OX Security, 2026). More than 380,000 publicly accessible vibe-coded apps on the open web, 2,000+ actively leaking data, with no attacker required (Red Access, 2026). AI-generated code now causes one in five enterprise security breaches (per industry analysis, 2026). These are not rare edge cases. They are the default outcome of shipping eleven unbuilt layers.

Four Failure Modes

These incidents look different. One founder, three days. Another founder, months. A platform, forty-eight days. Amazon, ninety days. But they all fail in the same four ways.

Technical failure is the most documented. Missing authentication, exposed database keys, access rules never configured, or configured backwards. These are fixable. The thirteen-layer framework tells you exactly where to look. Technical failure happens when the layers under the interface are never built by people who know what building them requires.

Design failure is less discussed and equally real. The user journey was never mapped. Error states were never written in language users can act on. Onboarding was never tested against how a real person reads and moves. Mobile “works” but is not designed for how people actually use their thumbs. Users leave products that feel wrong before they can name why. And a non-technical PM cannot see this failure any more than they can see a missing security layer, because they have no frame for what a well-designed product experience looks like from the inside.

Organisational failure is quieter and more consequential. Slater was not negligent. He was operating in a mental model where the demo was the product. When the person making decisions about readiness has never built or designed any of the layers underneath, those layers are permanently invisible to the decision-making process. The same blindspot covers security and design.

Perceptual failure is the one that makes the other three inevitable. It is last on this list, but first in the chain: everything else flows from it. It happens in the demo room. The prototype loads, clicks, and does the right thing. The investor nods. The client says “when can we have this?” The PM says “soon.” Everyone has experienced the same convincing illusion: a working product. What they experienced was two layers of thirteen, with no design system behind it.

Prototypes used to look like prototypes. Now a vibe-coded prototype loads, responds, and delivers the product’s core value proposition completely. The gap between it and a real product is invisible. Invisible gaps are the most expensive kind.

What the Prototype Is Actually For

None of this is an argument against building fast. The speed is real and useful. The tools are improving too: vibe coding platforms are adding authentication scaffolding, security checks, and deployment pipelines. What does not improve with the tools is the mental model that treats a convincing demo as a finished product.

The prototype is the most precise brief you will ever hold.

It communicates to engineers, designers, security specialists, and stakeholders exactly what you are trying to build, with a fidelity that no slide deck or written spec can match. You built the interface. You can demonstrate the flow, the feel, the user journey. You have eliminated the most common cause of failed software projects: the gap between what the people building it imagine and what the people wanting it actually need.

That is where the prototype’s job ends.

Treating it as a brief resolves all four failure modes at once.

It fixes the technical failure, because the brief goes to specialists before launch, not after the breach. It fixes the design failure, because the prototype is handed to a designer who uses it as a reference for the actual design system: the user journey, the error states, the onboarding, the mobile experience, the copy. The prototype shows what is wanted. The designer builds what will actually work. It fixes the organisational failure, because the PM’s role shifts from “is this ready to ship?” to “have the engineers and the designer finished their layers?” Those are questions anyone can ask and verify. And it fixes the perceptual failure, because when the prototype is a brief, the demo room’s question becomes “is this what we want to build?” not “when can we launch this?”

The right workflow: prototype → brief engineers and a designer → engineers build layers 3-13 → designer builds the design system → security review → launch.

The wrong workflow is: prototype → someone who cannot see the gap says “it looks ready” → launch.

Most vibe-coded products that reach production fail. Not because the tool failed. Because nobody in the demo room knew what the demo could not show.

Hand the prototype to an engineer. Hand it to a designer. That is the workflow. Everything else is a demo room where someone who cannot see the gap calls it done.

The Era of Visible Products