8 Fehler im Umgang mit AI Coding Agents (ich habe sie alle gemacht)

Die meisten Bugs, die ein AI Coding Agent in meine Projekte gebracht hat, waren mein Fehler.

Nicht der des Modells. Meiner. Nach zwei Jahren täglicher Arbeit mit Claude Code an Kundenprojekten bin ich meine schlimmsten AI-Momente noch einmal durchgegangen: kaputte Builds, mysteriöse Regressionen, Dateien, die plötzlich 400 Zeilen länger waren. Fast alles ließ sich auf etwas zurückführen, das ich getan oder ausgelassen hatte. Der Agent hat meine Schlamperei nur mit übermenschlicher Geschwindigkeit ausgeführt.

Das hier ist also kein weiterer Beitrag darüber, wie AI-Coding-Tools versagen. Es geht darum, wie wir sie falsch fahren. Acht Fehler, und ich habe jeden einzelnen davon gemacht.

"Die AI hat einen Bug geschrieben" ist die falsche Diagnose

Stack Overflows Entwicklerumfrage 2025 nennt die größte Frustration mit AI-Tools: Lösungen, die fast richtig sind, aber eben nur fast. Das Vertrauen in die Genauigkeit sinkt Jahr für Jahr, während die Nutzung weiter steigt. Die naheliegende Schlussfolgerung: Die Tools sind das Problem.

Was diese Statistik nicht sagt: Fast-richtiger Code wird erst dann zum ausgelieferten Bug, wenn ein Mensch ihn durchwinkt. Das Modell hat einen fehlerhaften Entwurf produziert. Ich habe ihn gemerged. Das sind zwei verschiedene Fehler, und nur einer davon liegt bei mir.

Warum trifft dein AI Coding Agent ständig schlechte Entscheidungen? Berechtigte Frage. Meiner hat genau so lange schlechte Entscheidungen getroffen, wie ich ihm schlechten Input gegeben habe: kein Plan, keine Grenzen, keine Tests, kein Kontext zum Projekt. Sobald ich meine Seite der Gleichung in Ordnung gebracht hatte, hörten die schlechten Entscheidungen größtenteils auf. Nicht alle. Größtenteils.

Gehen wir die Liste durch.

Fehler 1: Prompten, als würdest du einem Kollegen texten

"Fix den Login-Bug" ist kein Prompt. Das ist ein Wunsch.

Früher habe ich Einzeiler getippt, zugesehen, wie der Agent in die falsche Datei abgewandert ist, und daraus geschlossen, dass das Modell dumm ist. Dann fiel mir etwas Peinliches auf: Wenn mir ein Kollege eine vage Frage stellt, frage ich nach. Der Agent tut das meistens nicht. Er wählt eine Interpretation und zieht sie mit voller Überzeugung durch.

Der Fix kostet 60 Sekunden: Was ist kaputt, wo liegt es vermutlich, wie sieht "fertig" aus, was darf er nicht anfassen. Seit ich Prompts wie kleine Tickets schreibe statt wie Chat-Nachrichten, liegt die Abwander-Quote fast bei null.

Fehler 2: Code schreiben lassen, bevor ihr euch auf einen Plan geeinigt habt

Das nützlichste Feature in Claude Code ist der Plan-Modus, und ich habe ihn monatelang ignoriert.

Am Anfang habe ich den Agent bei einem Refactoring direkt Code schreiben lassen. Er hat "hilfsbereit" Dinge umgebaut, nach denen ich nie gefragt hatte, und ich habe mehr Zeit damit verbracht, den Diff zu entwirren, als das Refactoring von Hand gedauert hätte. Das Muster wiederholte sich, bis ich eine Gewohnheit geändert habe: erst planen, dann coden. Nach dem Vorgehen fragen, lesen, korrigieren, dann freigeben.

Ein falscher Plan kostet dich einen Absatz Lesezeit. Falscher Code kostet dich ein Review, einen Revert und ein Stück Vertrauen in deine eigene Codebase.

Fehler 3: Keine Tests, bevor du ihn loslässt

Ein Agent ohne Tests ist ein sehr schneller Praktikant ohne Aufsicht.

Ich habe einen Agent mal in einem Projekt ohne Testabdeckung an ein Feature gelassen. Alles sah gut aus. Tage später habe ich gemerkt, dass er still das Verhalten einer Helper-Funktion geändert hatte, die woanders verwendet wurde. Nichts ist abgestürzt. Das Ergebnis war einfach falsch, lautlos. Genau diese Kategorie von Bug meinte ich, als ich schrieb, dass Claude großartig darin ist, Software zu bauen, und genauso großartig darin, sie kaputt zu machen.

Heute ist die Regel simpel: Wenn der Code wichtig ist, existieren die Tests, bevor der Agent anfängt. Nicht danach. Der Agent führt sie selbst aus und korrigiert sich, was Tests von einer Pflichtübung in Leitplanken, die der Agent aktiv nutzt, verwandelt.

Fehler 4: Den Kontext nie zurücksetzen

Lange Sessions machen Agents schlechter, und ich habe zu lange gebraucht, um das zu akzeptieren.

Früher lief bei mir eine einzige Unterhaltung den ganzen Tag: Feature, Bugfix, Frage, nächstes Feature, alles im selben Kontextfenster. Am Nachmittag hat der Agent alte Anforderungen mit neuen verwechselt und Entscheidungen aus Aufgabe drei in Aufgabe neun geschleppt. Ich habe das Modell verantwortlich gemacht. Das Modell hat mit dem Müllhaufen gearbeitet, den ich ihm gegeben habe.

Kontexthygiene ist inzwischen eine Gewohnheit: neue Aufgabe, neue Session. Zusammenfassen, was zählt, den Rest fallen lassen. Es fühlt sich verschwenderisch an. Ist es nicht.

Fehler 5: Den Agent auf einem unsauberen Git-Status starten

Das Gruseligste, was ein Agent tun kann: zwanzig Dateien ändern, während du nicht mehr weißt, welche Änderungen von dir waren.

Ich habe mehr als einmal Agent-Runs auf meinen eigenen uncommitteten Änderungen gestartet. Als der Run schiefging, konnte ich nicht einfach reverten, weil der Revert auch meine Arbeit gelöscht hätte. Zeile für Zeile zu entwirren, was von mir und was von ihm war, ist die Art Stunde, die dich altern lässt.

Der Fix ist langweilig: vor jedem Agent-Run committen. Sauberer Zustand rein, ein revertbarer Commit raus. Langweilig ist der Punkt.

Fehler 6: Eine Riesenaufgabe statt fünf kleiner

"Bau das ganze Dashboard" produziert einen Diff mit 1.500 Zeilen. Niemand reviewt 1.500 Zeilen. Man scrollt sie.

Big-Bang-Prompts waren mein Standard, weil sie effizient wirkten. Aber die Diff-Größe wächst über das hinaus, was ich ehrlich zu lesen bereit bin, und ungereviewter Code wandert direkt auf den Haufen von AI-generiertem Code, den niemand versteht, wo er Zinsen sammelt, bis die Rechnung kommt.

Kleine Aufgaben, kleine Diffs, jeden einzeln reviewen. Langsamer pro Schritt. Schneller pro Projekt.

Fehler 7: Ihm dort vertrauen, wo du nichts überprüfen kannst

Die Zuversicht des Agents ist konstant. Seine Korrektheit nicht. Die Gefahrenzone liegt da, wo beides auseinanderläuft und du es nicht erkennen kannst.

Bei mir waren das Sicherheitsentscheidungen und die Wahl von Dependencies. Ein Agent installiert dir bereitwillig ein Paket, verdrahtet einen Auth-Flow und beschreibt alles mit voller Überzeugung. Wenn du das Ergebnis selbst nicht bewerten kannst, delegierst du nicht mehr. Du spielst Lotto. Genau das ist die Falle hinter der ganzen Vibe-Coding-Welle, und ich habe darüber geschrieben, was passiert, wenn niemand prüft, ob die eigene Scheune abgeschlossen ist.

Meine Regel heute: Alles, was Auth, Zahlungen oder Dependencies berührt, wird gegen eine Quelle geprüft, die nicht das Modell ist.

Fehler 8: Code reviewen wie eine Slack-Nachricht

Von den acht hat mich dieser am meisten gekostet, und er lockt mich immer noch täglich.

Der Code des Agents sieht professionell aus. Saubere Namen, ordentliche Kommentare, plausible Struktur. Genau diese Oberflächenpolitur schaltet den Skim-Modus ein: Die Augen gleiten, das Hirn nickt, die Hand genehmigt. Ich habe Diffs akzeptiert, die ich so "reviewt" habe, wie ich eine Slack-Nachricht lese, und ich habe dafür mit Bugs bezahlt, die ein ehrlicher Zwei-Minuten-Blick gefunden hätte. Die Politur ist das Gefährliche daran: Schlechter Code, der schlecht aussieht, bekommt Aufmerksamkeit. Schlechter Code, der gut aussieht, wird gemerged.

Ein Grund, warum ich diese Gewohnheit im Griff behalte: Ich weiß, dass meine eigenen Skills verkümmern, während ich die AI tippen lasse. Das Review ist der letzte Ort, an dem mein Urteilsvermögen noch das Sagen hat. Wenn ich dort skimme, habe ich komplett abgedankt.

Die Pre-Flight-Checkliste, bevor ein Agent Produktion anfasst

Sind Bugs und Vorfälle mit AI Coding Agents also unvermeidbar? Ein Teil davon, ja, genau wie bei menschlichem Code. Aber die Rate ist kein Schicksal. Sie ist Disziplin des Fahrers. Hier ist die Checkliste, die ich tatsächlich durchgehe, bevor ein Agent irgendetwas Wichtiges anfasst:

• Sauberer Git-Status. Committen oder stashen. Jeder Agent-Run muss nur einen Revert vom Verschwinden entfernt sein.
• Schriftlicher Plan freigegeben. Kein Code, bevor ich das Vorgehen gelesen und korrigiert habe.
• Tests existieren und laufen durch. Der Agent führt sie während der Arbeit aus, nicht danach.
• Scope explizit benannt. Welche Dateien, welches Verhalten, und was er nicht anfassen darf.
• Frischer Kontext. Neue Aufgabe, neue Session.
• Klein genug für ein ehrliches Review. Wenn ich den Diff nicht komplett lesen würde, ist die Aufgabe zu groß.
• Ein Verifikationsplan für alles, was ich nicht beurteilen kann. Security und Dependencies bekommen eine zweite Quelle.

Sieben Zeilen. Dauert zwei Minuten und hat mehr Vorfälle verhindert als jedes Modell-Upgrade.

Das Modell wurde besser. Meine Fehler haben das Upgrade überlebt.

Jedes Modell-Release ist besser als das davor, und jeder dieser acht Fehler mit AI Coding Agents übersteht das Upgrade, weil es nie um das Modell ging. Es geht um den Fahrer. Das war ich. An manchen Tagen bin ich es immer noch: Diese Woche habe ich mich dabei erwischt, wie ich einen Diff einfach durchgewunken habe, Checkliste hin oder her.

Null Vorfälle mit AI Coding Agents kann ich dir nicht versprechen. Das kann ehrlicherweise niemand. Was ich anbieten kann: acht Wege weniger, dir selbst ins Knie zu schießen, gelernt auf meine eigenen Kosten. Und wenn du ein zweites Paar Augen darauf willst, wie AI in deinen Entwicklungs-Workflow passt, ohne den Glücksspiel-Anteil, lass uns reden.