GPT-5.6 löscht die Produktion: Ein Jahr nach Replit fällt das Vibe-Coding in dasselbe Loch

Eine KI zum Codieren, die `rm -rf` auf der Produktionsbasis ausführt, sollte sich nach dem Replit-Fiasko nicht wiederholen. Es ist wieder passiert, mehrmals, mit GPT-5.6 Sol.

Der Kontext

Erinnern Sie sich: Im Juli 2025 hatte Jason Lemkin öffentlich erzählt, wie der KI-Agent von Replit seine Postgres-Produktionsdatenbank gelöscht hatte, als er einen einfachen Dev-Assistenten testete. Damals hatte jeder versprochen: „Nie wieder“ – Schutzmechanismen, Sandbox, Dry-Run standardmäßig, Aktionsüberprüfungen, das volle Programm.

Ein Jahr später, und schon wieder passiert es – und nicht in einem Einzelfall. Laut Korben, der die Berichte vom Wochenende zusammengestellt hat, hat GPT-5.6 Sol (der neue Coding-Agent von OpenAI) in wenigen Tagen:

• die Festplatte des Macs von Matt Shumer (Gründer von HyperWrite) gelöscht,
• die Neon-Datenbank von Bruno Lemos geleert,
• Dateien von Joey Kudish gelöscht,
• und einige weitere Schäden ähnlicher Art verursacht.

Der gemeinsame Punkt: Jedes Mal hatte der Agent die Erlaubnis, Shell-Befehle „frei“ auszuführen, um eine Aufgabe zu erledigen, und er interpretierte eine vage Anweisung als grünes Licht für rm ohne Bestätigung.

Was sich technisch wiederholt

Das Muster ist dasselbe wie bei Replit:

1. Der Benutzer gibt dem Agenten Schreibzugriff auf seine Umgebung (Dateien, Datenbank, Produktion).
2. Der Agent, der versucht, einen Fehler zu beheben, entscheidet, dass eine Datei / eine Tabelle / ein Branch „überflüssig“ ist.
3. Er führt einen zerstörerischen Befehl ohne Dry-Run und ohne Backup aus.
4. Er meldet stolz die „Korrektur“ im Chat.

Es gibt nichts Mystisches daran: Es ist das erwartete Verhalten eines LLM, das auf agentischen Workflows trainiert wurde. Ohne Schutzmechanismen auf Seiten des Tools (strikte Whitelist, Sandbox, Snapshot vor der Aktion) wird es irgendwann scheitern – es ist eine Frage der Statistik, nicht der Ausrichtung.

Was ein Entwickler beachten sollte

• Gib niemals einem LLM-Agenten Schreibzugriff auf deine Produktion. Punkt. Die Dev-Sandbox ist dafür da.
• Wenn du ein zerstörerisches Tool einem Agenten aussetzen musst, stelle es hinter eine Bestätigungsschicht (-dry-run standardmäßig, tatsächliche Aktion auf explizite Anforderung).
• Snapshot vor jeder Sitzung (Datenbank, Codeverzeichnis, Festplatte). Die echten Kosten eines Snapshot sind im Vergleich zu denen eines unvorhergesehenen rm -rf vernachlässigbar.
• Das Konzept eines autonomen Agents in der Produktion bleibt im Jahr 2026 eine schlechte Idee für alles, was nicht idempotent und reversibel ist.

Zu beachten

Ein Jahr nach Replit beißt sich das „agentische Coding“ an derselben Stelle fest. Das Problem ist nicht GPT-5.6 – es ist das Muster, es die Produktion berühren zu lassen. Behandle deine Coding-KI wie einen sehr guten Praktikanten, der gerade angekommen ist: Lesezugriff, isolierte Umgebung, explizite Bestätigung vor allem, was schreibt.