Was bei mir mit Coding-Agents schiefging – 5 teure Lektionen

Kein Hochglanz, sondern die Wege, die nicht funktioniert haben: fünf Fehler, die mich beim Entwickeln mit KI-Agenten Zeit, Nerven und einmal fast die Codebasis gekostet haben.

Über die Erfolge mit KI-Agenten schreiben alle. Über die Sackgassen kaum jemand – dabei lernt man dort am meisten. Ich baue im Industrieumfeld Agenten für Prozessautomatisierung und entwickle täglich mit Coding-Agents wie Claude Code und Copilot. Hier sind fünf Dinge, die bei mir gründlich schiefgingen, und was ich daraus gelernt habe.

1. Ich habe dem Agenten zu wenig Kontext gegeben – und zu viel Schuld

Mein erster Reflex war, Aufgaben so knapp zu formulieren wie für einen erfahrenen Kollegen, der das Projekt kennt. Der Agent kennt es aber nicht. Er füllte die Lücken mit plausiblen Annahmen – und baute sauberen Code für das falsche Problem.

Lektion: Die Qualität des Ergebnisses hängt fast vollständig an der Qualität der Aufgabenbeschreibung. Heute investiere ich mehr Zeit ins Beschreiben als früher ins Implementieren. Genau diese Verschiebung – weg vom Coden, hin zum präzisen Anweisen – ist der Kern der neuen Entwicklerrolle.

2. Ich habe generierten Code übernommen, ohne ihn zu verstehen

Ein Agent lieferte in Minuten ein Modul, das funktionierte. Ich übernahm es, ohne es wirklich zu lesen. Zwei Wochen später musste ich einen Fehler darin beheben – und verstand meinen eigenen Code nicht. Die Korrektur dauerte länger, als das Modul selbst zu schreiben gedauert hätte.

Lektion: „Funktioniert" ist nicht dasselbe wie „verstanden". Code, den niemand im Team durchdrungen hat, ist technische Schuld – egal, wer ihn geschrieben hat. Ich lese heute jeden generierten Abschnitt, als käme er aus einem Pull Request eines neuen Kollegen.

3. Ich ließ den Agenten zu große Schritte auf einmal machen

„Bau mir das ganze Feature" klingt verlockend. Das Ergebnis war ein 600-Zeilen-Wust, in dem ein subtiler Logikfehler steckte. Den Fehler in einer so großen Änderung zu finden, kostete mich einen halben Tag.

Lektion: Kleine, überprüfbare Schritte schlagen den großen Wurf. Ich lasse Agenten heute in Inkrementen arbeiten, die ich in wenigen Minuten reviewen kann. Das ist langsamer pro Prompt – aber drastisch schneller bis zum funktionierenden Ergebnis.

4. Ich vertraute der Architektur des Agenten

Agenten sind exzellent darin, innerhalb einer Struktur zu arbeiten. Sie sind schlecht darin, die richtige Struktur für ein wachsendes System zu wählen. Bei einem Projekt ließ ich den Agenten die Architektur bestimmen – nach drei Wochen war die Codebasis schneller in technische Schuld gerutscht, als das manuell je möglich gewesen wäre.

Lektion: Architektur ist Chefsache und bleibt menschlich. Wenn die Gesamtstruktur stimmt, sind Agenten ein Beschleuniger. Wenn nicht, beschleunigen sie den Weg ins Chaos.

5. Ich verließ mich auf „sieht plausibel aus"

Einmal generierte ein Agent eine Datenbankmigration, die korrekt aussah – und in einem Randfall stillschweigend Daten überschrieben hätte. Im Code-Review fiel es fast durch, weil alles plausibel wirkte. Plausibilität ist die gefährlichste Eigenschaft von KI-Code: Er sieht immer richtig aus.

Lektion: Gerade bei allem, was schwer rückgängig zu machen ist – Migrationen, Löschvorgänge, externe Aufrufe – prüfe ich besonders gründlich und teste explizit die Randfälle. Der Agent kennt die Tragweite nicht; ich muss sie kennen.

Das Muster hinter den fünf Fehlern

Alle fünf Lektionen laufen auf dasselbe hinaus: Coding-Agents ersetzen nicht das Denken, sie verschieben es. Weniger Zeit fürs Tippen, mehr Zeit für Kontext, Architektur, Review und Urteil. Die Entwicklerrolle wird dadurch nicht überflüssig – sie wird strategischer. Vom Programmierer zum Architekten.


Welcher dieser Fehler kommt Ihnen bekannt vor – oder welchen würden Sie ergänzen? Genau solche Erfahrungen sammeln wir hier. Mehr zum Einstieg in die agentische Entwicklung in der Stufe Softwareentwicklung mit Agenten.