/goal, /loop oder Routines: Hören Sie auf, Ihren Coding-Agenten zu babysitten
Wenn Sie noch einen Prompt tippen, warten, die Antwort lesen und den nächsten tippen, ist Ihr Coding-Agent genau so schnell wie Sie. Claude Code hat inzwischen drei Wege, ihn allein weiterarbeiten zu lassen: /goal arbeitet, bis eine Bedingung erfüllt ist, /loop wiederholt einen Prompt in einem Intervall, solange Ihre Session offen ist, und Cloud Scheduled Tasks, die die meisten noch Routines nennen, laufen, wenn Ihr Laptop zugeklappt ist. Sie sehen ähnlich aus, lösen aber verschiedene Probleme. Wer das falsche wählt, hat eine Aufgabe, die zu früh stoppt, ewig läuft oder mehr vom Kontingent verbraucht, als sie spart. So entscheide ich in Kundenprojekten, und so richte ich jede Variante ein, damit ich Ergebnisse prüfe statt jeden einzelnen Schritt.
10 Min. Lesezeit
1. Warum Ping-Pong der eigentliche Engpass ist
In einer normalen Session hält der Agent nach jeder Antwort an und wartet auf Sie. Für eine Frage ist das in Ordnung, aber eine echte Engineering-Aufgabe, etwa ein Modul auf eine neue API umzustellen, braucht Dutzende Turns: Tests laufen lassen, Fehler lesen, korrigieren, erneut laufen lassen. Wenn jeder Turn auf einen Menschen wartet, drücken Sie den ganzen Nachmittag Enter, und der Agent ist meistens untätig. Die Claude-Code-Doku ordnet die drei Optionen nach einer Frage: Was startet den nächsten Turn, und was beendet die Arbeit? Bei /goal startet der nächste Turn, sobald der vorherige fertig ist, und es endet, wenn ein Modell Ihre Bedingung bestätigt oder für unmöglich hält. Bei /loop startet der nächste Turn, wenn ein Intervall abgelaufen ist. Bei einer Routine startet ein Zeitplan, ein API-Aufruf oder ein GitHub-Event eine frische Cloud-Session. Wer so denkt, entscheidet fast mechanisch und benutzt kein Chatfenster mehr als Job-Scheduler.
2. /goal: arbeiten, bis eine Bedingung erfüllt ist
Sie tippen /goal und dahinter die Bedingung, und der Turn startet sofort; einen separaten Prompt brauchen Sie nicht. Laut Doku ist /goal technisch ein session-gebundener, prompt-basierter Stop-Hook: Nach jedem Turn schickt Claude Code die Bedingung und die Unterhaltung an Ihr konfiguriertes kleines, schnelles Modell. Das antwortet mit „noch nicht erfüllt“ (Claude macht weiter und nutzt die Begründung als Hinweis), „erfüllt“ (das Ziel wird gelöscht) oder „unmöglich“ (das Ziel wird mit einem Fehlereintrag gelöscht). Die wichtige Folge: Der Evaluator führt keine Befehle aus und liest keine Dateien. Er beurteilt nur, was Claude im Transkript gezeigt hat. „npm test endet mit 0“ funktioniert also, weil die Testausgabe in der Unterhaltung steht, „der Code ist sauber“ dagegen nicht. Die Bedingung darf bis zu 4'000 Zeichen lang sein, /goal allein zeigt Bedingung, Laufzeit, Turns, Token-Verbrauch und die letzte Begründung, und /goal clear stoppt es. Es läuft auch headless mit claude -p, so fahre ich lange Migrationen in CI-ähnlichen Umgebungen.
/goal all tests in test/billing pass (npm test -- test/billing exits 0),
npm run lint exits 0, no test is skipped or deleted,
no file outside src/billing and test/billing is modified,
and git status shows the work committed on the current branch.
Print the last 20 lines of the test output as proof.
Or stop after 25 turns and list what is still failing and why.Tipp aus der Praxis
/goal ändert Ihren Berechtigungsmodus nicht. Für unbeaufsichtigte Turns starten Sie es im Auto Mode; im manuellen Modus fragt Claude weiterhin vor jedem Tool-Aufruf, den Ihre Einstellungen nicht schon erlauben, und das Ziel wartet auf Sie.
3. Eine Bedingung schreiben, die 25 Turns übersteht
Die Doku empfiehlt drei Zutaten, und meiner Erfahrung nach braucht es alle drei. Erstens einen messbaren Endzustand: ein Testergebnis, einen Exit-Code des Builds, eine Anzahl Dateien, eine leere Queue. Zweitens eine genannte Prüfung, damit Claude weiss, wie es den Beweis liefert, zum Beispiel „npm test endet mit 0“ oder „git status ist sauber“. Drittens die Einschränkungen, die auf dem Weg zählen, etwa „keine andere Testdatei wird geändert“, denn ein Agent unter Druck macht einen Test gerne grün, indem er ihn abschwächt. Ergänzen Sie eine Turn- oder Zeitklausel wie „oder nach 25 Turns stoppen“, die der Evaluator aus der Unterhaltung beurteilt, damit ein Ziel nicht die ganze Nacht läuft. Zwei Fallen sehe ich oft: Bedingungen, die von etwas abhängen, das der Evaluator nicht sieht, etwa ein Dashboard oder eine Datei, die Claude nie ausgegeben hat, und Arbeit, die einen Subagenten oder eine Hintergrund-Shell beschäftigt. Dann überspringt Claude Code die Bewertung, bis ein Turn ohne laufende Arbeit endet, und nach 30 Minuten beginnen Check-ins. Und wenn Claude mehrere Turns lang keine Tools nutzt, stoppt die Schleife und gibt mit gesetztem Ziel an Sie zurück.
Tipp aus der Praxis
Lassen Sie den Agenten am Ende jedes Turns seine Beweise ausgeben (Exit-Codes, Zahlen, die letzten Zeilen des Testlaufs). Der Evaluator kann nur bestätigen, was er lesen kann.
4. /loop: einen Prompt wiederholen, während Sie arbeiten
/loop ist das richtige Werkzeug, wenn es keine Ziellinie gibt, sich aber ausserhalb der Session etwas ändert: ein Pull Request, der Review-Kommentare sammelt, eine Pipeline, ein Deployment. „/loop 10m prüfe die CI auf meinem PR“ läuft nach festem Takt; die Doku nennt s, m, h und d als Einheiten und rundet krumme Intervalle auf einen sauberen Cron-Schritt, mit einer Minute als Untergrenze. Lassen Sie das Intervall weg, wählt Claude nach jeder Runde eine Pause zwischen einer Minute und einer Stunde, kurz, während ein Build fertig wird, lang, wenn nichts passiert. Ein blankes /loop führt den eingebauten Wartungs-Prompt aus, der offene Arbeit fortsetzt, sich um den Pull Request des aktuellen Branches kümmert und Aufräumrunden dreht, oder Ihre eigene .claude/loop.md, falls vorhanden. Drei Grenzen zählen: Session und Rechner müssen laufen, wiederkehrende Tasks verfallen nach sieben Tagen automatisch, und Esc stoppt eine Schleife mit festem Intervall nicht. Sie bitten Claude, sie abzubrechen, etwa „brich die CI-Schleife ab“.
/loop 10m check the CI status and review comments on my open PR.
If a check failed, read the log, fix the cause on this branch, push and say what you changed.
If a reviewer asked for something, address it or reply why not.
When all checks are green and no comment is open, tell me and stop the loop.5. Routines: laufen, während Ihr Laptop zu ist
Eine Routine, die die Doku jetzt Cloud Scheduled Task nennt, ist eine gespeicherte Konfiguration: ein Prompt, ein oder mehrere Repositories und eine Auswahl an Connectoren, ausgeführt auf von Anthropic verwalteter Infrastruktur als vollständige Claude-Code-Session. Sie kann mehrere Trigger gleichzeitig haben. Ein Zeitplan läuft stündlich, nächtlich, wöchentlich oder einmalig, mit einer Stunde als kürzestem Intervall. Ein API-Trigger gibt dem Task einen eigenen Endpunkt: Sie senden einen POST mit Bearer-Token und können ein Feld „text“ mitgeben, etwa den Inhalt eines Alerts. Ein GitHub-Trigger reagiert auf Events wie pull_request.opened oder ein Release, mit Filtern auf Branches und Labels. Jeder Lauf klont die Repositories frisch und pusht auf Branches mit Präfix claude/, sofern der Prompt nichts anderes sagt. Er läuft als Sie: Commits tragen Ihren GitHub-User, und Läufe zählen gegen die Limits Ihres Plans. Angelegt werden Routines unter claude.ai/code/routines oder mit /schedule in der CLI, das nur Zeitplan-Trigger anlegt; API-Trigger gibt es nur im Web. Sie sind noch Research Preview, verfügbar für Pro, Max, Ultra, Team und Enterprise, und Owner von Team und Enterprise können sie für die ganze Organisation abschalten.
# Fire a cloud scheduled task (routine) from an alerting hook.
# URL and token come from the task's API trigger panel on claude.ai/code/routines.
curl -X POST "$ROUTINE_FIRE_URL" \
-H "Authorization: Bearer $ROUTINE_TOKEN" \
-H "anthropic-beta: experimental-cc-routine-2026-04-01" \
-H "anthropic-version: 2023-06-01" \
-H "Content-Type: application/json" \
-d '{"text": "Error rate above 2% on checkout since 14:05 UTC. Stack trace attached."}'Tipp aus der Praxis
Text an den API-Endpunkt kommt als nicht vertrauenswürdige Daten verpackt an, und Claude folgt Anweisungen darin nur, wenn der gespeicherte Prompt es sagt. Nennen Sie den Payload im Prompt ausdrücklich und legen Sie das Token im Secret Store Ihres Alerting-Tools ab.
6. Was wann
Meine Entscheidung passt in drei Fragen. Hat die Aufgabe einen Endzustand, den Tests oder Befehle beweisen können? Dann ist es ein /goal, egal ob „Build grün machen“, ein Framework-Upgrade oder eine grosse Datei aufteilen, bis jedes Modul unter einer Grössengrenze liegt. Muss es ohne Sie laufen, nach Uhrzeit oder bei einem Event? Dann ist es eine Routine in der Cloud, oder ein Desktop Scheduled Task, wenn es Dateien braucht, die nur auf Ihrem Rechner liegen. Gibt es kein Ende, und Sie brauchen es nur, solange Sie ohnehin arbeiten? Dann ist es /loop. In meinen Projekten heisst das: /goal für Migrationen und rote Builds, /loop, um ein Release oder einen Pull Request durchs Review zu begleiten, und Routines für das nächtliche Dependency-Update, den wöchentlichen Check auf veraltete Doku und ein erstes Review bei jedem neuen Pull Request. Probieren Sie die Entscheidungshilfe unten mit einer Aufgabe aus Ihrem eigenen Backlog.
Interaktiv
Welcher Modus passt zu Ihrer Aufgabe?
Beantworten Sie drei Fragen zur Aufgabe, die der Agent Ihnen abnehmen soll.
1.Hat sie ein Ziel, das eine Maschine prüfen kann (Tests grün, Datei da, Kennzahl erreicht)?
2.Soll sie in Intervallen wiederholen oder etwas beobachten?
3.Muss sie laufen, wenn Ihr Laptop aus ist, oder per Zeitplan, API-Aufruf oder GitHub-Event starten?
7. Leitplanken, bevor etwas unbeaufsichtigt läuft
Autonomie ist nur günstig, wenn ein Fehltritt günstig ist. Meine Basis bei jedem Kunden: Agenten arbeiten auf Branches, nie auf main, und Branch Protection oder Rulesets erzwingen das, was auch die Routines-Doku empfiehlt, um zu steuern, wohin Läufe pushen dürfen. Jedes Ziel hat ein Turn-Limit. Auto Mode läuft mit expliziten Deny-Regeln für Secrets wie .env-Dateien und Credential-Ordner, und niemand nutzt den Bypass-Modus auf einem Rechner, der Produktion erreicht. Routines bekommen nur die Repositories und Connectoren, die sie brauchen, denn alles, was sie tun, erscheint unter Ihrem Namen. Behalten Sie auch die Kosten im Blick: /usage zeigt Session-Kosten und Plan-Verbrauch, und ein Ziel pausiert von selbst, wenn Sie ein Nutzungslimit erreichen, statt still zu scheitern. Zum Schluss prüft und merged ein Mensch. In der Praxis prüfe ich einen fertigen Pull Request mit klarer Zusammenfassung statt dreissig Zwischenschritte, und genau dort entsteht die Zeitersparnis.
Tipp aus der Praxis
Starten Sie zwei Wochen lang mit Routines, die nur lesen und berichten (Triage, Zusammenfassungen, Review-Kommentare). Erst wenn deren Ergebnisse durchgehend nützlich sind, erlauben Sie solche, die Code pushen.
8. Was sich fürs Team ändert
Der grösste Wandel ist nicht technisch. Wenn Agenten selbst iterieren, wird die knappe Fähigkeit, „fertig“ präzise zu definieren und gut zu reviewen. Gute Teams schreiben Ziele wie Akzeptanzkriterien, pflegen eine kleine Bibliothek bewährter Bedingungen und Routine-Prompts im Repository und behandeln Änderungen daran wie Code, mit Review. Sie messen auch: Durchlaufzeit vom Ticket bis zur gemergten Änderung, wie oft ein Agenten-Pull-Request Nacharbeit braucht und was jede gemergte Änderung an Plan-Verbrauch kostet. In meinen eigenen Projekten liefert ein kleines Team so Tausende geprüfte Pull Requests im Jahr, ohne dass jemand ein Chatfenster babysittet. Die Werkzeuge werden weiter ihre Namen ändern, wie es Routines gerade getan haben. Das Muster bleibt: eine klare Ziellinie, ein automatischer Auslöser, ein sicherer Arbeitsort und ein menschliches Tor am Ende.
Fazit
Definieren Sie „fertig“ einmal, lassen Sie den Agenten an einem sicheren Ort iterieren und investieren Sie Ihre Aufmerksamkeit ins Review statt in jeden Schritt: Dort entsteht die echte Geschwindigkeit.
Echte Projekte dazu
Selbst ausprobieren
Quellen und offizielle Leitfäden
Weitere Artikel
- 3'025 Pull Requests in zehn Monaten: ein KI-gestützter Delivery-Prozess von innen
- Der EU AI Act für den Mittelstand: was für Sie gilt, und ab wann
- FinOps für KI-Kosten: Tokens, Caching, Routing und Budgets, die halten
- Ein Restaurant-Netzwerk in KI-Antworten sichtbar machen: ein GEO-Projekt Schritt für Schritt
- Wie diese Website gebaut ist: statisch, wo es geht, streamend, wo es muss
- Kubernetes-Kosten auf EKS und GKE: dasselbe Playbook, andere Hebel
- Eine Landing Zone für den Mittelstand, in Terraform oder Bicep: die Teile, die zählen
- Das Playbook für Legacy-Migrationen: Wellen, Parallelbetrieb und identische Zeilenzahlen und Prüfsummen
- MCP-Sicherheit im Detail: KI-Assistenten ins Produkt lassen, ohne die Türen zu öffnen
- Monitoring auf Geschäftsergebnisse: grüne Dashboards, leere Kasse
- KI-Agenten am Telefon: die Architektur, und die Stolperfallen, die keine Demo zeigt
- Restore-Tests: Ein Backup, das nie wiederhergestellt wurde, ist nur eine Hoffnung
- KI-Antworten auf Azure Static Web Apps streamen: der eine Header, der alles zurückhielt
- Einen KI-Assistenten für WhatsApp bauen, von Anfang bis Ende: was es über die Demo hinaus braucht
- Air-gapped-Systeme: kritische Software ganz ohne Internet betreiben
- Produktive KI auf AWS: Amazon Bedrock und AgentCore in einem privaten Setup
- Produktive KI auf Microsoft Foundry: ein privates Referenz-Setup für Agenten
- Claudes neue Pläne: Max, Ultra und was sie für Teams bedeuten
- OpenAI Codex Ende 2026: Goal Mode, Dots und wie man es absichert
- GitHub Copilot, Claude Code oder Codex? So würde ich für ein Unternehmen entscheiden
- GEO-Grundlagen: So erscheinen Sie in KI-Antworten
- Produktive KI auf Google Cloud: von Vertex AI zur Gemini Enterprise Agent Platform
- Lokale LLMs im Air-Gap-Netz: KI für Ihre sensibelsten Daten
- Ich will ein lokales LLM betreiben: Welchen Server soll ich kaufen?
- MiniMax M3: ein offenes Spitzenmodell zum Selbstbetreiben?
- Prompt-Research im grossen Stil mit einem offenen Modell
- SEO und GEO zusammen: ein praktisches Audit in 6 Schritten
- Kubernetes richtig dimensionieren: das Playbook, mit dem ein Cluster von 7 auf 4 Nodes kam
- Private KI für sensible Daten: ein lokales LLM-Setup, das durch die Sicherheitsprüfung kommt
- Vom KI-Prototyp zur Produktion: die acht Schichten, die ich ergänze, in dieser Reihenfolge