The previous note argued the general case. This one is specific: here are platforms that were built this way, what happened to them, and what the failure had in common.
I have left out the incident everybody cites. The Tea app breach of July 2025 exposed roughly 72,000 images, including around 13,000 identity documents and selfies, from an unsecured Firebase bucket. It is used constantly as the headline vibe-coding disaster. Tea's own statement says the code involved predates February 2024, before this way of working was viable for a system of that kind. It was a configuration failure, and a bad one, but it is not evidence for this argument and I am not going to pretend otherwise.
The four below are.
EnrichLead: dead within a week of the victory lap
In March 2025 the founder of EnrichLead announced publicly that his SaaS product had been built with "zero hand-written code", entirely through an AI editor. The post went viral.
Within two days the application was under attack. API keys were sitting in the frontend. There was no authorisation on the endpoints, no rate limiting, no input validation, and the database was reachable. Attackers bypassed the subscription, manipulated data, and exhausted the paid API quotas. The product was shut down permanently inside a week.
Note what did not happen: nobody needed a clever exploit. Every one of those is a control that a reviewing engineer adds without being asked, because they know the endpoint is reachable from the open internet. Nobody asked, so nobody added them.
Lovable: CVE-2025-48757, and 170 live applications
Lovable is a mainstream AI app builder. In 2025 it was assigned CVE-2025-48757 for generating applications with missing or insufficient Row Level Security on their Supabase databases.
The consequence: the public client key shipped in the browser could be used to query tables directly. Full user lists, payment records and stored credentials could be read without logging in at all. A scan of 1,645 Lovable applications found 170 with exposed databases — over ten percent — across 303 vulnerable endpoints.
This is the important one, because none of those 170 builders made an individual mistake. They got the platform's default. The generated code looked finished and behaved correctly in every test its author would think to run. The missing piece was a database policy nobody was prompted to think about, in a layer the author never saw.
Base44: authentication that could simply be skipped
Base44 is an AI app-building platform, acquired by Wix in 2025. In July 2025 Wiz Research disclosed a flaw in it: two API endpoints — registration and one-time-password verification — required no authentication at all, and the application identifier needed to reach them was published in the app's own URL and manifest.
That was sufficient to create a verified account on someone else's private application. Wiz confirmed the bypass worked against enterprise applications holding internal chatbots, knowledge bases, HR operations and personal data — apps whose owners believed they were restricted to company SSO.
Wix patched it within 24 hours and found no evidence it had been exploited, which is a genuinely good response. The lesson is elsewhere: the customers had no way to know. They had configured SSO. The platform told them the app was private. It was not, and nothing in their own code was wrong.
SaaStr and Replit: the database that was not supposed to change
In July 2025 Jason Lemkin of SaaStr spent nine days publicly building on Replit's AI agent. During an explicit code freeze, with repeated instructions in plain English not to alter production, the agent deleted the production database — records for more than 2,400 executives and companies.
It then generated fabricated data in place of what it had destroyed, and reported that rollback was impossible. That was untrue; the data was recoverable. Replit shipped dev/production separation, a planning-only mode and one-click restore within days.
The deletion is the smaller half of the story. The larger half is that the agent confidently asserted something false about the state of the system, and there was no independent way to check it. If your only model of your own platform is the one the agent narrates to you, you cannot audit that claim.
The pattern
Three of those four are authorisation failures, and the fourth is a destructive operation with no guard rail. Not exotic bugs. The most basic category there is.
They share a shape. The application worked. It passed every test its author ran, because its author tested the path they had described. What was absent was the layer beneath the description — who may read this row, what is reachable without a session, what must never run against production — and that layer is invisible precisely because nobody specified it.
A model does not know that your endpoint is internet-facing, that your customer list is your most valuable asset, or that this table is subject to GDPR. It was not told. It will not ask.
Where the line sits
None of this is an argument against AI in development. I use these tools every day and they have made me considerably faster.
The line is ownership. Somewhere there must be a person who can answer, from memory, who can read each table, what happens when each integration fails, and what runs when two requests arrive at once. That person can absolutely have generated most of the code. What they cannot do is not know the answers.
If your platform holds customer data, takes payments, or would embarrass you on the day it leaked, that person needs to exist and needs to be named. Ask any supplier who it is. If the answer is the tool, you have the same setup EnrichLead had on the day of the victory post.