Datenbank-Unfälle mit KI: Regel-Konflikte, Worktree-Kollisionen und was wirklich schützt

Vor Kurzem ging ein Fall durchs Netz: Eine KI-gestützte Cloud-Umgebung hat einem Nutzer die komplette Datenbank weggeräumt. Wer da genau was angeklickt hat, was im Chat stand, was die Sandbox eigentlich verhindern sollte — das wird vermutlich nie sauber rekonstruiert werden. Was bleibt, ist die unangenehme Frage: Wie passiert sowas überhaupt — und wie verhindere ich, dass es mir morgen passiert?

Wir arbeiten täglich intensiv mit Datenbanken im KI-Loop. Und seit ein paar Wochen fällt uns auf, dass zwei Klassen von Problemen besonders gefährlich sind — beide subtil, beide mit Datenverlust-Potenzial, beide nicht durch “noch eine Memory-Zeile” zu lösen.

Beobachtung 1: Die Sandbox blockt jetzt strenger — und das ist gut

In den letzten Wochen sehen wir deutlich häufiger, dass das Modell beim Schreiben auf eine Datenbank stehenbleibt und explizit eine Freigabe einholt. Kein stillschweigendes “ich fahr die Migration mal eben durch”, sondern ein hörbares “darf ich?”.

Das ist ein Fortschritt. Genau diese Klasse von Aktionen — schreibend, schwer reversibel, oft im Zuge “noch schnell aufräumen” — gehört nicht in den autonomen Modus. Wer hier eine zusätzliche Bestätigungsschleife einzieht, fängt einen großen Teil der wirklich teuren Unfälle ab, bevor sie passieren.

Aber: Das löst nicht das eigentliche Problem. Es entschärft es nur an einer Stelle.

Beobachtung 2: Eigene Regeln stehen sich gegenseitig im Weg

Hier wird es interessant. Wer auf Geschwindigkeit optimiert, hat irgendwo in seinen Regeln stehen: „Bei kleinen, trivialen Sachen einfach machen.” Macht Sinn — sonst fragt das Modell bei jedem Komma nach.

Das Problem: Eine kleine Datenbank-Migration fühlt sich trivial an. Ein Feld hinzufügen, einen Index setzen, eine Spalte umbenennen. Drei Zeilen SQL. Ist aber eben nicht trivial — sondern potenziell datenbewegend, schwer rückgängig zu machen, und in Produktion teuer.

Genau das ist uns passiert. Eine Migration, die unter “DB-Migrationen brauchen Freigabe” hätte fallen müssen, wurde vom Modell unter “kleine triviale Sachen einfach machen” verbucht. Nachgefragt: „Sorry, das habe ich als trivial eingestuft.” Wortlaut der Regel, die das Modell aktiviert hatte — exakt der Wortlaut, den wir selbst geschrieben hatten.

Kein böser Wille, kein Bug. Zwei Regeln, die sich überlappen, und das Modell hat geraten. Manchmal richtig. In diesem Fall falsch.

Das ist genau das Muster, das wir in „Die KI macht, was sie will — und keine CLAUDE.md hält sie auf” beschrieben haben: Regeln sind Wünsche, keine Garantien. Wenn sich zwei Wünsche widersprechen, entscheidet das Modell — und die Wahrscheinlichkeit, dass es im Sinne des riskanteren Wegs entscheidet, ist nicht null.

Beobachtung 3: Worktrees können sich gegenseitig die DB zerschießen

Das ist die Geschichte, bei der wir uns die Datenbank tatsächlich selbst abgeschossen haben — und die war kein KI-Fehler, sondern ein Workflow-Fehler, den wir nicht auf dem Schirm hatten.

Setup: Wir arbeiten parallel in mehreren Git-Worktrees. Worktree A baut eine Migration mit fortlaufender Nummer, sagen wir Migration 70. Worktree C, parallel angelegt, baut ebenfalls eine Migration — und vergibt ebenfalls Nummer 70, weil zum Zeitpunkt des Anlegens noch keine 70 existiert hat.

Beide Migrationen laufen, beide Worktrees denken, sie wären sauber. Tatsächlich liegen jetzt zwei verschiedene Migrationen mit derselben Nummer im System — und je nachdem, welche zuletzt durchläuft, ist die andere weg, ohne Spur, ohne Warnung. Und weil beide Worktrees ihre eigene lokale Sicht haben, fällt es lange nicht auf.

Das ist kein KI-Problem. Das wäre auch ohne KI passiert, wenn zwei Entwickler parallel an dem System arbeiten. Aber: KI-Workflows machen es wahrscheinlicher, weil mehr parallele Tasks in mehr Worktrees in kürzerer Zeit Migrationen produzieren als ein einzelner menschlicher Entwickler je geschafft hätte.

Und das Modell kann es im Moment der Migration nicht prüfen — weil es die anderen Worktrees nicht sieht. Die Single Source of Truth fehlt einfach.

Was strukturell schützt — und was nur beruhigt

Aus diesen drei Punkten lassen sich klare Schichten ableiten:

• Schicht 1: Sandbox-Bestätigung für schreibende Operationen. Hilft gegen die spontanen, unausgesprochenen “ich mach das mal eben mit”. Greift, ist aber noch nicht überall stabil. Kein Verlass im Einzelfall.
• Schicht 2: Konsistente Regeln an einer Stelle. Eliminiert die Fälle, in denen das Modell zwischen “trivial” und “kritisch” raten muss, weil beide Regeln gleichzeitig zutreffen. Pflichtarbeit, oft unterschätzt.
• Schicht 3: Single Source of Truth für State, der über Worktrees hinaus existiert. Migrationen, Schema-Versionen, laufende Jobs — alles, was nicht in einem einzelnen Worktree leben kann, gehört in eine geteilte Schicht, die jede Instanz vor der Aktion abfragt.

Schicht 1 ist nice-to-have. Schicht 2 musst du selbst pflegen. Schicht 3 ist Tooling, das du entweder kaufst, baust oder weglässt — und wenn du es weglässt, ist es nur eine Frage der Zeit.

Was wir bei BoostN dazu bauen

Genau für Schicht 3 entwickeln wir gerade ein Feature: eine geteilte Migrations-Tabelle als Bestandteil der BoostN Web-App. Statt dass jede neue Migration nur lokal in einem Worktree-Ordner landet, wird sie in eine kollektive Tabelle eingetragen — inklusive Nummer, Beschreibung, Worktree-Herkunft, Zeitstempel. Jede KI-Instanz, die eine neue Migration anlegen will, fragt zuerst dort an. Nummer 70 schon vergeben? Dann gibt es eine harte Antwort statt eines Schulterzuckens.

Damit wird das Worktree-Problem strukturell gelöst, nicht nur per Disziplin. Das Modell muss nicht mehr raten, ob seine Nummer kollidiert — es weiß es.

Im selben Atemzug überlegen wir, das Sicherheitsnetz darunter zu legen: zeitgesteuerte Datenbank-Dumps, die in denselben Bereich geschrieben werden. Wir hatten das bisher über GitHub Actions gelöst — funktioniert, läuft aber gegen das Storage-Limit. In der eigenen Datenbank ist das sauberer, vor allem für den Live-Betrieb, in dem wir ohnehin Backups vorhalten wollen — und das wäre dann auch direkt etwas, das wir Kunden mitanbieten können.

Fazit

Datenbank-Unfälle mit KI sind selten ein einzelner spektakulärer Fehler. Sie sind in der Regel eine Verkettung: eine zu großzügige Geschwindigkeitsregel, eine zu enge Trivialitäts-Einschätzung, ein Worktree, der vom anderen nichts weiß, eine Sandbox, die genau diese Aktion nicht abgefangen hat.

Die unbequeme Wahrheit: Du kannst diese Klasse von Unfällen nicht durch besseres Prompting wegbekommen. Du brauchst Schichten — Sandbox-Bestätigung, konsistente Regeln, geteilten State. Wer eine davon weglässt, hat irgendwann eine Geschichte zu erzählen, die er lieber nicht erzählen würde. Und wer alle drei hat, schläft deutlich ruhiger — auch wenn das Modell um drei Uhr morgens noch eine Migration ausrollt, die sich “irgendwie trivial” angefühlt hat.

Weiterlesen

Eine Stufe weiter herausgezoomt — Begriffsapparat aus der KI-Sicherheitsforschung, der Replit-Vorfall vom Juli 2025 und unsere Anti-Kaskade-Regel im Detail: „Wenn die KI Ja sagt, ohne zu fragen — und plötzlich die Datenbank weg ist”.

Entdecke mehr

Blog

Tokens sparen mit Claude: 6 Prinzipien, mit denen Experten doppelt so schnell arbeiten

Wie ich meine CLAUDE.md von Stilrichtlinie auf Token-Budget umgestellt habe — 6 Prinzipien für weniger Kosten, weniger Wartezeit und ehrlicheres Reporting.

Glossar

Speech-to-Text (STT)

Speech-to-Text bezeichnet die automatische Umwandlung gesprochener Sprache in Text durch ein KI-Modell. Im KI-Workflow ersetzt STT die Tastatur als Eingabekanal — entscheidend ist die Modellgröße und das domänenspezifische Vokabular.

Lexikon

KI-Coding-Tools im Vergleich

Cursor, Windsurf, Claude Code, GitHub Copilot, Continue.dev, Aider im Vergleich. Mit Tabelle und Entscheidungshilfe für vier typische Workflows.

Themenuebersicht

Arbeiten mit KIWorkflowsKI-WerkzeugeCoding-CLI