Ratchet Pattern

“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.


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.

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. 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.

RolleZuständigkeit
GenerierungLLM
Bewertungverifier
Fortschrittskontrolleratchet

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.

GeeignetUngeeignet
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.

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 + VerifierEinsatzzweck
Ratsche + go test + coverageFunktionsweise Testgenerierung
Ratsche + Strukturregel-ValidatorCode-Struktur-Bereinigung
Ratsche + hurl pass/failAPI-Endpunkt-Verifizierung
Ratsche + Spezifikations-KreuzvalidierungSSOT-Konsistenz sicherstellen
Ratsche + Toulmin verdictBenutzerdefinierte 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?


Verwandter Artikel: Modell-IQ vs. Feedback-Topologie — Der theoretische Hintergrund des Ratchet Pattern. Warum Feedback-Struktur wichtiger ist als Modellleistung.