Loop Engineering: Claude Code Loops, Routinen und Workflows

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), /loop (wiederkehrende lokale Ausführungen), das offizielle Ralph-Plugin (Iteration, bis ein Versprechen eingehalten ist), 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.234 (August 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 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.¹¹)

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 routine 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 kleines, schnelles Modell, ob die Bedingung erfüllt ist. Falls nicht, beginnt Claude einen weiteren Durchlauf, statt Ihnen wieder die Kontrolle zu übergeben.“⁹ Der Evaluator (standardmäßig Haiku) gibt Ja/Nein sowie eine Begründung zurück, die Claude als Anleitung für den nächsten Durchlauf verwendet. 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.¹¹

Zwei Änderungen in v2.1.234 härten den Loop selbst ab. Ein goal löscht sich nun mit einem Hinweis selbst, wenn ein Durchlauf aufgrund eines nicht behebbaren Fehlers abbricht – etwa wegen widerrufener Authentifizierung, aufgebrauchten Guthabens oder eines Kontextüberlaufs –, statt in einer Sitzung aktiv zu bleiben, die nicht mehr handeln kann. Wenn Hintergrundaufgaben ein goal mindestens 30 Minuten warten lassen, prüft Claude außerdem deren Status, statt unbegrenzt zu warten (CLAUDE_CODE_GOAL_CHECKIN_MINUTES passt den Schwellenwert an; 0 stellt das frühere Verhalten mit unbegrenzter Wartezeit wieder her).³³

/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) 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.“¹³

Die entscheidende Einschränkung: /loop ist an Ihre Sitzung gebunden. Schließen Sie das Terminal, endet der Loop – für dauerhafte Ausführungen sind routines vorgesehen.

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

Das offizielle ralph-wiggum plugin von Anthropic macht aus dem bevorzugten Brute-Force-Muster der Community ein Produkt: 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.¹⁴

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 (oder sagen einfach „use a workflow“); Claude schreibt ein JavaScript-Orchestrierungsskript – agent() startet einen subagent mit optionalen Ausgaben nach dem JSON-Schema, pipeline() führt Elemente durch mehrere Phasen, gewöhnliche await-Anweisungen, loops und Bedingungen steuern den Ablauf –, das anschließend von einer Runtime im Hintergrund ausgeführt wird. „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: 16 agents gleichzeitig, 1.000 pro Lauf („verhindert außer Kontrolle geratene loops“), keine Benutzereingaben während des Laufs; in .claude/workflows/ gespeicherte Skripte werden zu wiederverwendbaren Slash-Befehlen; Läufe lassen sich mit zwischengespeicherten agent-Ergebnissen fortsetzen.¹⁶ 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. 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 (Research Preview seit v2.1.32, Februar 2026) verbirgt sich ein Teamleiter mit Teammitgliedern, die „unabhängig arbeiten, jeweils in ihrem eigenen Kontextfenster, und direkt miteinander kommunizieren“ – also ein Peer-Graph statt eines subagent-Baums. Die Koordination erfolgt über eine gemeinsame Aufgabenliste mit Abhängigkeiten, durch Dateisperren abgesicherte Beanspruchung und Postfächer für jeden agent. Durch hooks erzwungene quality gates (TaskCompleted mit Exit-Code 2 blockiert) schalten maschinelle Prüfungen zwischen ein Teammitglied und den Status „fertig“.¹⁷

Routines – loops, die Ihren Laptop überdauern

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“ – entweder in der von Anthropic verwalteten Cloud oder auf Ihren eigenen selbst gehosteten Runnern.¹⁸ Drei kombinierbare Auslöser stehen zur Verfügung: cron-Zeitplan (Mindestintervall 1 Stunde), API-Auslösung (POST .../routines/{id}/fire) und GitHub-Ereignisse. Die Erstellung erfolgt über /schedule oder claude.ai/code/routines. Die Läufe werden autonom und ohne Genehmigungsaufforderungen ausgeführt – genau deshalb ist der Hinweis in der Dokumentation so entscheidend: Ein grüner Laufstatus „bedeutet nicht, dass die Aufgabe in Ihrem Prompt erfolgreich war. Öffnen Sie den Lauf, lesen Sie das Transkript und prüfen Sie, was Claude tatsächlich getan hat.“¹⁸

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“.¹⁹ Self-hosted runners (v2.1.224, Team/Enterprise) führen Cloud-Sitzungen und routines auf Ihren eigenen Computern aus – die Grundlage für Flotten auf Organisationsebene.²⁰

Das Ralph Pattern

Die Community war zuerst da. Im Juli 2025 veröffentlichte Geoffrey Huntley den Essay, der die Technik nach der Figur aus The 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 übertragen und Tests/Lints als „backpressure“ fungieren.²¹ Die moderne Headless-Variante derselben Struktur ist claude -p "$(cat PROMPT.md)" in einer Shell-Schleife, was im Wesentlichen dem entspricht, was Anthropics eigener C-Compiler-harness ausführte.²³ Seine angegebenen Ergebnisse (der MVP eines 50.000-Dollar-Auftrags für 297 Dollar an Tokens; sechs Repositories über Nacht bei einem Hackathon) gingen mit ebenso klaren Einschränkungen einher: nur für Greenfield-Projekte, Platzhalter- und Doppelimplementierungen als wiederkehrende Fehlermuster sowie „LLMs spiegeln die Fähigkeiten des Operators wider.“

Anthropic verwendet den Namen in seinem technischen Material nie, doch das Pattern ist inzwischen gleich in zweifacher Hinsicht offizielle Doktrin: Der Essay über langlebige agents vom November 2025 schreibt exakt diese Struktur vor — ein Initialisierungsagent erstellt Funktionslisten und Fortschrittsdateien, anschließend folgen frische Programmieragents pro Kontextfenster, die „die Sitzung beginnen, indem sie die Fortschrittsnotizen und Git-Commit-Protokolle lesen“²² — und beim C-Compiler-Projekt vom Februar 2026 liefen sechzehn Claude agents 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. So entstanden über etwa 2.000 Sitzungen rund 100.000 Zeilen Rust für ungefähr 20.000 Dollar.²³ Der Verifikationssatz des Essays enthält die gesamte Theorie des Patterns: „Es ist wichtig, dass der Aufgabenverifikator nahezu perfekt ist.“

Warum frischer Kontext einer einzigen langen Sitzung überlegen ist: Mit zunehmender Auslastung des Sitzungskontexts sinkt die Effektivität — der Konsens unter Praktikern verortet die Schwelle für Abweichungen bei ungefähr 100.000 Tokens — und Komprimierungszusammenfassungen sind verlustbehaftete Paraphrasen, die Fehler in selbstsicher klingende Prosa verwandeln.²⁴ Ralphs Konzept aus frischen Instanzen und Dateien umgeht beides. (Die sitzungsinterne Schleife des offiziellen Plugins gibt einen Teil dieses Vorteils zugunsten der Bequemlichkeit auf; für lange Läufe bleibt die Headless-Variante mit externem Zustand das robustere Pattern.)

Auch das abschreckende Beispiel des Patterns ist lehrreich: Ein Praktiker führte das Plugin mit einem vagen Prompt und max_iterations: 0 aus — was unendlich und nicht deaktiviert bedeutet —, woraufhin Claude sich 1.966-mal dieselbe klärende Frage stellte und der Stop hook jede weitere Nachricht an sich riss.²⁵ Iterationslimits sind unverzichtbar.

Wenn aus Schleifen Graphen werden

Eine einzelne Schleife setzt voraus, dass ihre Iterationen unabhängig voneinander oder streng sequenziell sind. Sobald parallele Arbeit Abhängigkeiten aufweist — Aufgabe B benötigt die Ausgabe von A, zwei agents würden dieselbe Datei bearbeiten —, kollidieren formlose Schleifen, und Sie benötigen eine explizite Struktur: eine Aufgabenliste mit Abhängigkeitsarrays, Dateireservierung und Merge-Disziplin. Das ist der ehrliche Kern der Debatte um Schleifen und Graphen: Schleifen für ein Repository und ein Ziel; Graphen, wenn parallele Arbeit eine Reihenfolge erfordert.²⁶

Die Graphoptionen, nach zunehmendem Infrastrukturbedarf geordnet:

1. Dynamische Workflows — Abhängigkeiten werden im Kontrollfluss von JavaScript ausgedrückt; Barrieren gibt es nur dort, wo eine Phase tatsächlich alle vorherigen Ergebnisse benötigt. Die von Anthropic benannten Topologien: Auffächern und Synthetisieren, adversariale Verifikation, Generieren und Filtern, Turnier („Erzeugen Sie N agents, die dieselbe Aufgabe jeweils mit unterschiedlichen Ansätzen bearbeiten“, anschließend paarweise bewerten) und Schleifen bis zum Abschluss.¹⁵
2. Agent teams — eine gemeinsame Aufgabenliste mit Abhängigkeitsverfolgung und einem Lead, der Pläne genehmigt; der Graph besteht aus Daten, nicht aus Code.¹⁷ Eine Standardeinstellung hat sich für dieses Pattern geändert: Seit v2.1.233 sind die Aufgabenwerkzeuge (TaskCreate/Get/Update/List, TodoWrite) bei Opus 4.8, Sonnet 5, Fable 5 und neueren Versionen standardmäßig deaktiviert — die Dokumentation weist ausdrücklich darauf hin, dass agents ohne die Aufgabenwerkzeuge „über Nachrichten statt über die gemeinsame Aufgabenliste koordinieren“. Bei einer Standardkonfiguration der aktuellen Generation existiert die Aufgabenliste also unbemerkt nicht. Mit CLAUDE_CODE_ENABLE_TODO_TOOLS=1 stellen Sie sie wieder her.³³
3. Externe Orchestratoren — die Skalierungslösungen der Community: Steve Yegges Gas Town führt 20–30 Claude Code-Instanzen anhand von DAGs aus Git-gestützten „beads“ aus (75.000 Zeilen Go in 17 Tagen; nach seiner eigenen Darstellung zugleich „ein Geldfresser“, der hohe Fähigkeiten des Operators voraussetzt);²⁷ claude-flow/Ruflo (rund 31.000 Sterne) organisiert Schwärme in einer Königin-/Worker-Hierarchie; Engines im Stil von LangGraph legen darüber eine typisierte Zustandsmaschine mit Claude Code innerhalb der Knoten.

Chernys eigene Formalisierung dieser Entwicklung ist die im Juli 2026 über Anthropic veröffentlichte Leiter Steps of AI Adoption: Gated (0 agents) → Assisted (~1) → Parallel (~10) → Supervised autonomy (~100, wobei „die meisten agents von Claude und nicht von Menschen gestartet werden“) → AI-native (1.000+). Sein begleitender Rat: „Auf jeder Stufe müssen Sie die nächsten Engpässe identifizieren und beseitigen sowie die nächsten Schutzmechanismen aufbauen.“²⁸

Verifikationstechnik

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

Anthropics Eskalationsleiter, aus dem aktuellen Best-Practices-Dokument: Geben Sie Claude etwas, das ein Bestehen oder Scheitern erzeugt, und „die Schleife schließt sich von selbst“ → eine /goal-Bedingung, die von einem separaten Evaluator erneut geprüft wird → ein Stop hook als „deterministisches Gate“ → „ein Verifikations-subagent oder ein dynamischer Workflow, der seine eigenen Ergebnisse prüft, lässt ein frisches Modell versuchen, das Ergebnis zu widerlegen, sodass der agent, der die Arbeit erledigt, nicht zugleich derjenige ist, der sie bewertet.“²⁹ Die dazugehörige Evidenznorm lautet: „Lassen Sie Claude Belege zeigen, statt den Erfolg lediglich zu behaupten.“

Die drei Feedbackklassen, aus dem Essay über Agent SDK: regelbasiertes Feedback („klar definierte Regeln für eine Ausgabe und anschließend eine Erklärung, welche Regeln warum verletzt wurden“ — die beste Form), visuelles Feedback (Screenshots, Pixel-Diffs) und LLM-as-judge (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 ein judge, der lediglich eine Meinung abgibt.

Konvergenzbedingungen. Die prägnanteste kritische Betrachtung von Schleifen — Yoko Lis Analyse vom August 2026 — reduziert Konvergenz auf vier Voraussetzungen: einen definierten Zielzustand, einen beobachtbaren Istzustand, präzise lokale Änderungen und Stoppregeln außerhalb des Generators. Die entscheidende Zahl aus ihrem instrumentierten Experiment: 67 % des Tokenverbrauchs der Schleife bewirkten keinerlei Verbesserung, weil nichts der Schleife signalisierte, dass der zusätzliche Nutzen nur noch logarithmisch zunahm.³⁰ Budgetlimits dienen nicht bloß der Kostenkontrolle; sie sind die Stoppregel der letzten Instanz.

Testintegrität. Aus Anthropics Doktrin für langlebige agents: „Tests dürfen keinesfalls entfernt oder bearbeitet werden, da dies zu fehlender oder fehlerhafter Funktionalität führen könnte.“²² Schleifen nutzen Spezifikationen aus — sie bestehen die sichtbaren Tests, verfehlen aber die verborgene Absicht —, daher muss der Verifikator selbst vor dem agent geschützt werden, den er bewertet.

Bewerten Sie Ergebnisse, nicht Wege. Aus dem Essay über evals: „Bewerten Sie, was der agent hervorgebracht hat, nicht den Weg dorthin“, verwenden Sie codebasierte graders für objektive Kriterien und modellbasierte graders für Bewertungsraster, und kalibrieren Sie: „Sie wissen erst dann, ob Ihre graders gut funktionieren, wenn Sie die Transkripte und Bewertungen vieler Durchläufe gelesen haben.“³¹

Eine weitere Unterscheidung wird in den meisten Diskussionen übersehen: Wenn jede Prüfung in einer Schleife deterministisch ist, gehört überhaupt kein Modell in diese Schleife. Ein Abweichungswächter, der Zeitstempel vergleicht, ein Linkprüfer, ein Build-Wächter — all das sind zeitgesteuert ausgeführte Shell-Skripte: null Tokens, Sekunden pro Lauf, vollkommen reproduzierbar. Reservieren Sie modellgesteuerte Schleifen für Iterationen, die Urteilsvermögen erfordern. Die günstigste Schleife ist jene, die nie ein Modell aufruft.

Kosten- und Sicherheitsdisziplin

Der lauteste Einwand der Community gegen die Entwicklung von Schleifen betrifft die Kosten, und die Postmortem-Berichte bestätigen ihn: ein Fehler beim Erzeugen von subagents, der in fünf Minuten 4 Millionen Tokens verbraucht; nächtliche Schleifen, die Tausende Dollar kosten; Nutzungslimits, die „viel schneller als erwartet“ erreicht werden.³² Eine dieser Grenzen hat sich inzwischen verschoben: Seit v2.1.234 wird eine Sitzung automatisch fortgesetzt, sobald ein claude.ai-Nutzungslimit zurückgesetzt wird (deaktivierbar unter /config → „Continue automatically at usage limit“) — eine nächtliche Schleife, die zuvor am Limit endete, wird nun fortgesetzt, sobald sich das Zeitfenster wieder öffnet. Dadurch werden die nachfolgenden Budgetkontrollen wichtiger, nicht weniger wichtig.³³ Die daraus entstandene Disziplin, wobei jeder Punkt einer ausgelieferten Kontrollfunktion entspricht:

Die letzte Zeile verdient einen eigenen Absatz, denn so schützen sich die offensivsten Praktiker: Machen Sie den Pull Request zum Schadensradius. Chernys dauerhaft aktive Hintergrund-agents — einer verbessert fortlaufend die Architektur, ein anderer sucht nach doppelten Abstraktionen — reichen ohne menschlichen Auslöser PRs ein;² ohne Prüfung wird nichts zusammengeführt. Eine dauerhaft aktive Schleife, deren schlimmster Fall „ein nicht zusammengeführter Branch“ ist, kann mit hoher Intensität laufen; eine Schleife, die in main schreibt, kann das nicht. Führen Sie Schleifen schrittweise ein: Beginnen Sie rein beobachtend (Berichte, keine Schreibvorgänge), bauen Sie durch unspektakuläre Läufe Vertrauen auf und lassen Sie sie erst danach Änderungen vorschlagen — wobei der Reihenfolgenachweis („Die Bereinigung erfolgt erst, nachdem die Verifikation den neuen Marker zurückgegeben hat“) und eine vollständige Erklärung des Schadensradius vor der Einrichtung des Zeitplans schriftlich festgehalten werden müssen. Die wirtschaftlichen Aspekte dieses Einführungspfads behandelt Schleifen gewinnen dort, wo Verifikation günstig ist: Die Verifikationskosten und nicht die Konstruktion der Schleife entscheiden darüber, was unbeaufsichtigt laufen kann.

Der tiefgreifendste Einwand betrifft nicht die Kosten, sondern die Prüfkapazität — Schleifen erzeugen Code schneller, als Menschen ihn sinnvoll prüfen können.³⁴ Dafür gibt es keine clevere Lösung, sondern nur ehrliche Eingrenzung: Unbeaufsichtigte Schleifen gehören ausschließlich dorthin, wo die Verifikation maschinell prüfbar ist, und nirgendwo sonst. „Wenn Sie es nicht verifizieren können, liefern Sie es nicht aus.“²⁹

Eine Flotte betreiben

Der Endzustand des loop engineering ist nicht ein einzelner Loop, sondern eine dauerhaft einsatzbereite Flotte. So sieht die Praxis aus, sobald sie sich etabliert hat:

• Spezifikationen als Dateien. Jeder Loop ist eine versionierte Spezifikation – Name, Stufe, Zeitplan, Ziel, verifier, zulässige Tools, Budget, Zeitlimit – und liegt in dem Repository, dem er dient. Wenn Sie dieselbe manuelle Prüfung dreimal durchgeführt haben, wird daraus eine Spezifikation.
• Zwei Stufen, Aufstieg nach Bewährung. Observe-Loops dürfen alles lesen, aber nur in ihr eigenes Berichtsverzeichnis schreiben, und können sofort eingeplant werden. Act-Loops greifen in die reale Umgebung ein und erfordern einen Nachweis der Ausführungsreihenfolge, eine Erklärung zum blast radius sowie einen verifier, der nicht der maker ist – alles schriftlich festgehalten, bevor der Zeitplan erstellt wird. Loops beginnen als Observe und müssen sich den Aufstieg verdienen.
• Die Trennung von exec und Modell. Deterministische Prüfungen laufen als Skripte (null Token, 1–2 Sekunden); Modell-Loops bleiben Aufgaben vorbehalten, die Urteilsvermögen erfordern. Der tägliche Herzschlag einer Flotte kann kostenlos sein.
• Berichtsverträge. Eine Zeile pro Prüfung, PASS|FAIL <check>: <reason>, angehängt an eine datierte Berichtsdatei. Wenn Sie keine auf einen Blick verständliche PASS-Zeile definieren können, ist der Loop noch nicht bereit. Ein Digest-Loop liest die Berichte der Flotte, damit ein Mensch nur eine Seite lesen muss statt dreißig.
• Selbstpflegende Baselines. Die besten Drift-Wächter leiten ihre Erwartungen aus dem Artefakt ab, das sie schützen – etwa aus den in einem Leitfaden selbst vermerkten Zeitstempeln oder den Hashes einer lockfile. Dadurch aktualisiert eine Änderung am Artefakt zugleich den Wächter, und es gibt keine zweite Wahrheitsquelle, deren Pflege vergessen werden könnte.
• Robuste Zeitplanung. Lokale Flotten nutzen den Scheduler des Betriebssystems (launchd, cron, systemd timers), der ein Runner-Skript aufruft; Cloud-Flotten verwenden routines. Sitzungsgebundene Loops (/loop) sind für Arbeiten gedacht, bei denen Sie anwesend sind.

Damit wird Chernys „my job is to write loops“ konkret: Die menschliche Arbeit verlagert sich auf die Spezifikation von Prüfungen, verifiers und Budgets – sowie auf das Lesen der Berichte.

Die ersten beiden Loops, die sich zu bauen lohnen

Wenn Sie eine Flotte bei null beginnen, machen sich zwei Loops sofort bezahlt – beide haben sich im harness dieser Website bewährt:

Der Gate-Loop – maker-checker für alles, was Sie veröffentlichen. Ein neuer evaluator (ohne Erinnerung an vorherige Runden) bewertet das Artefakt anhand eines expliziten Maßstabs; Sie beheben jeden benannten Befund; ein weiterer neuer evaluator bewertet erneut; der Loop endet, sobald der Maßstab erreicht oder eine feste Höchstzahl an Runden ausgeschöpft ist. Zwei Praxiserkenntnisse aus einem Sprint mit fünfzehn Beiträgen: Korrekturen können neue Fehler verursachen (die Behebung in einer Runde schrieb eine Abbildung fälschlich einer Quelle zu, was der evaluator der nächsten Runde erkannte), und evaluators irren in beide Richtungen – einer wollte eine wahre Aussage mit großer Überzeugung „korrigieren“. Deshalb werden konkrete Korrekturen anhand der Quelle überprüft, bevor sie übernommen werden. Der checker ist nicht die Autorität; die Quelle ist es.

Der Groundskeeper – der Einstiegspunkt für die Act-Stufe. Pro Durchlauf genau eine kleine, objektiv überprüfbare Korrektur, auf einem Branch; alle Tests müssen grün sein, bevor der PR geöffnet wird; der Loop führt niemals einen Merge durch. Zwei Regeln sorgen für Sicherheit: Alles Mehrdeutige wird markiert, nicht behoben (der erste beaufsichtigte Durchlauf lehnte die Bearbeitung eines Fehlalarms des Detektors richtigerweise ab), und ein bereits vorhandener Fehler auf main wird als solcher gemeldet, niemals in den Diff des Loops aufgenommen.

Ein Detail aus dem Flottenbetrieb, das Sie übernehmen sollten: Geben Sie unbeaufsichtigten Modell-Loops einen session lease – verschieben Sie jeden Durchlauf, solange im selben Repository eine interaktive Sitzung aktiv ist. Zwei schreibende Prozesse mit demselben Checkout werden ihre Commits irgendwann miteinander verschachteln; durch den lease gibt der Loop dem Menschen konstruktionsbedingt Vorrang.

Häufig gestellte Fragen

Was ist loop engineering?

Die Praxis, AI agents Arbeitszyklen so lange wiederholen zu lassen, bis eine Abbruchbedingung erfüllt ist, anstatt sie Zug um Zug durch Prompts anzuleiten. Die Aufgabe des Engineers verlagert sich vom Schreiben der Prompts auf den Entwurf des Loops: seine Regel für die erneute Ausführung (eine Bedingung, ein Zeitplan, ein Ereignis), seinen Zustand zwischen den Iterationen, seinen verifier und sein Budget. Anthropic gab der Disziplin im Juni 2026 ihren Namen; ihre Claude Code-Oberflächen sind /goal, /loop, das Ralph plugin, routines und dynamic workflows.

Was ist ein Ralph loop?

Ein nach Geoffrey Huntley benanntes Brute-Force-Autonomiemuster vom Juli 2025: Claude Code wird in einer Shell-while-Schleife ausgeführt 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 bietet ein offizielles ralph-wiggum plugin, das die Wiederholungen innerhalb der Sitzung über einen Stop hook ausführt; --max-iterations dient dabei als primärer Sicherheitsmechanismus.

Wie führe ich Claude Code in einem Loop aus?

Wählen Sie den niedrigsten passenden Ring: /goal <condition>, um zu iterieren, bis ein separater evaluator die Erfüllung einer Bedingung bestätigt; /loop <interval> <prompt> für wiederkehrende Ausführungen, solange Ihre Sitzung geöffnet ist; /ralph-loop, um eine einzelne Aufgabe bis zu einem Erfüllungsversprechen zu bearbeiten; /schedule, um eine Cloud-routine zu erstellen, die nach einem cron-Zeitplan ohne Ihren Computer 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 wird verlagert. Sie schreiben ihn einmal in die Spezifikation des Loops, der ihn anschließend erneut ausführt; zunehmend schreibt ein orchestrierender agent die aufgabenspezifischen Prompts (dynamic workflows, Chernys „it’s actually another Claude that does the prompting“). An die Stelle des Prompt-Entwurfs als menschliches Handwerk tritt das Verifikationsdesign: Bedingungen so zu formulieren, dass eine Maschine oder ein frisches Modell sie prüfen kann.

Worin unterscheiden sich ein Loop, eine routine und ein workflow in Claude Code?

Ein Loop (/loop) führt einen Prompt nach einem Zeitplan innerhalb Ihrer lokalen Sitzung erneut aus und endet mit ihr. Eine routine verpackt dieselbe Idee für die Ausführung auf einer Cloud-Infrastruktur – ausgelöst durch cron, API oder ein GitHub-Ereignis, ohne dass ein Laptop erforderlich ist. Ein workflow ist der Orchestrierungsgraph eines einzelnen Durchlaufs: ein von Claude geschriebenes JavaScript-Skript, das bis zu 1.000 subagents startet und koordiniert, wobei Loops und Verzweigungen im Code statt im Kontext abgebildet sind.

Wie viel kosten Agent-Loops?

Die ehrliche Spanne reicht von „null“ bis „ruinös“, und die entscheidende Variable ist das Design. Deterministische Wächter kosten nichts – sie sind zeitgesteuerte Skripte. Modell-Loops werden pro Iteration abgerechnet: Begrenzen Sie sie (--max-iterations, --max-budget-usd), machen Sie die Ergebnisse beobachtbar, damit der Loop bei abnehmendem Nutzen stoppen kann, und behandeln Sie jede Begrenzung als Abbruchregel, nicht als Unannehmlichkeit. Die Fehleranalysen – Tausende Dollar über Nacht, 4M Token in wenigen Minuten – haben dieselbe Ursache: Es fehlte eine externe Abbruchbedingung.

Wann sollte aus einem Loop ein Graph werden?

Sobald bei parallelen Arbeiten Abhängigkeiten entstehen: Eine Aufgabe benötigt das Ergebnis einer anderen oder zwei agents würden dieselben Dateien bearbeiten. Loops handhaben ein Repository und ein Ziel; Graphen (dynamic workflows, agent teams, externe Orchestratoren) ergänzen Abhängigkeitsreihenfolgen, Dateireservierungen und Merge-Disziplin. Wechseln Sie erst zu Graphen, wenn tatsächlich Kollisionen auftreten – die zusätzliche Struktur geht zulasten der Beobachtbarkeit und erhöht den Einrichtungsaufwand.

Änderungsprotokoll