KI-Coding-Fehler:4 Wege, wie Claude deinen Code sabotiert

KI-Coding-Fehler sabotieren deine Codebasis nicht mit Code, der kaputtgeht. Sie sabotieren sie mit Code, der funktioniert — etwa sechs Monate lang. Claude liegt ständig selbstsicher falsch, und die gefährliche Variante ist nicht die, bei der es offensichtlich falsch liegt. Es ist die, bei der es plausibel falsch liegt: Code, der kompiliert, läuft und in Ordnung scheint, gebaut auf einer falschen Annahme über deine Daten oder deine Geschäftslogik.

In elf Monaten Aufbau von FIKR Space kamen immer wieder dieselben vier schlechten Muster aus der KI. Jedes hätte sechs Monate später eine andere, ganz bestimmte Art von Schmerz verursacht, hätte ich es akzeptiert. Hier sind sie in einfachem Deutsch — was Claude vorschlägt, warum es vernünftig aussieht und was es dich später genau kostet.

Warum KI standardmäßig mittelmäßigen Code liefert

Claude wurde mit Millionen Codebasen trainiert, und die meisten davon waren mittelmäßig. Wenn du nicht angibst, was du willst, bekommst du den Median-Output — voller Abkürzungen und Kompromisse, die erfahrene Ingenieure nie akzeptieren würden. Keine dieser Abkürzungen scheitert heute. Alle scheitern später, und genau deshalb überstehen sie die Prüfung durch einen Gründer, der nur schaut, ob das Feature gerade jetzt funktioniert.

Deine Aufgabe ist nicht, den Code zu schreiben. Deine Aufgabe ist, die erfahrene Stimme in der Partnerschaft zu sein — dagegenzuhalten, wenn etwas nicht gut riecht, auch wenn du nicht sofort sagen kannst, warum.

Fehler 1: Der JSON-Blob — eine Krimskramsschublade statt eines Aktenschranks

Claude schlägt gern vor, strukturierte Daten als JSON-Blob zu speichern — ein flexibles Feld, das alles enthält — statt in einer richtigen Tabelle mit richtigen Spalten. Stell dir vor, du wirfst deine Dokumente in eine Krimskramsschublade statt in einen Aktenschrank. Die Schublade funktioniert prima, solange zehn Dokumente drin sind.

Bei mir kam das in Woche drei auf. Claude schlug vor, die strategischen Zieldaten der Nutzer — Quartalsziele, OKR-Status, Alignment-Kennzahlen — als JSON-Spalte in der Nutzertabelle zu speichern. Es hätte funktioniert. Etwa drei Monate lang. Dann musste ich eine grundlegende Geschäftsfrage beantworten: Zeige mir alle Nutzer, deren Q3-Zielerreichung unter sechzig Prozent liegt. Gegen einen JSON-Blob bedeutet das, die Krimskramsschublade jedes einzelnen Nutzers zu öffnen und alles darin zu lesen, bevor man filtern kann — ein Ansatz, der bei fünfzig Nutzern skalierte und bei fünfhundert gestorben wäre. Das später zu beheben hätte bedeutet, sechs Monate Kundendaten zu migrieren und zwölf Services umzuschreiben. Das Dagegenhalten in Woche drei kostete eine zusätzliche Stunde Design-Gespräch. Der Neubau in Monat sechs hätte drei Wochen gekostet.

Fehler 2: Enums — die heutigen Optionen in Stein meißeln

Ein Enum ist ein Feld, dessen erlaubte Werte im Voraus festgelegt sind — als würdest du die Speisekarte deines Restaurants drucken, statt sie auf eine Tafel zu schreiben. Claude hat einen starken Hang zu Enums für jedes Feld mit einer kleinen, bekannten Wertemenge: Abo-Stufe, Nutzerrolle, Benachrichtigungstyp. Jedes fühlt sich im Moment offensichtlich fix an.

Jedes meiner Felder brauchte innerhalb eines Jahres neue Werte — eine neue Abo-Stufe, eine neue Rolle, eine neue Benachrichtigungskategorie. Und ein Enum in der Datenbank zu ändern erfordert ein mehrstufiges Ritual: Constraints löschen, den Typ neu anlegen, jede Zeile aktualisieren. Eine Lookup-Tabelle — die Tafel-Version — ist eine normale Tabelle, die wächst, indem man eine Zeile hinzufügt. Das Enum sperrt die Spalte in der Realität von heute ein; die Lookup-Tabelle bietet Platz für die von morgen. Dasselbe Muster, ein anderer Standard. Halte dagegen. Fordere die Lookup-Tabelle.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Fehler 3: any-Typen — den Rauchmelder abschalten

Die gesamte Aufgabe von TypeScript besteht darin, eine ganze Klasse von Bugs abzufangen, bevor deine Nutzer sie je sehen, indem es prüft, dass jedes Datenstück die Form hat, die der Code erwartet. Wenn diese Prüfung bei etwas Komplexem scheitert, schlägt Claude manchmal vor, die Daten als any zu markieren — das heißt: „hör auf, das zu prüfen.“ Der Fehler verschwindet. Der Build klappt. Das Feature geht live. Du hast gerade einen Rauchmelder abgeschaltet, und es passiert nichts, bis es raucht.

Das ist das tückischste Muster, weil das Symptom unsichtbar ist. Sechs Monate später änderst du woanders im Produkt etwas, und der Typfehler, der den Bruch hätte abfangen sollen, tut es nicht — weil irgendwo davor ein any das Signal still verschluckt. Der Bug geht in Produktion. Du erfährst es durch eine Kundenmeldung. Jedes any, das du jetzt akzeptierst, ist ein künftiger Dienstagnachmittag, den du mit der Fehlersuche für ein Problem verbringst, das das Typsystem verhindern sollte.

Fehler 4: Stilles Verschlucken von Fehlern — Ausfälle, die niemand hört

Der schlimmste der vier. Claude schreibt manchmal das Äquivalent von try { ... } catch (e) { return null } — „wenn irgendetwas schiefgeht, sag nichts und gib ein leeres Ergebnis zurück“ — und nennt es elegante Fehlerbehandlung. Dieser Code besteht jeden Test, den du schreibst, weil deine Tests den Fehlerfall nicht gezielt auslösen.

Im Produktivbetrieb, wenn der echte Fehler eintritt, gibt die Funktion nichts zurück. Still. Der Rest des Systems weiß nicht, dass etwas schiefgelaufen ist. Der Nutzer sieht einen leeren Bildschirm. Der Fehler wird nirgends protokolliert. Du erfährst es erst, wenn sich ein Kunde beschwert — und selbst dann kannst du nicht nachvollziehen, was passiert ist, weil nie ein Fehler ausgelöst wurde. Bekämpfe das jedes einzelne Mal: spezifische Fehler, spezifisch behandelt, laut protokolliert. Die fünf zusätzlichen Zeilen Code ersparen dir den nächsten Ausfall.

Das Muster hinter allen vier KI-Coding-Fehlern

Die gute Nachricht: Claude reagiert gut darauf, hinterfragt zu werden. Wenn du sagst „Nein, ich will das als eigene Tabelle, nicht als JSON-Blob — und hier ist der Grund“, strukturiert es den Code elegant um und verbessert oft, was es ursprünglich vorgeschlagen hatte. Das Modell ist kooperativ. Du musst nur die erfahrene Stimme sein.

Zwei Gewohnheiten machen das Dagegenhalten systematisch statt glücksabhängig. Briefe die KI richtig, bevor sie irgendetwas baut — das ist die PRP-Methode. Und lass nie Tempo die Struktur ersetzen — das ist die ganze Lektion der Vibe-Coding-Falle. Spezifizieren. Dagegenhalten. Die richtige Struktur einfordern. Das kostet pro Feature etwas mehr Zeit und verschafft dir eine Codebasis, die du in Monat zwölf noch weiterentwickeln kannst, statt einer, die du neu bauen musst.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Warum verursacht KI-generierter Code erst Monate später Probleme?

Weil die KI darauf optimiert, die heutige Anfrage zum Laufen zu bringen, nicht darauf, wie sich der Code entwickelt. Trainiert auf Millionen überwiegend mittelmäßiger Codebasen, greift sie standardmäßig zu Abkürzungen — flexible Blobs, feste Wertelisten, abgeschaltete Prüfungen, verschluckte Fehler —, die jetzt jeden Test bestehen und ihre Kosten erst zeigen, wenn das Produkt wächst oder sich ändert.

Wie erkenne ich schlechten KI-Code, wenn ich Code nicht lesen kann?

Befrage Veränderung und Fehlschlag, nicht Syntax. Frag die KI: Was passiert, wenn wir hier einen neuen Wert ergänzen müssen? Wie würden wir diese Daten durchsuchen, wenn es zehnmal so viele gibt? Was passiert, wenn diese Operation fehlschlägt — wohin geht der Fehler? Wenn die Antworten Migrationen, Neuschreiben oder „es gibt nichts zurück“ enthalten, halte dagegen.

Soll ich Claude meine Architekturentscheidungen treffen lassen?

Nein. Claude ist ein brillanter Umsetzer und ein mittelmäßiger Architekt. Frag, ob etwas eine eigene Tabelle oder eine JSON-Spalte sein sollte, und die Antwort ist meist in Ordnung, manchmal schlecht, gelegentlich großartig — und du kannst nicht sagen, welche, solange du keinen eigenen architektonischen Geschmack entwickelt hast. Die Architekturentscheidungen sind deine; die Umsetzungsentscheidungen sind Claudes.

Verlangsamt Dagegenhalten bei der KI nicht den Bau?

Ein wenig, pro Feature — und es ist der beste Tausch, den du je machen wirst. Das Dagegenhalten beim JSON-Blob kostete mich in Woche drei eine zusätzliche Stunde Design-Gespräch. Ihn zu akzeptieren hätte in Monat sechs drei Wochen Neubau gekostet, plus die Migration von sechs Monaten Kundendaten.