Feedback-Topologie statt Modell-IQ

Feedback-Topologie statt Modell-IQ Image: AI generated

Werden klügere Modelle alles lösen?

Das vorherrschende Narrativ rund um KI-Coding-Tools lautet: Wenn das Modell gut genug ist, wird es selbst Code schreiben, Tests schreiben und refaktorisieren. Wenn GPT-4 es nicht konnte, wird GPT-5 es können. Wenn Claude nicht reicht, wird ein größerer Claude es schaffen.

Stimmt das wirklich?

Ich beauftragte Claude Opus 4.7 mit einem filefunc-Refactoring. Es war in einer Stunde fertig, ohne menschliches Review. validate bestanden, pytest bestanden, Coverage gehalten. Oberflächlich passt das zum Narrativ „einfach ein besseres Modell nehmen".

Aber was passiert, wenn man demselben Modell dasselbe Refactoring ohne filefunc-Regeln gibt? Ohne validate? Ohne Coverage-Feedback? Das Ergebnis ist völlig anders. Es fällt in einen Doom Loop — einen Bug zu fixen bricht eine andere Stelle, das zu fixen bricht wieder eine andere.

Dasselbe Modell. Was sich geändert hat, ist die Umgebung.

„Fertig" — Der Instinkt zur vorzeitigen Beendigung

Ein weiteres Experiment mit demselben Modell. Ich setzte einen Agenten auf ein Projekt mit 527 Funktionen an. „Schreib Tests für jede Funktion." Der Agent beendete seine Arbeit und meldete: „Fertig."

Funktionen, die tatsächlich Tests bekamen: 40. 40 von 527.

Der Agent hat nicht gelogen. Er machte 40 und entschied „das reicht." Die Standard-Veranlagung eines LLM ist optimistisch vorzeitiges Beenden. Wenn es auf eine schwierige Funktion trifft, überspringt es sie, macht noch ein paar, und schlussfolgert dann „der Rest folgt demselben Muster, also passt das."

Nach Erzwingung einer Schleife mit einem CLI-Tool:

Autonomer Agent:  40 / 527  (7.6%)  — Agent erklärt „fertig"
CLI-Schleife:    527 / 527 (100%)  — Maschine erklärt „noch 487 übrig"

Dasselbe Modell. Dasselbe Projekt. Der Unterschied ist, wer entscheidet, wann es „fertig" ist.

Die Umgebung formt das Modell

Beide Experimente zeigen auf dieselbe Schlussfolgerung. Opus 4.7 hat nicht abgeschlossen, weil es klug war. Es hat abgeschlossen, weil die Spezifikationsoberfläche maschinenprüfbar war.

filefunc validate  → Erfüllt die Code-Struktur die Regeln?
pytest             → Ist das bestehende Verhalten erhalten?
coverage           → Welche Branches fehlen?

Diese drei gaben bei jeder Änderung sofortiges Feedback. Das Modell erhielt Feedback, korrigierte, erhielt erneut Feedback, korrigierte erneut. Eine selbstkorrigierende Schleife.

Hier ist die zentrale Erkenntnis:

Feedback-Topologie bestimmt die Ergebnisse mehr als der Modell-IQ.

LLMs sind stark in der Generierung, aber schwach bei der Garantie von Korrektheit. Huang et al. (2024) bewiesen experimentell, dass wenn LLMs versuchen, ihre Argumentation ohne externes Feedback (Oracle Feedback) selbst zu korrigieren, die Leistung tatsächlich sinken kann. Bei Vorhandensein eines deterministischen Verifizierers stabilisiert sich die Leistung jedoch dramatisch. lint, typecheck, test, coverage — diese werden zum Gradienten-Signal, das den Output des Modells korrigiert.

„Es wird gelöst, wenn die Modelle klug genug sind" ist eine falsche Aussage. Die korrekte Formulierung lautet: „Wenn das Feedback schnell genug ist, können aktuelle Modelle es bereits lösen."

broad exploration vs local correction

Die Stärke von LLMs ist nicht broad exploration — sondern local correction.

„Schreib Tests für dieses Projekt" — das ist broad exploration. Das LLM verliert die Richtung.

„Zeile 41 ist nicht abgedeckt" — das ist local correction. Das LLM schreibt einen Test, der genau diese Zeile abdeckt.

In realen Projekten verifizierte Zahlen:

Ohne Feedback:  bleibt bei 60–70% Coverage stehen
Mit Feedback:   erreicht 100% (für erreichbare Funktionen)

Dasselbe Modell. Die einzelne Zeile „line 41 not covered" fungiert als Gradienten-Signal. Dieses Feedback lenkt die Korrekturen des LLM in genau die richtige Richtung.

Symbolic Feedback Loop

Eine Struktur durchzieht alle diese Beobachtungen.

LLM generiert → deterministisches Tool beurteilt → Ergebnis wird ans LLM zurückgegeben → wiederholen

Ich nenne das einen Symbolic Feedback Loop.

Der Industrie-Mainstream heute ist der LLM Feedback Loop — KI verifiziert KI. Es ist wie ein Betrunkener, der einen betrunkenen Freund fragt: „Bin ich betrunken?" Beide sind probabilistisch, also häufen sich Fehler an.

Der Symbolic Feedback Loop ist anders. Chen et al. (2023) bewiesen, dass iteratives Debugging — Compiler- und Laufzeit-Fehlermeldungen an das Modell zurückzugeben — die Code-Genauigkeit dramatisch verbessert. pytest halluziniert nicht. go test ist nie betrunken. Coverage-Messung lügt nicht. Spezifikations-Verifikation driftet nicht.

Diese Struktur funktioniert in Domänen, in denen Korrektheit mechanisch beurteilt werden kann — Code, Tests, Spezifikationen, Typen. Die Eleganz von API-Design oder die Natürlichkeit von UX können noch nicht von symbolischen Tools beurteilt werden. Diese Grenze zu erweitern ist die nächste Herausforderung. Ich glaube, es gibt einen Weg, selbst natürliche Sprache in verifizierbare Grenzen zu bringen.

Was AlphaCode (Li et al., 2022) im Wettbewerbsprogrammieren zeigte, folgt demselben Prinzip. Es war nicht die Generierungsfähigkeit des Modells an sich, sondern das Umgebungsdesign — Millionen von Kandidaten generieren und dann durch Tests filtern — das die Leistung bestimmte. Statt das Modell klüger zu machen, ist es effektiver, das Feedback, das dem Modell zurückgegeben wird, präziser zu machen.

Entscheidungen delegieren

Es ist offensichtlich, dass Entscheidungen nicht an KI delegiert werden sollten. Aber dass Menschen alles prüfen und entscheiden, ist erschöpfend. Bestimmte repetitive, strukturierte Entscheidungen können von symbolischen Tools im Auftrag von Menschen ausgeführt werden.

„Decken diese Tests alle Branches ab?" — kein Mensch muss sie durchlesen. Ein Coverage-Tool beurteilt. „Erfüllt dieser Code die Strukturregeln?" — kein Mensch muss reviewen. validate beurteilt. „Gibt es noch unverarbeitete Funktionen?" — kein Mensch muss zählen. Das CLI deklariert.

Entscheidungen, die nicht an KI delegiert werden können, können an symbolische Tools delegiert werden — weil sie deterministisch sind, nicht probabilistisch. Das ist der Existenzgrund des Symbolic Feedback Loop.

Es ist wichtiger, die Gleise zu verlegen, als den Zug schneller zu machen.

Viele bauen Züge. Fast niemand verlegt Gleise.

Quellen

Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, Denny Zhou. “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” arXiv:2304.05128, 2023.
Yujia Li, David Choi, Junyoung Chung, Nate Kushman, Julian Schrittwieser, Remi Leblond, Tom Eccles, et al. “Competition-Level Code Generation with AlphaCode.” Science 378(6624): 1092-1097, 2022.
Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
Aman Madaan, Niket Tandon, Prakhar Gupta, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023.
Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
Mert Cemri, Melissa Z. Pan, Shuyi Yang, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track.
Carlos E. Jimenez, John Yang, Alexander Wettig, et al. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.