Loop Engineering: Schleifen, Routinen und Workflows mit Claude Code

Kurzfassung: Loop engineering ist die Disziplin, Agents so lange Arbeitszyklen wiederholen zu lassen, bis eine Abbruchbedingung erfüllt ist – statt sie Zug für Zug mit Prompts anzuleiten. Boris Cherny von Anthropic, der Entwickler von Claude Code, beschreibt seinen eigenen Workflow unverblümt: „Ich gebe Claude keine Prompts mehr. Bei mir laufen loops. Sie geben Claude die Prompts und finden heraus, was zu tun ist. Meine Aufgabe ist es, loops zu schreiben.“¹ Claude Code bietet inzwischen eine vollständige Palette an loop-Oberflächen: /goal (Wiederholung, bis ein separates Modell die Erfüllung einer Bedingung bestätigt oder sie für unerfüllbar erklärt), /loop (wiederkehrende lokale Ausführungen), das offizielle Ralph-Plugin (Iteration, bis ein Versprechen eingehalten ist), geplante Cloud-Aufgaben (früher routines; Cloud-Cron) und dynamic workflows (Claude schreibt einen JavaScript-Orchestrierungsgraphen und führt damit bis zu 1.000 subagents aus). Keine dieser Funktionen bildet jedoch das tragende Fundament dieser Disziplin, sondern die Verifizierung. Ein loop konvergiert nur, wenn etwas außerhalb des Generators – ein Test, ein Bewertungsmodell, ein Pixel-Diff oder eine maschinelle Prüfung – entscheidet: „Fertig.“ Machen Sie es richtig, verstärken sich die loops gegenseitig; machen Sie es falsch, finanzieren Sie einen äußerst kostspieligen Random Walk. Dieser Leitfaden behandelt sämtliche loop-Oberflächen samt Versionsangaben, das Ralph-Muster und seine Fehlermodi, den Punkt, an dem loops zu Graphen werden müssen, die Verifizierungsleiter, Kosten- und Sicherheitsdisziplin sowie den Betrieb einer dauerhaft aktiven Flotte. Stand: Claude Code v2.1.312 (Oktober 2026).

Was ist Loop Engineering?

Vor zwei Jahren schrieben Entwickler den Quellcode von Hand. Dann schrieben agents den Code anhand menschlicher Prompts. Der derzeit stattfindende Wandel setzt eine Ebene höher an: agents geben agents Prompts, und der Mensch schreibt das System, das entscheidet, welche Prompts ausgeführt werden. Cherny bewertet diesen Entwicklungssprung ganz direkt: „So groß der Schritt vom Quellcode zu agents war, loops sind ebenso wichtig und ein ebenso großer Schritt.“²

Seine Definition ist erfrischend unspektakulär: „Ein Loop ist im Wesentlichen ein cron job, der lokal für Claude ausgeführt wird. Eine Routine ist dasselbe, läuft aber in der Cloud.“³ Die exotisch klingende Praxis – über Nacht „Hunderte, manchmal Tausende agents 5, 10 oder 20 Stunden lang“ auszuführen,⁴ Claude Code „seit über sechs Monaten zu 100 % von Claude Code geschrieben“⁴ – lässt sich auf wenige Grundelemente reduzieren: einen Prompt, der nach einem Zeitplan oder bei Eintritt einer Bedingung erneut ausgelöst wird, einen Zustand, der zwischen den Iterationen erhalten bleibt, und eine Prüfung, die den Lauf beendet.

Anthropic gab der Disziplin im Juni 2026 ihren Namen: loops sind „agents, die Arbeitszyklen wiederholen, bis eine Abbruchbedingung erfüllt ist“, und „die Qualität der Ausgabe eines loops hängt von dem System ab, das ihn umgibt“.⁵ Um dieses System geht es in diesem Leitfaden.

Ein Hinweis zur Herkunft, da sich der Diskurs Mitte 2026 schnell entwickelte: Der Begriff „graph engineering“ – in viralen Beiträgen häufig Cherny zugeschrieben – wurde von der Community geprägt (Peter Steinbergers Frage vom 18. Juli „Sprechen wir noch über loops oder sind wir schon zu graphs übergegangen?“, die Hamel Husain weiterverbreitete), nicht von Anthropic oder Cherny.⁶ Das viel zitierte Statement „85 % unserer Entwickler … die Methode dafür ist graph engineering“ kursiert ausschließlich in Beiträgen Dritter. Bei der Vorbereitung dieses Leitfadens konnten wir es in keiner Primärquelle zu seinen Vorträgen finden (dem Gespräch bei der YC Startup School, Bloombergs Odd Lots oder dem Meta-@Scale-Bericht von TechCrunch); betrachten Sie die Zuschreibung daher als unbestätigt. Seine tatsächliche Arbeitsweise ist graphenförmig (Orchestratoren, die Implementierungs-, Prüf- und Korrektur-subagents bis zu einer Verschachtelungstiefe von 5 starten), doch das belegte Vokabular lautet loops, routines und workflows – und genau dieses Vokabular verwendet dieser Leitfaden.

Der Fünf-Minuten-Golden-Path

Mit drei Befehlen gelangen Sie vom Prompting zum Looping:

# 1. A goal loop: Claude keeps working until a SEPARATE model confirms the condition
/goal all tests pass and coverage is above 80%

# 2. A recurring local loop: re-runs on a schedule while your session is open
/loop 30m check CI on my open PRs and fix any failures

# 3. A cloud scheduled task (formerly a routine): runs on Anthropic's infrastructure whether your laptop is open or not
/schedule every morning at 7am: triage new issues, reproduce what you can, draft fixes as PRs

Der Unterschied zwischen diesen Befehlen und einem Prompt ist struktureller, nicht kosmetischer Natur: Jeder besitzt eine Regel für die erneute Ausführung (eine Bedingung, einen Takt, einen cron) und benötigt eine Abbruchregel. Im gesamten restlichen Leitfaden geht es darum, diese beiden Regeln zuverlässig zu gestalten.

Der Kern-Loop und die eine Regel

Jedes agentische System durchläuft denselben inneren Zyklus, den die Agent-SDK-Dokumentation von Anthropic als Kontext erfassen → Aktion ausführen → Arbeit überprüfen → wiederholen festschreibt.⁷ Auch der eigene Prozess von Claude Code ist ein Loop: den Prompt auswerten, Tools aufrufen, Ergebnisse lesen und dies wiederholen, bis eine Antwort keine Tool-Aufrufe mehr enthält.⁸

Loop Engineering legt äußere loops um diesen inneren Zyklus – und übernimmt dabei dessen eine unverhandelbare Regel, die sich in jeder ernst zu nehmenden Quelle des Fachgebiets findet:

Der agent, der die Arbeit ausführt, bewertet sie niemals selbst.

• In der /goal-Dokumentation von Anthropic: „Über den Abschluss entscheidet ein neues Modell und nicht dasjenige, das die Arbeit ausführt.“⁹
• Im Essay von Anthropic über das harness-Design: „Die Trennung zwischen dem agent, der die Arbeit ausführt, und dem agent, der sie bewertet, erweist sich als wirkungsvoller Hebel zur Lösung dieses Problems.“¹⁰
• Cherny über das, was Praktiker übersehen: „Die Verifikation ist wahrscheinlich das Wichtigste, was die meisten Menschen nicht richtig umsetzen.“³ Sein konkretes Beispiel für die Anweisung zu einer zweiwöchigen Neuentwicklung von Electron in Swift: „Führen Sie die Electron-App in der virtuellen Mac-Maschine aus, erstellen Sie einen Screenshot und untersuchen Sie ihn dann Pixel für Pixel. Vergleichen Sie ihn mit der Swift-Version. Hören Sie erst auf, wenn Sie fertig sind.“³

Der Grund dafür ist mechanischer, nicht moralischer Natur: Ein Modell, das gefragt wird „Sind Sie fertig?“, neigt zu positiver Selbstbewertung, und ein selbstbewusst formulierter Verlauf kann eine modellbewertete Abbruchbedingung zu einem vorschnellen „fertig“ überreden.¹¹ Externe Verifikation – eine Testsuite, ein Compiler, ein Pixelvergleich oder ein neues Modell, das kein Eigeninteresse an der Antwort hat – liefert als Einziges ein Signal, das dem standhält.

Die Autonomieleiter

Die Loop-Oberflächen in Claude Code bilden eine Leiter vom „erneut Enter drücken“ bis zu „läuft ohne Sie“. Mit jeder Stufe steigt sowohl die Autonomie als auch der Verifikationsaufwand:

(Die Einteilung in Stufen folgt der Taxonomie von pardel.dev vom Juli 2026, der übersichtlichsten unabhängigen Kartierung dieses Themenfelds.¹¹)

Zwischen den Stufen 3 und 5 liegt eine lokale Option: Geplante Desktop-Aufgaben laufen ohne geöffnete Sitzung auf Ihrem Rechner, in Intervallen bis hinunter zu 1 Minute, wenn Claude sie festlegt (1 Stunde in den Formularen), und die Dokumentation verweist auf sie, „wenn Sie Zugriff auf lokale Dateien und Tools benötigen“.¹²

Die Disziplin dieser Leiter lautet: Beginnen Sie auf der niedrigsten Stufe, die Ihr Problem löst, und steigen Sie erst dann höher, wenn die Verifikation einer Stufe erwiesenermaßen funktioniert. Ein /goal, dessen Bedingung sich nicht als überprüfbares Kriterium formulieren lässt, ist noch nicht bereit, eine geplante Cloud-Aufgabe zu werden.

Die Loop-Oberflächen im Detail

(Dieser Leitfaden behandelt die Loop-Oberflächen selbst. Der Claude Code-Leitfaden ist die vollständige CLI-Referenz – Konfiguration, Berechtigungen, hooks, MCP – und der Leitfaden zur Agent-Architektur erklärt, wie harness-Komponenten zusammenspielen; loops führen Sie auf beiden aufbauend aus.)

/goal – der Evaluator-Optimizer-Loop

/goal <condition> lässt Claude weiterarbeiten, bis die Bedingung erfüllt ist: „Nach jedem Durchlauf prüft ein Modell, ob die Bedingung erfüllt ist. Beurteilt das Modell sie als noch nicht erfüllt, beginnt Claude einen weiteren Durchlauf, statt Ihnen wieder die Kontrolle zu übergeben.“⁹ Technisch ist „/goal ein Wrapper um einen sitzungsbezogenen, promptbasierten Stop hook“, weshalb es überall dort nicht verfügbar ist, wo hooks abgeschaltet sind (disableAllHooks oder allowManagedHooksOnly in verwalteten Einstellungen). Der Evaluator ist Ihr konfiguriertes kleines, schnelles Modell und gibt eines von drei Urteilen zurück, jeweils mit einer kurzen Begründung:⁹

Dies funktioniert auch headless: claude -p "/goal ..." führt den Loop bis zum Abschluss aus.

Hinweise zur Ausgestaltung: Formulieren Sie die Bedingung beobachtbar („Tests werden bestanden“, „der Endpunkt gibt 200 zurück“, „null TypeScript-Fehler“) und nicht als Wunschvorstellung („der Code ist sauber“). Ein unpräziser Verifier gibt dem Loop keine Richtung vor – und da sich ein modellbewertetes Kriterium durch ein selbstbewusst formuliertes Transkript zur Zustimmung bewegen lässt, sollten Sie /goal nach Möglichkeit mit einer maschinellen Prüfung kombinieren.¹¹ Die Dokumentation benennt die Grenze ausdrücklich: Der Evaluator „führt keine Befehle aus und liest keine Dateien eigenständig, formulieren Sie die Bedingung also als etwas, das Claudes eigene Ausgabe belegen kann“.⁹ Legen Sie auch die Abbruchregel in die Bedingung: Eine Klausel wie or stop after 20 turns wird wie der Rest bewertet, und eine Bedingung darf bis zu 4.000 Zeichen lang sein. Antwortet Claude dem Evaluator mehrere Durchläufe hintereinander ohne Tool-Nutzung, stoppt Claude Code den Loop und gibt Ihnen die Kontrolle zurück, wobei das goal gesetzt bleibt.⁹

Die Fehlerbehandlung, erstmals in v2.1.234 abgehärtet,³⁴ deckt inzwischen jede Art ab, auf die ein Durchlauf scheitern kann:

Verwaltet ein Host wie die Desktop-App oder eine Cloud-Sitzung die Anmeldedaten, bleibt das goal bei einem Authentifizierungsfehler aktiv, weil der Host den Zugriff selbst wiederherstellt. Und wenn Hintergrundarbeit ein goal warten lässt, sieht Claude nach 30 Minuten nach dem Rechten, erneut 1 Stunde später und danach alle 2 Stunden, wobei es zwischen Ihren Prompts höchstens drei solcher Check-ins im Leerlauf startet (CLAUDE_CODE_GOAL_CHECKIN_MINUTES legt das erste Intervall fest; 0 schaltet Check-ins und automatische Wiederholungen ab).⁹

/loop – wiederkehrende lokale Läufe

/loop [interval] <prompt> führt einen Prompt nach einem Zeitplan erneut aus: in einem festen Intervall (/loop 5m check the deploy), selbst getaktet (Claude wählt anhand der Beobachtungen die nächste Verzögerung, zwischen einer Minute und einer Stunde) oder als bloßes /loop für einen integrierten Wartungsdurchlauf. Im Hintergrund arbeiten CronCreate/CronList/CronDelete (5-Felder-cron, 50 Aufgaben pro Sitzung, Ablauf nach 7 Tagen) und das Monitor-Tool, das die Ausgabe eines Hintergrundskripts streamt, anstatt sie regelmäßig abzufragen.¹² Chernys eigenes Einführungsbeispiel: „/loop kümmere dich um alle meine PRs. Behebe Build-Probleme automatisch, und wenn Kommentare eingehen, nutze einen worktree-agent, um sie zu bearbeiten.“¹³ Um den integrierten Wartungsprompt zu ersetzen, schreiben Sie eine loop.md (.claude/loop.md im Projekt, die Vorrang hat, oder ~/.claude/loop.md); „Änderungen an loop.md werden bei der nächsten Iteration wirksam“, und Inhalte über 25.000 Bytes werden abgeschnitten.¹²

Die entscheidende Einschränkung: /loop lebt in einem laufenden Claude Code-Prozess. „Aufgaben werden nur ausgelöst, während Claude Code läuft und sich im Leerlauf befindet.“ Beenden Sie Claude Code, werden sie nicht mehr ausgelöst; schicken Sie die Sitzung in den Hintergrund, läuft der Loop ohne Terminal weiter; setzen Sie sie mit --resume oder --continue fort, kehren die mit CronCreate geplanten Aufgaben zurück, ein selbst getakteter /loop jedoch nicht, starten Sie ihn also erneut.¹² Für Arbeit, die die Sitzung überdauern muss, vergleicht die Dokumentation drei Oberflächen:¹²

Für Arbeit, die bei ausgeschaltetem Rechner laufen muss, sind geplante Cloud-Aufgaben vorgesehen.

Das Ralph plugin – iterieren, bis das Versprechen erfüllt ist

Das offizielle ralph-loop plugin von Anthropic macht aus dem bevorzugten Brute-Force-Muster der Community ein Produkt. Im Repository anthropics/claude-plugins-official heißt es seit dem 6. Januar 2026 ralph-loop; an diesem Tag benannte Anthropic es „gemäß rechtlicher Beratung“ von ralph-wiggum um. Am 26. Oktober 2026 löschte das Repository claude-code seine eigene veraltete ralph-wiggum-Kopie, und sein Marketplace installiert ralph-loop nun aus dem offiziellen Repository, sodass „bestehende Plugin-IDs weiterhin funktionieren“.¹⁴ Der Mechanismus: Ein Stop hook fängt den Versuch von Claude ab, die Sitzung zu beenden, und speist den Prompt erneut ein, sodass das Modell in derselben Sitzung kontinuierlich iteriert. /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<string>" startet den Vorgang; /cancel-ralph bricht ihn ab. Das README weist ausdrücklich darauf hin, dass --max-iterations „Ihr primärer Sicherheitsmechanismus“ ist – ein exakter Zeichenfolgenvergleich für den Abschluss kann dauerhaft fehlschlagen.¹⁴ Unter jedem Stop-hook-Loop liegt eine Grenze des harness: „Blockiert der hook acht Stopps hintereinander ohne Tool-Aufruf dazwischen, setzt sich Claude Code über die nächste Blockierung hinweg und beendet den Durchlauf“ (CLAUDE_CODE_STOP_HOOK_BLOCK_CAP hebt die Grenze an).²⁹ Das beendet einen Loop, der keine Fortschritte mehr macht; einen Ralph-Loop, der weiterhin Tools aufruft, beendet es nicht, weshalb die Iterationsgrenze weiterhin zählt.

Dynamische workflows – Claude schreibt den Graphen

Dynamische workflows wurden mit Claude Code v2.1.154 (Mai 2026) eingeführt und im Einführungspost von Anthropic vom 2. Juni 2026 ausführlich beschrieben. Sie stellen den größten konzeptionellen Sprung dar: „Claude kann nun sein eigenes harness spontan und passgenau für die jeweilige Aufgabe schreiben.“¹⁵ Sie beschreiben die Aufgabe, sagen „use a workflow“ oder fügen das Schlüsselwort ultracode ein; Claude schreibt ein JavaScript-Orchestrierungsskript, in dem agent() einen subagent mit optionalen Ausgaben nach dem JSON-Schema startet, pipeline() je einen pro Element einer Liste ausführt, parallel() eine Gruppe gleichzeitig ausführt und gewöhnliche await-Anweisungen, loops und Bedingungen den Ablauf steuern; eine Runtime führt es im Hintergrund aus. /effort ultracode geht noch weiter: Claude „plant für jede substanzielle Aufgabe in der Sitzung einen workflow“, und eine solche Sitzung „erreicht ein Sitzungs- oder Wochenlimit früher als dieselbe Arbeit ohne diese Einstellung“.¹⁶ „Ein workflow überführt den Plan in Code … Ein workflow-Skript verwaltet den Loop, die Verzweigungen und die Zwischenergebnisse selbst, sodass der Kontext von Claude nur die endgültige Antwort enthält.“¹⁶

Grenzen und Struktur laut Dokumentation:¹⁶

In .claude/workflows/ gespeicherte Skripte werden zu wiederverwendbaren Slash-Befehlen. Ein Lauf wird anhand gespeicherter agent-Ergebnisse fortgesetzt, wenn Claude ihn neu startet, doch ein fehlgeschlagener agent „läuft erneut, ebenso jeder agent, den das Skript danach startet, selbst bereits abgeschlossene“, und ein Lauf, den Sie mittendrin in den Hintergrund schicken oder beenden, „wird nicht von selbst fortgesetzt“.¹⁶

Die charakteristische Topologie lautet fan-out / refute / converge: unabhängige Such-agents, gefolgt von adversarial verifiers, die jede Erkenntnis widerlegen sollen; die Iteration läuft, bis die Antworten der Prüfung standhalten. Anthropic liefert inzwischen eine Ausprägung davon aus: Der integrierte workflow /deep-research „fächert Websuchen zu einer Frage über mehrere Blickwinkel auf, ruft die gefundenen Quellen ab und gleicht sie miteinander ab, stimmt über jede Aussage ab und liefert einen Bericht mit Quellenangaben, aus dem Aussagen herausgefiltert sind, die dem Abgleich nicht standhielten“, und wenn seine Verifier eine Aussage nicht prüfen können, „führt der Bericht diese Aussage als unverifiziert auf, statt sie als widerlegt zu zählen“.¹⁶ Das prominenteste Ergebnis aus dem Einführungspost: Buns Portierung seiner 535.496 Zeilen umfassenden Zig-Codebasis nach Rust – daraus entstand eine Rust-Codebasis mit mehr als einer Million Zeilen – innerhalb von elf Tagen (3.–14. Mai 2026) durch 64 parallele agents, laut Jarred Sumners Bericht.¹⁵

Agent teams – der Peer-Graph

Hinter CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 (in v2.1.32, Februar 2026, als Research Preview hinzugefügt; die Dokumentation sagt inzwischen „Agent teams sind experimentell und standardmäßig deaktiviert“) verbirgt sich ein Teamleiter mit Teammitgliedern, die „unabhängig arbeiten, jeweils in ihrem eigenen Kontextfenster, und direkt miteinander kommunizieren“. Das ergibt einen Peer-Graph statt eines subagent-Baums, koordiniert über eine gemeinsame Aufgabenliste mit Abhängigkeiten, durch Dateisperren abgesicherte Beanspruchung und Postfächer für jeden agent. Durch hooks erzwungene quality gates schalten maschinelle Prüfungen zwischen ein Teammitglied und den Status „fertig“: TaskCompleted mit Exit-Code 2 blockiert den Abschluss, und TeammateIdle mit Exit-Code 2 hält ein Teammitglied bei der Arbeit.¹⁷ Zwei Verhaltensweisen sollten Sie kennen, bevor Sie die Funktion einschalten: Solange agent teams aktiviert sind, „startet ein subagent, den Claude benennt, als Teammitglied, sodass Teams auch entstehen können, wenn Sie keines angefordert haben“, und „Ein Teammitglied kann keine Berechtigungsabfrage genehmigen und keine Zustimmung in Ihrem Namen erteilen“.¹⁷

Routines – loops, die Ihren Laptop überdauern

Eine geplante Cloud-Aufgabe (früher eine routine) ist „eine gespeicherte Claude Code-Konfiguration: ein Prompt, ein oder mehrere Repositorys und eine Gruppe von Konnektoren, einmal gebündelt und anschließend automatisch ausgeführt“ und läuft auf von Anthropic verwalteter Cloud-Infrastruktur oder in der selbst gehosteten Umgebung Ihrer Organisation.¹⁸ Der alte Name bleibt dort erhalten, wo eine Umbenennung etwas kaputt machen würde: in der Webadresse (claude.ai/code/routines), im Alias /routines für /schedule und im API-Pfad /fire. Drei kombinierbare Auslöser stehen zur Verfügung: ein Zeitplan (Mindestintervall 1 Stunde für einen wiederkehrenden Takt oder ein einmaliger Lauf zu einem festgelegten Zeitpunkt), API-Auslösung (POST .../routines/{id}/fire) und GitHub-Ereignisse. Die Erstellung erfolgt über /schedule, die Desktop-App oder claude.ai/code/routines. Die Sitzung eines Laufs startet im Auto-Modus, sofern dieser verfügbar ist; ein Klassifikator erlaubt oder blockiert jede Aktion, und der Lauf hält an und wartet etwa bei einer Aktion, die selbst im Auto-Modus eine Abfrage auslöst (einer ask-Regel), oder bei wiederholten Blockierungen. Genau deshalb ist der Hinweis in der Dokumentation so entscheidend: Das Ergebnis eines Laufs sagt aus, „wie die Sitzung endete, nicht, ob Claude die in Ihrem Prompt beschriebene Arbeit erledigt hat; öffnen Sie also den Lauf und lesen Sie sein Transkript, um zu sehen, was passiert ist“.¹⁸ Zwei Fehlerbehebungen seit September zeigen, dass die Lücke real ist: Bis v2.1.286 wurden Läufe, deren Cloud-Sitzung nie startete, als Succeeded angezeigt, und bis v2.1.302 wurden Läufe „als Completed angezeigt, nachdem ihre Cloud-Sitzung unerwartet gestoppt war“.³⁶ Dieselbe Version verhinderte außerdem, dass ein zwischendurch fehlgeschlagener Lauf von vorn wiederholt wurde, „was Arbeit wiederholen konnte, etwa denselben Bericht zweimal zu veröffentlichen“; ein Grund, ausgelöste Arbeit idempotent zu gestalten.³⁶

Anthropic führt in den eigenen Codebasen „jeden Tag vielleicht 20 oder 30 dieser routines“ aus – zum Entfernen ungenutzten Codes, zur Verbesserung der Testabdeckung und zur Auslieferung von Experimenten.³

Die unterstützenden Komponenten

Background subagents (standardmäßig seit v2.1.198) halten delegierte Arbeit aus Ihrem Kontext heraus; das /agents-Panel dient zu ihrer Überwachung. Cross-session messaging (v2.1.224) verwandelt unabhängige Sitzungen mithilfe von SendMessage in einen nachrichtenvermittelnden Graphen. Die dabei geltende Sicherheitsdoktrin ist nachahmenswert: Eine Nachricht aus einer anderen Sitzung „gilt niemals als Ihre Zustimmung“.¹⁹ Aus einer mit Remote Control verbundenen Sitzung erreicht es auch Ihre Sitzungen auf anderen Rechnern (v2.1.225+) und in der Cloud. Für Wartezeiten zwischen loops bittet die Eingabe notify_when_idle (v2.1.236+)³⁶ eine Sitzung auf diesem Rechner um eine einzige Benachrichtigung, sobald sie das nächste Mal in den Leerlauf geht oder beendet wird, und Claude Code abonniert diese, „ohne einen Durchlauf zu starten oder Tokens in der beobachteten Sitzung zu verbrauchen“.¹⁹ Self-hosted runners (v2.1.224, Team/Enterprise) führen Cloud-Sitzungen und geplante Cloud-Aufgaben (früher routines) auf Ihren eigenen Computern aus, die Grundlage für Flotten auf Organisationsebene.²⁰

Das Ralph-Muster

Die Community war zuerst so weit. Im Juli 2025 veröffentlichte Geoffrey Huntley den Essay, der die Technik nach der Figur aus Die Simpsons benannte: Ralph ist buchstäblich

while :; do cat PROMPT.md | claude-code ; done

— sein Einzeiler, exakt wie veröffentlicht — ein Repository, eine Aufgabe pro Iteration, frischer Kontext bei jedem Durchlauf, wobei Spezifikationen und Fortschrittsdateien im Dateisystem den Zustand zwischen den Iterationen bewahren und Tests/Lints als „Gegendruck“ wirken.²¹ Die moderne Headless-Variante desselben Musters ist claude -p "$(cat PROMPT.md)" in einer Shell-Schleife. Im Wesentlichen nutzte auch der eigene C-Compiler-harness von Anthropic diese Form.²³ Seinen berichteten Ergebnissen (MVP eines Auftrags im Wert von 50.000 Dollar für 297 Dollar an Tokenkosten; sechs Repositories über Nacht bei einem Hackathon) standen ebenso klare Grenzen gegenüber: nur Neuentwicklungen, Platzhalter und doppelte Implementierungen als wiederkehrende Fehlerbilder sowie „LLMs spiegeln die Fähigkeiten der Bedienenden wider“.

Anthropic verwendet den Namen in seinen technischen Veröffentlichungen nie, doch das Muster ist inzwischen gleich zweifach offizielle Leitlinie: Der Essay über lang laufende Agenten vom November 2025 schreibt genau diese Form vor — ein Initialisierungsagent erstellt Funktionslisten und Fortschrittsdateien, anschließend übernehmen pro Kontextfenster neue Programmieragenten, die „zu Beginn der Sitzung die Datei mit den Fortschrittsnotizen und die Git-Commit-Protokolle lesen“²² — und beim C-Compiler-Projekt vom Februar 2026 liefen sechzehn Claude-Agenten parallel — „Ich habe einen harness gebaut, der Claude in eine einfache Schleife steckt“, wie Nicholas Carlini es beschreibt — mit dateibasierten Aufgabensperren und Git als Synchronisierungsschicht. Dabei entstanden rund 100.000 Zeilen Rust in etwa 2.000 Sitzungen für ungefähr 20.000 Dollar.²³ Der Satz zur Verifikation aus dem Essay bringt die gesamte Theorie des Musters auf den Punkt: „Es ist wichtig, dass die Instanz zur Aufgabenprüfung nahezu perfekt ist.“

Warum frischer Kontext einer langen Sitzung überlegen ist: Je voller der Kontext einer Sitzung wird, desto stärker sinkt ihre Wirksamkeit — nach übereinstimmender Einschätzung aus der Praxis setzt die Abweichung bei etwa 100.000 Tokens ein — und Zusammenfassungen bei der Kontextkomprimierung sind verlustbehaftete Paraphrasen, die Fehler in selbstsicher formulierte Aussagen verwandeln.²⁴ Ralphs Ansatz aus frischen Agenteninstanzen und Dateien umgeht beides. (Die Schleifen innerhalb einer Sitzung im offiziellen Plugin geben zugunsten der Bequemlichkeit einen Teil dieser Vorteile auf; für lange Läufe bleibt die Headless-Variante mit externem Zustand das stärkere Muster.)

Auch das warnende Beispiel zu diesem Muster ist lehrreich: Ein Anwender startete das Plugin mit einem vagen Prompt und max_iterations: 0 — das bedeutet unendlich, nicht deaktiviert — und Claude stellte sich 1.966-mal dieselbe Rückfrage, während der Stop hook jede nachfolgende Nachricht abfing.²⁵ Iterationsgrenzen sind unverzichtbar.

Wenn Schleifen zu Graphen werden

Eine einzelne Schleife setzt voraus, dass ihre Iterationen unabhängig oder streng sequenziell sind. Sobald parallele Arbeit Abhängigkeiten hat — Aufgabe B benötigt die Ausgabe von A, zwei Agenten würden dieselbe Datei bearbeiten — geraten frei laufende Schleifen aneinander. Dann brauchen Sie eine explizite Struktur: eine Aufgabenliste mit Abhängigkeitsarrays, die Reservierung von Dateien und klare Regeln für das Zusammenführen von Änderungen. Darauf läuft die Debatte über Schleifen und Graphen tatsächlich hinaus: Schleifen für ein Repository und ein Ziel; Graphen, wenn parallele Arbeit eine festgelegte Reihenfolge braucht.²⁶

Die Graphoptionen, geordnet nach zunehmendem Infrastrukturbedarf:

1. Dynamische Workflows — Abhängigkeiten werden im Kontrollfluss von JavaScript ausgedrückt; Synchronisationsbarrieren gibt es nur dort, wo eine Phase tatsächlich alle vorherigen Ergebnisse benötigt. Die von Anthropic benannten Topologien: auffächern und zusammenführen, adversarielle Verifikation, generieren und filtern, Turnier („Starten Sie N Agenten, die dieselbe Aufgabe jeweils mit unterschiedlichen Ansätzen bearbeiten“, und bewerten Sie sie anschließend paarweise) sowie Schleifen bis zum Abschluss.¹⁵
2. Agententeams — eine gemeinsame Aufgabenliste mit Nachverfolgung von Abhängigkeiten; ein Teammitglied, das gestartet wird, während sich die Leitung im Planmodus befindet, sendet seinen Plan zur Genehmigung, und Claude Code genehmigt ihn automatisch; die Leitung prüft ihn nur, wenn Sie ein laufendes In-Process-Teammitglied in den Planmodus schalten (Shift+Tab); der Graph liegt als Daten vor, nicht als Code.¹⁷ Bei diesem Muster hat sich eine Standardeinstellung geändert, erstmals in v2.1.233:³⁴ Die Werkzeuge zur Aufgabenverfolgung (TaskCreate, TaskGet, TaskUpdate, TaskList, TodoWrite) sind jetzt „standardmäßig nur auf Opus 4.7, Sonnet 4.6, Haiku 4.5 und älteren Modellen verfügbar“, eine Standardauswahl, die ab v2.1.268 gilt.³⁸ Agenten ohne sie „koordinieren sich über Nachrichten statt über die gemeinsame Aufgabenliste“,¹⁷ sodass die Aufgabenliste bei einem aktuellen Modell in einer gewöhnlichen lokalen Sitzung fehlt, solange Sie sie nicht ausdrücklich aktivieren; Hintergrund- und Cloud-Sitzungen erhalten die Werkzeuge bei jedem Modell.³⁸ Aktivieren lassen sie sich mit CLAUDE_CODE_ENABLE_TODO_TOOLS=1, --allowedTools TaskCreate oder einer --tools-Liste, die sie nennt. Eine exportierte Variable erreicht kein Teammitglied in einem geteilten Fensterbereich; um einem solchen die Werkzeuge zu geben, starten Sie die Leitung mit claude --settings '{"env":{"CLAUDE_CODE_ENABLE_TODO_TOOLS":"1"}}'.³⁸
3. Externe Orchestratoren — die Skalierungslösungen der Community: Steve Yegges Gas Town betreibt 20–30 Claude Code-Instanzen mit DAGs aus Git-gestützten „beads“ (75.000 Zeilen Go in 17 Tagen, nach eigener Aussage auch „ein Geldfresser“, der hohe Kompetenz bei der Bedienung erfordert);²⁷ claude-flow/Ruflo (rund 31.000 Sterne) organisiert Schwärme in einer Hierarchie aus Königin und Arbeitsagenten; Engines nach dem Vorbild von LangGraph legen eine typisierte Zustandsmaschine darüber, mit Claude Code innerhalb der Knoten.

Cherny selbst formalisiert diese Entwicklung mit dem Stufenmodell Steps of AI Adoption, das im Juli 2026 über Anthropic veröffentlicht wurde: Freigabegebunden (0 Agenten) → Unterstützt (~1) → Parallel (~10) → Beaufsichtigte Autonomie (~100, wobei „die meisten Agenten von Claude gestartet werden, nicht von Menschen“) → KI-nativ (1.000+). Sein Rat dazu: „Bei jedem Schritt … müssen Sie die nächsten Engpässe finden und abbauen sowie die nächsten Schutzvorkehrungen aufbauen.“²⁸

Verifikationsengineering

Alles bisher Beschriebene ist Infrastruktur. Dieser Abschnitt ist das Produkt.

Das Eskalationsmodell von Anthropic, aus der aktuellen Dokumentation zu bewährten Vorgehensweisen, geht von einem einzigen Tipp aus: „Geben Sie Claude etwas, das es ausführen kann und das mit Bestanden oder Nicht bestanden zurückkommt. Sobald es das hat, kann es selbstständig weitermachen, und Sie müssen nicht zusehen.“ Die Stufen reichen dann von Claudes eigener Entscheidung bis zur Durchsetzung durch den harness: eine Zeile im Prompt (run the auth tests after, and keep going until they pass) → eine /goal-Bedingung, die „ein separates Modell nach jedem Durchlauf anhand des Gesprächs prüft“, was „bei langen Hintergrundläufen wichtig ist, in denen Claude einen Durchlauf manchmal mit einer Fortschrittszusammenfassung beendet, obwohl noch Punkte offen sind“ → ein Stop hook, „von Claude Code (dem harness) durchgesetzt, sodass der Durchlauf erst endet, wenn die Typprüfung besteht oder das Blockierungslimit erreicht ist“ → ein Review „durch jemanden, der den Code nicht geschrieben hat“, bei dem /code-review „den Diff in einem frischen subagent prüft, der Ihr Gespräch nie gesehen hat. Er lässt sich nicht von der Argumentation beeinflussen, die den Code hervorgebracht hat“.²⁹ Der zugehörige Belegstandard: „Bitten Sie Claude um Belege: den ausgeführten Befehl und seine Ausgabe oder den Screenshot“, denn „bei einer Sitzung, die Sie nicht beobachtet haben, sind sie auch die einzigen Belege, die Sie haben“.²⁹ Die adversariale Widerlegung, mit der diese Leiter früher endete, steht inzwischen in der Workflow-Dokumentation, deren Beispielprompt einen Workflow auffordert, „jede Erkenntnis vor dem Bericht adversarial zu verifizieren“.¹⁶

Dieselbe Dokumentation ordnet jede Anweisung danach ein, was Claude entscheidet und was Claude Code durchsetzt. Drei ihrer Zeilen sind die Abbruch-, Budget- und Merge-Regeln einer Schleife:²⁹

Eine unbeaufsichtigte Schleife braucht in jeder Zeile einen Eintrag aus der rechten Spalte; die linke Spalte ist alles, was einer Schleife bleibt, wenn niemand einen geschrieben hat. Die Dokumentation verabschiedet außerdem eine Prompt-Gewohnheit: Zeilen wie „keep going, loop until done, don’t be lazy“ führen „eher zu Mehrarbeit, als dass sie einen Stillstand beheben“, und „bei Läufen, die niemand beobachtet, setzen /goal oder ein Stop hook es durch“.²⁹

Die drei Feedbackklassen, aus dem Essay Agent SDK: regelbasiertes Feedback („klar definierte Regeln für eine Ausgabe und anschließend eine Erklärung, welche Regeln nicht erfüllt wurden und warum“ — die beste Form), visuelles Feedback (Screenshots, Pixelvergleiche) und LLM als Bewertungsinstanz (unscharfe Bewertungsraster — in den Worten von Anthropic „im Allgemeinen keine besonders robuste Methode“).⁷ Bevorzugen Sie sie in dieser Reihenfolge; eine vorhandene deterministische Prüfung ist besser als eine Bewertungsinstanz, die Meinungen abgibt.

Konvergenzbedingungen. Die treffendste kritische Auseinandersetzung mit Schleifen — Yoko Lis Analyse vom August 2026 — führt Konvergenz auf vier Voraussetzungen zurück: einen definierten Zielzustand, einen beobachtbaren Istzustand, präzise lokale Änderungen und Abbruchregeln außerhalb des Generators. Ihr mit Messinstrumenten begleitetes Experiment liefert die Zahl, die Sie sich merken sollten: 67 % des Tokenverbrauchs der Schleife brachten keinerlei Verbesserung, weil nichts der Schleife signalisierte, dass der Zugewinn nur noch logarithmisch wuchs.³⁰ Budgetgrenzen dienen nicht bloß der Kostenkontrolle; sie sind eine Abbruchregel als letztes Mittel.

Testintegrität. Aus den Leitlinien von Anthropic für lang laufende Agenten: „Tests zu entfernen oder zu bearbeiten ist inakzeptabel, weil dadurch Funktionen fehlen oder fehlerhaft sein könnten.“²² Schleifen nutzen Spezifikationen aus — sie bestehen die sichtbaren Tests, verfehlen aber die dahinterstehende Absicht. Deshalb muss die Prüfinstanz selbst vor dem Agenten geschützt werden, den sie beurteilt.

Bewerten Sie Ergebnisse, nicht Wege. Aus dem Essay über Evaluationen: „Bewerten Sie, was der Agent erzeugt hat, nicht den Weg dorthin.“ Verwenden Sie codebasierte Bewertungsverfahren für objektive Kriterien und modellbasierte für Bewertungsraster, und kalibrieren Sie diese: „Ob Ihre Bewertungsverfahren gut funktionieren, wissen Sie erst, wenn Sie die Protokolle und Bewertungen vieler Versuche lesen.“³¹

Eine weitere Unterscheidung bleibt in der Debatte meist unbeachtet: Wenn jede Prüfung in einer Schleife deterministisch ist, gehört überhaupt kein Modell in die Schleife. Eine Abweichungsüberwachung, die Zeitstempel vergleicht, eine Linkprüfung, eine Build-Überwachung — das sind zeitgesteuerte Shell-Skripte: null Tokens, wenige Sekunden pro Durchlauf, vollständig reproduzierbar. Setzen Sie modellgesteuerte Schleifen nur für Iterationen ein, die Urteilsvermögen erfordern. Die günstigste Schleife ist die, die niemals ein Modell aufruft.

Kosten- und Sicherheitsdisziplin

Der lauteste Einwand aus der Community gegen Loop Engineering betrifft die Kosten, und die Fehleranalysen bestätigen ihn: ein Fehler beim Starten von subagents, der in fünf Minuten 4 Mio. Tokens verbrauchte; nächtliche Loops, die Tausende Dollar verschlangen; Nutzungslimits, die „viel schneller als erwartet“ erreicht wurden.³² Eine dieser Grenzen hat sich inzwischen verschoben: Seit v2.1.234 wird eine Sitzung automatisch fortgesetzt, sobald ein claude.ai-Nutzungslimit zurückgesetzt wird (die Einstellung autoContinueAtUsageLimit; abschaltbar unter /config → „Continue automatically at usage limit“).³⁴³⁷ Der Geltungsbereich ist eng. „Automatisches Fortsetzen ist in interaktiven Sitzungen, die mit einem claude.ai-Abonnement angemeldet sind, standardmäßig aktiviert“; bei „einem Zurücksetzen, das mehr als 24 Stunden entfernt ist“, etwa bei einem Wochenlimit, beginnt Claude Code das Warten nicht von sich aus; wer Claude Code beendet, beendet auch das Warten; und in „Hintergrundsitzungen und -p-Läufen“ „bietet Claude Code das Warten gar nicht erst an“, was headless Ralph und claude -p "/goal ..." einschließt.³⁷ Innerhalb einer solchen Sitzung folgen Loops der Einstellung: Ein pausiertes /goal wird beim Zurücksetzen fortgesetzt,⁹ und seit v2.1.271 wartet ein Workflow-Lauf das Limit ab, statt seine Agenten scheitern zu lassen, höchstens zweimal pro Lauf.¹⁶ Ein nächtlicher Loop, der in einer offenen interaktiven Sitzung bleibt, kann das Limit jetzt überdauern; einer, der headless oder in einer Hintergrundsitzung läuft, stoppt weiterhin daran. Damit werden die folgenden Budgetkontrollen noch wichtiger. Daraus hat sich eine Disziplin entwickelt, deren Bestandteile jeweils einer bereits verfügbaren Kontrollmöglichkeit entsprechen:

Die letzte Zeile verdient einen eigenen Absatz, denn so sichern sich selbst die offensivsten Praktiker ab: Begrenzen Sie den Schadensradius auf den Pull Request. Chernys dauerhaft laufende Hintergrundagenten — einer verbessert kontinuierlich die Architektur, einer sucht nach doppelten Abstraktionen — reichen PRs ein, ohne dass ein Mensch sie anstößt;² ohne Review wird nichts zusammengeführt. Ein dauerhaft aktiver Loop, dessen schlimmstmögliches Ergebnis „ein nicht zusammengeführter Branch“ ist, kann intensiv arbeiten; ein Loop, der auf main schreibt, kann das nicht. Geplante Cloud-Aufgaben liefern genau das als Standard: „Claude pusht seine Arbeit auf einen Branch mit dem Präfix claude/, sofern Ihr Prompt es nicht anweist, auf einen anderen Branch zu pushen“, und GitHub-Branch-Schutz oder Rulesets entscheiden, wohin ein Lauf pushen darf.¹⁸ Erweitern Sie die Befugnisse von Loops schrittweise: Beginnen Sie mit reiner Beobachtung (Berichte, keine Schreibzugriffe), lassen Sie durch unspektakuläre Durchläufe Vertrauen entstehen und gehen Sie dann zu Änderungsvorschlägen über — wobei der Nachweis der Ausführungsreihenfolge („die Bereinigung läuft erst, nachdem die Verifikation die neue Markierung zurückgegeben hat“) und eine vollständige Beschreibung des Schadensradius vor der Einrichtung des Zeitplans schriftlich vorliegen müssen. Die Wirtschaftlichkeit dieses stufenweisen Vorgehens behandelt Loops gewinnen dort, wo Verifikation günstig ist: Die Kosten der Verifikation entscheiden darüber, was unbeaufsichtigt laufen kann, nicht die Konstruktion des Loops.

Keine Eingabe eines Loops gilt als Zustimmung. Vier dokumentierte Regeln stimmen überein: Eine Nachricht aus einer anderen Sitzung „gilt niemals als Ihre Zustimmung“;¹⁹ ein Teammitglied „kann keine Berechtigungsabfrage genehmigen und keine Zustimmung in Ihrem Namen erteilen“;¹⁷ der ausgelöste Prompt einer geplanten Cloud-Aufgabe „kann während des Laufs nicht als Genehmigung oder Zustimmung für Aktionen dienen“, und mit einer API-Auslösung gesendeter Text „kommt in einem <routine-fire-payload>-Block an, der ihn als nicht vertrauenswürdige Daten kennzeichnet“;¹⁸ und im Auto-Modus „zählt“ der Prompt, den ein Workflow-Skript an agent() übergibt, „nicht als Anfrage von Ihnen“, weil „Claude Code ihn als vom Skript berechneten Text kennzeichnet“.¹⁶ Übernehmen Sie die Regel in Ihre eigenen Loops: Text, den eine Maschine erzeugt hat, ist Daten, und eine Genehmigung kommt von einem Menschen.

Der tiefgreifendste Einwand betrifft nicht die Kosten, sondern die Review-Kapazität — Loops erzeugen Code schneller, als Menschen ihn sinnvoll prüfen können.³³ Darauf gibt es keine raffinierte Antwort, nur eine ehrliche Eingrenzung: Unbeaufsichtigte Loops gehören genau dorthin, wo sich Ergebnisse maschinell überprüfen lassen, und nirgendwo sonst. Wenn Sie es nicht verifizieren können, veröffentlichen Sie es nicht.

Was eine kontrollierte Studie über harness-Komponenten aussagt

Die meisten Empfehlungen zum harness, auch die dieses Leitfadens, stammen von Praktikern, die im Produktivbetrieb jeweils eine Sache ändern. Eine Studie der UMass Amherst, Emory, UNC Charlotte und Zoom vom September 2026 untersuchte dies unter kontrollierten Bedingungen: Ein eigens entwickelter harness, „dessen Ausführungsschleife unverändert bleibt, während drei Komponenten variiert werden: Planung, Aktionsraum und Kontextverwaltung“, wurde in „176 aufeinander abgestimmten Konfigurationen mit fünf Strategien zur Kontextverwaltung, vier Kontextfensterbudgets und gezielten Ablationen von Planung und Aktionsraum“ auf SWE-Bench Verified und Terminal-Bench 2.1 getestet — mit vier Modellen mit offenen Gewichten, drei Nemotron-3-Größen und Mistral-Medium-3.5-128B.³⁵ Die vier Ergebnisse in den Worten der Autoren:

• „Kontextverwaltung wird mit knapper werdendem Kontextfensterbudget zunehmend wertvoll, wobei der größte Nutzen darin besteht, Fehler durch Kontextüberläufe zu verhindern.“
• „Regelbasiertes Auslassen von Inhalten vor der LLM-basierten Zusammenfassung bietet unter den Strategien zur Kontextverwaltung insgesamt die höchste Effizienz. Ausgelassene Inhalte wieder abrufbar zu machen, fügt dagegen Mechanismen hinzu, die Modelle selten nutzen und die keinen Genauigkeitsgewinn bringen.“
• „Planung wandelt sich von einer Stütze für die Genauigkeit schwächerer Modelle zu einem Mittel zur Kostensenkung bei stärkeren Modellen, deren Genauigkeit sich dabei kaum verändert.“
• „Vordefinierte Werkzeuge verbessern die Leistung von Modellen mit schwächeren Bash-Fähigkeiten. Modelle mit guten Bash-Fähigkeiten können dagegen mit einer reinen Bash-Schnittstelle effektiv arbeiten und deutlich geringere Kosten erzielen, insbesondere bei Aufgaben mit Schwerpunkt auf der Kommandozeile.“

Nach meiner Einschätzung betreffen drei dieser Ergebnisse unmittelbar das Loop Engineering. Kontextverwaltung ist eine Absicherung gegen Überläufe: Ein lang laufender Loop sollte sein Kontextfenster budgetieren und umfangreiche Werkzeugausgaben auslassen, bevor er irgendetwas zusammenfasst. Auf Mechanismen zum erneuten Abrufen, die das Modell ohnehin nicht nutzt, kann er verzichten. Bei einem leistungsfähigen Modell ist Planung eher ein Stellrad für die Kosten als ein Hebel für die Genauigkeit — das sollte man wissen, bevor man einem Loop mit einem starken Modell eine Planungsphase hinzufügt. Und das Ergebnis zur reinen Bash-Schnittstelle entspricht der Trennung von Skriptausführung und Modell auf einer höheren Ebene: Wenn der ausführende Akteur leistungsfähig ist, kosten weniger, dafür umfangreichere Aktionen weniger. Die Einschränkungen nennt die Studie selbst. Vier Modelle, zwei Benchmarks und ein für das Experiment gebauter harness statt eines verfügbaren Agenten — die Ergebnisse lassen sich daher als Richtungen übertragen, nicht als konkrete Einstellungen.³⁵

Eine Flotte betreiben

Der Endzustand des Loop Engineering ist kein einzelner Loop, sondern eine dauerhaft betriebene Flotte. So sieht die Praxis aus, wenn sie sich eingespielt hat:

• Spezifikationen als Dateien. Jeder Loop ist eine versionierte Spezifikation — Name, Stufe, Zeitplan, Ziel, Prüfinstanz, erlaubte Werkzeuge, Budget, Zeitlimit — im Repository, dem er dient. Wenn Sie dieselbe manuelle Prüfung dreimal eingegeben haben, wird daraus eine Spezifikation. Anthropic liefert eine kleine Version dieser Idee aus: Eine loop.md-Datei ersetzt den integrierten Prompt des bloßen /loop, und Änderungen daran werden bei der nächsten Iteration wirksam.¹²
• Zwei Stufen, Aufstieg durch Bewährung. Loops der Stufe Beobachten dürfen alles lesen, schreiben aber nur in ihr eigenes Berichtsverzeichnis und können sofort eingeplant werden. Loops der Stufe Handeln greifen in ihre Umgebung ein und benötigen einen Nachweis der Ausführungsreihenfolge, eine Beschreibung des Schadensradius und eine Prüfinstanz, die nicht zugleich der Ersteller ist — alles schriftlich festgehalten, bevor der Zeitplan existiert. Loops beginnen als Beobachter und verdienen sich den Aufstieg.
• Die Trennung von Skriptausführung und Modell. Deterministische Prüfungen laufen als Skripte (null Tokens, 1–2 Sekunden); Modell-Loops bleiben Aufgaben vorbehalten, die Urteilsvermögen verlangen. Die tägliche Statusprüfung einer Flotte kann kostenlos sein.
• Verbindliche Berichtsvorgaben. Eine Zeile pro Prüfung, PASS|FAIL <check>: <reason>, angehängt an eine mit Datum versehene Berichtsdatei. Wenn Sie keine auf einen Blick erfassbare PASS-Zeile definieren können, ist der Loop noch nicht bereit. Ein Zusammenfassungs-Loop liest die Berichte der Flotte, damit der Mensch eine Seite liest statt dreißig.
• Sich selbst aktualisierende Referenzwerte. Die besten Drift-Wächter leiten ihre Erwartungen aus dem Artefakt ab, das sie überwachen — den im Leitfaden selbst erfassten Zeitstempeln, den Hashes der Lockdatei selbst. So aktualisiert eine Änderung am Artefakt zugleich den Wächter, und es gibt keine zweite maßgebliche Quelle, die man vergessen könnte.
• Dauerhafte Zeitplanung. Lokale Flotten nutzen den Scheduler des Betriebssystems (launchd, cron, systemd-Timer), der ein Ausführungsskript aufruft, oder geplante Desktop-Aufgaben, wenn der Rechner eingeschaltet bleibt; Cloud-Flotten bestehen aus geplanten Cloud-Aufgaben (früher Routinen). Sitzungsgebundene Loops (/loop) eignen sich für Arbeiten, bei denen Sie anwesend sind, oder für eine Sitzung im Hintergrund.¹²

Damit nimmt Chernys Aussage „Meine Aufgabe ist es, Loops zu schreiben“ konkrete Form an: Die menschliche Arbeit verlagert sich darauf, Prüfungen, Prüfinstanzen und Budgets festzulegen — und die Berichte zu lesen.

Die ersten beiden Loops, die sich lohnen

Wenn Sie eine Flotte von Grund auf aufbauen, zahlen sich zwei Loops sofort aus — beide haben sich im harness dieser Website bewährt:

Der Gate-Loop — das Ersteller-Prüfer-Prinzip für alles, was Sie veröffentlichen. Eine frische Bewertungsinstanz (ohne Erinnerung an vorherige Runden) bewertet das Artefakt anhand einer ausdrücklich festgelegten Messlatte; Sie bearbeiten jeden benannten Befund; eine neue Bewertungsinstanz bewertet erneut; der Loop endet beim Erreichen der Messlatte oder einer festen Rundenobergrenze. Zwei Praxiserfahrungen aus einem Sprint mit fünfzehn Beiträgen: Korrekturen können neue Fehler einführen (eine Korrektur ordnete eine Zahl falsch zu, was die Bewertungsinstanz der nächsten Runde erkannte), und Bewertungsinstanzen irren in beide Richtungen — eine „korrigierte“ selbstsicher eine zutreffende Aussage. Deshalb werden konkrete Korrekturen vor ihrer Übernahme anhand der Quelle überprüft. Maßgeblich ist nicht die Prüfinstanz, sondern die Quelle.

Der Platzwart — der Einstieg in die Stufe „Handeln“. Pro Durchlauf eine kleine, objektiv überprüfbare Korrektur auf einem Branch, grüne Tests vor dem Öffnen des PRs, und der Loop führt niemals selbst zusammen. Zwei Regeln sichern ihn ab: Alles Mehrdeutige wird markiert, nicht korrigiert (der erste beaufsichtigte Durchlauf lehnte einen Fehlalarm des Detektors richtigerweise ab), und ein bereits auf main bestehender Fehler wird als solcher gemeldet, niemals in den Diff des Loops übernommen.

Ein Detail aus dem Flottenbetrieb, das Sie übernehmen sollten: Geben Sie unbeaufsichtigten Modell-Loops eine Sitzungslease — verschieben Sie jeden Durchlauf, solange im selben Repository eine interaktive Sitzung aktiv ist. Zwei schreibende Akteure in einem Checkout werden früher oder später ihre Commits vermischen; durch die Lease räumt der Loop dem Menschen grundsätzlich Vorrang ein.

FAQ

Was ist Loop Engineering?

Die Praxis, KI-Agenten Arbeitszyklen wiederholen zu lassen, bis eine Stoppbedingung erfüllt ist, statt ihnen Schritt für Schritt Prompts zu geben. Die Aufgabe des Engineers verlagert sich vom Schreiben von Prompts auf die Gestaltung des Loops: seine Regel für die erneute Auslösung (eine Bedingung, ein Zeitplan, ein Ereignis), seinen Zustand zwischen Iterationen, seine Prüfinstanz und sein Budget. Anthropic benannte die Disziplin im Juni 2026; in Claude Code ist sie über /goal, /loop, das Ralph-Plugin, geplante Cloud-Aufgaben (früher Routinen) und dynamische Workflows zugänglich.

Was ist ein Ralph-Loop?

Ein von Geoffrey Huntley im Juli 2025 benanntes Brute-Force-Muster für autonomes Arbeiten: Claude Code läuft in einer while-Schleife der Shell und erhält bei jeder Iteration denselben Prompt mit frischem Kontext. Fortschrittsdateien und Git übertragen den Zustand zwischen den Durchläufen, während Tests als Gegendruck dienen. Anthropic liefert ein offizielles ralph-loop-Plugin (im Januar 2026 von ralph-wiggum umbenannt), das die Wiederholung innerhalb der Sitzung über einen Stop-Hook umsetzt, wobei --max-iterations als primärer Sicherheitsmechanismus dient.

Wie lasse ich Claude Code in einem Loop laufen?

Wählen Sie die niedrigste passende Ebene: /goal <condition>, um zu iterieren, bis eine separate Bewertungsinstanz eine Bedingung bestätigt; /loop <interval> <prompt> für wiederkehrende Durchläufe, solange eine Claude Code-Sitzung läuft; /ralph-loop, um eine Aufgabe bis zu einer Abschlusszusage zu bearbeiten; /schedule, um eine geplante Cloud-Aufgabe zu erstellen, die per Cron ohne Ihren Rechner läuft. Im Headless-Betrieb ist claude -p innerhalb einer Shell-Schleife mit externer Prüfung die klassische Form.

Ersetzen Loops das Prompting?

Der Prompt verschwindet nicht — er verlagert sich. Sie schreiben ihn einmal in die Spezifikation des Loops, und der Loop löst ihn erneut aus; zunehmend schreibt ein orchestrierender Agent die Prompts für die einzelnen Aufgaben (dynamische Workflows, Chernys „eigentlich übernimmt ein weiterer Claude das Prompting“). An die Stelle des Formulierens von Prompts tritt als menschliches Handwerk die Gestaltung der Verifikation: Bedingungen zu formulieren, die eine Maschine oder ein frisches Modell überprüfen kann.

Was ist der Unterschied zwischen einem Loop, einer Routine und einem Workflow in Claude Code?

Ein Loop (/loop) führt einen Prompt nach Zeitplan innerhalb einer lokalen Claude Code-Sitzung erneut aus und wird nicht mehr ausgelöst, sobald dieser Prozess endet; eine Sitzung im Hintergrund hält ihn am Laufen. Eine geplante Cloud-Aufgabe (früher eine Routine) setzt dieselbe Idee auf Cloud-Infrastruktur um: ausgelöst durch Cron, API oder ein GitHub-Ereignis, ohne dass ein Laptop benötigt wird. Ein Workflow ist der Orchestrierungsgraph eines einzelnen Durchlaufs: ein JavaScript-Skript, das Claude schreibt und das bis zu 1.000 subagents startet und koordiniert, wobei Schleifen und Verzweigungen im Code statt im Kontext verankert sind.

Wie viel kosten Agenten-Loops?

Die ehrliche Spanne reicht von „null bis ruinös“, und entscheidend ist die Gestaltung. Deterministische Wächter kosten nichts — sie sind Skripte mit einem Zeitplan. Modell-Loops werden pro Iteration abgerechnet: Begrenzen Sie sie (--max-iterations, --max-budget-usd), machen Sie ihren Nutzen beobachtbar, damit der Loop bei abnehmendem Ertrag stoppen kann, und behandeln Sie jedes Limit als Stoppregel, nicht als Unannehmlichkeit. Die Fehleranalysen — Tausende Dollar über Nacht, 4 Mio. Tokens in Minuten — haben eine gemeinsame Ursache: keine externe Stoppbedingung.

Wann sollte aus einem Loop ein Graph werden?

Wenn bei paralleler Arbeit Abhängigkeiten entstehen: Eine Aufgabe benötigt das Ergebnis einer anderen, oder zwei Agenten würden dieselben Dateien bearbeiten. Loops bearbeiten ein Repository und ein Ziel; Graphen (dynamische Workflows, Agententeams, externe Orchestratoren) ergänzen eine von Abhängigkeiten bestimmte Reihenfolge, die Reservierung von Dateien und Disziplin beim Zusammenführen. Wechseln Sie erst zu Graphen, wenn tatsächlich Kollisionen auftreten — die zusätzliche Struktur erschwert die Beobachtbarkeit und erhöht den Einrichtungsaufwand.

Änderungsverlauf