On January 28, 2026, a founder posted on social media that he had just launched an AI social network. He highlighted one detail above everything else: he hadn’t written a single line of code. AI tools had built the whole thing. Three days later, security researchers at Wiz found his production database open to the public. One-and-a-half million API authentication tokens. Thirty-five thousand email addresses. Every private message on the platform. No attacker needed to break in. The database was just there, waiting for anyone who looked.
The founder didn’t know it was exposed. The AI that built his application didn’t know either, because nobody had asked it to care.
That was Moltbook. It will not be the last story like it you hear this year.
There is a specific thing that happened over the last two years that nobody has summarised cleanly. Building software got dramatically faster. Deploying software got easier. Understanding what you deployed did not get easier at all. In some ways it got harder, because the person holding the keys stopped being the person who built the locks.
Vibe coding is the shorthand for this: describing what you want to an AI tool, reviewing the output casually if at all, and shipping it. It is real, it is widespread, and in specific circumstances it is genuinely useful. The problem is that the circumstances where it is useful and the circumstances where people are using it have almost nothing in common right now.
What AI Code Generation Is Actually Optimised For
When you ask an AI coding tool to build a user authentication flow, it will build one. It will pass the happy path. The user enters the correct password and gets in. What it does not reliably do is reason about the unhappy paths: the attack surfaces, the access control logic, what happens when someone tries 30,000 common passwords in two minutes, or what a malicious payload in a form field can do to a database that was never told to defend itself.
It is not that the AI is careless. It satisfies the requirement you gave it. Security assumptions that an experienced engineer applies instinctively are not part of the stated requirement. Rate limiting, Row Level Security on your database tables, input sanitisation, proper token expiry, the habit of asking “what happens when this goes wrong”: none of these appear in the brief the founder typed into the chat window. They live in the unstated layer of professional judgment that comes from having seen what breaks at scale.
A Q1 2026 assessment of over 200 vibe-coded applications found that 91.5% contained at least one vulnerability traceable to AI omission or hallucination. Forty-five percent fail OWASP Top-10 security benchmarks. Georgia Tech’s Vibe Security Radar tracked 74 real-world CVEs in AI-generated code by mid-2026, up from six in January. These are not numbers from a cautious academic paper. These are live, shipped applications that real users are trusting with their data.
The structural issue is that AI generates code that satisfies the stated requirement, without the security layer that experienced developers apply as a matter of course. The gap is not in what the AI wrote. The gap is in what nobody thought to ask.
The “We’ll Fix It Post-Launch” Trap
Here is where it gets expensive.
Most founders who vibe-code their MVPs know, at some level, that they have cut corners. The reasoning is reasonable on paper: we are not storing sensitive data yet, we do not have real users yet, we will come back and clean it up when we have resources. It falls apart in practice because the moment the product works, it attracts users. And the moment it attracts users, there is no time to rebuild the foundation because there is now a building on top of it.
Quittr is a useful example here. A habit-tracking app, built with AI-assisted code generation, hit one million dollars in revenue in ten days and received a mention from Oprah. By any measure, a success story. The Firebase database was publicly readable for all 39,000 users during that window. Health data. Payment information. Behavioral records. The founder had no reason to check because the app worked. It worked spectacularly. A misconfigured database does not announce itself. It waits.
Tea App exposed private direct messages between users. Lovable-built applications, 170 of them catalogued under CVE-2025-48757, had their access control logic inverted, meaning users could see data that belonged to other accounts. In March 2026 alone, 35 new CVEs were traced directly to AI-generated code in production. The root cause repeats in every case: AI generated code that did what it was asked, without the assumptions an experienced developer brings to the work as standard practice.
The pattern is not bad AI. It is a workflow that stops at “it works” without asking what it does not do.
The Economics Are Catching Up
For the first year or two, the cost of this is invisible. The application runs. Users are happy. The bill has not arrived.
Then something changes. A security researcher files a bug report. A compliance audit finds that the database structure does not meet HIPAA or PCI requirements. A new engineer joins and says, quietly, that they are not sure how any of this actually works. The shortcuts that felt temporary stop being hypothetical.
An estimated 8,000 or more startups that built production applications with AI tools are currently looking at full or partial rebuilds. The cost per rebuild ranges from $50,000 to $500,000, depending on how much of the original architecture needs to go. The total industry cleanup cost sits somewhere between $400 million and $4 billion. That number is growing every quarter.
The year-two maintenance cost on unreviewed AI-generated code runs approximately four times the cost of code that was properly reviewed from the start. Even in year one, the cost advantage of moving fast is smaller than it looks: teams running AI-generated code without review face 1.7 times the testing burden and twice the code churn of teams that reviewed as they went. The speed is real. The savings are mostly not.
Where the Line Actually Is
The answer is not to stop using AI in development. That discussion ended already. The question is where to draw the line on what gets shipped without human review.
For internal tools, throwaway prototypes, data migration scripts, or an admin dashboard used by a team of five people who all work at the company: vibe coding is probably fine. The blast radius of a mistake is contained. The person harmed by broken code is also the person who can fix it.
For customer-facing production systems, especially anything handling personal data, financial transactions, healthcare records, or authentication: AI-generated code requires structured review by someone who understands what they are looking at. Not a cursory glance. Not running the test suite. A review by an engineer who can reason about what the AI built, where it made assumptions, and what it silently left out.
That review layer is what AI-powered development done properly actually looks like. The AI generates the structure. The engineer validates the logic, the access controls, the failure modes. The speed comes from the AI. The reliability comes from the human who remembers what broke the last time this kind of thing went wrong.
For teams dealing with older codebases that were vibe-coded during the growth phase and now need to be made trustworthy, this is increasingly what application modernisation work looks like in 2026. Taking the AI-generated foundation and rebuilding it with ownership intact.
The Accountability Gap
The deeper problem with vibe coding in production is not technical. It is accountability.
When a senior engineer writes authentication logic, they own it. They know why it is structured the way it is. If it breaks at 3am, they can reason about what went wrong. When an AI writes authentication logic and a non-technical founder ships it without review, nobody owns it in that sense. Nobody can reason about it. The system works right up until it does not, and when it does not, the gap between the code and the person responsible for it becomes the entire problem.
This is a version of the same mess that offshore development created at its worst: teams building systems nobody could maintain, vendors who moved on, clients left holding code they could not read. The mechanism is different. The outcome is recognisable.
Workflow automation built on shaky foundations amplifies this. When AI-generated processes are layered on top of AI-generated code, the surface area for silent failure grows. The system keeps running until something in the middle snaps, and tracing that snap requires someone who understands what they built.
What to Check Before Something Else Checks It for You
If you have a production application that was built primarily with AI tools and has not had a structured review, a few things are worth looking at before the Wiz researchers do.
Find out whether your database has Row Level Security configured, and whether it is configured correctly rather than in a permissive default state. Find out whether your authentication logic has been reviewed by someone who understands access control. Find out whether any API keys, credentials, or secrets are hardcoded in your repository or exposed in client-side code. Check whether your rate limiting is real or whether it exists only in the code comments.
If you do not know the answers to any of those questions, that is the answer.
Getting fast to market matters. Staying in the market, at scale, under a compliance audit, when your biggest client is on the line at 3am, matters more. The founders who will build durable companies with AI tools are the ones who treat AI output as a first draft. The ones who understand that “does it work?” and “is it production-ready?” are two different questions that often have two different answers.
That gap between the demo and the production system is not new. It has always been where the real work lives. AI tools did not close it. They made it easier to step over it without noticing.
Sounds familiar?