+210 XP

Loops und autonome Runs: /loop, Iteration und Scheduling

# Loops und autonome Runs: Iteration und Scheduling

Manche Arbeit ist nicht eine Aufgabe, sondern dieselbe Aufgabe in Wiederholung, bis eine Bedingung erfüllt ist. „Behebe weiter Bugs, bis alle Tests durchlaufen.“ „Prüfe das Deployment jede Minute, bis es live ist, dann sag mir Bescheid.“ „Fasse jeden Morgen um 8 zusammen, was sich über Nacht im Repo geändert hat.“ Keine davon ist eine einzelne Aktion. Es sind Loops mit einer Abbruchbedingung, und Claude Code handhabt sie auf zwei unterschiedliche Weisen, je nachdem, ob die Wiederholung innerhalb eines Runs oder über viele geplante Runs hinweg passiert.

In dieser Lektion geht es darum, Claude Code in einem Loop laufen zu lassen: iterieren, bis ein Ziel erreicht ist, autonom arbeiten, ohne dass Sie jeden Schritt begleiten, und einen Agenten in einem festen Takt starten lassen. Genauso wichtig: die Guardrails, die verhindern, dass ein unbeaufsichtigter Run Ihr Token-Budget oder Ihre Codebasis verbrennt.

Wann ein Loop das richtige Werkzeug ist

Ein Loop lohnt sich, wenn drei Dinge zutreffen:

  • Die Aufgabe wiederholt sich. Sie führen dieselbe Operation mehr als einmal aus (pollen, wiederholen, iterieren).
  • Es gibt eine messbare Abbruchbedingung. Tests laufen durch, ein Build ist grün, eine Datei existiert, ein Wert überschreitet einen Schwellenwert. Wenn Sie „fertig“ nicht präzise beschreiben können, können Sie nicht sicher loopen.
  • Das Ergebnis verbessert sich mit jedem Durchlauf, oder Sie warten auf eine externe Änderung. Tests zu reparieren verbessert sich mit jedem Durchlauf. Einen Build zu pollen wartet auf etwas Externes.

Wenn keines davon zutrifft, ist ein einzelner Call schlanker und billiger. Loopen Sie nicht, nur weil Sie es können. „Refaktoriere diese Funktion“ ist ein Call. „Refaktoriere jede Funktion, bis der Linter still ist“ ist ein Loop.

Wie Iteration in Claude Code tatsächlich funktioniert

Claude Code läuft in Ihrem Terminal und hat bereits Zugriff auf Ihre Dateien, Ihre Shell und Ihre git-Historie. Es gibt kein eigenes Loop-Kommando. Stattdessen erhalten Sie Iteration auf eine von zwei Weisen.

Die erste Weise ist innerhalb eines einzelnen Runs. Sie beschreiben die Aufgabe, die Abbruchbedingung und eine harte Obergrenze direkt in Ihrem Prompt, und Claude führt die Arbeit aus, prüft die eigene Ausgabe gegen die Bedingung und wiederholt, bis die Bedingung erfüllt oder die Obergrenze erreicht ist. Claude kann ein Kommando ausführen, das Ergebnis lesen, entscheiden, ob es fertig ist, und erneut handeln, alles innerhalb einer Session. Das ist das Muster „mach weiter bis X“.

Die zweite Weise ist ein Shell-Loop um den Headless-Modus. Sie rufen claude -p "..." (ein einzelner Prompt, der läuft und beendet wird) aus einer bash-while-Schleife oder einem Skript auf, und Ihr Skript verantwortet die Wiederholung, die Verzögerung zwischen den Runs und die Exit-Logik. Das ist die richtige Form, um etwas Externes in einem festen Intervall zu pollen, weil Ihr Skript das Timing kontrolliert.

Hier ist das Muster innerhalb der Session. Sie geben Claude die Aufgabe, die Abbruchbedingung und die Obergrenze in einfacher Sprache:

bash
claude
> Run the full test suite with pytest. If any tests fail,
  read the failure output, fix the SOURCE code (not the tests),
  and run the suite again. Repeat until all tests pass or you
  have made 10 attempts. If you hit 10 attempts, stop and tell me
  what is still failing.

Beachten Sie die drei Dinge, die in diesem Prompt eingebaut sind. Die Aufgabe ist explizit (pytest ausführen, Code reparieren). Die Abbruchbedingung ist eindeutig (alle Tests laufen durch). Und es gibt eine harte Obergrenze (10 Versuche), damit ein hartnäckiger Bug nicht endlos kreisen kann.

Und hier ist das Intervall-Muster als Shell-Loop, nützlich, wenn Sie auf etwas außerhalb Ihrer Kontrolle warten:

bash
# Poll a deploy every 30s, up to 20 times, until it returns 200
for i in $(seq 1 20); do
  if curl -sf -o /dev/null https://myapp.example.com/health; then
    claude -p "The deploy is live. Post a one-line 'shipped' note."
    break
  fi
  sleep 30
done

Das Skript verantwortet den Loop, die Verzögerung und die Obergrenze. Claude läuft nur, wenn es etwas zu tun gibt.

Warum die Abbruchbedingung maschinell prüfbar sein muss

„Repariere den Code, bis er gut aussieht“ ist keine Loop-Bedingung. Claude hat kein objektives Signal zum Prüfen, also wird es entweder willkürlich aufhören oder endlos weiterpolieren. „Repariere den Code, bis pytest mit 0 endet“ ist prüfbar: Der Exit-Code ist ein Fakt, kein Urteil.

Gute Loop-Bedingungen sind Dinge, die ein Kommando beantworten kann:

  • pytest-Exit-Code ist 0
  • npm run build läuft erfolgreich
  • git status zeigt keine uncommitteten Änderungen
  • ein bestimmter String erscheint in einer Logdatei
  • ein HTTP-Endpunkt gibt 200 zurück

Immer wenn Sie „fertig“ als Kommando ausdrücken können, das Erfolg oder Fehler zurückgibt, haben Sie einen Loop, dem Sie zutrauen können, von selbst zu stoppen.

Das durchgearbeitete Beispiel: reparieren, bis die Suite grün ist

Das ist der kanonische Use Case, machen wir ihn also konkret. Sie haben eine Test-Suite mit einer Handvoll Fehlern nach einem unsauberen Merge. Sie wollen, dass Claude iteriert: Tests laufen lassen, lesen, was kaputt ist, den Source patchen, erneut laufen lassen, bis die ganze Suite grün ist.

bash
claude
> Goal: make the entire test suite pass.
  1. Run: pytest -x --tb=short
  2. If exit code is 0, the goal is met. Stop and summarize what changed.
  3. If tests failed, read the traceback, fix the SOURCE code only.
     Never edit or delete tests to make them pass.
  4. Commit each fix with a clear message, then repeat from step 1.
  Budget: stop after 8 attempts and report if not green by then.

Lesen Sie die Guardrails, die in diesem Prompt versteckt sind. Schritt 3 verbietet die häufigste Abkürzung, nach der ein autonomer Agent greift: den fehlschlagenden Test löschen. Ohne Einschränkung kann ein Modell, das aufgefordert wird, „Tests zum Laufen zu bringen“, durchaus entscheiden, dass der schnellste Weg ist, den Test zu entfernen. Die Anweisung „fix the SOURCE code only, never edit tests“ schließt diese Tür.

Die Anweisung, pro Fix zu committen, ist ebenfalls wichtig. Sie gibt Ihnen eine saubere git-Historie zum Review und ein einfaches Revert, falls einer von Claudes Fixes falsch war. Wenn der Run endet, reviewen Sie das Diff, nicht den Prozess.

Genau bei dieser Art von Aufgabe zahlt sich Iteration aus. Ein einzelnes Reparieren-und-Stoppen würde eine Runde Fehler beseitigen und wahrscheinlich eine zweite Runde offenlegen, die es nie angefasst hat. Iteration arbeitet sich durch alles, während Sie etwas anderes tun.

Autonomous Test-Fixing Loops in Claude Code

Watch on YouTube

Guardrails für unbeaufsichtigte Runs

Sobald ein Run abläuft, ohne dass Sie jeden Schritt beobachten, kann er in Maschinengeschwindigkeit Schaden anrichten oder Geld verschwenden. Drei Guardrails sind nicht verhandelbar.

1. Ein hartes Budget

Jeder Loop braucht eine Obergrenze, die nicht vom Urteil des Modells abhängt. Eine Versuchszahl im Prompt ist die einfachste Variante. Wenn Ihr Skript den Loop verantwortet, begrenzen Sie dort die Anzahl der Iterationen (das for i in $(seq 1 20) oben ist genau das). Das Budget ist ein Fallback für den Fall, dass die Abbruchbedingung nie eintritt, denn manchmal lassen sich die Tests wirklich nicht zum Laufen bringen, und dann soll der Run aufgeben und Ihnen Bescheid geben, statt endlos weiterzuprobieren.

2. Eine klare Abbruchbedingung

Oben behandelt, gehört aber auf die Guardrail-Liste, weil sie der primäre Sicherheitsmechanismus ist. Das Budget ist der Fallback; die Abbruchbedingung ist der vorgesehene Ausgang. Ein Run mit Budget, aber ohne echte Abbruchbedingung läuft jedes Mal einfach bis zur Obergrenze.

3. Ein menschliches Review-Gate

Für alles, was Zustand ändert (Code schreibt, Commits pusht, Nachrichten sendet, eine bezahlte API aufruft), legen Sie vorab fest, wo ein Mensch abzeichnet. Zwei gängige Muster:

  • Review am Ende. Der Run läuft vollständig autonom, produziert aber nur einen Branch und ein Diff. Sie reviewen vor dem Merge. Das ist das Green-Tests-Beispiel: Commits stapeln sich auf einem Branch, nichts geht live, bis Sie es sagen.
  • Review pro Aktion. Sie konfigurieren die Permission-Prompts von Claude Code so, dass riskante Operationen (Dateischreibvorgänge außerhalb eines Verzeichnisses, Shell-Kommandos, Netzwerkaufrufe) jedes Mal Ihre Zustimmung brauchen. Langsamer, aber angemessen, wenn der Blast Radius groß ist.

Sie steuern das über die Permission-Einstellungen von Claude Code. Beschränken Sie, welche Tools der Agent verwenden und welche Verzeichnisse er anfassen darf, bevor Sie ihn unbeaufsichtigt laufen lassen. Die Claude Code Dokumentation behandelt Permission-Modi und Tool-Konfiguration im Detail.

Eine nützliche Regel im Kopf: Je autonomer der Run, desto engere Sandbox. Ein Run, den Sie beobachten, kann weitreichende Permissions haben. Einer, der um 3 Uhr nachts startet, während Sie schlafen, sollte fast nichts anfassen können außer der einen Sache, für die er da ist.

Wissenscheck

1. Was ist laut Lektion der wesentliche Unterschied zwischen einer Aufgabe, die einen Loop rechtfertigt, und einer, die ein einzelner Call sein sollte?

2. Warum besteht die Lektion darauf, dass Sie „fertig“ präzise beschreiben können müssen, bevor Sie einen Loop verwenden?

3. Ein Entwickler möchte, dass Claude ein CI-Deployment jede Minute pollt und ihn benachrichtigt, sobald es live geht. Welche /loop-Variante passt und warum?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die zwei Varianten des /loop-Kommandos korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Elemente, die laut Lektion die Form eines gut geformten /loop-Kommandos definieren.

Wählen Sie alle richtigen Antworten aus.

Scheduling: Runs, die in einem Takt starten

Iteration beantwortet „wiederhole, bis fertig“. Scheduling beantwortet „lauf später wieder, in einem Rhythmus“. Ein wiederkehrender Digest, ein nächtlicher Dependency-Check, ein Wochenbericht: Das sind keine Runs, die bis zu einer Bedingung kreisen, sondern Aufgaben, die nach Zeitplan aufwachen.

Claude Code betreibt keinen Hintergrund-Daemon. Sie planen es genauso, wie Sie jedes Kommandozeilen-Tool planen: mit dem Scheduler Ihres Betriebssystems (cron unter Linux und macOS, Task Scheduler unter Windows) oder einem CI-Runner wie GitHub Actions.

Hier ist ein nächtlicher Repo-Digest als cron-Eintrag, der Claude im nicht-interaktiven (Headless-)Modus ausführt:

bash
# Every weekday at 8:00 AM, summarize overnight git activity
0 8 * * 1-5 cd /home/me/project && \
  claude -p "Summarize commits from the last 24 hours grouped by \
  author. Flag anything touching auth/ or billing/. Output markdown." \
  >> ~/digests/daily-$(date +\%F).md 2>&1

Das -p-Flag führt einen einzelnen Prompt aus und beendet sich, genau das, was Sie für einen geplanten Job wollen: keine interaktive Session, deterministischer Start und Abschluss, Ausgabe in eine Datei umgeleitet. Kombinieren Sie das mit einem MCP-Server, und derselbe geplante Run könnte diesen Digest in Slack posten oder ein GitHub-Issue öffnen. Wie Sie diese Verbindungen verdrahten, steht in den Model Context Protocol Docs.

Für Scheduling, das bei Ihrem Repo statt auf einer Maschine lebt, ist GitHub Actions das natürliche Zuhause. Anthropics offizielle Claude Code GitHub Action lässt Sie Claude nach Zeitplan oder bei Repo-Events auslösen (ein neuer PR, ein Issue mit einem bestimmten Label). Ein wöchentlicher on: schedule-Workflow, der Claude Dependencies auditieren und einen PR öffnen lässt, ist ein sauberer, reviewbarer, geplanter autonomer Run.

Geplante Runs brauchen dieselben Guardrails, nur mehr davon

Ein geplanter Job ist per Definition autonom: Niemand schaut zu, wenn er startet. Alles aus dem Guardrails-Abschnitt gilt doppelt. Geben Sie ihm ein Budget, geben Sie ihm eine Abbruchbedingung selbst für einen einmaligen Digest (damit ein hängender externer Aufruf ihn nicht weiterlaufen lässt), und leiten Sie alles, was Zustand ändert, über ein Review-Gate. Ein geplanter Run, der einen PR öffnet, ist sicher. Ein geplanter Run, der auf main pusht, ist eine Fußangel, die auf eine schlechte Nacht wartet.

Iteration gegen Scheduling gegen einen einzelnen Call

Kurzer Entscheidungsleitfaden:

  • Einzelner Call: eine Aufgabe, keine Wiederholung, Sie sind dabei. „Refaktoriere dieses Modul.“
  • Iteration innerhalb der Session: beschreiben Sie Aufgabe, prüfbare Abbruchbedingung und eine Versuchsobergrenze in einem Prompt; Claude wiederholt, bis es fertig ist. „Repariere, bis die Tests durchlaufen, max. 8 Versuche.“
  • Shell-Loop um claude -p: Ihr Skript verantwortet die Wiederholung und die Verzögerung und ruft Claude in jedem Durchlauf auf. Am besten, um etwas Externes in einem Intervall zu pollen. „Prüfe das Deployment alle 30s, bis es live ist.“
  • Geplanter Run: wacht in einem Takt auf, meist mit einer frischen einzelnen Aufgabe, per cron oder GitHub Actions mit claude -p. „Jeden Morgen, Digest des Repos.“

Die stärksten Setups kombinieren beides: ein geplanter GitHub-Actions-Workflow, der nachts startet und innerhalb dieses Runs Claude iterieren lässt, bis seine Dependency-Upgrades die CI bestehen. Takt außen, Iteration innen.

Wichtigste Erkenntnisse

  • Loopen Sie nur, wenn die Aufgabe sich wiederholt und „fertig“ maschinell prüfbar ist. Wenn Sie die Abbruchbedingung nicht als Kommando ausdrücken können, das Erfolg oder Fehler zurückgibt, haben Sie noch keinen sicheren Loop.
  • Claude Code hat kein eigenes Loop-Kommando. Iteration bekommen Sie, indem Sie Aufgabe, Abbruchbedingung und eine Versuchsobergrenze in einem Prompt beschreiben, oder indem Sie claude -p in einen Shell-Loop packen, der die Wiederholung verantwortet.
  • Jeder unbeaufsichtigte Run braucht drei Guardrails: ein hartes Budget (Versuche, Zeit oder Tokens), eine klare Abbruchbedingung und ein menschliches Review-Gate für alles, was Zustand ändert.
  • Nehmen Sie dem Agenten die Abkürzung. „Bring die Tests zum Laufen“ lädt dazu ein, Tests zu löschen; sagen Sie „repariere nur den Source, editiere niemals Tests“ und committen Sie jeden Fix, damit Sie ein sauberes Diff reviewen und keinen Blackbox-Prozess.
  • Planen Sie mit den Werkzeugen, die Sie schon haben: cron, Task Scheduler oder GitHub Actions, die claude -p im Headless-Modus ausführen. Claude Code ist der Worker, nicht der Scheduler.
  • Je autonomer der Run, desto engere Sandbox. Ein Run, den Sie beobachten, kann weitreichende Permissions haben; einer, der startet, während Sie schlafen, sollte nur die eine Sache anfassen können, für die er existiert.