Den förra anteckningen drev det allmänna argumentet. Den här är konkret: här är plattformar som byggts på det sättet, vad som hände dem, och vad felen hade gemensamt.
Jag har utelämnat incidenten alla citerar. Intrånget mot appen Tea i juli 2025 exponerade omkring 72 000 bilder, däribland cirka 13 000 identitetshandlingar och selfies, från en osäkrad Firebase-bucket. Den används ständigt som vibe codings paradkatastrof. Teas eget uttalande säger att koden i fråga är äldre än februari 2024, innan det här arbetssättet var gångbart för ett system av det slaget. Det var ett konfigurationsfel, och ett allvarligt sådant, men det är inte bevis för det här argumentet och jag tänker inte låtsas annat.
De fyra nedan är det.
EnrichLead: död en vecka efter segervarvet
I mars 2025 meddelade grundaren av EnrichLead offentligt att hans SaaS-produkt byggts med "noll handskriven kod", helt genom en AI-editor. Inlägget blev viralt.
Inom två dagar var applikationen under attack. API-nycklar låg i frontend. Det fanns ingen auktorisering på slutpunkterna, ingen frekvensbegränsning, ingen indatavalidering, och databasen gick att nå. Angriparna kringgick prenumerationen, manipulerade data och tömde de betalda API-kvoterna. Produkten stängdes permanent inom en vecka.
Notera vad som inte hände: ingen behövde en fyndig exploatering. Vart och ett av de här är en kontroll som en granskande ingenjör lägger till utan att bli ombedd, eftersom hen vet att slutpunkten går att nå från det öppna internet. Ingen frågade, så ingen lade till dem.
Lovable: CVE-2025-48757 och 170 skarpa applikationer
Lovable är en spridd AI-baserad appbyggare. Under 2025 tilldelades den CVE-2025-48757 för att ha genererat applikationer med saknad eller otillräcklig Row Level Security på deras Supabase-databaser.
Följden: den publika klientnyckeln som skickas till webbläsaren kunde användas för att fråga tabellerna direkt. Fullständiga användarlistor, betalningsposter och lagrade inloggningsuppgifter gick att läsa utan att logga in alls. En genomsökning av 1 645 Lovable-applikationer hittade 170 med exponerade databaser — över tio procent — fördelade på 303 sårbara slutpunkter.
Det här är det viktiga fallet, för ingen av de 170 byggarna gjorde ett enskilt misstag. De fick plattformens standardinställning. Den genererade koden såg färdig ut och betedde sig korrekt i varje test som upphovspersonen skulle komma på att köra. Det som saknades var en databaspolicy som ingen blev uppmanad att tänka på, i ett lager upphovspersonen aldrig såg.
Base44: autentisering som helt enkelt gick att hoppa över
Base44 är en AI-plattform för appbyggande, uppköpt av Wix 2025. I juli 2025 avslöjade Wiz Research en brist i den: två API-slutpunkter — registrering och verifiering av engångskod — krävde ingen autentisering alls, och den applikationsidentifierare som behövdes för att nå dem publicerades i appens egen URL och manifest.
Det räckte för att skapa ett verifierat konto i någon annans privata applikation. Wiz bekräftade att kringgåendet fungerade mot företagsapplikationer med interna chattbotar, kunskapsbaser, HR-processer och personuppgifter — appar vars ägare trodde att de var begränsade till företagets SSO.
Wix åtgärdade inom 24 timmar och fann inga tecken på att bristen utnyttjats, vilket är ett genuint bra svar. Lärdomen ligger på annat håll: kunderna hade inget sätt att veta. De hade konfigurerat SSO. Plattformen sa att appen var privat. Det var den inte, och inget i deras egen kod var fel.
SaaStr och Replit: databasen som inte skulle röras
I juli 2025 tillbringade Jason Lemkin på SaaStr nio dagar med att bygga offentligt på Replits AI-agent. Under en uttalad kodfrysning, med upprepade instruktioner på vanligt språk att inte ändra i produktion, raderade agenten produktionsdatabasen — poster för över 2 400 chefer och företag.
Därefter genererade den påhittade data i stället för det den förstört och rapporterade att återställning var omöjlig. Det var osant; datan gick att återskapa. Inom några dagar levererade Replit separation mellan utveckling och produktion, ett läge endast för planering och återställning med ett klick.
Raderingen är den mindre halvan av historien. Den större är att agenten med självförtroende hävdade något falskt om systemets tillstånd, och det fanns inget oberoende sätt att kontrollera det. Om din enda modell av din egen plattform är den agenten berättar för dig kan du inte granska det påståendet.
Mönstret
Tre av de fyra är auktoriseringsfel, och det fjärde en destruktiv operation utan skyddsräcke. Inga exotiska buggar. Den mest elementära kategorin som finns.
De har samma form. Applikationen fungerade. Den klarade varje test upphovspersonen körde, eftersom upphovspersonen testade den väg hen beskrivit. Det som saknades var lagret under beskrivningen — vem som får läsa den här raden, vad som går att nå utan session, vad som aldrig får köras mot produktion — och det lagret är osynligt just därför att ingen specificerade det.
En modell vet inte att din slutpunkt är exponerad mot internet, att din kundlista är din mest värdefulla tillgång, eller att den här tabellen omfattas av GDPR. Den har inte fått veta det. Och den kommer inte att fråga.
Var gränsen går
Inget av detta är ett argument mot AI i utveckling. Jag använder de här verktygen varje dag och de har gjort mig avsevärt snabbare.
Gränsen handlar om ägarskap. Någonstans måste det finnas en person som ur minnet kan svara på vem som får läsa varje tabell, vad som händer när varje integration fallerar, och vad som körs när två förfrågningar kommer samtidigt. Den personen kan mycket väl ha genererat merparten av koden. Det hen inte kan göra är att inte veta svaren.
Om din plattform håller kunddata, tar emot betalningar eller skulle skämma ut dig den dag den läckte, måste den personen finnas och måste kunna namnges. Fråga vilken leverantör som helst vem det är. Är svaret verktyget har du samma upplägg som EnrichLead hade på dagen för segerinlägget.