9 Sekunden: was PocketOS über Verantwortung in vibe-engineered Software sagt
9 Sekunden
Was PocketOS über Verantwortung in vibe-engineered Software sagt
Es dauerte neun Sekunden, bis die Produktionsdatenbank von PocketOS und sämtliche Backups gelöscht waren. Kein Hack. Kein Insider. Kein Stromausfall. Ein Cursor-Agent — angetrieben von Claude Opus 4.6, dem zu diesem Zeitpunkt stärksten verfügbaren Modell — stieß bei einer routinemäßigen Aufgabe auf ein Authentifizierungsproblem, fand in einer fremden Datei einen API-Token mit Admin-Rechten, benutzte ihn, und schaffte das Problem entschlossen aus der Welt: indem er die Datenbank entfernte.
Jeremy Crane, Gründer von PocketOS (Software für Autovermietungen), postete den Vorfall öffentlich auf X. 30 Stunden Ausfall. Älteste wiederherstellbare Sicherung: drei Monate alt. Reservierungen manuell rekonstruiert. Railway-CEO Jake Cooper musste persönlich für eine Recovery eingreifen.
Das ist keine Vibe-Coding-Story
Genau das macht den Vorfall interessant. Bei Moltbook, Tea oder Enrichlead saßen Builder am Steuer, die kein klassisches Engineering-Hintergrund hatten. Bei PocketOS war es ein erfahrener Software-Engineer. Die Plattform war nicht Lovable oder Bolt, sondern Cursor — das Werkzeug der Profis, mit den besten verfügbaren Modellen, mit explizit konfigurierten Sicherheitsregeln. Genau die Konfiguration, die das Vibe-Coding-Problem hätte lösen sollen.
Es hat trotzdem nicht gereicht.
Das ist nicht vibe coding. Das ist vibe engineering — KI-augmentierte Software-Entwicklung durch Menschen mit Engineering-Erfahrung, mit den stärksten Modellen am Markt. Und auch hier ist die Datenbank in neun Sekunden weg.
Die Lücke ist nicht technisch — sie ist organisatorisch
Die strukturelle Frage ist nicht "wie konnte die KI das tun". Sie ist: wer war eigentlich namentlich verantwortlich für die Entscheidung, ob die Datenbank gelöscht werden darf?
In einem klassischen Engineering-Setup hätte ein Senior-Engineer ein Code-Review gemacht, ein DBA hätte eine Migration freigegeben, ein Ops-Verantwortlicher hätte die Deletion gegenzeichnen müssen. Diese Menschen sind nicht aus Bürokratie in der Schleife. Sie sind die Träger der Verantwortung dafür, dass eine zerstörerische Aktion bewusst geschieht.
Wenn der KI-Agent autonom handelt, übernimmt er das Routing. Er übernimmt die Analyse. Was er nicht übernimmt — und nicht übernehmen kann — ist die Verantwortung für eine destruktive Entscheidung in dem Moment, in dem sie getroffen wird. Das ist kein Modell-Fehler. Es ist eine Lücke in der Architektur des Systems.
Cranes eigene Empfehlung nach dem Vorfall ist exakt diese Diagnose: "AI-Agenten sollten zerstörerische Aufgaben nicht ohne Bestätigung ausführen." Was Crane fordert, ist ein DRI-Gate — eine Directly Responsible Individual, eine namentlich benannte Person, die die zerstörerische Entscheidung übernimmt, bevor sie passiert.
Was das mit Vibe Coding zu tun hat
Vibe-Coding-Plattformen wie Lovable und Replit haben dieses Problem in den letzten Monaten verstärkt sichtbar gemacht. Aber PocketOS zeigt, dass die zugrunde liegende Lücke nicht plattform-spezifisch ist. Sie entsteht überall dort, wo autonomie-fähige Agenten ohne explizite menschliche Verantwortlichkeits-Gates arbeiten.
Bei vibe-gecodeten Apps macht die Lücke RLS-Defaults und exponierte Schlüssel teuer. Bei vibe-engineered Apps macht sie 9-Sekunden-Datenbank-Löschungen möglich. Beide haben dasselbe strukturelle Defizit: niemand ist namentlich verantwortlich für die destruktive Entscheidung in dem Moment, in dem sie getroffen wird.
Auch wenn vibe-engineering-Tools und vibe-coding-Platformen es so gut wie jedem ermöglichen, wundervolle Anwendungen und profitable Businesses zu bauen - diese Tools übernehmen nicht die Verantwortung. Es gibt kein Accountability-Toggle-Switch: nicht in Lovables mobile app und es gibt auch kein Verwantwortungs-Skill in claude code oder cursor.
Die Antwort ist nicht "mehr KI-Sicherheit". Die Antwort ist eine organisatorische: ein menschliches DRI-Gate vor jeder zerstörerischen Aktion oder eine klare Delegation der Verantwortung an ein AI Ops Unternehmen. Das ist eine architektonische und organisatorische Entscheidung, keine technische.
Anthropic hat zwei Tage später Claude Opus 4.7 mit verbesserten Safety-Mechanismen für autonome Aufgaben veröffentlicht. Das ist eine richtige Antwort. Es ist nur nicht die einzige Antwort, die fehlt. Es gibt keinen deterministischen Toggle für Accountability. Genau wie in lovable, replit, etc etc.
Was du mitnehmen kannst
Wenn du eine Anwendung in Produktion betreibst — vibe-gecodet oder vibe-engineered — und nicht klar sagen kannst, welcher Mensch namentlich für welche destruktive Aktion verantwortlich ist, fang dort an. Vor jedem Migration-Skript, vor jedem Cleanup-Job, vor jedem Agent-Lauf, der schreibend auf Produktionsdaten zugreift, gehört ein Name.
Du kannst dieses Gate nicht an die Plattform delegieren. Du kannst es nicht an den Agenten delegieren. Du kannst es nur an einen Menschen delegieren — und dieser Mensch muss zum Zeitpunkt der Entscheidung im Loop sein.
Bei Lastable ist genau das Teil unseres Managed-Ops-Modells: jede destruktive Aktion auf Kunden-Infrastruktur hat einen namentlichen Owner und ein Pre-Action-Gate. Das ist nicht sexy. Es verhindert nur 9-Sekunden-Vorfälle. Und es nimmt die Middle-Manager Rolle ein, die dein Unternehmen nicht mehr hat.