Alle reden davon, wie viel Zeit AI spart. Stimmt. Aber über die Stunden, die man mit KI-Fehlern verliert, redet kaum jemand.
Ich nutze Claude Code seit Monaten täglich. Mein Workflow hat sich fundamental verändert, ich bin schneller, ich liefere konsistenteren Code. Das stimmt alles. Dieser Artikel ist der Gegenpart dazu – die Momente, in denen ich vor dem Terminal saß und dachte: "Was zur Hölle hat das gerade gemacht?"
Nicht um AI schlechtzureden. Sondern weil ein realistisches Bild hilfreicher ist als endloser Hype.
Das aggressive Refactoring
Ich hatte eine Vue-Komponente, die über drei Dateien verteilt war – historisch gewachsen, nicht schön, aber funktional. Meine Anfrage war eigentlich harmlos: "Räum das auf und konsolidiere die Typen."
Claude Code hat das gemacht. Und noch etwas mehr. Und noch etwas mehr.
Am Ende hatte ich eine elegante, saubere Komponente – und vier Features, die still und leise verschwunden waren. Darunter ein Edge Case beim Laden von leerem Inhalt, der zwar nirgendwo dokumentiert war, aber von zwei anderen Teilen der App still vorausgesetzt wurde. Kein Test, kein Kommentar, kein Hinweis. Die AI hat den Code gesehen, nicht das Verhalten dahinter.
Was passiert ist: Claude Code hatte keinen Kontext über das Gesamtverhalten der Anwendung. Es hat den Code analysiert, nicht die Semantik dahinter. Das Refactoring war technisch korrekt – aber es hat Implizites gebrochen, das nirgendwo explizit stand.
Was ich jetzt anders mache: Bei Refactorings gebe ich explizit mit, welches Verhalten erhalten bleiben muss. "Räum das auf, aber diese drei Fälle müssen danach noch funktionieren: ..." Das klingt offensichtlich. Aber ich habe es anfangs regelmäßig vergessen.
Die halluzinierte API
Das hier ist unangenehm zu erzählen, weil der Fehler auch bei mir lag.
Ich arbeitete an einer Integration mit einem externen Service und bat Claude Code, die Anbindung zu schreiben. Die Antwort war flüssig, selbstsicher, gut strukturiert. Methoden, die plausibel klangen, Parameter, die Sinn ergaben – alles da.
Nur: Zwei der Methoden existieren nicht. Die API hat sie nie gehabt. Claude kannte eine ältere Version der Dokumentation, oder hat sie sich schlicht zusammengereimt – ich weiß es nicht genau. Was ich weiß: Der Code hat kompiliert, hat keine Typfehler geworfen, und ist erst beim ersten echten API-Call gecrasht.
Ich hätte das früher merken können. Ich hätte die offiziellen Docs gegenchecken sollen, bevor ich den Code akzeptiert habe. Hab ich nicht. Ich war in Flow, der Code sah gut aus, und ich habe vertraut.
Das ist das Gefährliche an confident falschem Output. Wenn die AI zögert oder "Ich bin nicht sicher" schreibt, bin ich vorsichtig. Wenn sie klar und strukturiert antwortet, senke ich meine Skepsis. Das ist genau der falsche Reflex.
Was ich jetzt anders mache: Alles, was externe APIs oder Libraries betrifft, verifiziere ich gegen die originalen Docs. Nicht weil ich der AI grundsätzlich misstraue – sondern weil das Risiko bei API-Halluzinationen besonders hoch ist und der Check meistens zwei Minuten dauert.
Der fehlende Kontext in der CLAUDE.md
Dieser hier ist vollständig mein Fehler – aber er hat mit Claude Code zu tun, also gehört er hier rein.
Wer Kontext-Engineering: Warum dein Prompt das kleinste Problem ist gelesen hat, weiß: Die CLAUDE.md ist das Fundament. Aber nur wenn sie vollständig ist.
Ich habe eine neue Sektion auf meiner Website implementieren lassen. Der Builder-Agent hat gute Arbeit gemacht, die Sektion sah sauber aus. Nur: Die Section-Labels – kleine, monospace formatierte Labels über den Überschriften – waren in normalem Text statt im CLI-Stil geschrieben.
Das war in meiner CLAUDE.md nicht dokumentiert. Irgendwann hatte ich die Regel eingeführt – alle Section-Labels müssen im Terminal-Stil sein, mit $-Prefix oder //-Kommentarsyntax – aber ich hatte vergessen, das in die Spezifikation zu schreiben.
Die AI hat sich an dem orientiert, was sie gesehen hat: ältere Sektionen, die ich selbst noch ohne den Stil gebaut hatte. Sie hat daraus ein Muster abgeleitet. Das Muster war falsch, weil ich mein eigenes System im Laufe der Zeit geändert hatte, ohne die Dokumentation nachzuziehen.
Das Ergebnis: Ich musste alle Labels manuell korrigieren und danach endlich die Regel in die CLAUDE.md schreiben.
Was ich jetzt anders mache: Wenn mir bei einem Output etwas nicht gefällt und ich denke "das hätte die AI eigentlich wissen können" – erste Frage: Steht das in der CLAUDE.md? Meistens lautet die Antwort: nein, noch nicht.
Der logische Fehler im syntaktisch korrekten Code
Das hier ist der subtilste Fehler – und der, den ich am längsten nicht gefunden habe.
Ich hatte eine Filterfunktion, die Posts nach Kategorie und Tag filtern sollte – kombiniert, mit einem AND-Operator. Claude Code hat die Funktion geschrieben, sie hat kompiliert, sie hat den offensichtlichen Testfall bestanden.
Was ich erst Tage später gemerkt habe: Die Funktion hat OR statt AND implementiert. Nicht weil die AI den Unterschied nicht kennt – sondern weil meine Anfrage die Logik nicht eindeutig definiert hatte. Ich hatte geschrieben "filtere nach Kategorie und Tag". Das kann AND bedeuten. Es kann aber auch OR bedeuten, wenn man es so liest: "gib mir Posts, die zur Kategorie passen, und gib mir Posts, die zum Tag passen".
Die AI hat sich für eine Interpretation entschieden. Sie hat mich nicht gefragt. Und ich habe den Output nicht auf logische Korrektheit geprüft – nur auf syntaktische.
Was ich jetzt anders mache: Bei Logik mit booleschen Verknüpfungen schreibe ich die erwarteten Ergebnisse explizit in die Anfrage. "Gefiltert wird mit AND: nur Posts, die beides erfüllen, sollen erscheinen." Zwei Sätze mehr. Vermeidet Stunden Debugging.
Was diese Fehler gemeinsam haben
Wenn ich auf meine schlechtesten Claude Code Sessions zurückschaue, sehe ich ein Muster:
Die AI hat nicht versagt, weil sie schlecht ist. Sie hat versagt, weil der Kontext gefehlt hat – entweder in meiner Anfrage, in meiner Dokumentation, oder in meinem Review-Prozess.
Implizites Wissen über mein Projekt existiert für die AI nicht. Was ich "offensichtlich finde", weil ich seit Monaten täglich mit dieser Codebase arbeite, ist für Claude Code nur dann sichtbar, wenn es dokumentiert ist oder direkt aus dem Code ableitbar ist.
Confident output ist kein Qualitätssignal. Das ist vielleicht die wichtigste Erkenntnis. Die AI klingt immer ungefähr gleich sicher. Ob sie eine triviale Formatierung macht oder eine API erfindet – der Ton bleibt ähnlich. Mein Misstrauen darf nicht von der Tonlage abhängen.
Meine Anfragen waren unpräzise. Mindestens die Hälfte der beschriebenen Fehler hätte ich mit einer präziseren Anfrage verhindert. "Räum das auf" ist keine Spezifikation. "Implementiere den Filter" ist keine Spezifikation. Das ist ein Wunsch. Eine Spezifikation definiert, was am Ende wahr sein muss.
Was ich daraus gelernt habe
Ich reviewe Code von Claude Code heute anders als früher. Nicht flüchtiger – gründlicher, aber in anderen Dimensionen.
Syntax? Meistens korrekt. Typen? Meistens korrekt. Logik bei nicht-trivialen Fällen? Da lese ich langsamer. Externe Abhängigkeiten? Gegenchecken. Implizite Verhaltenserwartungen? Explizit formulieren, bevor die AI anfängt.
Der Entwickler bleibt verantwortlich. Das ist keine Kritik an AI-Tools – das ist die Grundlage für vernünftigen Einsatz. Die Geschwindigkeit, die Claude Code mir gibt, ist real. Die Fehler, die dabei passieren können, sind es auch. Wer das weiß und damit arbeitet, spart Zeit. Wer es ignoriert und blind akzeptiert, verliert irgendwann eine Nacht mit einem Bug, den ein Zwei-Minuten-Review verhindert hätte.
AI ist kein Autopilot. Es ist ein sehr fähiger Copilot, der alles glaubt, was du ihm sagst – einschließlich der Dinge, die du vergessen hast zu sagen.