Self-Correction Loop

1. Konzeptüberblick und systemisches Problem

Eine der größten Illusionen bei der Arbeit mit KI ist die Erwartung, dass ein Sprachmodell komplexen, funktionsfähigen Code im ersten Versuch fehlerfrei schreibt. In der Praxis verlassen sich selbst erfahrene Entwickler ständig auf Tool-basierte Diagnose: Sie starten Compiler, analysieren Fehler-Highlighting in der IDE und untersuchen Testmeldungen.

Wenn man einen Agenten ohne Feedback-Loop betreibt, treten folgende Probleme auf:

1. Blinde syntaktische Halluzinationen: Das Modell verwendet sicher veraltete Bibliotheksmethoden oder greift auf nicht existierende Objekt-Eigenschaften zu.
2. Unfähigkeit, komplexe Bugs zu beheben: Ohne Analyse des Stacktraces kennt der Agent den tatsächlichen Absturzpunkt des Programms zur Laufzeit nicht.
3. Manuelle Belastung für Entwickler: Menschen müssen Terminal-Meldungen manuell in den Chat kopieren und um Korrekturen bitten.

Der Self-Correction Loop (Zyklus des geerdeten Selbstkorrigierens) verwandelt die Codegenerierung in eine gesteuerte Engineering-Pipeline: Der Agent nimmt Änderungen vor, führt Validierungs-Tools aus, analysiert die Ausgabe der Umgebung und wiederholt Versuche so lange, bis die Tests „grün“ sind.

2. Architektonische Taxonomie und mentales Modell

Ein zuverlässiger Self-Correction-Loop basiert auf drei Ebenen deterministischer Feedback-Oracles:

• 1. Syntaktische und statische Oracles (Static Oracles): Kompilierungs- und Typ-Check-Tools (tsc --noEmit, mypy, cargo check). Sie arbeiten in Millisekunden und liefern präzise Fehlerkoordinaten (Datei, Zeile, Spalte, erwarteter und tatsächlicher Typ).
• 2. Dynamische Verhaltens-Oracles (Dynamic Test Oracles): Test-Runner (vitest, pytest, jest). Sie prüfen die tatsächliche Ausführungslogik, das Verhalten bei Randbedingungen (Boundary Conditions) und die Abwesenheit von Regressionen.
• 3. Stilistische und architektonische Linter (Linters): eslint, biome, ruff. Sie überwachen die Einhaltung des Company Code Styles, verbieten die Verwendung von any und erkennen ungenutzte Variablen.
• 4. Strategien zur Fehlerbehebung:
  • Surgical Diff (Chirurgischer Patch): Ersetzung nur weniger gezielter Zeilen einer Funktion.
  • Full File Rewrite (Vollständiges Umschreiben): Eine riskante Methode, die oft fremde Bugs einführt.

3. Technische Pipeline und interne Mechanik

Der Lebenszyklus einer iterativen Fehlerbehebung:

1. Patch Generation & Application (Anwendung von Änderungen): Der Agent generiert einen Patch für die Quelldatei und schreibt die Änderungen ins Dateisystem.
2. Oracle Execution (Ausführung der Prüfung): Die Runtime startet automatisch den Validierungsbefehl in einem isolierten Prozess (z. B. npm test).
3. Exit Code & Stacktrace Extraction (Ergebnisauswertung):
   • Wenn der Exit Code 0 ist – gilt die Aufgabe als erledigt, der Zyklus endet erfolgreich.
   • Wenn der Exit Code != 0 ist – parst die Runtime stderr/stdout, entfernt visuelles Rauschen und erstellt eine strukturierte Fehlermeldung.
4. Context Injection & Re-prompting (Weitergabe des Feedbacks): Der Agent erhält folgende Meldung: „Test user-auth.test.ts schlug in Zeile 42 fehl mit der Fehlermeldung: Expected status 200, received 401. Hier ist ein Fragment der Datei um Zeile 42. Finde die Ursache und schlage eine Korrektur vor.“ Der Prozess wird mit einem Versuchs-Zähler wiederholt.

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Autonome Behebung von TypeScript-Fehlern

Der Agent aktualisiert die Methodensignatur in einer gemeinsamen Bibliothek. Der Start von tsc deckt 8 Dateien mit gebrochenen Verträgen auf. Der Agent arbeitet sequenziell jede Datei durch, korrigiert Parametertypen und stoppt erst, wenn der Compiler keine Fehler mehr ausgibt.

02. Test-Driven Development (TDD)

Ein Ingenieur schreibt eine Reihe strenger Unit-Tests, die die Business-Anforderungen für eine neue API beschreiben. Der Agent erhält die Aufgabe, den Implementierungscode zu schreiben. Innerhalb des Self-Correction-Loops schreibt das Modell Code, führt Tests aus, analysiert Diskrepanzen und bringt alle Tests ohne menschliches Zutun auf den grünen Status.

03. Automatische Migration veralteter Abhängigkeiten

Beim Übergang auf eine neue Major-Version eines Frameworks führt der Agent die Testsuite aus und aktualisiert basierend auf Meldungen über veraltete Methoden (Deprecation Warning) den Anwendungscode automatisch auf moderne APIs.

5. Fallstricke, typische Fehler und Sicherheit

• Löschen oder Abschwächen von Tests (Test Cheating): Bei schwierigen Tests könnte das Modell versuchen, das Problem durch Hinzufügen von it.skip() oder Kommentieren von expect() zu lösen. Blockieren Sie immer die Möglichkeit, Testdateien zu bearbeiten, oder prüfen Sie den Git Diff auf Modifikationen im Testordner.
• Oszillation und „sanftes Loopen“ (Flip-Flop Edits): Der Agent behebt einen Fehler in Datei A, was Datei B bricht; dann behebt er Datei B, was wieder A bricht. Wenn das System eine Wiederholung des identischen Code-Zustands erkennt, muss der Zyklus sofort stoppen.
• Umschreiben statt Heilen (Over-Fixing): Anstatt eines einzelnen falschen Arguments umzuschreiben, ersetzt der Agent die gesamte 300-Zeilen-Funktion und verliert dabei Optimierungen und wichtige Details. Erzwingen Sie vom Agenten die Verwendung lokalisierter Diff-Patches.