Letzten Dezember hat Boris Cherny in einem einzigen Monat 259 Pull Requests abgeschickt. Jeder einzelne von Claude geschrieben. Er sagt, er habe die ganze Zeit keinen Editor geöffnet.
Sein Job war es nicht, Code zu schreiben. Es war, das Ding zu schreiben, das den Code schreibt. Peter Steinberger hat es in zwei Zeilen zusammengefasst, die über 8 Millionen Mal gesehen wurden: „Du solltest keine Coding-Agenten mehr prompten. Du solltest Loops entwerfen, die deine Agenten prompten."
Das ist Loop Engineering. Du baust ein kleines System, das die Arbeit findet, sie an einen Agenten übergibt, das Ergebnis prüft und den nächsten Schritt entscheidet – und dann lässt du es laufen, während du schläfst.
Der Haken kam im selben Monat. Der Loop von jemand anderem lief elf Tage lang unbeaufsichtigt und verbrannte 47.000 Dollar, bevor es jemand bemerkte. Also sind das eigentlich zwei Fähigkeiten, und fast jeder lehrt nur die erste: einen Loop zu bauen, der Arbeit liefert – und die Bremsen zu bauen, die verhindern, dass er dich über die Klippe fährt.
Eine Frage entscheidet, welchen Loop du gebaut hast: Konvergiert er gegen etwas Wahres, oder ist er nur ein teurer Random Walk?
1. Ein Loop besteht aus sechs Teilen und einer Frage
Unter dem ganzen Lärm besteht ein funktionierender Loop aus sechs Teilen. Die Liste sieht beim ersten Hinsehen zu schlicht aus. Das Detail in jedem Teil entscheidet, ob ein Loop zusammenhält oder über Nacht Geld verliert.
Das alles baust du nicht mehr von Hand. Vor einem Jahr bedeutete ein Loop einen Haufen Shell-Skripte, die dir gehörten und die du für immer betreut hast. Jetzt stecken die Teile in den Produkten, und dieselben sechs bilden sich sowohl in der OpenAI Codex App als auch in Claude Code ab. Wenn du das einmal siehst, ist das Werkzeug nicht mehr das Argument, und der Loop wird zum Design.
1TEIL AUFGABE IM LOOP CODEX CLAUDE CODE2------------- --------------------------- ------------------------- --------------------------3State Erinnerung über Läufe hinweg markdown / Linear (MCP) markdown / Routines + MCP4Automations Laufen nach Zeitplan Automations-Tab + Triage /loop (Skill), Routines, /goal5Worktrees Parallele Agenten trennen Worktree pro Thread --worktree, isolation: worktree6Skills Deine Absicht kodieren ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Connectors An deine echten Tools MCP-Server (config.toml) MCP-Server (.mcp.json)8Sub-Agenten Macher von Prüfer trennen TOML in .codex/agents/ .claude/agents/ + Agententeams
2. State ist das Einzige, was der nächste Lauf erbt
Fang unten an, denn alles andere baut darauf auf.
Ein Modell vergisst, wenn ein Lauf endet. Der Chat stirbt, der Kontext wird gelöscht, der nächste Lauf wacht auf und weiß nichts. Die Erinnerung im Chat stirbt mit dem Lauf. Sie muss auf der Festplatte leben.
In der Praxis ist das eine Datei. Eine STATUS.md im Repository oder ein Linear-Board, das über einen Connector erreicht wird, das festhält, was erledigt ist, was in Arbeit ist, was als Nächstes kommt – und die Handvoll Dinge, die der Loop niemals anfassen darf.
1# STATUS.md (der Loop liest dies zuerst, schreibt es zuletzt)2## Erledigt3- [x] auth: Migration auf Tokens v2, Tests grün4## In Arbeit5- [ ] billing: Webhook-Refactoring (PR #214, CI rot)6## Als Nächstes7- [ ] dashboard: Flaky-Test in test/charts8## Niemals9- infra/ nicht ohne einen Menschen ändern
Behandle den Loop wie eine Nachtschicht, die du nie beobachtest. Du wirst nicht danach beurteilt, was er um 3 Uhr morgens gemacht hat. Du wirst nach der Notiz beurteilt, die um neun auf deinem Schreibtisch liegt. Entwirf diese Notiz zuerst, und der größte Teil des Loops entwirft sich von selbst.
3. Automations sind der Unterschied zwischen einem Loop und etwas, das du einmal ausgeführt hast
Ein Loop verdient den Namen nur, wenn er von alleine feuert.
In der Codex-App baust du einen im Automations-Tab: das Repository, der Prompt, der Rhythmus. Läufe, die etwas finden, landen in einem Triage-Posteingang; Läufe, die nichts finden, archivieren sich selbst. OpenAI nutzt das für das unglamouröse Rückgrat einer Codebasis: tägliches Issue-Triage, CI-Fehlerzusammenfassungen, das Erwischen eines Bugs, den jemand letzte Woche eingeschleust hat.
Claude Code erreicht das über ein paar Primitive, und die populären Zusammenfassungen werden mit den Details falsch, also lohnt es sich, genau zu sein. /loop ist ein Skill, kein eingebauter Befehl, und er wiederholt einen Prompt in einem Rhythmus, solange deine Sitzung geöffnet ist. Wiederkehrende Cloud-Jobs sind Routines, gesetzt mit /schedule, mit einem Minimum von einer Stunde, und sie laufen weiter, während dein Laptop zugeklappt ist. Es gibt keine lokale Crontab.
Der, den es zu lernen lohnt, ist /goal. Er läuft, bis eine von dir geschriebene Bedingung wahr ist, und nach jeder Runde prüft ein separates, kleineres Modell, ob du wirklich fertig bist. Der Agent, der den Code geschrieben hat, darf ihn nicht benoten.
1# Claude Code: Laufen, bis wirklich fertig, nicht bis es sich fertig anfühlt2/goal all tests in test/auth pass and the lint step is clean34# Claude Code: Ein wiederkehrender Cloud-Job (Minimum 1 Stunde)5/schedule daily PR triage at 9am67# Codex: Ein Automationsprompt (Rhythmus im Formular setzen)8"Weekdays 9am: scan open PRs, flag failing CI or no reviewer, post to Triage."
Schreibe die Stopp-Bedingung wie einen Vertrag. „Alle Tests in test/auth bestehen" ist ein Vertrag. „Mach es besser" ist, wie ein Loop bis zum Zahltag läuft.
4. Worktrees halten parallele Agenten aus dem Weg
Sobald du mehr als einen Agenten laufen lässt, ändert sich die Fehlerart. Es ist nicht mehr das Modell. Es sind zwei Agenten, die dieselbe Datei schreiben – dasselbe Chaos wie zwei Entwickler, die in denselben Zeilen committen, ohne miteinander zu reden.
Ein Git-Worktree ist die Wand zwischen ihnen: ein separates Arbeitsverzeichnis in einem eigenen Branch, das die Repository-Historie teilt, sodass die Änderungen eines Agenten nicht in den Checkout eines anderen gelangen können.
1# Claude Code: Ein isolierter Checkout pro Agent2claude --worktree feature-auth34# Oder bei einem Sub-Agenten im Frontmatter von .claude/agents/<name>.md:5# isolation: worktree67# Codex: Wähle "Worktree", wenn du einen Thread öffnest (jeder einen detached HEAD)
Ein Haken, den das Tool nicht erwähnen wird. Worktrees beseitigen die Kollision, nicht den Engpass. Du bleibst die Decke. Egal wie viele Agenten du startest, deine eigene Review-Bandbreite entscheidet, wie vielen du vertrauen kannst.
5. Skills sind deine Absicht, einmal geschrieben, von außen
Ein Agent startet jeden Lauf kalt und füllt jede Lücke in deiner Absicht mit einer selbstbewussten Vermutung. Ein Skill ist diese Absicht, die dort aufgeschrieben ist, wo das Modell sie jedes Mal liest – damit es aufhört zu raten.
Das Format ist bei beiden Tools gleich: ein Ordner mit einer SKILL.md, die Anweisungen und eine Beschreibung enthält, plus alle Skripte, die sie braucht. Sie feuert, wenn du sie beim Namen nennst oder wenn deine Aufgabe auf ihre Beschreibung passt – genau der Grund, warum eine flache, wörtliche Beschreibung besser ist als eine clevere.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Read yesterday's CI failures, open issues, and recent5 commits; write each finding to STATUS.md as a task.6---71. Pull failing CI and cluster by root cause.82. Match each to the open issue or commit that caused it.93. Write one STATUS.md task per real finding. Skip the noise.
Ohne Skills lernt jeder Zyklus dein Projekt von Grund auf neu. Mit ihnen wird der Loop jeden Morgen ein bisschen schärfer.
6. Connectors lassen den Loop handeln, nicht nur reden
Ein Loop, der nur das Dateisystem sehen kann, ist ein Spielzeug. Connectors, gebaut auf dem gemeinsamen MCP-Standard, lassen den Agenten dein Issue-Tracker lesen, eine Staging-API ansprechen, eine Datenbank abfragen, in einen Channel posten.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
Das ist die Grenze zwischen einem Agenten, der sagt „hier ist die Lösung", und einem Loop, der den Pull Request öffnet, das Ticket verlinkt und selbstständig grün meldet. Da beide Tools MCP sprechen, kann ein Connector, den du für eines verkabelst, normalerweise auch im anderen verwendet werden.
7. Sub-Agenten halten den Macher vom Prüfer fern
Der wertvollste Zug in jedem Loop ist die Trennung des Agenten, der schreibt, von dem, der prüft.
Ein Modell, das seine eigene Arbeit reviewt, besteht sich selbst jedes Mal. Ein zweiter Agent, mit anderen Anweisungen und idealerweise einem anderen Modell, fängt ein, wovon sich der erste selbst überzeugt hat.
1# Codex: .codex/agents/reviewer.toml2name = "reviewer"3description = "Adversarial PR reviewer: correctness, security, missing tests."4developer_instructions = "Review like an owner. Assume the author is wrong5 until the diff proves otherwise."6model_reasoning_effort = "high"78# Claude Code: Frontmatter von .claude/agents/reviewer.md9# name: reviewer10# description: Adversarial reviewer. Use after any code change.11# model: opus
Einer erkundet, einer implementiert, einer verifiziert anhand der Spezifikation. Das ist es, was /goal bereits im Inneren tut: Ein frisches Modell entscheidet, ob die Arbeit erledigt ist. Zweite Meinungen kosten Tokens, denn jeder Agent verbraucht sein eigenes Modell und seine eigenen Tools – also gib sie dort aus, wo es teuer ist, falsch zu liegen.
8. Wie ein Loop aussieht
Setze die sechs Teile zusammen, und ein einzelner Thread wird zu einer kleinen Maschine.
Jeden Morgen läuft eine geplante Automatisierung auf dem Repository. Sie ruft deinen Triage-Skill auf, der die nächtlichen CI-Fehler, die offenen Issues und die letzten Commits liest und jeden echten Befund in die STATUS.md schreibt. Für jeden Befund, der es wert ist, öffnet der Loop einen isolierten Worktree, schickt einen Sub-Agenten los, um den Fix zu entwerfen, und einen zweiten, um ihn gegen deine Skills und deine Tests zu reviewen. Connectors öffnen den PR und aktualisieren das Ticket. Was der Loop nicht selbst erledigen kann, wartet in deinem Triage-Posteingang. STATUS.md merkt sich, was bestanden hat und was noch offen ist, sodass morgen dort weitergeht, wo heute aufgehört hat.
Was dich morgens tatsächlich erwartet, ist eine kurze Übergabe, keine Wand aus Logs:
1# 9:00 — die nächtliche Übergabe des Loops (dein Triage-Posteingang)2BEREIT ZUM MERGEN3 PR #218 fix flaky test in test/charts CI grün4 PR #219 retry webhook on 429, add backoff test CI grün5BRAUCHT DICH6 auth/session.ts zwei sichere Wege, das zu beheben; ich habe keinen gewählt, du entscheidest7RUHE8 7 geplante Läufe haben nichts gefunden und sich selbst archiviert
Du hast es einmal entworfen. Du hast nichts davon gepromptet.
9. Baue die Bremsen, bevor du gehst
Das ist die Hälfte, die niemand lehrt, und sie entscheidet, ob dein Loop ein Gewinn oder ein Verlust ist.
Die Rechnung über 47.000 Dollar war kein cleveres Modell, das durchgedreht ist. Es waren zwei Agenten, ein Analysator und ein Verifizierer, die sich höflich gegenseitig um mehr Arbeit baten – ohne Schrittbegrenzung, ohne Budgetobergrenze und ohne Stopp-Bedingung. Es lief elf Tage lang. Ein einziger Deckel hätte es beim ersten Mal gestoppt.
Baue die Bremsen ein, bevor du die PS auf die Straße bringst. Verschicke den Motor nicht, bevor du das Bremspedal verschickt hast.
1# Diese draufschrauben, BEVOR du gehst:2- Schrittdeckel: --max-turns 50 (harter Stopp, keine Ausnahmen)3- Budgetgrenze: claude -p --max-budget-usd 10 (Print-Modus; pro Phase)4- Schadensradius: ein Worktree, ein Branch, schreibgeschützt außerhalb src/5- Schutzschalter: gleiches Tool + gleiche Args 3x hintereinander = Anhalten6- Totmann-Prüfung: schreibe einen Heartbeat in STATUS.md pro Lauf; Stille ruft dich auf
Bemesse einen Loop nach dem, was er zerstören kann, nicht nach dem, was du von ihm willst: welche Repos, welche Branches, wie viele Dollar, wie viele Schritte, bevor er sich zwangsweise beendet. Wähle zuerst den Schadensradius, dann die Aufgabe.
Und kalkuliere ihn ehrlich. Steinbergers Hundert-Agenten-Flotte ist real und kostet etwa 1,3 Millionen Dollar pro Monat. Sie funktioniert, weil OpenAI ihn inzwischen anstellt und die Rechnung bezahlt. Der Grenzfall ist gesponsert. Deiner nicht. Bei einem Tarif von 20 bis 200 Dollar ist der Loop, der sich lohnt, klein, gedeckelt und auf eine einzige langweilige Aufgabe gerichtet – nicht auf einen Schwarm.
1DIE KOSTENSPANNE (alle real, alle aus den letzten sechs Monaten)2-----------------------------------------------------------------3259 PRs in 30 Tagen ein Entwickler, 100 % von Claude geschrieben447.000 $ in 11 Tagen ein ausgebüxter Loop ohne Deckel, niemand hat aufgepasst5~1,3 Mio. $ pro Monat eine 100-Agenten-Flotte (die Rechnung wird gesponsert)6-----------------------------------------------------------------7Gleiche Technologie. Der Unterschied sind die Bremsen.
10. Wie Loops sterben
Jeder Loop, der scheitert, stirbt einen von vier Toden. Lerne jetzt die Namen, damit du sie um 3 Uhr morgens erkennst.
Ausbrechende Rekursion. Zwei Agenten füttern sich gegenseitig für immer. Die Heilung sind der Schrittdeckel und die Budgetgrenze von oben, nichts Klügeres.
Stiller Tod. Ein Entwickler erreichte über Nacht mit einem Lauf ein volles Kontextfenster, stoppte und versuchte dann immer wieder, in dieselbe Wand wieder einzusteigen, während er noch lebendig aussah. Dein Loop kann stundenlang tot sein und trotzdem Fortschritt melden. Die Heilung ist ein Heartbeat und ein frischer Kontext pro Phase, kein endloser Lauf.
Der Random Walk. Ohne überprüfbare Stopp-Bedingung driftet der Loop vom Ziel weg statt darauf zu. Eine bestehende Testsuite ist ein Fixpunkt, den er erreichen kann. „Sieht fertig aus" ist keiner.
Verständnisschuld. Je schneller ein Loop Code liefert, den du nicht geschrieben hast, desto größer wird die Lücke zwischen dem, was dein Repository tut, und dem, was du verstehst. Lass ihn lange genug ungelesen laufen, und du hörst auf, der Ingenieur zu sein, und wirst zum Abnickautomat. Die Heilung ist eine von Menschen gelesene Kontrollstelle, die der Loop niemals überspringen darf.
11. Baue den Loop. Bleib der Ingenieur.
Zwei Personen können denselben Loop bauen und zu gegensätzlichen Ergebnissen kommen. Der eine nutzt ihn, um bei Arbeit, die er bis ins Mark versteht, schneller zu werden. Der andere nutzt ihn, um aufzuhören, die Arbeit überhaupt zu verstehen. Der Loop kann sie nicht auseinanderhalten. Du kannst.
Chernys Punkt war nie, dass die Arbeit leichter geworden ist. Es ist, dass der Hebel sich verschoben hat: vom Prompt zum Loop und vom Tippen zum Urteilsvermögen. Das ist ein härterer Job als Prompten, kein leichterer.
Also hier ist der nächste Schritt, und er ist bewusst klein, denn das ist früh und die Kosten schwanken wild. Morgen früh, nimm den langweiligsten Job, den du immer noch von Hand machst – Triage von CI, Schließen von veralteten Issues, Verfolgen eines flaky Tests – und wickle einen gedeckelten Loop darum. Bremsen zuerst. Klein genug, dass du immer noch jedes Diff liest, das er liefert.
Niemand, der 200 Pull Requests im Monat verschickt, hat mit hundert Agenten angefangen. Sie haben mit einem Loop angefangen, dem sie vertrauten, und sie sind die ganze Zeit der Ingenieur geblieben. Baue diesen einen.
