KI-Coding-Agenten können heute erstaunlich viel. Sie finden Fehler, schlagen Patches vor, schreiben Tests, refaktorieren ganze Module und arbeiten sich schneller durch fremden Code, als ein Mensch es könnte. Das Problem beginnt dort, wo Geschwindigkeit mit Verständnis verwechselt wird.

Denn viele KI-Agenten beheben nicht die Ursache eines Fehlers, sondern dessen sichtbare Folgen. Sie dichten Lecks ab, statt die gebrochene Leitung zu reparieren. Das Ergebnis sieht zunächst gut aus: Der Test ist grün, der Endpoint antwortet wieder, das Ticket scheint erledigt. Doch unter der Oberfläche wächst der Code. Zusätzliche Bedingungen, neue Flags, doppelte Validierungen, defensive Sonderfälle, Hilfsmethoden für Randprobleme, die es ohne den ursprünglichen Designfehler gar nicht geben dürfte. Das System läuft wieder – aber es ist schwerer, fragiler und oft unverständlicher geworden.

Genau das ist die eigentliche Gefahr beim Arbeiten mit KI in produktivem Code: nicht der offensichtliche Fehlgriff, sondern der scheinbar funktionierende Workaround. Denn ein menschlicher Entwickler merkt irgendwann, dass eine Lösung „komisch aussieht“. Eine KI hat diesen Instinkt nicht zuverlässig. Sie optimiert auf das lokale Problem, nicht automatisch auf die strukturelle Gesundheit des Systems.

Der trügerische Erfolg des grünen Tests

In vielen Teams ist der Moment der Erleichterung klar definiert: Das Problem ist weg, die Pipeline ist grün, das Feature läuft. Damit endet oft auch die Aufmerksamkeit. Genau dort müsste sie eigentlich beginnen.

Wenn ein Fehler mehrere Iterationen gebraucht hat, wenn verschiedene Ansätze ausprobiert wurden, wenn zusätzliche Guards, Konfigurationen oder Sonderlogik eingeführt wurden, dann ist die Wahrscheinlichkeit hoch, dass sich Symptom-Fixes im Code angesammelt haben. Sie sind nicht unbedingt falsch. Aber sie sind oft nur historisch erklärbar, nicht architektonisch notwendig.

Das klassische Muster sieht so aus:

1. Ein Fehler tritt auf.
2. Die KI findet eine plausible Stelle.
3. Dort wird etwas abgefangen.
4. Der Fehler verschwindet.
5. Später zeigt sich ein ähnliches Problem an anderer Stelle.
6. Die KI ergänzt weitere Schutzlogik.
7. Dann kommen Logging, Retry, Fallback, Null-Prüfung, Konfigurationsschalter, Hilfsmethode Nummer drei.

Irgendwann ist aus einer schlichten Ursache ein Gebilde aus Sicherheitszäunen geworden.

Das ist kein Zeichen von Intelligenz, sondern von lokalem Optimieren ohne Gesamtrevision.

Warum die KI zu Symptom-Reparaturen neigt

Das Verhalten ist logisch. Ein Coding-Agent arbeitet meist entlang sichtbarer Evidenz: Stacktrace, Fehlermeldung, failing test, diff, Kontextfenster. Daraus erzeugt er die wahrscheinlichste Reparatur. Das genügt oft, um ein einzelnes Problem zu lösen. Es genügt aber nicht automatisch, um das System wieder zu vereinfachen.

Drei Ursachen sieht man dabei besonders häufig.

Erstens: zu enger Kontext. Die KI sieht die abstürzende Methode, aber nicht den gesamten Datenfluss, der überhaupt erst zu dem fehlerhaften Zustand geführt hat.

Zweitens: Optimierung auf lokale Korrektheit. Wenn ein Patch den Test wieder grün macht, wird er bevorzugt, auch wenn er strukturell unnötig komplex ist.

Drittens: fehlende Entrümpelung nach erfolgreichem Fix. Menschen neigen schon dazu, provisorische Lösungen im Code zu lassen. KI tut das erst recht, wenn niemand explizit den Auftrag gibt, nach dem erfolgreichen Fix noch einmal zurückzugehen und Ballast zu entfernen.

Deshalb reicht es nicht, einen KI-Agenten nur zu fragen: „Mach den Fehler weg.“ Die wichtigere zweite Anweisung lautet: „Prüfe jetzt, welche Teile deiner eigenen Reparatur eigentlich überflüssig geworden sind.“

Der entscheidende zweite Schritt: Root-Cause + Cleanup Pass

Nach jedem stabil erreichten Meilenstein sollte ein zweiter, eigener Arbeitsgang folgen. Nicht als neues Feature, nicht als Schönheitskorrektur, sondern als strukturelle Qualitätskontrolle.

Dieser zweite Durchlauf hat eine andere Aufgabe als das Debugging. Er soll nicht mehr primär reparieren, sondern prüfen:

• Wurde wirklich die Ursache behoben?
• Welche Workarounds sind nur deshalb entstanden, weil die Ursache vorher nicht sauber isoliert war?
• Welche Teile des neu hinzugekommenen Codes sind redundant?
• Wo wurde aus Vorsicht zusätzliche Komplexität eingebaut, die nun wieder entfernt werden kann?
• Welche Robustheit ist echt – und welche nur aufblasende Scheinsicherheit?

Dieser Pass ist im Grunde das, was gute Senior-Entwickler instinktiv tun: Sie schauen nicht nur, ob etwas jetzt funktioniert, sondern ob der Weg dorthin das System beschädigt hat.

Was ein guter Cleanup-Prompt leisten muss

Ein brauchbarer Prompt für diesen zweiten Durchgang darf nicht allgemein nach „Refactoring“ fragen. Das wäre zu weich und zu beliebig. Er muss die KI auf Ursachen, Kausalität und Vereinfachung festnageln.

Entscheidend sind dabei sieben Punkte.

1. Re-Grounding des Kontexts

Bevor die KI irgendetwas vereinfacht, muss sie den relevanten Pfad neu aufbauen: Entry-Point, Datenfluss, Invarianten, Fehlerklassen, Abhängigkeiten, Nebenwirkungen. Sonst entrümpelt sie blind.

2. Trennung von Ursache und Symptom

Der Agent muss explizit gezwungen werden, frühere Fixes als symptomatisch zu markieren und einer vermuteten Ursache zuzuordnen. Allein diese Denkrichtung verhindert schon einen Teil des Aktionismus.

3. Vereinfachung als Ziel, nicht als Nebeneffekt

Viele Refactorings machen Code formal „schöner“, aber nicht einfacher. Ein guter Prompt verlangt ausdrücklich: weniger Abstraktionen, weniger Flags, weniger doppelte Checks, weniger „just in case“-Code.

4. Stabilität statt Eleganz

Die Aufgabe ist nicht, aus dem Code ein Architektur-Schaustück zu machen. Die Aufgabe ist, die einfachste robuste Lösung zu finden. Dazu gehören Idempotenz, Fehlerbehandlung, Ressourcenverbrauch, Security-Grundlagen und nachvollziehbares Logging.

5. Verifikation gegen die Ursache

Tests sollen nicht nur bestätigen, dass das Symptom verschwunden ist, sondern dass die echte Ursache nun abgedeckt ist. Ideal ist die klassische Reihenfolge: reproduzierender Test, Refactor, wieder grün.

6. Begrenztes Ausgabeformat

Wenn der Prompt die KI nicht bremst, produziert sie schnell halbe Gutachten. Ein hart begrenztes Format zwingt zur Priorisierung und macht das Ergebnis im Alltag nutzbar.

7. Harte Constraints

Keine neuen Features. Keine neuen Frameworks. Keine „Nice-to-haves“. Keine Architekturreise. Nur minimale Änderungen mit maximaler Wirkung.

Der Prompt, der den Unterschied macht

Der folgende Prompt ist deshalb weniger ein Schreibauftrag als ein Arbeitsprotokoll für eine zweite technische Inspektion:

Act like a Senior Staff Software Engineer, Debugging-Spezialist und Code-Refactoring-Reviewer für Production-Systeme.

Ziel: Du führst nach einem erreichten Meilenstein (Feature/Domain abgeschlossen oder Methode stabil) einen “Root-Cause + Cleanup Pass” über den gesamten relevanten Codepfad vom Startpunkt bis zur stabil laufenden Stelle aus. Du entfernst Over-Engineering, Redundanzen und symptomatische Workarounds, ohne Verhalten zu ändern (außer klaren Bugs), und erhöhst langfristige Wartbarkeit und Runtime-Stabilität.

Input, den ich dir gebe:
(a) Problem-/Feature-Beschreibung,
(b) Repo/Dateien oder relevante Ausschnitte,
(c) Startpunkt/Entry (z.B. Endpoint, CLI, Job),
(d) aktuelle Tests/Logs,
(e) Definition of Done.

Arbeitsanweisung (strikt Schritt-für-Schritt):

1. Kontext re-grounden: Benenne Entry-Point, Datenfluss, Invarianten, Fehlerklassen, Abhängigkeiten. Liste die minimalen “Correctness Contracts” (z.B. Inputs/Outputs, Nebenwirkungen, Performance/Threading).
2. Root-Cause Audit: Identifiziere die eigentliche Ursache(n) von früheren Problemen (nicht Symptome). Markiere symptomatische Fixes/Workarounds und ordne sie einer vermuteten Ursache zu.
3. Simplify & De-duplicate: Schlage Refactorings vor, die Komplexität reduzieren (KISS, DRY, Single Responsibility). Entferne unnötige Abstraktionen, doppelte Validierungen, tote Flags, “just in case”-Code, übermäßige Konfigurierbarkeit, premature optimizations.
4. Stabilitäts-Checks: Prüfe Fehlerbehandlung, Idempotenz, Nebenläufigkeit, Ressourcen (DB/IO), Grenzen/Nulls, Logging/Telemetry, Security basics. Behalte die einfachste robuste Lösung.
5. Verifikation: Definiere/aktualisiere Tests, die die Root Cause abdecken (Unit/Integration). Wenn möglich: Reproduzierender Test zuerst, dann Refactor, dann green.
6. Ausgabeformat:
   • Kurzüberblick (max. 5 Sätze)
   • Dann maximal 5 Bullets: What changed / Where / Why (Root Cause) / Risks / Next steps
   • Danach konkrete Patch-Vorschläge mit klarer Dateipfad+Funktion+Änderung (diff-artig oder präzise Snippets).
7. Constraints: Keine neuen Features, kein “Nice-to-have”, keine neuen Frameworks ohne zwingenden Grund. Bevorzuge minimale Änderungen mit maximaler Wirkung. Wenn etwas unklar ist: wähle die einfachste gültige Interpretation und dokumentiere Annahmen.

Der entscheidende Punkt ist nicht die Formulierung „Senior Staff Engineer“. Das kann man auch weglassen. Entscheidend ist die Verfahrenslogik: erst rekonstruieren, dann Ursachen identifizieren, dann vereinfachen, dann gegen die Ursache testen.

Die KI aus ihrem natürlichen Reparaturmodus holen

Ein Agent ist meist gut darin, einen Defekt zu überdecken. Er ist deutlich schlechter darin, nach erfolgreichem Fix freiwillig zu sagen: „Übrigens, drei der neuen Bedingungen sind jetzt überflüssig, zwei Validierungen doppeln sich, und diese Hilfsklasse existiert nur, weil wir anfangs die falsche Stelle repariert haben.“

Genau diese Selbstkritik muss man erzwingen.

Der Prompt macht noch etwas anderes richtig: Er fordert keine groß angelegte Neuarchitektur. Das ist wichtig, weil KI-Refactoring sonst schnell gefährlich wird. Wer einer Maschine nur sagt „Mach den Code besser“, bekommt oft eine Mischung aus Stilkorrektur, Abstraktionswut und Umbaumaßnahmen, die mit dem ursprünglichen Problem wenig zu tun haben. Der hier beschriebene Cleanup-Pass bleibt dagegen am konkreten Codepfad und an der konkreten Ursache.

Das ist nicht spektakulär. Aber genau deshalb ist es produktionsfähig.

Woran man symptomatische Fixes erkennt

Wer mit KI-Agenten arbeitet, sollte sich einige Warnsignale antrainieren. Wenn nach einem Fix eines oder mehrere dieser Muster auftauchen, ist ein Cleanup-Pass fast immer sinnvoll:

• Mehrere neue Bedingungen, die denselben Zustand an verschiedenen Stellen absichern.
• Zusätzliche Flags oder Konfigurationsparameter, die nur einen Sonderfall entschärfen.
• Doppelte Validierungen entlang desselben Datenflusses.
• Helper-Methoden, deren einziger Zweck das Abfedern eines strukturellen Problems ist.
• Retry-Logik, die nicht auf Transienten, sondern auf falsche Zustände reagiert.
• Null-Checks oder Defaults, die nur deshalb nötig sind, weil Daten früher nicht sauber garantiert wurden.
• Logging, das primär Verwirrung dokumentiert, statt Systemzustände sinnvoll zu beschreiben.

Solche Stellen sind oft nicht „falsch“. Aber sie sind Kandidaten für das, was ich technischen Klebeschaum nennen würde: Es hält irgendetwas zusammen, macht das System aber größer und schwerer.

Der eigentliche Gewinn: weniger Runtime-Risiko

Viele Entwickler denken bei Cleanup zunächst an Lesbarkeit oder Stil. Das greift zu kurz. Der wahre Gewinn liegt in der Laufzeitstabilität.

Jeder unnötige Zweig im Code ist ein weiterer Pfad, der theoretisch betreten werden kann. Jede zusätzliche Konfiguration ist eine weitere Kombination, die niemand vollständig getestet hat. Jeder Workaround erzeugt implizite Annahmen. Jede verdoppelte Validierung kann auseinanderlaufen. Jede unnötige Abstraktion vergrößert die Distanz zwischen Ursache und Wirkung.

Deshalb ist Entrümpeln kein ästhetischer Luxus. Es ist eine Form von Risikoreduktion.

Gerade in produktiven Systemen gilt: Weniger Mechanik bedeutet oft weniger Versagensmöglichkeiten.

KI ist stark – aber sie braucht einen zweiten Blick

Ich arbeite sehr gern mit KI-Coding-Agenten. Sie sind schnell, unermüdlich, oft überraschend treffsicher und in vielen Situationen ein realer Produktivitätshebel. Aber sie haben eine systematische Schwäche: Sie beenden Probleme häufig dort, wo Menschen sie erst richtig verstehen würden.

Deshalb sollte man den ersten erfolgreichen Fix nie mit der endgültigen Lösung verwechseln.

Die bessere Arbeitsweise ist zweistufig:

Erst den Fehler beheben.
Dann den gesamten relevanten Codepfad noch einmal prüfen, diesmal nicht mit der Frage „Läuft es?“, sondern mit der Frage „Was davon ist jetzt noch wirklich nötig?“

Genau in diesem zweiten Durchgang entsteht robuste Software. Nicht, weil sie mehr kann, sondern weil sie weniger Ballast mit sich herumschleppt.

Und vielleicht ist das die wichtigste Lektion beim Arbeiten mit KI in der Softwareentwicklung: Nicht jede funktionierende Lösung ist schon eine gute Lösung. Manche sind nur erfolgreich kaschierte Umwege.

Für einen produktiven Codebestand ist das auf Dauer zu teuer.

---

Schlussformel für den Alltag

Sobald eine Methode stabil läuft oder eine fachliche Domäne abgeschlossen ist, sollte der Auftrag an den KI-Agenten nicht enden mit: „Fertig.“

Er sollte enden mit:

„Gehe den gesamten Codepfad vom Einstieg bis zur stabilen Stelle noch einmal durch. Finde nicht neue Features, sondern alte Notlösungen. Entferne alles, was nicht mehr nötig ist. Behalte nur die einfachste robuste Lösung.“

Das ist Wartbarkeit.