Zuletzt aktualisiert am 27. Juli 2026 vom Editorial Team. Ursprünglich auf Towards AI veröffentlicht.

„My job is to write loops.“

Diese Aussage stammt von Boris Cherny, der Claude Code bei Anthropic leitet. Cherny hat gesagt, dass er aufgehört habe, Claude direkt zu prompten, und nun seine Zeit damit verbringe, die Loops zu entwerfen, die Claude für ihn prompten [1]. Die Bemerkung löste zusammen mit mehreren ähnlichen Kommentaren in diesem Jahr eine Welle von Erklärstücken zu Loop Engineering aus [1][2]. Nachdem ich sechs davon gelesen hatte, baute ich selbst einen solchen Loop.

Genauer gesagt baute ich die zwei Komponenten, die fast jedes Erklärstück beschreibt, die aber offenbar nur wenige wirklich Ende zu Ende ausführen. Die erste war eine Run-until-done-Schleife: Statt das Modell nach einem Fehlschlag erneut raten zu lassen, erhält es seine eigenen echten Testfehler. Die zweite war ein Maker/Checker-Setup: Das Modell, das den Code schreibt, darf nicht der endgültige Richter darüber sein, ob der Code korrekt ist.

Diese Unterscheidung ist wichtig, weil Workflows von Coding-Agenten häufig auf derselben Trennung beruhen: Ein System schlägt eine Änderung vor, während ein anderes Tool, eine Testsuite oder ein Modell entscheidet, ob die Änderung akzeptabel ist. Wenn der Feedback-Kanal oder der Verifizierer schwach ist, kann der Loop automatisiert wirken, ohne tatsächlich nennenswert sicherer zu werden.

Ich implementierte beides von Grund auf in etwa 600 Zeilen Python, verband es mit claude-opus-4-8 und evaluierte es anhand von MBPP+ [3]. MBPP+ ist ein EvalPlus-Benchmark für kleine Python-Programmieraufgaben, wodurch er nützlich war, um Loop-Verhalten zu isolieren, ohne Komplikationen auf Repository-Ebene einzubeziehen. Die Gesamtkosten über alle hier diskutierten Experimente hinweg lagen unter zwei Dollar. Die zweite Komponente — die oft als die sicherere Hälfte behandelt wird, weil sie „tatsächlich Tests ausführt“, statt dem Wort des Modells zu vertrauen — lieferte in meinen Messungen Ergebnisse, vor denen diese Erklärstücke nicht gewarnt hatten.

Die Kurzfassung: Die zwei Kernbestandteile von Loop Engineering sind einfach zu verbinden und leicht unbemerkt falsch umzusetzen. Meine „echte Feedback“-Schleife sah zunächst nicht von zufälligen Wiederholungsversuchen zu unterscheiden aus, bis ich einen Fehler in meinem eigenen Test-Harness fand. Mein „sicherer“ testausführender Verifizierer hatte eine höhere False-Accept-Rate als ein Checker, der das Modell lediglich fragte, wie zuversichtlich es sei. Den Loop zu bauen, ist die einfachen 20%.

Einen Loop ins Leere verdrahten

Ein Großteil der Texte über Loop Engineering endet beim Schaltbild. Es zeigt einen Auslöser, ein verifizierbares Ziel, Tools, Zustand und Stoppregeln — fünf Kästen mit Pfeilen dazwischen. Die implizite Botschaft lautet: Sobald die Kästen verbunden sind, funktioniert der Loop.

Das ist so, als würde man einen Rauchmelder installieren und das Haus für sicher erklären, weil der Melder an der Decke montiert und verkabelt ist, ohne zu prüfen, ob er eine funktionierende Batterie hat.

Genau auf dieses Problem stieß ich mit meiner „echte Feedback“-Schleife. Sie war mit der tatsächlichen Testausgabe verbunden, nicht mit einem generischen Retry-Prompt. Theoretisch hätte sie eine Schleife, die nur die Nachricht „that was wrong, try again“ erhielt, klar übertreffen müssen. Mein erster Lauf zeigte etwas anderes.

Der Grader, der den Grader bewertet

Bevor ich den Loop selbst anfasste, baute ich die Komponente, von der alles andere abhing: einen Scorer, der Kandidaten-Code in einem isolierten Subprozess mit hartem Timeout ausführt und ihn anhand versteckter Tests bewertet.

Ich vertraute dem Scorer erst, als er sich selbst bewertet hatte. Bei einer bekanntermaßen korrekten Lösung musste er bestehen. Bei einer bekanntermaßen falschen Lösung musste er fehlschlagen und den Assertion-Fehler anhängen. Bei einer Endlosschleife musste er durch das Timeout beendet werden, statt für immer zu hängen.

Anschließend validierte ich die gesamte Pipeline mit 75 MBPP+-Referenzlösungen. Alle 75 bestanden. Erst danach vertraute ich irgendeiner Zahl, die der Loop produzierte.

Der Loop, der korrekt aussah, es aber nicht war

Der Loop selbst war sehr einfach. Er erzeugte eine Lösung, bewertete sie und gab bei einem Fehlschlag den echten stderr zurück — nicht ein generisches „try again“, sondern den tatsächlichen Fehler — für bis zu drei Versuche.

Ich baute außerdem einen Kontrollarm, weil ich einer Schlagzeilenzahl ohne Basislinie nicht vertrauen wollte. Die Kontrolle nutzte den identischen Loop, ersetzte den echten Fehler jedoch durch eine generische Anweisung: „that was wrong, write a different solution.“ Wenn echtes Feedback diese Variante nicht klar übertraf, war etwas in der Verdrahtung defekt.

Beim ersten Lauf über 35 Probleme waren alle drei Arme identisch. Das war kein Beleg für einen funktionierenden Loop. Es war ein Warnsignal in Form eines Loops.

Statt mich auf die Topline-Kennzahl zu konzentrieren, untersuchte ich die Fehlschläge und fand das Problem: Der Hidden-Test-Harness von MBPP+ schlug mit einem bloßen AssertionError fehl. Er enthielt weder die fehlschlagende Eingabe noch den erwarteten Wert oder den tatsächlichen Wert. Dadurch war „echtes Feedback“ informationsseitig identisch mit „try again“, weil das Modell nichts erhielt, worauf es reagieren konnte.

Ich instrumentierte den Harness so, dass er die fehlschlagende Eingabe, die erwartete Ausgabe und den tatsächlich vom Code zurückgegebenen Wert meldete. Bei denselben 35 Problemen in einem zweiten Lauf löste echtes Feedback ein Problem, das der generische Arm nicht lösen konnte, zu Kosten von etwa 2.500 zusätzlichen Input-Tokens über den gesamten Lauf hinweg.

Der Loop war nicht defekt gewesen. Das Signal, mit dem er verbunden war, war leer. Nur der Kontrollarm machte das sichtbar; die Schlagzeilenkennzahl allein hätte es nicht getan.

Der Verifizierer scheiterte auf eine Weise, die die Theorie nicht vorhergesagt hatte

Ein Loop braucht eine Stoppregel, und „das Modell sagt, es sei fertig“ ist keine Stoppregel. Daher baute ich einen Checker, der aus der Spezifikation eigene Tests schreibt. Er sieht niemals die versteckten Tests und niemals den Lösungscode, den er bewertet. Anschließend führt er diese Tests aus. Die Regel lautete: nur bei einem vollständig sauberen Durchlauf akzeptieren und standardmäßig ablehnen.

Ich verglich diesen Verifizierer mit drei schwächeren Checkern anhand von 41 Kandidaten, die mein Loop erzeugt hatte: 33 korrekt und 8 falsch. Gemessen wurde die False-Accept-Rate, also wie oft ein Checker Code durchwinkt, obwohl der Code tatsächlich defekt ist.

Ich erwartete, dass der testausführende Checker bei False Accepts klar gewinnen würde. Das tat er nicht. Er ließ einen höheren Anteil falschen Codes durch als jeder der meinungsbasierten Checker.

Der Grund war wichtiger als die Zahl. Alle acht falschen Kandidaten stammten aus drei Problemen mit wirklich mehrdeutigen Spezifikationen. Der Checker und der Fixer waren dasselbe Modell, das denselben mehrdeutigen Satz las. Die selbst geschriebenen Tests des Checkers codierten daher dasselbe Missverständnis, das bereits im falschen Code steckte, wodurch der falsche Code diese Tests sauber bestand.

Die meinungsbasierten Checker „gewannen“ diesen False-Accept-Vergleich vor allem, weil sie generell zurückhaltend waren. Genau diese Zurückhaltung ist auch der Grund, warum sie vier- bis fünfmal mehr korrekten Code fälschlich ablehnten.

Tests auszuführen ist kein Freifahrtschein gegen False Accepts. Es ist eine andere Art von Evidenz: eine, die eine konkrete Eingabe, einen erwarteten Wert und einen tatsächlichen Wert enthält statt eines allgemeinen Eindrucks. Das macht ihre False-Reject-Rate von 3% als echtes Gate nutzbar. Ein Checker, der 15% guter Arbeit ablehnt, kann einen Workflow in Wiederholungsversuchen begraben, bevor er eine schlechte Zusammenführung verhindert.

Die zwei Teile kombinieren

Die finale Zusammensetzung führt zuerst die Feedback-Schleife aus. Wenn diese fehlschlägt, sampelt sie frische Kandidaten und lässt den Verifizierer — nicht das Vertrauen des Modells — entscheiden, was eingereicht wird. Sie enthält außerdem einen expliziten Aufgabepfad, falls nichts die Hürde nimmt.

Ich evaluierte dieses Setup auf einem zurückgehaltenen Ausschnitt von MBPP+, den ich beim Bau keiner der vorherigen Komponenten verwendet hatte. Die Bewertung erfolgte anhand der versteckten Tests, unabhängig davon, was der Verifizierer entschieden hatte.

Der Loop erledigte im Wesentlichen die gesamte Arbeit: Er fügte 14,2 Punkte hinzu, rettete fünf von sechs Single-Shot-Fehlschlägen und erforderte etwa 10 zusätzliche API-Aufrufe. Die Verifizierer-Stufe wurde genau einmal ausgelöst, bei dem einen Problem, das der Loop nicht lösen konnte. Der erste gesampelte Kandidat bestand seine eigenen selbst geschriebenen Tests und fiel dennoch bei den versteckten Tests durch.

Das war ein echter False Accept, passend zu dem Fehlermodus, den die frühere Tabelle vorhergesagt hatte. Er wurde nur erkannt, weil der Runner Einreichungen gegen eine Wahrheitsquelle bewertet, die der Verifizierer nie sieht. Wäre das eigene Urteil des Verifizierers endgültig gewesen, wäre dieser Bug ausgeliefert worden.

Die Gesamtkosten für diese Stufe betrugen 45 Aufrufe, also ungefähr dreizehn Cent.

Wo der Ansatz scheitert

Dieser Ansatz funktioniert, wenn das Ziel wirklich testbar ist: eine Funktion mit versteckten Testfällen, ein Schema, das entweder validiert oder nicht, oder ein Orakel, das der Loop nicht durch Argumentieren umgehen kann. Er funktioniert nicht, wenn die Spezifikation selbst mehrdeutig ist, weil ein Checker mit demselben Modell dasselbe Missverständnis wie der Generator übernehmen kann. In diesem Fall ist die Lösung nicht unbedingt ein raffinierterer Checker. Sie ist eine klarere Spezifikation oder ein unabhängiges Orakel aus einer völlig anderen Modellfamilie.

Ich habe dies außerdem nur an kleinen, eigenständigen MBPP+-Funktionen getestet. Das Experiment befasste sich nicht mit einer großen Codebasis mit dateiübergreifenden Abhängigkeiten. Ich habe keine Worktree-Isolation für das parallele Ausführen mehrerer Loops gebaut oder getestet. Das ist ein reales Problem, aber nicht das Problem, das dieses Experiment gemessen hat.

Der Loop endet außerdem bei „verifiziert“. Er entscheidet nicht, ob eine Änderung automatisch angewendet oder an einen Menschen eskaliert wird. Das wird zu einem separaten und schwierigeren Problem, sobald das System irgendetwas mit echten Schreibrechten berührt.

Hier anfangen

Beginnen Sie mit dem Grader. Schreiben Sie den Selbsttest — known-good, known-bad und infinite-loop — bevor Sie irgendeine Loop-Logik schreiben. Dieses Fünf-Minuten-Skript ist der wichtigste Schutz vor einer fiktiven Schlagzeilenzahl.

Für eine Codebasis mit selbst einer kleinen Menge an Unit-Tests sollten Sie als Nächstes die Feedback-Schleife verdrahten und den generischen Retry-Kontrollarm von Tag eins an daneben aufbauen. Vertrauen Sie der Verbesserung nicht, bevor sie „try again“ schlägt.

Bauen Sie danach einen zweiten Checker und vergleichen Sie ihn mit dem ersten. Wenn die False-Accept-Tabelle dem widerspricht, was die Theorie nahelegte — und das kann passieren —, wird der Grund zeigen, warum der Loop wichtiger ist als das Modell darunter.

References

[1] Rohan Mistry, “Prompt Engineering Is Dead. Loop Engineering Is Here.,” Towards AI, July 2026.

[2] Mehmet Özel, “Loop Engineering for AI Agents : Building Verifiable, Self-Correcting Coding Workflows,” Towards AI, June 2026.

[3] EvalPlus, “MBPP+ Dataset,” Hugging Face Datasets.