Loop Engineering: Schleifen gewinnen dort, wo Verifikation billig ist

Boris Cherny, der Ingenieur, der Claude Code geschaffen hat, hält tagsüber fünf bis zehn Sitzungen mit ein paar Hundert laufenden Agenten offen und lässt jede Nacht ein paar Tausend laufen.² Als sich in der vergangenen Woche ein Clip auf X verbreitete, in dem er sagt „Ich prompte Claude nicht mehr … meine Aufgabe ist es, Schleifen zu schreiben”, behandelten die meisten Kommentare diesen Satz als Prophezeiung über autonome Softwareentwicklung, und binnen weniger Tage hatte Addy Osmani eine ganze Disziplin danach benannt: Loop Engineering.⁷ Ich habe mir die vollständigen Transkripte der drei Vorträge beschafft, aus denen der Clip stammt. Die Transkripte erzählen eine leisere Geschichte, und es ist die leise Fassung, auf der sich aufbauen lässt: Jede Schleife, die Cherny tatsächlich benennt, hat eine Erfolgsbedingung, die eine Maschine kostenlos prüfen kann. Über das, was Sie automatisieren können, entscheiden nicht die Schleifen selbst, sondern die Kosten der Verifikation. Ich lasse seit Februar Schleifen produktiv laufen, und meine Logs decken sich mit den Transkripten – einschließlich zweier Vorfälle, in denen sie mich die Lektion auf die harte Tour gelehrt haben.

TL;DR / Die wichtigsten Erkenntnisse

• Das virale Zitat stammt aus Chernys Interview bei Acquired Unplugged, wo er Schleifen als nächsten Schritt auf einem Kontinuum von Lochkarten über Assembler und Hochsprachen bis zum Prompten einordnet.¹ Diesem Übergang gibt er nur eine kurze Haltbarkeit: „die nächsten paar Monate und vielleicht den Rest des Jahres.”¹
• Die Mechanik ist bewusst banal. In seinem Sequoia-Vortrag beschreibt Cherny /loop als Claude, das per cron einen sich wiederholenden Job plant.² Seine benannten Schleifen hüten Pull Requests, halten die CI gesund und gruppieren alle 30 Minuten Twitter-Feedback.²
• Jede dieser Schleifen ist Hausmeisterarbeit. Jede hat einen maschinell prüfbaren Endzustand: CI grün, PR rebased, Feedback geclustert. Keines seiner benannten Beispiele baut unbeaufsichtigt Funktionen.
• Die Aufgabe, Schleifen zu schreiben, löst sich bereits im Modell auf. Cherny berichtet, dass neuere Modelle von sich aus Schleifen starten, und er bezeichnet das Schreiben von Schleifen auf Nutzerseite als „ein Produktdesign-Problem”, das bedeutet: „Ich mache meine Arbeit nicht gut.”⁵
• Die bleibende Fähigkeit unter dem Meme: zu entscheiden, was sich gefahrlos unbeaufsichtigt automatisieren lässt. Diese Entscheidung ist ein Urteil über Verifizierbarkeit, und sie bleibt Ihnen erhalten, auch nachdem die Schleifensyntax verschwunden ist.

Was er tatsächlich sagte

Der Clip, den alle teilten, stammt aus einem Live-Interview bei Acquired. Cherny leitet den Satz mit Familiengeschichte ein: Sein Großvater programmierte in der Sowjetunion mit Lochkarten, und sein Vater schrieb Assembler und „hätte sich über mich lustig gemacht, weil ich Python schreibe.” Dann kam der Teil, der die Runde machte:

„Das ist sozusagen das Wesen der Programmierung: Die Abstraktionsebene steigt immer weiter … So, wie ich vor einem Jahr programmiert habe, schrieb ich Code mit einer Art Autovervollständigung in einer IDE. Im November habe ich meine IDE deinstalliert, weil ich sie nicht mehr benutzte … Zu dem Zeitpunkt ließ ich vielleicht fünf, zehn Claude-Instanzen parallel laufen, und mein Programmieren bestand darin, Claude zu prompten, Code zu schreiben. Jetzt ist es noch eine Stufe höher gegangen … wo ich Claude gar nicht mehr prompte. Ich habe Schleifen, die laufen. Sie sind es, die Claude prompten und gewissermaßen herausfinden, was zu tun ist. Meine Aufgabe ist es, Schleifen zu schreiben.”¹

Das vollständige Acquired-Unplugged-Interview; die Passage über Schleifen beginnt bei 11:14.

Zwei Details aus dem vollständigen Transkript schafften es nie in die Clips. Erstens datiert Cherny den Übergang selbst: Schleifen seien das, was „wir in den nächsten paar Monaten und vielleicht über den Rest des Jahres sehen werden.”¹ Er beschreibt eine Phase, kein Ziel. Zweitens, ein Quellenhinweis für alle, die den Diskurs zurückverfolgen: Mehrere virale Posts schrieben das Schleifen-Material seinem einstündigen Auftritt im Y-Combinator-Podcast zu. Ich habe das vollständige Transkript dieser Episode geprüft. Es enthält keine einzige Erwähnung von Schleifen; die Episode behandelt die Entstehungsgeschichte des Produkts und Sub-Agenten.⁶ Der Kern steckt im Acquired-Interview und einem 24-minütigen Sequoia-Vortrag.

Eine Schleife ist ein Cron-Job

Der Sequoia-Vortrag liefert die Mechanik, und sie ist bewusst nüchtern:

„Mehr ist es nicht: Claude nutzt cron, um einen Job für irgendeinen Zeitpunkt in der Zukunft zu planen, und es ist ein wiederkehrender Job. Er kann jede Minute laufen, alle fünf Minuten, jeden Tag.”²

Der Sequoia-Vortrag liefert jedes mechanische Detail, das die viralen Clips ausließen; der Schleifen-Abschnitt beginnt bei 7:56.

Cherny lässt Dutzende davon laufen. Die, die er namentlich nennt: eine Schleife, die seine PRs hütet (CI repariert, automatisch rebased), eine Schleife, die die CI gesund hält (sie repariert instabile Tests), und eine Schleife, die alle 30 Minuten Feedback von Twitter zieht und gruppiert.² Routines, vorgestellt auf Anthropics Veranstaltung „Code with Claude” im Mai, verlagert dasselbe Muster auf die Serverseite, sodass die Schleife auch ein geschlossenes Laptop überlebt.² Simon Willison, der die Keynote live bloggte, hielt die Einordnung fest, die Anthropic selbst verwendet: Routines seien „higher-order prompts”.¹² Cherny hatte den Leuten seit Monaten erzählt, dass /loop und /schedule zwei der mächtigsten Funktionen im Produkt seien; sein kanonischer Einstieg ist eine Fünf-Minuten-Schleife, die PRs hütet.¹¹

Das Muster hat einen gröberen Vorfahren. Geoffrey Huntleys Ralph-Wiggum-Technik ist, in seinen eigenen Worten, „Ralph ist eine Bash-Schleife”: eine while true-Schleife, die einem Agenten endlos dieselbe Prompt-Datei vorlegt, wobei der Fortschritt zwischen den Iterationen in Dateien und der Git-Historie erhalten bleibt.⁹ Anthropic liefert Ralph inzwischen als offizielles Plugin aus, das die Beendigungsversuche des Agenten abfängt und den Prompt erneut einspeist, bis ein Abschluss-String erscheint oder eine Iterationsobergrenze erreicht ist.⁹ The Register bestätigte, dass Cherny Ralph selbst verwendet, und zitierte Huntleys Warnung, wohin die Ökonomie führt: Start-ups werden die Technik nutzen, um bestehende SaaS-Unternehmen zu klonen und zu unterbieten, weil agentisches Programmieren für rund 10 Dollar pro Stunde läuft.¹⁰ Die Abstammung ist wichtig, weil sie das tatsächliche Alter der Idee zeigt: Die Schleife ist die älteste Kontrollstruktur in der Informatik, und an dem Konstrukt selbst ist nichts neu.¹⁵

Jede Schleife, die er nennt, ist Hausmeisterarbeit

Hier ist die Beobachtung, die der Diskurs übersprungen hat. Zählen Sie Chernys Schleifen noch einmal auf und sehen Sie sich ihre Endzustände an:

Jede hat entweder eine maschinell prüfbare Erfolgsbedingung oder erzeugt eine Ausgabe, bei der Fehler nichts kosten. Keines seiner benannten Beispiele lautet „bau die Funktion, während ich schlafe.” Der Mann, der jede Nacht ein paar Tausend Agenten laufen lässt, beschreibt seine persönliche Automatisierung als CI-Reparatur, Rebasing und Feedback-Triage.

Das scheinbare Gegenbeispiel bestätigt die Regel. Anthropics eigenes Engineering-Team ließ 16 Agenten zwei Wochen lang in Endlosschleifen laufen und produzierte einen C-Compiler in Rust mit 100.000 Zeilen, zu Rechenkosten von rund 20.000 Dollar.⁸ Ein Compiler ist das am besten verifizierbare Artefakt in der Software überhaupt: eine riesige Testsuite aus Programmen, die entweder korrekt kompilieren und laufen oder eben nicht. Das Team wählte ein Ziel, bei dem die Verifikation nahezu kostenlos ist, und selbst dann schrieb Nicholas Carlini, der das Experiment leitete, dass es „ein echtes Problem” sei, wenn Programmierer Software ausliefern, die sie nie persönlich verifiziert haben.⁸

Addy Osmanis Essay, der die Disziplin „Loop Engineering” tauft, landet von der Designseite her bei derselben Einschränkung: „Eine unbeaufsichtigt laufende Schleife ist auch eine Schleife, die unbeaufsichtigt Fehler macht.”⁷ Seine vorgeschlagene Architektur (getrennte Verifizierer-Agenten, damit der Erzeuger nie seine eigene Arbeit benotet) ist ein Versuch, billige Verifikation dort herzustellen, wo sie nicht von Natur aus entsteht.⁷

Was mich meine eigenen Schleifen lehrten

Im Februar habe ich über mein nächtliches Agentensystem geschrieben, damals, als der höfliche Begriff für die Technik noch eine Simpsons-Anspielung war.¹⁶ Seitdem konvergierten alle Schleifen, die in meinem Setup überlebten, auf dieselbe Form, und die, die scheiterten, lehrten mich mehr als die, die funktionierten.

Die Überlebenden haben die Form einer Prüfung. Eine nächtliche Schleife liest die Commits des Tages, ordnet die berührten Dateien live geschalteten URLs zu, lädt jede betroffene Seite und meldet mit Ladezeiten, ob sie besteht oder fehlschlägt. Eine Sicherheitsschleife beobachtet über Nacht Endpunkte und schreibt ein Morgenbriefing. Eine Crawl-Schleife liest die Googlebot- und Bingbot-Aktivität über meine Properties hinweg und meldet Drift in der Indexierung. Keine davon erzeugt etwas. Jede beobachtet, vergleicht mit einem erwarteten Zustand und meldet. Wenn eine fehlzündet, kostet das einen veralteten Bericht, kein kaputtes Produkt. Die morgendliche Lektüre dauert Minuten, weil die Ausgabe pro Eintrag binär ist: bestanden, fehlgeschlagen, hier nachsehen.

Die Fehlschläge waren Schleifen, die handelten. Eine Isolations-Funktion, die automatisch Git-Worktrees für parallele Agenten anlegte, löschte zweimal Scratch-Verzeichnisse, die sie für entbehrlich hielt; die Reichweite der Automatisierung umfasste Dateien, die sie nicht erstellt hatte und nicht verstand. Eine geplante Cache-Bereinigung lief einmal in der falschen Reihenfolge relativ zu einem Deploy, und Such-Crawler erhielten 11 Stunden lang 404-Fehler für Seiten, die existierten, weil die Bereinigung korrekte zwischengespeicherte Antworten verdrängte, bevor der Origin-Server ihren Ersatz auslieferte.¹⁶ Keiner der beiden Fehlschläge kam von einem schlechten Modell. Beide kamen daher, dass ich einer Schleife Schreibzugriff gewährte, deren Vorbedingungen ich nicht festgenagelt hatte. Jede hat jetzt eine Schutzvorrichtung: Die Worktree-Automatisierung ist rundweg blockiert, und Bereinigungen laufen erst, nachdem die Deploy-Verifikation bestanden ist. Die allgemeine Regel, die ich daraus zog: Eine Schleife, die nur liest, braucht einen Zeitplan; eine Schleife, die schreibt, braucht einen Reihenfolgenachweis und eine Begrenzung ihrer Reichweite, bevor sie sich den Zeitplan verdient.

Diese Regel erklärt auch den Teil von Chernys Setup, den die Leute am schwersten glauben können. „Tatsächlich erledige ich inzwischen die meiste Arbeit von meinem Handy aus”, sagt er und führt Sitzungen über den Code-Tab in der Claude-App.² Ein Handy ist ein schrecklicher Ort, um Code zu prüfen, und ein guter Ort, um einen Bestanden/Fehlgeschlagen-Bericht zu lesen. Die Handy-Behauptung ist eine verkappte Verifikationsbehauptung: Seine Schleifen liefern eine Ausgabe, die klar genug ist, um sie auf einen Blick anzunehmen oder abzulehnen – was nur möglich ist, wenn die Erfolgsbedingungen entworfen wurden, bevor die Schleife zu laufen begann.

Die Leiter der Verifikationskosten

Wenn die These hält, reduziert sich die Wahl, was zu automatisieren ist, auf eine Frage: Wer verifiziert das Ergebnis, und was kostet diese Verifikation? Hier ist die Leiter, die ich heranziehe, bevor irgendeine Aufgabe einen Zeitplan bekommt.

Die entscheidende Spalte ist die zweite, und der Schwierigkeitsgrad der Aufgabe taucht darin nie auf. Eine schwere Aufgabe mit einem kostenlosen Verifizierer (der instabile Test) wird vor einer leichten Aufgabe mit einem teuren automatisiert (eine einzeilige Textänderung, die ein Mensch freigeben muss). Chernys Schleifen, Anthropics Compiler und meine Überlebenden sitzen alle in der oberen Hälfte der Leiter; der virale Kommentar nahm die untere Hälfte an.

Die Form, die die Leiter übersteht, sieht wie ein einziges Aufseher-Muster aus, unabhängig vom Maßstab:

Die Anatomie einer Schleife, die sich ihren Zeitplan verdient. Der Verifizierer ist kräftiger gezeichnet, weil er der tragende Kasten ist: Entfernen Sie ihn, und die Schleife läuft weiter, aber niemand weiß, was sie getan hat.

Die kleinste Schleife, die sich zu betreiben lohnt, ist nur lesend, selbstprüfend und auf einen Blick erfassbar – was sie sicher macht, sie heute zu schreiben, und langweilig, sie morgen zu beobachten:

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Innerhalb von Claude Code ist dieselbe Schleife eine Zeile: /loop 24h gefolgt von der Anweisung. Die Beförderung kommt später. Nachdem der Bericht einen Monat lang langweilig war, hat sich die Schleife eine Erwägung für die nächste Sprosse der Leiter verdient – und nicht früher.

Die Aufgabe, die übrig bleibt

Die seltsamste Passage im Sequoia-Vortrag untergräbt das Meme, das sie hervorbrachte. Cherny sagt, neuere Modelle hätten begonnen, Schleifen zu starten, ohne dass man sie darum bat: Er fordert eine Datenabfrage an, das Modell bemerkt, dass sich die Daten im Laufe der Zeit ändern, schlägt alle 30 Minuten einen wiederkehrenden Bericht vor und verdrahtet den Bericht von sich aus in Slack.⁵ Seine Schlussfolgerung: „Es ist nicht Aufgabe der Nutzer, herauszufinden, wie sie die Werkzeuge besser halten … es ist eigentlich ein Produktdesign-Problem, und ich mache meine Arbeit nicht gut.”⁵ Das Regress-Argument, das Skeptiker auf X aufwarfen (wenn heute Menschen Schleifen schreiben, schreiben morgen Modelle die Schleifen), erweist sich als Anthropics Fahrplan, eingeräumt von genau der Person, um die sich das Meme dreht.

Er geht noch weiter: „Mit besser werdendem Modell wird der Agentenrahmen tendenziell weniger wichtig”, und sagt voraus, dass Berechtigungsmodi, Abwehrmaßnahmen gegen Prompt-Injection und Mensch-im-Kreislauf-Kontrollpunkte mit besserer Ausrichtung verblassen.³ Bei der Hälfte dieses Tauschs nehme ich die Gegenseite ein. Das Sicherheitsgerüst mag schrumpfen. Das Orchestrierungsgerüst wird nach seiner eigenen Darstellung zur ganzen Aufgabe: Die Agenten der Anthropic-Ingenieure koordinieren sich über Slack miteinander, während ihre Besitzer arbeiten, und „wir haben nirgendwo im Unternehmen mehr manuell geschriebenen Code. Das gesamte SQL wird von Modellen geschrieben.”⁴ Irgendjemand entscheidet, was diese Agenten anfassen dürfen, was als erledigt gilt und was passiert, wenn zwei von ihnen uneins sind. Diese entscheidende Schicht ist die eigentliche Agenten-Schnittstelle, und cron ist der einfache Teil davon.

Die bleibende Fähigkeit ist also nicht die Schleifensyntax, die das Modell bereits aufsaugt, und nicht das Prompten, das die Schleifen zuerst aufgesogen haben. Die bleibende Fähigkeit ist die Urteilsentscheidung, die unter beiden liegt: zu entscheiden, was sich gefahrlos unbeaufsichtigt automatisieren lässt. Diese Entscheidung ist immer eine Frage nach den Verifikationskosten. CI-Reparatur wurde zuerst automatisiert, weil die Testsuite bereits der Verifizierer war. Feedback-Clustering wurde automatisiert, weil Fehler kostenlos sind. Die Funktionsentwicklung sträubt sich, weil die Verifikation noch einen Menschen kostet, der das Diff liest, und ein erfahrener Ingenieur auf Hacker News brachte die daraus folgende Falle unverblümt auf den Punkt: Das Werkzeug erfordert geschultes Urteilsvermögen, um es zu steuern, und der Gebrauch des Werkzeugs untergräbt genau dieses Urteilsvermögen.¹⁴

Casey Newtons Platformer-Interview mit Cherny lief unter der Überschrift „Claude Codes Schöpfer über das Ende des Software-Ingenieurs”. Darin sagt Cherny voraus, dass sich der Titel „Software-Ingenieur” bis zum Jahresende in etwas wie „Builder” auflöst, während die Zahl der Menschen, die über Agenten Code schreiben, um das Hundertfache wächst.¹³ Builder sind in dieser Prognose die Menschen, die die Schleifen wählen. Gut zu wählen heißt zu wissen, bevor irgendetwas läuft, woran Sie erkennen werden, dass es funktioniert hat.

Die wichtigsten Erkenntnisse

Für Ingenieure, die Coding-Agenten betreiben: - Prüfen Sie Ihre Automatisierungskandidaten nach Verifikationskosten, nicht nach Aufregung. CI-Reparatur, Rebasing, Überwachung und Berichterstellung haben heute kostenlose Verifizierer; automatisieren Sie diese zuerst. - Wenden Sie die Lesen/Schreiben-Trennung an: Eine nur lesende Schleife braucht einen Zeitplan, während eine Schleife mit Schreibzugriff eine explizite Reihenfolgenbedingung und eine Reichweitenbegrenzung braucht, bevor sie unbeaufsichtigt läuft. - Entwerfen Sie den Bericht vor der Schleife. Wenn Sie die Ausgabe der Schleife nicht in 10 Sekunden von Ihrem Handy aus ablehnen können, ist die Schleife nicht bereit, nachts zu laufen.

Für Team-Leads: - Ihre Prüfkapazität, nicht Ihre Agentenanzahl, ist die Obergrenze für nützliche Parallelität. Agenten über diese Obergrenze hinaus hinzuzufügen erzeugt ungeprüfte Merges, keinen Durchsatz. - Trennen Sie Erzeuger von Prüfern. Ein Agent, der seine eigene Arbeit verifiziert, behauptet Korrektheit; ein separater Verifizierer mit einem anderen Blickwinkel hat zumindest eine Chance, die Behauptung zu entlarven.

Für Werkzeugbauer: - Cherny nennt das Schreiben von Schleifen auf Nutzerseite ein Produktdesign-Versagen, und die Modelle starten Schleifen bereits selbst.⁵ Eine UX zum Verfassen von Schleifen zu bauen, heißt für eine Schicht zu bauen, die der Modellanbieter absorbieren will. Die langlebigere Oberfläche ist die Verifikation: Evidenz, Ablaufspuren und die Ergonomie des Annehmens/Ablehnens.

FAQ

Quellen