Image: AI generated
Wenn Ihr KI-Agent sagt “fertig”, aber es eigentlich nicht ist, wenn der Agent schwierige Aufgaben ueberspringt, wenn Sie wollen, dass eine Maschine – und nicht ein Mensch – die Fertigstellung beurteilt – dieser Artikel erklaert diese Struktur.
“Alles erledigt”
Ich beauftragte einen KI-Agenten, Tests für 527 Funktionen zu schreiben. Der Agent beendete seine Arbeit und meldete:
“Fertig.”
Tatsächlich geschriebene Tests: 40 Funktionen.
Er hat nicht gelogen. Nach 40 kam er zu dem Schluss: “Das reicht.” Bei schwierigen Funktionen übersprang er einfach, machte noch ein paar und entschied: “Der Rest folgt dem gleichen Muster — passt schon.”
LLMs sind gut im Generieren. Aber ihre Einschätzung, ob etwas fertig ist, ist unzuverlässig. Huang et al. wiesen experimentell nach, dass die Selbstkorrektur von LLMs ohne externes Feedback die Leistung tatsächlich verschlechtern kann[1].
Die Ratsche
Eine Ratschenknarre hat Zähne, die nur in eine Richtung greifen. Dreht man, geht es vorwärts. Lässt man los, bleibt es stehen — aber es geht nie zurück.
Ratchet Pattern überträgt diesen Mechanismus auf die Agentensteuerung. Verifizierungscode, der nach diesem Pattern geschrieben wird, heißt ratchet code — Code, der niemals eine Regression unter ein zuvor bestandenes Verifikationsniveau zulässt.
Punkt 1: Maschinelle Prüfung → PASS → Weiter
Punkt 2: Maschinelle Prüfung → FAIL → Erneuter Versuch (mit Feedback)
Punkt 2: Maschinelle Prüfung → PASS → Weiter
...
Punkt N: PASS → Fertig. Stopp.
Drei Regeln:
- Zeige immer nur einen Punkt gleichzeitig.
- Erst bei Bestehen wird der nächste freigegeben.
- Wenn alles bestanden ist, wird gestoppt.
Implementiert man diese Regeln als CLI, muss der Agent nur einen einzigen Befehl kennen: next. Alles andere entscheidet die Maschine.
Der Agent stoppt bei 40, die Ratsche schafft 527
Dasselbe Modell. Dasselbe Projekt. Dieselben 527 Funktionen.
Autonomer Agent: 40 / 527 (7,6%) — Agent erklärt "Fertig"
Ratchet CLI: 527 / 527 (100%) — Maschine erklärt "Noch 487 übrig"
Der Unterschied liegt nicht in der Leistung des Modells. Es geht darum, wer “Ende” bestimmt.
Beim autonomen Agenten entscheidet das LLM über den Abbruch. LLMs sind optimistisch. Nach 40 “fühlt” es sich ausreichend an. In der Trace-Analyse von 1.600 Agentenläufen durch Cemri et al. machte die vorzeitige Terminierung — die Zielerreichung zu deklarieren, bevor sie tatsächlich erreicht war — 6,2 % aller Fehlermodi aus[2]. Bei der Ratsche entscheidet die Maschine über den Abbruch. Die Maschine fühlt nichts. Bis die Zahl der verbleibenden Punkte bei 0 steht, lautet das Urteil: “Noch nicht.”
Definition in einem Satz
Einen probabilistischen Agenten in eine deterministische Zustandsmaschine einbetten.
| Rolle | Zuständigkeit |
|---|---|
| Generierung | LLM |
| Bewertung | verifier |
| Fortschrittskontrolle | ratchet |
Viele Systeme überlassen Generierung, Bewertung und Abbruchentscheidung komplett dem LLM. Ratchet trennt diese Verantwortlichkeiten.
Fünf Prinzipien
1. Die Abbruchbedingung ist maschinell
pass/fail. Nicht “looks good”. Wenn go test besteht: PASS. Wenn coverage 100% erreicht: PASS. Kein Raum für subjektive Einschätzungen.
2. PASS ist unveränderlich
Bestandene Punkte werden nicht wieder geöffnet. Kein Zurückdrehen. Die Zahl der verbleibenden Punkte sinkt monoton.
remaining_work(t+1) ≤ remaining_work(t)
Was heute gebaut wurde, wird morgen nicht wieder aufgerissen. Es geht nur vorwärts. Das ist der fundamentale Unterschied zum “24-Stunden-Agenten”. Ein Agent ohne Abbruchbedingung entfernt morgen die Abstraktion, die er heute hinzugefügt hat, und fügt sie übermorgen wieder hinzu. Die Ratsche lässt solche Oszillationen nicht zu.
3. Das LLM generiert nur
Code generieren, Tests schreiben, Änderungsvorschläge machen — das ist die Rolle des LLM. Was geändert werden soll, ob es bestanden ist, was als Nächstes kommt, ob es fertig ist — all das entscheidet die Maschine. Das LLM ist kein planner, sondern ein constrained generator.
4. Dem Agenten wird das Recht auf Abbruchentscheidung entzogen
Wenn das LLM “fertig” sagt, stoppt es bei 40. Wenn die Maschine “fertig” sagt, stoppt es bei 527. Der Daseinszweck der Ratsche lässt sich in diesem einen Satz zusammenfassen.
5. Der Verifier muss deterministisch sein
Nicht alles kann ein verifier sein.
| Geeignet | Ungeeignet |
|---|---|
go test | “looks cleaner” |
| coverage-Messung | “seems better” |
| AST validation | “more scalable” |
| schema diff | “clean architecture” |
Bedingungen für einen Verifier: deterministic, machine-checkable, resumable, localized feedback. Wenn diese vier Kriterien nicht erfüllt sind, greifen die Zähne der Ratsche nicht.
Feedback als gradient signal
Wenn die Ratsche nur “bestanden/nicht bestanden” zurückgibt, korrigiert das LLM ohne Richtung. Je konkreter das Feedback, desto präziser die Korrektur des LLM.
Schwaches Feedback: "Test fehlgeschlagen" → LLM korrigiert ohne Richtung
Mittleres Feedback: "Coverage 65%" → LLM verstärkt ungefähr
Starkes Feedback: "Zeile 41, 44, 70 nicht abgedeckt" → LLM deckt genau diese Zweige ab
In der Praxis verifizierte Zahlen:
Ohne Feedback: Bleibt bei 60–70% Coverage stehen
Mit Feedback: 100% erreicht (bei erreichbaren Funktionen)
Dasselbe Modell. Eine einzige Zeile “line 41 not covered” fungiert als gradient signal. Die Self-Debug-Forschung von Chen et al. bewies, dass iteratives Debugging durch Zurückführen von Compiler-/Runtime-Fehlermeldungen an das Modell die Code-Genauigkeit dramatisch verbessert[3].
Je höher die Auflösung des Feedbacks, desto genauer die Korrekturen des LLM, desto weniger Schleifendurchläufe, desto geringer die Kosten.
Agenten sterben. Der Fortschritt überlebt.
Agenten brechen unweigerlich ab. Token-Limit, Netzwerkfehler, Sitzungsabbruch. Wenn die Ratsche den Fortschrittsstatus persistent speichert, kann der nächste Agent dort weitermachen, wo der vorherige aufgehört hat.
Agent A: Funktionen 1–200 bearbeitet → stirbt
Agent B: next → Macht bei 201 weiter
Agent C: next → Macht bei 401 weiter
Agenten sind Einwegprodukte. Fortschritt akkumuliert sich.
Verifier austauschen — anderes Werkzeug
Die Ratsche ist nicht an einen bestimmten Verifier gebunden. Tauscht man den Verifier aus, entsteht ein anderes Werkzeug.
| Ratsche + Verifier | Einsatzzweck |
|---|---|
Ratsche + go test + coverage | Funktionsweise Testgenerierung |
| Ratsche + Strukturregel-Validator | Code-Struktur-Bereinigung |
| Ratsche + hurl pass/fail | API-Endpunkt-Verifizierung |
| Ratsche + Spezifikations-Kreuzvalidierung | SSOT-Konsistenz sicherstellen |
| Ratsche + Toulmin verdict | Benutzerdefinierte Regeln erzwingen |
Das Pattern ist eines. Der Verifier bestimmt die Domäne.
Fragen
Wie viele Punkte hat Ihr Agent abgeschlossen, bevor er “Alles erledigt” sagte?
War das wirklich alles?
Wer hat “Ende” entschieden — der Agent oder die Maschine?
Verwandte Artikel
- Modell-IQ vs. Feedback-Topologie — Der theoretische Hintergrund des Ratchet Pattern. Warum Feedback-Struktur wichtiger ist als Modellleistung.
- tsma — Implementierung des Ratchet Pattern für Go-Tests. 527 Funktionen, null TODO.
- filefunc — Implementierung des Ratchet Pattern für Code-Struktur. typer refaktoriert, alle 1155 Tests bestanden.
Quellen
[1] 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. arXiv:2310.01798
[2] Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Tanay Chopra, Aditya Tiwari, Kurt Keutzer, Aditya Parameswaran, et al. “Why Do Multi-Agent LLM Systems Fail?” NeurIPS 2025 Datasets and Benchmarks Track. arXiv:2503.13657
[3] Xinyun Chen, Maxwell Lin, Nathanael Scharli, Denny Zhou. “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128
[4] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” NeurIPS 2023. arXiv:2303.11366
[5] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. “Self-Refine: Iterative Refinement with Self-Feedback.” NeurIPS 2023. arXiv:2303.17651
[6] 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. DOI:10.1126/science.abq1158
[7] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” ICLR 2024. arXiv:2310.06770
Änderungsverlauf
- 2026-05-15: Erstveröffentlichung