Warum Coding-Agenten funktionieren und warum sie scheitern

Dasselbe Modell. Das im Web-Chat halluzinierte, liefert in Claude Code ein 200-Zeilen-Feature auf Anhieb. Codex’ /goal löst ein ganzes Issue. Das Modell wurde nicht plötzlich klüger. Was sich geändert hat, ist die Struktur.

Warum sie funktionieren

Die Schleife der konversationellen KI sieht so aus:

LLM → Mensch → LLM → Mensch

Das gesamte Feedback ist natürliche Sprache. Probabilistische Generierung gefolgt von probabilistischer Bewertung. Die Genauigkeit degradiert als Produkt.

Die Schleife der Coding-Agenten ist anders:

LLM → Code-Generierung → Datei speichern → Test ausführen → pass/fail → LLM
LLM → Code-Bearbeitung → Build → Erfolg/Fehler → LLM
LLM → Type-Check → Fehlermeldung → LLM

Deterministische Gates sitzen in der Schleife. Das Dateisystem speichert exakt das, was geschrieben wurde. Ein Test ist pass oder fail. Der Compiler sagt falsch, wenn es falsch ist. Diese dienen unbeabsichtigt als Ratchets.

Ein LLM ist eine unzuverlässige Komponente. Aber ein zuverlässiges Protokoll auf unzuverlässigen Komponenten aufzubauen ist ein Grundprinzip der Ingenieurwissenschaft. Von Neumann bewies 1956 mathematisch, dass allein Mehrheitsentscheidung verrauschte Bauteile zu zuverlässiger Berechnung befähigen kann (Von Neumann, 1956). TCP baut zuverlässige Zustellung auf einem unzuverlässigen Netzwerk. RAID baut zuverlässigen Speicher auf unzuverlässigen Festplatten. ECC baut zuverlässige Berechnung auf unzuverlässigem Speicher.

Der Grund, warum Coding-Agenten funktionieren, ist derselbe. Ein unzuverlässiges LLM wird mit deterministischen Verifizierern ergänzt (Tests, Builds, Linter, Type-Checker). Die SWE-agent-Studie zeigte, dass selbst dasselbe Modell je nach Agent-Computer-Interface-Design dramatisch unterschiedliche Leistung zeigt (Yang et al., NeurIPS 2024). Es ist die Topologie, nicht die Modellfähigkeit, die den Erfolg verursacht.

Aber warum scheitern sie?

Sie funktionieren, sagte ich. Aber manchmal scheitern sie. Warum?

Weil zufällig vorhandene Ratchets und bewusst entworfene Ratchets verschiedene Dinge sind.

Ratchet-freie Zonen existieren

Wenn ein Agent Code ohne Tests bearbeitet? Der Build geht durch, Lint geht durch, aber die Funktionalität ist kaputt. In Zonen ohne deterministische Gates urteilt das LLM probabilistisch, und probabilistische Urteile degradieren als Produkt.

Von 200 Endpoints haben 180 Tests und 20 nicht. Der Agent behandelt 180 perfekt und pflanzt still Bugs in die 20. Deshalb bekommt man „fast fertig, aber irgendetwas stimmt nicht."

Die Informationsdichte des Feedbacks ist unzureichend

Ich führte ein Sortierexperiment mit 1.000 Wörtern durch. CPU: 0,08ms bei 100%. LLM: 438 Sekunden bei 97,7%. Das allein ist bemerkenswert — 97,7% durch reine Kognition. Aber die eigentliche Entdeckung lag woanders.

Ich variierte nur das Feedback-Level auf dasselbe Ergebnis:

Feedback	Ergebnis
Keins	6 Fehler (99,4%)
„Es gibt Fehler"	10 Fehler (99,0%) — schlechter
„Es gibt 23 Fehler"	1 Fehler (99,9%)
„6 Fehler, hier sind sie"	0 Fehler (100%)

Nur „du liegst falsch" zu sagen verursacht Überkorrektur und verschlechtert die Dinge. Eine Anzahl zu geben schafft ein Ziel zum Verfolgen. Positionen zu geben erreicht Perfektion.

Die meisten Agenten heute operieren auf der zweiten Ebene. Wenn ein Test fehlschlägt, wissen sie „etwas stimmt nicht", aber sie vermitteln nicht den strukturellen Grund. Fehlermeldungen existieren, aber sie sind Symptome, nicht Ursachen.

Blinde Flecken existieren, und Wiederholung behebt sie nicht

Im Sortierexperiment hinterließ das LLM 6 Fehler in R2. In R3 meldete es „keine Fehler". In R4b meldete es erneut „keine Fehler". Es übersah dieselben 6 auf dieselbe Weise.

Ohne Hinweise, egal wie viele Wiederholungen, konvergierte es bei 99,4%. Erst als es erfuhr „6 verbleiben" erreichte es schließlich 100%.

Dasselbe passiert bei Coding-Agenten. Der Agent erzeugt einen Bug, macht Self-Review mit „sieht gut aus", und wenn man ihn erneut zum Fixen auffordert, übersieht er dieselbe Stelle. Huang et al. (2024) zeigten, dass ohne externes Feedback die Selbstkorrektur von Argumentationsfehlern durch LLMs die Leistung tatsächlich verschlechtert (Huang et al., ICLR 2024). Deshalb ist Retry nicht die Antwort. Blinde Flecken sind eine strukturelle Limitation der probabilistischen Natur des Modells, kein Mangel an Einsatz.

Multiplikation wirkt bei Skalierung

97,7% Genauigkeit zweimal verkettet: 0,977² = 95,4%. Dreimal: 93,2%. Zehnmal: 79,2%.

Ein Agent, der eine einzelne Datei bearbeitet, macht das gut. Aber 100 Dateien refaktorisieren? Selbst bei 97% pro Schritt ergeben 100 Schritte 0,97¹⁰⁰ = 4,8%. Scheitern ist praktisch garantiert.

Das ist die mathematische Erklärung dafür, warum „Vibe Coding bei 200 Endpoints zusammenbricht." In kleinen Projekten ist die Kettenlänge niedrig genug, dass die Wahrscheinlichkeit hält. In großen Projekten wird die Multiplikation katastrophal.

Was wird gebraucht

Die Gründe für das Funktionieren und die Gründe für das Scheitern zeigen auf denselben Punkt: das Vorhandensein oder Fehlen deterministischer Verifikations-Gates.

Aktuelle Agenten verlassen sich auf zufällig vorhandene Ratchets (Tests, Builds, Linter). Sie bewusst zu entwerfen macht sie stärker.

Was es bedeutet, Ratchets bewusst zu entwerfen:

Erstens, Ratchet-freie Zonen identifizieren. Code ohne Tests, APIs ohne Schemas, Daten ohne Typen. Jeder Ort, an dem der Agent probabilistisch urteilt, ist eine Schwachstelle.

Zweitens, den Informationsgehalt des Feedbacks erhöhen. Nur pass/fail zurückzugeben induziert Überkorrektur. „Wo, warum und wie sich das Tatsächliche vom Erwarteten unterscheidet" muss strukturiert kommuniziert werden.

Drittens, deterministische Gates zwischen Verkettungsschritte einfügen. 10 Schritte auf einmal auszuführen macht die Multiplikation katastrophal, aber mit einem Ratchet an jedem Schritt zu sperren setzt die Degradierung zurück.

LLMs sind bemerkenswerte Generatoren. Sie sortieren 1.000 Wörter mit 97,7% Genauigkeit durch reine Kognition. Menschen können das nicht. Aber alles unter 100% bricht unter Wiederholung zusammen. 0,977 zum Quadrat ist 0,954.

Coding-Agenten funktionieren nicht, weil das Modell klug ist. Sie funktionieren, weil deterministische Gates in der Schleife sitzen. Sie scheitern, weil diese Gates fehlen.

Generierung kann probabilistisch sein. Verifikation muss deterministisch sein.

Quellen

Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Shannon, C.E. & McCarthy, J. (Eds.), Automata Studies, Annals of Mathematical Studies, No. 34, Princeton University Press, pp. 43-98.
Saltzer, J.H., Reed, D.P., & Clark, D.D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems, 2(4), 277-288.
Patterson, D.A., Gibson, G., & Katz, R.H. (1988). “A Case for Redundant Arrays of Inexpensive Disks (RAID).” Proceedings of the 1988 ACM SIGMOD International Conference on Management of Data, pp. 109-116.
Hamming, R.W. (1950). “Error Detecting and Error Correcting Codes.” The Bell System Technical Journal, 29(2), 147-160.
Yao, S. et al. (2023). “ReAct: Synergizing Reasoning and Acting in Language Models.” ICLR 2023.
Shinn, N. et al. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023.
Jimenez, C.E. et al. (2024). “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024.
Yang, J. et al. (2024). “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” NeurIPS 2024.
Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024.
Kamoi, R. et al. (2024). “When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs.” TACL, 12, 1298-1318.
Cemri, M. et al. (2025). “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657.
Arbuzov, M.L., Shvets, A.A., & Beir, S. (2025). “Beyond Exponential Decay: Rethinking Error Accumulation in Large Language Models.” arXiv:2505.24187.