Wird es gelöst, wenn das Modell klüger wird?
Das vorherrschende Narrativ der AI-Coding-Tools lautet so: Wenn das Modell gut genug wird, schreibt es guten Code, gute Tests und refaktoriert von alleine. Was mit GPT-4 nicht geklappt hat, wird mit GPT-5 klappen. Was Claude nicht schafft, wird ein größeres Claude schaffen.
Stimmt das wirklich?
Ich ließ Claude Opus 4.7 ein filefunc-Refactoring durchführen. Ohne menschliches Review war es in einer Stunde fertig. validate bestanden, pytest bestanden, Coverage gehalten. Vom Ergebnis her passt es zum Narrativ „ein gutes Modell reicht".
Aber was passiert, wenn man demselben Modell dasselbe Refactoring ohne filefunc-Regeln aufträgt? Ohne validate? Ohne Coverage-Feedback? Das Ergebnis ist völlig anders. Es gerät in einen Doom Loop. Beim Beheben eines Bugs bricht etwas anderes, beim Beheben davon bricht wieder etwas anderes.
Dasselbe Modell. Was sich geändert hat, ist die Umgebung.
„Fertig!" — Der Instinkt des Agenten zur vorzeitigen Beendigung
Mit demselben Modell ein weiteres Experiment. Ein Agent wurde autonom auf ein Projekt mit 527 Funktionen losgelassen. „Schreibe Tests für alle Funktionen." Der Agent beendete die Arbeit und meldete: „Erledigt."
Tatsächlich geschriebene Tests: 40. 40 von 527.
Der Agent hat nicht gelogen. Nach 40 hat er entschieden, „das reicht". Die Grundtendenz eines LLM ist optimistischer vorzeitiger Abbruch. Bei schwierigen Funktionen wird übersprungen, nach ein paar weiteren kommt die Schlussfolgerung: „Der Rest folgt demselben Muster, das reicht."
Nach Erzwingung einer Schleife durch ein 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 „Ende" ist?
Die Umgebung formt das Modell
Beide Experimente zeigen dasselbe Ergebnis. Opus 4.7 hat nicht durchgehalten, weil das Modell klug ist. Sondern weil die specification surface machine-checkable war.
filefunc validate → Erfüllt die Codestruktur die Regeln?
pytest → Ist das bestehende Verhalten erhalten?
coverage → Welche Verzweigungen fehlen?
Diese drei gaben bei jeder Änderung sofortiges Feedback. Das Modell nahm das Feedback auf, korrigierte, erhielt erneut Feedback, korrigierte erneut. Ein self-correcting loop.
Der Kernpunkt ist folgender:
Die Feedback-Topologie bestimmt das Ergebnis mehr als der IQ des Modells.
LLMs sind stark in der Generierung, aber schwach in der Correctness-Garantie. Doch mit einem deterministic verifier stabilisiert sich die Leistung drastisch. Lint, Typecheck, Test, Coverage — sie werden zum gradient signal, das die Ausgabe des Modells korrigiert.
„Wenn das Modell gut genug wird, löst sich das Problem" ist eine falsche These. Präziser: „Wenn das Feedback schnell genug ist, löst auch das aktuelle Modell das Problem."
broad exploration vs local correction
Die Stärke eines LLM liegt nicht in broad exploration, sondern in local correction.
„Schreibe Tests für dieses Projekt" — das ist broad exploration. Das LLM verliert die Orientierung.
„Line 41 ist nicht abgedeckt" — das ist local correction. Das LLM schreibt präzise einen Test, der genau diese Zeile abdeckt.
In der Praxis verifizierte Zahlen:
Ohne Feedback: Stoppt bei 60–70% Coverage
Mit Feedback: 100% erreicht (bezogen auf erreichbare Funktionen)
Dasselbe Modell. Eine einzige Zeile „line 41 not covered" dient als gradient signal. Dieses Feedback lenkt die Korrekturen des LLM in die richtige Richtung.
Symbolic Feedback Loop
Eine Struktur durchzieht all diese Beobachtungen.
LLM generiert → deterministisches Tool urteilt → Ergebnis geht zurück ans LLM → Wiederholung
Das nenne ich Symbolic Feedback Loop.
Der aktuelle Mainstream der Branche ist der LLM Feedback Loop. AI validiert AI. Ein Betrunkener fragt seinen betrunkenen Freund: „Bin ich betrunken?" Beide sind probabilistisch, also akkumulieren sich die Fehler.
Der Symbolic Feedback Loop ist anders. pytest halluziniert nicht. go test ist nicht betrunken. Coverage-Messung lügt nicht. Spezifikationsvalidierung driftet nicht.
Diese Struktur funktioniert in Bereichen, in denen Correctness maschinell überprüfbar ist — Code, Tests, Spezifikationen, Typen. Die Eleganz eines API-Designs oder die Natürlichkeit einer UX kann ein symbolisches Tool noch nicht beurteilen. Diese Grenze zu erweitern, ist die nächste Aufgabe. Ich glaube, dass es einen Weg gibt, auch natürliche Sprache in verifiable Grenzen zu bringen.
Statt das Modell klüger zu machen, ist es effektiver, das Feedback, das man dem Modell zurückgibt, präziser zu machen.
Delegation von Entscheidungen
Es ist selbstverständlich, dass man Entscheidungen nicht an AI delegieren sollte. Allerdings ist es mühsam, wenn Menschen alles überprüfen und entscheiden müssen. Bestimmte repetitive und formalisierte Entscheidungen können symbolische Tools anstelle des Menschen übernehmen.
„Deckt dieser Test alle Verzweigungen ab?" — Ein Mensch muss das nicht lesen. Das Coverage-Tool urteilt. „Erfüllt dieser Code die Strukturregeln?" — Ein Mensch muss das nicht reviewen. validate urteilt. „Gibt es noch unbearbeitete Funktionen?" — Ein Mensch muss das nicht zählen. Das CLI deklariert es.
Entscheidungen, die man nicht an AI delegieren kann, kann man an symbolische Tools delegieren. Weil es kein Probabilismus ist, sondern Determinismus. Das ist der Existenzgrund des Symbolic Feedback Loop.
Es ist wichtiger, Gleise zu verlegen, als den Zug schneller zu machen.
Viele bauen Züge. Fast niemand verlegt die Gleise.