Dasselbe Modell. Das Modell, das im Web-Chat halluzinierte, liefert in Claude Code ein 200-Zeilen-Feature auf einen Schlag. Codex’ /goal loest ein ganzes Issue auf einmal. Das Modell ist nicht ploetzlich klueger geworden. Was sich geaendert hat, ist die Struktur.
Warum es funktioniert
Die Schleife der konversationellen KI sieht so aus:
LLM → Mensch → LLM → Mensch
Das gesamte Feedback ist natuerliche Sprache. Auf probabilistische Generierung folgt probabilistische Bewertung. Die Genauigkeit verschlechtert sich multiplikativ.
Die Schleife eines Coding-Agenten ist anders:
LLM → Code-Generierung → Datei speichern → Test ausfuehren → pass/fail → LLM
LLM → Code-Aenderung → Build → Erfolg/Fehler → LLM
LLM → Typ-Check → Fehlermeldung → LLM
In der Schleife stecken deterministische Gates. Das Dateisystem speichert exakt das, was geschrieben wurde. Tests sind entweder pass oder fail. Der Compiler sagt, wenn etwas falsch ist. Diese Elemente wirken unbeabsichtigt als Ratchet.
Ein LLM ist eine unreliable component. Aber ein reliable protocol auf unreliable components aufzubauen, ist grundlegendes Engineering. TCP schafft reliable delivery ueber ein unreliable network. RAID schafft reliable storage ueber unreliable disks. ECC schafft reliable computation ueber unreliable memory.
Der Grund, warum Coding-Agenten funktionieren, ist derselbe. Auf ein unreliable LLM wurden deterministic verifiers (Tests, Build, Linter, Typ-Checker) aufgesetzt. Nicht die Modellleistung, sondern die Topology ist die Ursache des Erfolgs.
Und warum scheitern sie dann?
Es funktioniert, wurde gesagt. Aber manchmal bricht es zusammen. Warum?
Weil es einen Unterschied gibt zwischen einem Ratchet, das zufaellig vorhanden ist, und einem, das bewusst entworfen wurde.
Es gibt Abschnitte ohne Ratchet
Was passiert, wenn ein Agent Code ohne Tests aendert? Der Build laeuft durch, der Lint laeuft durch, aber die Funktionalitaet ist kaputt. In Abschnitten ohne deterministische Gates urteilt das LLM probabilistisch, und probabilistische Urteile verschlechtern sich multiplikativ.
Von 200 Endpoints haben 180 Tests und 20 nicht. Der Agent bearbeitet die 180 perfekt und pflanzt in den 20 still Bugs ein. Deshalb entsteht das Gefuehl: “Es ist fast fertig, aber irgendetwas stimmt nicht.”
Die Informationsdichte des Feedbacks ist unzureichend
Ein Experiment sortierte 1000 Woerter. Die CPU brauchte 0,08 ms bei 100 %. Das LLM brauchte 438 Sekunden bei 97,7 %. Das allein ist beeindruckend — 97,7 % durch reine Kognition. Aber die eigentliche Entdeckung lag woanders.
Fuer dasselbe Ergebnis wurde nur das Feedback-Niveau variiert:
| Feedback | Ergebnis |
|---|---|
| Keines | 6 Fehler (99,4 %) |
| “Es gibt Fehler” | 10 Fehler (99,0 %) — verschlechtert |
| “Es gibt 23 Fehler” | 1 Fehler (99,9 %) |
| “6, an diesen Stellen” | 0 Fehler (100 %) |
Wenn man nur sagt “es ist falsch”, fuehrt Ueberkorrektur zu einer Verschlechterung. Wenn man die Anzahl der Fehler nennt, entsteht ein Zielwert, und das Modell sucht beharrlich. Wenn man auch die Position angibt, korrigiert es perfekt.
Die meisten heutigen Agenten verharren auf der zweiten Stufe. Wenn ein Test fehlschlaegt, wissen sie “irgendetwas ist falsch”, aber sie vermitteln nicht den strukturellen Grund, warum es falsch ist. Fehlermeldungen existieren zwar, aber sie zeigen Symptome, nicht Ursachen.
Es gibt blinde Flecken, und Wiederholung loest sie nicht
Im Sortierexperiment hinterliess das LLM in R2 sechs Fehler. In R3 meldete es “keine Fehler”. In R4b meldete es erneut “keine Fehler”. Es uebersah dieselben sechs auf dieselbe Weise.
Ohne Hinweis konvergierte es bei 99,4 %, egal wie oft man wiederholte. Erst als man sagte “es sind noch 6 uebrig”, erreichte es 100 %.
Bei Coding-Agenten passiert dasselbe. Der Agent erzeugt einen Bug, beurteilt im Self-Review “kein Problem”, und uebersieht beim erneuten Korrekturversuch dieselbe Stelle. Deshalb ist Retry keine Loesung. Blinde Flecken sind eine strukturelle Grenze, die aus der probabilistischen Natur des Modells entsteht, kein Mangel an Anstrengung.
Bei Skalierung wirkt Multiplikation
97,7 % Genauigkeit zweimal verkettet ergibt 0,977² = 95,4 %. Dreimal: 93,2 %. Zehnmal: 79,2 %.
Ein Agent, der eine einzelne Datei aendert, macht das gut. Aber ein Refactoring ueber 100 Dateien? Selbst wenn jeder Schritt 97 % hat, ergibt das nach 100 Schritten 0,97¹⁰⁰ = 4,8 %. Scheitern ist praktisch garantiert.
Das ist die mathematische Erklaerung dafuer, warum “Vibe Coding bei 200 Endpoints zusammenbricht”. Bei kleinen Projekten ist die Zahl der Verkettungen gering genug, dass die Wahrscheinlichkeit standhaelt. Bei grossen Projekten wirkt die Multiplikation verheerend.
Was gebraucht wird
Der Grund fuer das Funktionieren und der Grund fuer das Scheitern zeigen auf dieselbe Stelle: das Vorhandensein oder Fehlen deterministischer Verifikations-Gates.
Heutige Agenten verlassen sich auf zufaellig vorhandene Ratchets (Tests, Build, Linter). Wenn man diese bewusst entwirft, werden sie staerker.
Was es bedeutet, Ratchets bewusst zu entwerfen:
Erstens: Abschnitte ohne Ratchet identifizieren. Code ohne Tests, APIs ohne Schema, Daten ohne Typen. Jede Stelle, an der der Agent probabilistisch urteilt, ist eine Schwachstelle.
Zweitens: die Informationsdichte des Feedbacks erhoehen. Nur pass/fail zurueckzugeben provoziert Ueberkorrektur. “Wo, warum und was von der Erwartung abweicht” muss strukturiert vermittelt werden.
Drittens: zwischen den Verkettungsschritten deterministische Gates einfuegen. Zehn Schritte auf einmal auszufuehren laesst die Multiplikation verheerend wirken, aber wenn jeder Schritt durch ein Ratchet fixiert wird, wird die Verschlechterung zurueckgesetzt.
Ein LLM ist ein bemerkenswerter Generator. Es sortiert 1000 Woerter durch reines Denken mit 97,7 % Genauigkeit. Das koennte kein Mensch. Aber alles unter 100 % bricht bei Wiederholung zusammen. 0,977 zum Quadrat ist 0,954.
Coding-Agenten funktionieren nicht, weil das Modell klug ist. Sondern weil in der Schleife deterministische Gates stecken. Sie scheitern, wenn diese Gates fehlen.
Generierung darf probabilistisch sein. Verifikation muss deterministisch sein.
Verwandte Artikel
- Ratchet Pattern — Wie man Agenten dazu bringt, die Arbeit zu beenden — Struktur und Prinzipien des Ratchet-Musters
- Modell-IQ ist weniger wichtig als Feedback-Topologie — Die Struktur des Feedbacks bestimmt die Leistung
- Einschränkungen sind Verträge — Rationale Einschränkungen befreien Systeme
- filefunc — Eine Datei, ein Konzept — LLM-native Code-Struktur
- KI-Denken aus ersten Prinzipien — Wie man mit KI denkt