Erste Schritte mit Loops

• Statt Coding-Agents bei jedem Prompt einzeln anzuweisen, geht der Trend zu einem Agent-Betriebsmuster über, bei dem Arbeitszyklen wiederholt werden, bis eine Stoppbedingung erfüllt ist
• Das Claude-Code-Team klassifiziert Loops nach vier Kriterien: Auslöser, Stoppmechanismus, verwendete Primitive und geeignete Aufgabentypen
• Die wichtigsten Loop-Typen sind Turn-based, Goal-based, Time-based und Proactive
• Nicht jede Aufgabe braucht komplexe Loops; man sollte mit der einfachsten Lösung beginnen und Muster selektiv anwenden
• Die Qualität der Loop-Ausgaben hängt von den umgebenden Systemen ab, daher sind die Pflege der Codequalität und das Management der Token-Nutzung zentral

---

Definition von Loops und Klassifizierungskriterien

• Das Claude-Code-Team definiert einen Loop als Agent, der Arbeitszyklen wiederholt, bis eine Stoppbedingung erfüllt ist
• Vier Kriterien zur Klassifizierung von Loops
  • Wie wird er ausgelöst?
  • Wie wird er gestoppt?
  • Welche Claude-Code-Primitives verwendet er?
  • Für welche Art von Aufgaben eignet er sich am besten?
• Komplexe Loops sind nicht immer nötig; zuerst einfache Lösungen bevorzugen und Muster anschließend selektiv einsetzen

Turn-based Loops

• Werden durch einen User-Prompt ausgelöst und stoppen, wenn Claude die Aufgabe als erledigt einschätzt oder zusätzlichen Kontext benötigt
• Geeignet für kurze Aufgaben, die nicht zu einem regelmäßigen Prozess oder Zeitplan gehören
• Das Management erfolgt über konkrete Prompts und durch bessere Verifikation mithilfe von Skills, wodurch die Zahl der Turns sinkt
• Jeder Prompt startet einen manuellen Loop, bei dem der Nutzer jeden Turn anweist; dies wird als agentic loop bezeichnet
  • Claude sammelt Kontext → führt Aktionen aus → prüft die Aufgabe → wiederholt bei Bedarf → antwortet
  • Beispiel: Bei der Anfrage, einen Like-Button zu erstellen, liest Claude den Code, bearbeitet ihn, führt Tests aus und gibt das Ergebnis zurück; danach prüft der Nutzer manuell und schreibt den nächsten Prompt
• Die Verifikationsphase kann manuelle Abläufe in SKILL.md codieren und so den Bereich erweitern, den Claude selbst prüfen kann
  • Werkzeuge und Connectors müssen enthalten sein, mit denen Ergebnisse betrachtet, gemessen oder interaktiv geprüft werden können
  • Je quantitativer die Verifikation ist, desto einfacher ist die Selbstprüfung

• Beispiel für SKILL.md (verify-frontend-change)

  • Regel, UI-Änderungen vor der Erklärung als abgeschlossen End-to-End zu verifizieren
  • Erfolg beim Editieren allein darf nicht als Abschluss gemeldet werden; wie ein menschlicher Reviewer prüfen
    • Dev-Server starten und die bearbeitete Seite im Browser öffnen
    • Geänderte Elemente direkt bedienen (Buttons, Eingaben, Toggles anklicken), Zustandsänderungen prüfen, Vorher-/Nachher-Screenshots
    • In der Browser-Konsole sicherstellen, dass es null neue Fehler oder Warnungen gibt
    • Mit Chrome Devtools MCP einen Performance-Trace ausführen und Core Web Vitals auditieren
  • Wenn ein Schritt fehlschlägt, korrigieren und ab Schritt 1 erneut ausführen; nicht in einem nur teilweise verifizierten Zustand zurückgeben

Goal-based Loops (/goal)

• Werden durch einen manuellen Prompt in Echtzeit ausgelöst und stoppen, wenn das Ziel erreicht ist oder die maximale Turn-Zahl erreicht wurde
• Geeignet für Aufgaben mit verifizierbaren Abschlusskriterien
• Das Management erfolgt über konkrete Abschlusskriterien und explizite Turn-Obergrenzen, etwa „nach 5 Versuchen stoppen“
• Bei komplexen Aufgaben, für die ein einzelner Turn nicht reicht, verbessert sich die Leistung des Agents durch Iteration
• Wenn mit /goal der Zielzustand definiert wird, entscheidet Claude nicht vorschnell selbst, ob es „gut genug“ ist
  • Bei jedem Stoppversuch prüft ein Evaluator-Modell die Bedingungen; bis zum Erreichen des Ziels oder der vorgegebenen Turn-Zahl wird weitergearbeitet
  • Deterministische Kriterien wie die Zahl bestandener Tests oder ein bestimmter Score-Schwellenwert sind effektiv
• Beispiel
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Time-based Loops (/loop und /schedule)

• Werden in einem festgelegten Zeitintervall ausgelöst und stoppen bei Abbruch durch den Nutzer oder wenn die Aufgabe abgeschlossen ist (PR gemergt, Queue geleert)
• Geeignet für wiederkehrende Aufgaben oder für Schnittstellen zu externen Umgebungen und Systemen
• Das Management erfolgt, indem Intervalle länger gewählt werden oder indem ereignisbasiert statt zeitbasiert reagiert wird
• Manche agentic Aufgaben sind wiederkehrend: Die Aufgabe bleibt gleich, nur die Eingaben ändern sich, z. B. jeden Morgen Slack-Nachrichten zusammenfassen
• Aufgaben mit Abhängigkeit von externen Systemen interagieren, indem sie bei jedem Intervall prüfen und auf Änderungen reagieren, z. B. PRs mit Code-Reviews oder CI-Fehlern
• /loop führt den Prompt in jedem Intervall erneut aus
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop läuft auf dem Computer des Nutzers und stoppt beim Beenden; mit /schedule lässt sich daraus eine Routine machen und in die Cloud verlagern

Proactive Loops

• Werden durch Events oder Zeitpläne ausgelöst, ohne menschlichen Eingriff in Echtzeit
• Jede Aufgabe endet, wenn ihr Ziel erreicht ist; die Routine selbst läuft, bis der Nutzer sie abschaltet
• Geeignet für gut definierte, wiederkehrende Arbeitsabläufe wie Bug-Reports, Issue-Triage, Migrationen und Dependency-Upgrades
• Das Management erfolgt, indem Routinen auf kleinere, schnellere Modelle geroutet werden und das stärkste Modell nur für Teile mit erforderlichem Urteilsvermögen genutzt wird
• Durch Kombination der oben genannten Primitives mit Auto Mode, Dynamic Workflows (Research Preview) usw. lassen sich langlaufende Loops aufbauen

• Beispielkonfiguration für die Verarbeitung von Feedback

  • Mit /schedule (Research Preview) eine Routine zum Prüfen neuer Reports ausführen
  • Mit /goal den Abschluss definieren, mit Skills die Verifikationsmethode dokumentieren
  • Mit Dynamic Workflows Agents für Klassifizierung, Fix und Review jedes Reports orchestrieren
  • Mit Auto Mode die Routine ohne Berechtigungsabfragen ausführen
  • Beispiel für einen kombinierten Prompt: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Codequalität bewahren

• Die Qualität der Loop-Ausgaben hängt von den umgebenden Systemen ab; Systemdesign ist daher wichtig
• Codebase sauber halten: Claude folgt den Mustern und Konventionen der bestehenden Codebase
• Mittel zur Selbstverifikation bereitstellen: Mit Skills den teaminternen „guten Zustand“ codieren
• Zugriff auf Dokumentation erleichtern: In der Dokumentation von Frameworks und Bibliotheken stehen aktuelle Best Practices
• Second Agent für Code-Reviews verwenden: Ein Reviewer mit frischem Kontext ist weniger voreingenommen und nicht von den Schlussfolgerungen des Haupt-Agents beeinflusst; den eingebauten /code-review-Skill oder Code Review für Github nutzen
• Wenn einzelne Ergebnisse unter den Standards liegen, nicht nur einzelne Issues beheben, sondern codieren, dass das System selbst verbessert wird

Token-Nutzung managen

• Loops brauchen klare Grenzen; folgende Prinzipien gelten
• Geeignete Primitive und Modelle wählen: Für kleine Aufgaben sind Multi-Agenten-Setups oder Loops unnötig; für manche Aufgaben günstigere, schnellere Modelle verwenden
• Klare Erfolgs- und Stoppkriterien definieren: Den Abschlusszustand konkretisieren, damit er nicht zu früh erreicht wird
• Pilot vor großem Lauf: Dynamic Workflows können Hunderte Agents erzeugen; zunächst in kleinem Umfang die Nutzung messen
• Für deterministische Aufgaben Skripte verwenden: Skripte auszuführen ist günstiger, als Schritte schlussfolgern zu lassen; z. B. stellt ein PDF-Skill ein Skript zum Ausfüllen von Formularen bereit, das ausgeführt wird, statt jedes Mal Code neu zu generieren
• Routinen nicht häufiger als nötig ausführen: Das Intervall an die Änderungsfrequenz des überwachten Ziels anpassen
• Nutzung prüfen: /usage analysiert die Nutzung nach Skills, Subagents und MCPs; /goal ohne Argumente zeigt die aktuelle Turn-Zahl und Token-Nutzung; /workflows zeigt die Token-Nutzung jedes Agents und kann jederzeit gestoppt werden

Erste Schritte

• Zusammenfassung nach Loop-Typ
  • Turn-based: Verification-Checks delegieren; bei Exploration und Entscheidungen verwenden; Custom-Verification-Skills nutzen
  • Goal-based: Stoppbedingungen delegieren; verwenden, wenn der Abschlusszustand bekannt ist; /goal nutzen
  • Time-based: Trigger delegieren; verwenden, wenn Aufgaben außerhalb des Projekts nach Zeitplan auftreten; /loop und /schedule nutzen
  • Proactive: Prompts delegieren; verwenden, wenn Aufgaben wiederkehrend und gut definiert sind; all das oben Genannte sowie Dynamic Workflows nutzen
• Zum Start die eigene Arbeit betrachten und eine Aufgabe auswählen, bei der man selbst der Engpass ist, um zu entscheiden, welche Teile delegierbar sind
  • Kann man Verifikations-Checks schreiben?
  • Ist das Ziel klar genug?
  • Kommt die Aufgabe nach einem Zeitplan herein?
• Wenn eine Idee entsteht, den Loop ausführen und beobachten, wo er stecken bleibt oder zu viel ausführt; keine Angst vor iterativer Verbesserung