KI-Fehler in der Produktion:So stoppst du jeden einzelnen
Die 10 KI-Fehler in der Produktion: was Claude falsch gemacht hat, das richtige Muster und die genaue Anweisung, die jeden dieser Fehler künftig verhindert.
Die KI-Fehler in der Produktion sind vorhersehbar und dokumentiert: Die KI schreibt Code, der in der Demo funktioniert und live scheitert. Beim Bau meiner eigenen Plattform mit Claude habe ich jeden Fehler protokolliert, der korrigiert werden musste: 28 wiederkehrende Lektionen, jede mit der genauen Anweisung, die sie verhindert. Hier sind die zehn, die am meisten kosten, wenn sie durchrutschen.
Der Sinn dieser Liste ist nicht, dich von KI-Entwicklung abzuschrecken. Im Gegenteil: Weil die Fehler vorhersehbar sind, sind sie vermeidbar – mit einem Satz in deinem Prompt oder einer festen Regel in deinen Projektanweisungen. Du musst den richtigen Code nicht schreiben. Du musst das falsche Muster erkennen und wissen, was du sagen musst.
Warum die KI jedes Mal dieselben Fehler macht
KI optimiert für den Happy Path – die Version deines Features, in der die Daten existieren, der Nutzer eingeloggt ist, nichts fehlschlägt und nur ein einziger Kunde die App je benutzt. Diese Version überzeugt in der Demo. Produktion ist alles andere: Sitzungen laufen ab, zwei Nutzer klicken gleichzeitig, Daten fehlen, und Kunde A darf die Datensätze von Kunde B niemals sehen.
Die KI überspringt das nicht aus Nachlässigkeit. Sie überspringt es, weil du nicht danach gefragt hast – und anders als ein Senior-Entwickler ergänzt sie unausgesprochene Anforderungen nicht aus Erfahrung. Diese vier Sabotage-Verhaltensweisen sind eine verwandte, aber andere Liste, die ich separat behandelt habe; die heutigen zehn drehen sich darum, was produktionsreifer Code braucht und die KI standardmäßig weglässt.
Die 10 KI-Fehler in der Produktion, das richtige Muster und die Anweisung
| Was Claude getan hat | Das richtige Muster | Wie du es anweist |
|---|---|---|
| Einen doppelten Service für bereits vorhandene Funktionalität angelegt | Eine einzige Quelle der Wahrheit pro Domäne – erweitere den bestehenden Service | „Prüfe vor dem Anlegen einer neuen Datei, ob es bereits einen ähnlichen Service gibt, und erweitere ihn" |
| UI-Komponenten direkt mit der Datenbank sprechen lassen | Drei Schichten: Komponenten nutzen Hooks, Hooks nutzen Services, nur Services greifen auf die Datenbank zu | „Importiere den Datenbank-Client nie in Komponenten – folge der 3-Schichten-Architektur" |
| Starre ENUM-Typen für Status und Kategorien verwendet | Lookup-Tabellen, die du ohne Codeänderung erweitern kannst | „Keine Enums – lege eine Lookup-Tabelle mit Code, Anzeigename, Sortierreihenfolge und Aktiv-Flag an" |
| Fremdschlüssel ohne Indizes angelegt | Jeder Fremdschlüssel bekommt einen Index; häufige Abfragekombinationen bekommen zusammengesetzte Indizes | „Jede Fremdschlüssel-Spalte muss einen Index haben" |
| Tabellen ohne Organisationsspalte gebaut | Multi-Tenancy von Tag 1: Jede Geschäftstabelle ist auf den Kunden begrenzt, dem die Daten gehören | „Jede Geschäftstabelle bekommt organization_id, not null, als zweite Spalte" |
| Row-Level Security komplett übersprungen | RLS auf jeder Tabelle aktiviert, mit Policies für Lesen, Einfügen, Ändern und Löschen | „Aktiviere nach dem Anlegen jeder Tabelle RLS und füge alle vier organisationsbezogenen Policies hinzu" |
| In Komponenten nur den Happy Path behandelt | Überall vier Zustände: Laden, Fehler, Leer und Erfolg | „Jede Komponente, die Daten abruft, muss Laden, Fehler, Leer und Erfolg behandeln" |
| Fehler stillschweigend scheitern lassen | Abfangen, mit Kontext loggen und dem Nutzer ein Wiederholen anbieten | „Jede asynchrone Funktion bekommt Fehlerbehandlung: loggen, einen verständlichen Fehler werfen, ein Wiederholen anzeigen" |
| Daten auf Anfrage dauerhaft gelöscht | Soft Deletes – Datensätze als gelöscht markieren, Daten behalten, Rückgängigmachen erlauben | „Lösche Geschäftsdaten nie hart – setze deleted_at und deleted_by und filtere sie in Abfragen heraus" |
| Mehrstufige Schreibvorgänge ohne Transaktion ausgeführt | Zusammengehörige Schreibvorgänge gelingen oder scheitern gemeinsam, nie halb | „Diese Schreibvorgänge müssen atomar sein – alle gelingen oder alle werden zurückgerollt" |
Die vollständigen 28 Lektionen – darunter Typsicherheit, Logging, Barrierefreiheit, fest eincodierte IDs und Testabdeckung – findest du im Kurs AI Product Builder, jede mit Vorher-Nachher-Code und dem Prompt zum Kopieren.
Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →Die zwei Fehler, die dein Unternehmen beenden können
Acht der zehn kosten dich Zeit. Zwei können dich die Firma kosten.
Fehlende Multi-Tenancy und fehlende Row-Level Security sind Datenpannen-Maschinen. Ohne Organisationsspalte in jeder Tabelle liegen die Daten all deiner Kunden auf einem ungeteilten Haufen, und nur Glück im Anwendungscode verhindert, dass Kunde A die Datensätze von Kunde B sieht. Row-Level Security ist die Mauer auf Datenbankebene, die auch hält, wenn dein Code Bugs hat – und dein Code wird Bugs haben. Die KI überspringt beides, wenn man es ihr nicht sagt, denn in „Baue mir einen Projekt-Tracker" steht nichts davon, dass die Unternehmen anderer Leute ebenfalls in dieser Datenbank leben werden.
Nachrüsten ist brutal: Die Organisationsspalte später hinzuzufügen heißt, jede Tabelle zu migrieren, jede Zeile nachzufüllen, jede Abfrage zu aktualisieren und alles neu zu testen. Ein Satz im ursprünglichen Prompt – oder eine Woche Migrations-Chirurgie später. Wähle den Satz.
Verwandle Korrekturen in feste Regeln
Die KI Fehler für Fehler zu korrigieren heißt, gegen die Flut zu kämpfen. Der Zug, der sich aufsummiert, ist, jede Korrektur in deine Projektanweisungsdatei zu schreiben, damit jede künftige Sitzung mit den bereits geladenen Regeln startet – die Mechanik habe ich in der einen Datei, die 90 % der KI-Fehler verhindert erklärt. Ein Regelblock, so kurz wie dieser, verändert alles Nachgelagerte:
Folge der 3-Schichten-Architektur. Jede Tabelle bekommt organization_id, Audit-Spalten und RLS-Policies. Keine Enums – Lookup-Tabellen. Indexiere jeden Fremdschlüssel. Nur Soft Deletes. Jede Komponente behandelt Laden, Fehler, Leer und Erfolg. Jede asynchrone Funktion hat Fehlerbehandlung.
Zehn Zeilen. Einmal geschrieben. Bei jedem Prompt durchgesetzt, den du je ausführst. Das ist der Unterschied zwischen die KI korrigieren und sie lenken – was die eigentliche Aufgabe ist, wie ich in du bist der Architekt argumentiert habe.
12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →Häufig gestellte Fragen
Wenn die KI all diese Fehler macht – ist es sicher, damit zu bauen?
Ja – weil die Fehler konsistent sind, nicht zufällig. Ein Junior-Entwickler macht jede Woche andere Fehler; die KI macht dieselben zehn, bis du die Regel schreibst, die jeden einzelnen stoppt. Ein dokumentierter Fehlermodus mit bekannter Ein-Zeilen-Vorbeugung ist ein beherrschbares technisches Risiko, kein Grund, ein Team einzustellen.
Wie fange ich diese Fehler ab, wenn ich Code nicht flüssig lesen kann?
Prüfe mit Fragen, nicht durch zeilenweises Lesen. Frage die KI direkt, nachdem sie etwas erzeugt hat: Hat jede Tabelle eine Organisationsspalte und RLS-Policies? Sind Löschungen Soft Deletes? Behandelt diese Komponente Lade-, Fehler- und Leerzustände? Die KI ist ehrlich über ihre eigenen Auslassungen, wenn man gezielt fragt – die Tabelle oben ist praktisch deine Prüf-Checkliste.
Sollte ich diese Probleme in Code beheben, den die KI schon geschrieben hat?
Priorisiere nach Risiko. Behebe zuerst das Sicherheitspaar – Organisationsbezug und Row-Level Security –, bevor du echte Kunden aufnimmst, denn Nachrüsten wird mit wachsenden Daten nur schwerer. Fehlende Zustände, Logging und Soft Deletes lassen sich Feature für Feature beheben, wenn du jeden Screen anfasst.
Wohin kommen die festen Regeln eigentlich?
In eine Projektanweisungsdatei, die dein KI-Tool zu Beginn jeder Sitzung liest – bei Claude eine CLAUDE.md-Datei in deinem Projekt. Jede Korrektur, die du je machst, wird in diese Datei befördert, sodass du sie genau einmal machst. Die Einrichtung dauert Minuten und ist in der CLAUDE.md-Anleitung beschrieben.
Wie gefangen bist du wirklich?
Mach den Corporate Suffocation Index – die kostenlose Einschätzung, ob du bereit bist, Solopreneur zu werden.