` | Paralleles mechanisches Refactoring | v2.1.63+ | Jede Einheit erhält einen eigenen Git-Worktree |
`/goal` ähnelt Ralph Loop am meisten. Im Hintergrund prüft ein Evaluatormodell (standardmäßig Haiku) bei jedem Zug, ob das Ziel erreicht wurde. Falls nicht, enthält die nächste Iteration einen Hinweis, was genau zu beheben ist. Wenn ja, stoppt sie. Ich habe `/goal` ausführlich im Leitfaden zum [autonomen Arbeiten mit Claude Code über Nacht mit /goal](https://ailoot.ai/blog/de/goal-mode-claude-code-codex/) behandelt – darin findest du sofort einsetzbare Szenarien für 14 Stunden Arbeit.
`/batch` ist ein seltener, aber leistungsstarker Befehl. Wenn du dieselbe Änderung in mehr als 100 Dateien vornehmen musst (API-Migration, Austausch von Komponenten, Umbenennung), schickt `/batch` jede Datei an einen separaten Subagenten in einem eigenen Git-Worktree. Die Änderungen geraten nicht in Konflikt – jeder Agent arbeitet in einer isolierten Kopie. Mehr über Subagenten erfährst du im Leitfaden zu [verschachtelten Subagenten](https://ailoot.ai/blog/de/claude-code-nested-subagents/).
In der Beschreibung dieses Ansatzes durch den Autor heißt es schlicht:
Harte Limits für `/loop` und `/goal`:
- Eine Aufgabe läuft, solange Claude Code geöffnet ist. Schließe das Terminal, und die Schleife endet. Für einen längeren Zyklus über Nacht verwendest du einen Remote-Server oder deinen eigenen Shell-Wrapper.
- Die maximale Laufzeit einer wiederkehrenden Aufgabe beträgt **7 Tage** (danach wird sie automatisch gelöscht, um vergessene Schleifen zu verhindern).
- Bis zu **50 gleichzeitige Aufgaben** in einer Sitzung.
Du möchtest ein Setup entwickeln, das Claude zuverlässig macht? Ralph Loop ist nur ein Teil davon. Es lohnt sich, alle drei Komponenten zu berücksichtigen: **KI-Klon + Second Brain + Context Engineering** – diese Kombination macht Claude von einem „Assistenten, der halluziniert“ zu einem Werkzeug, dem du eine Aufgabe geben und dich dann anderen Dingen widmen kannst.
## So startest du deine erste autonome Schleife in 5 Minuten
Das Wichtigste
Am schnellsten startest du mit dem integrierten `/goal`. Öffne Claude Code und gib einen Befehl mit einem Ziel und einer überprüfbaren Stoppbedingung ein. Dann kannst du dich anderen Dingen widmen. Claude generiert Code, führt Tests aus, liest Fehlermeldungen, behebt sie und führt die Tests erneut aus, bis sie bestehen.
5 Schritte:
1. ### Öffne das Projekt in Claude Code
Wechsle im Terminal zum Projektstammverzeichnis und führe `claude` aus. Warte, bis Claude `CLAUDE.md` gelesen und das Repository indiziert hat.
2. ### Lege ein Ziel und eine Stoppbedingung fest
Das Ziel beschreibt, was erledigt werden muss. Die Stoppbedingung gibt an, woran Claude erkennt, dass es fertig ist. Idealerweise ist es ein Befehl, der 0 oder 1 zurückgibt. Beispiel: „Ziel: Alle 23 Tests in `tests/api/*.test.ts` bestehen. Stoppen, wenn `pnpm test` den Exitcode 0 zurückgibt.“
3. ### Führe /goal aus
Befehl:
```
/goal Alle Tests in tests/api/*.test.ts müssen bestehen. Führe pnpm test aus, lies die Fehlermeldungen, behebe sie und führe den Befehl erneut aus. Stoppe, wenn der Exitcode = 0 ist. Maximal 20 Iterationen.
```
Claude startet die Schleife: führt Tests aus – sieht einen Fehler – öffnet die Datei – behebt ihn – führt die Tests erneut aus.
4. ### Setze eine Budgetgrenze
Verwende in einem Hintergrund-Tab `/usage`, um den Verbrauch zu überwachen. Lege für den Tag ein Token- oder Geldlimit fest, damit du nicht dein ganzes Guthaben in einer einzigen Schleife aufbrauchst. Mehr dazu im Leitfaden dazu, [wie du Claude-Code-Limits nicht aufbrauchst](https://ailoot.ai/blog/de/claude-code-token-limits-saving/).
5. ### Widme dich anderen Dingen
Komm in 30 Minuten zurück. Bei einer einfachen Aufgabe steht dort bereits „DONE, alle Tests bestanden“. Bei einer komplexeren Aufgabe lies den Bericht: „bei Iteration 20 gestoppt, Grund X“. Erledige von Hand, was die Schleife nicht geschafft hat, und starte sie dann erneut.
## Verifier-Muster: Wie Claude seine Arbeit in einer Schleife selbst prüft
Das Wichtigste
Claude sollte immer eine Möglichkeit haben, seine Arbeit zu prüfen. Ohne Prüfung beginnt ein Agent in einer Schleife zu halluzinieren – er entscheidet, die Aufgabe sei erledigt, obwohl tatsächlich alles kaputt ist. Ein Verifier ist ein Befehl (Tests, Lint, Evaluatormodell, benutzerdefinierte Prüfung), der ein eindeutiges „fertig/nicht fertig“ zurückgibt.
Es gibt drei Arten von Verifiern:
**1. Technisch (Exitcode)** – am zuverlässigsten. `pnpm test`, `npm run lint`, `tsc --noEmit`, `playwright test`. Sie geben 0 oder 1 zurück, ohne dass eine Interpretation nötig ist. `/goal` funktioniert ebenfalls so – im Hintergrund wird das Haiku-Evaluatormodell verwendet, das bei jedem Zug prüft, ob die Bedingung erfüllt wurde (bis zu 4000 Zeichen).
**2. Evaluatormodell** – ein zweites Modell betrachtet das Ergebnis des ersten Modells und bewertet es anhand eines Kriterienkatalogs. Gut für Aufgaben ohne formale Prüfung („Ist der Schreibstil gut?“ „Passt das Design zur Marke?“). Bei Anthropic heißt dies `Claude Code Review` – ein Modus, in dem ein separater Reviewer-Agent die Arbeit des Hauptagenten auf Logikfehler, Grenzfälle und Sicherheitsprobleme prüft. Laut internen Daten von Anthropic findet er bei großen PRs **84 % der Probleme** (gegenüber 16 % beim Basisansatz).
**3. Benutzerdefinierte Prüfung** – ein Shell-Skript, das du selbst schreibst. „Wenn die Logs das Wort ERROR nicht enthalten, ist es erledigt.“ „Wenn die Datei `output.json` existiert und parsebar ist, ist es erledigt.“ „Wenn die Seite `/pricing` den Status 200 zurückgibt, ist es erledigt.“
```
Finde 10 Gründe, warum dieses Projekt völlig schiefgelaufen sein könnte.
Versetze dich in die Lage, dass etwas schiefgegangen ist.
Ich kann diese Geschichte viele Male durchspielen –
bevor ich sie der Öffentlichkeit zugänglich mache.
```
Der häufigste Anfängerfehler ist, **eine Schleife ohne Verifier zu starten**. Der Agent dreht sich im Kreis: schreibt Code, prüft ihn nicht, glaubt, er sei fertig, geht zur nächsten Iteration über und schreibt um, was er schon erledigt hat. Drei Stunden später herrscht Chaos und die Rechnung beträgt 200 $.
Die beste Regel, die ich gelernt habe: **Schreibe zuerst den Verifier und starte dann die Schleife**. Wenn du die Stoppbedingung nicht in einer Zeile formulieren kannst, ist die Aufgabe noch nicht bereit für Autonomie.
## Wie du eine hohe Rechnung über Nacht vermeidest: Budgetgrenzen und Stoppbedingungen
Das Wichtigste
Eine Schleife ohne Budgetgrenze, Kosten-Stoppbedingung oder Verifier kann eine hohe Rechnung verursachen, bevor es jemand bemerkt. Drei Schutzmaßnahmen können das verhindern: ein Iterationslimit, ein Token- oder Geldlimit und ein Stagnationsdetektor.
Drei wichtige Bremsen für jede Schleife über Nacht:
**1. Iterationslimit.** `--max-iterations 20`. Die Schleife kann nicht öfter als N-mal laufen – selbst wenn der Verifier nicht auslöst. Wenn sie nach 20 Iterationen die Stoppbedingung nicht erreicht hat, steckt die Aufgabe fest und erfordert menschliches Eingreifen.
**2. Token- oder Geldlimit.** `/usage limit 50` – höchstens 50 $ pro Tag. Nähert sich die Schleife dem Limit, stoppt sie automatisch und sendet eine Warnung. Das schützt vor einer außer Kontrolle geratenen Schleife.
**3. Fortschrittsprüfung mit ausdrücklicher Vereinbarung.** Der folgende `HEAD`-Vergleich erkennt neue Commits, nicht jede Codeänderung. Verwende ihn nur in einem isolierten Worktree, in dem jede Iteration mit Codeänderungen vor dem Vergleich einen lokalen Checkpoint-Commit anlegt. Nützliche, noch nicht committete Änderungen verändern `HEAD` nicht und können fälschlich als Stillstand gelten. Bewahre auch das Verifier-Ergebnis auf: Ein neuer Commit belegt eine erfasste Änderung, keine Verbesserung und keinen Erfolg.
Beispielhafter Wrapper-Aufbau mit diesen drei Prüfungen. Kostenabfrage und Agentenaufruf sind vom verwendeten Runner abhängig und keine geprüfte CLI-Installationsanleitung. Bestätige diese Schnittstellen für die installierte Version vor der Anpassung. Die Commit-Prüfung setzt für jede Iteration mit Codeänderungen einen lokalen Checkpoint-Commit voraus. Hinterlässt der Runner nicht committete Änderungen, halte zur Prüfung an, statt „kein Fortschritt“ festzustellen.
```bash
#!/bin/bash
PROMPT="$1"
MAX_ITER=20
MAX_COST_USD=50
COMPLETION="DONE"
PREV_HASH=""
STAGNATION=0
for i in $(seq 1 $MAX_ITER); do
# Money limit
CURRENT_COST=$(claude usage --json | jq '.cost_usd')
if (( $(echo "$CURRENT_COST > $MAX_COST_USD" | bc -l) )); then
echo "STOP: budget cap $MAX_COST_USD reached"
break
fi
# Run
OUTPUT=$(claude code -p "$PROMPT" --auto-accept)
# Completion check
if echo "$OUTPUT" | grep -q "$COMPLETION"; then
echo "STOP: completion signal"
break
fi
# Prüft nur Commit-Fortschritt: Jede Codeänderungsrunde braucht einen Checkpoint-Commit.
# HEAD erkennt keine nützlichen, noch nicht committeten Änderungen.
CURRENT_HASH=$(git rev-parse HEAD 2>/dev/null)
if [ "$CURRENT_HASH" = "$PREV_HASH" ]; then
STAGNATION=$((STAGNATION + 1))
if [ "$STAGNATION" -ge 3 ]; then
echo "STOP: stagnation 3 iterations"
break
fi
else
STAGNATION=0
fi
PREV_HASH="$CURRENT_HASH"
done
```
Prüfe die Fortschrittskontrolle vor einer Erweiterung: Eine Bearbeitung ohne Commit ist nicht erfasste Arbeit; ein Checkpoint-Commit ändert `HEAD`; nur der separate Verifier kann Erfolg feststellen. Drei unveränderte Commitstände bedeuten unter dieser Vereinbarung keine neu erfassten Änderungen, nicht zwingend unveränderte Arbeitsdateien. Danach kannst du ergänzen: eine Slack-Warnung beim Stoppen, einen automatischen Telegram-Bericht am Morgen oder eine Push-Benachrichtigung, wenn das Budget 80 % erreicht. Das Prinzip bleibt dasselbe: Eine Schleife braucht **Bremsen**, nicht nur einen Beschleuniger.
## 5 sofort einsetzbare Szenarien für Schleifen über Nacht
Das Wichtigste
Nicht jede Aufgabe eignet sich für eine autonome Schleife. Gute Kandidaten sind Aufgaben mit einem eindeutigen Verifier, die iterativ bearbeitet werden können: Tests, Refactoring, Überwachung, Artikel-Pipelines, Datenimporte. Schlecht geeignet sind Aufgaben ohne formale Prüfung oder mit mehreren subjektiven Kriterien.
**Szenario 1: Fehlgeschlagene Tests zum Bestehen bringen**
```
/goal Es gibt 47 fehlgeschlagene Tests im Verzeichnis tests/. Ziel: Sie alle bestehen lassen.
Führe pnpm test aus, lies stderr, öffne die Datei mit dem Fehler, behebe ihn und führe pnpm test erneut aus.
Stoppe, wenn Exitcode 0. Maximal 30 Iterationen.
```
**Szenario 2: Umfangreiches Refactoring über 200 Dateien**
```
/batch Ersetze den alten apiV1 API-Client in allen Dateien unter src/**/*.ts durch den neuen apiV2.
Jede Datei erhält einen eigenen Worktree. Führe nach dem Austausch tsc --noEmit aus und behebe alle Fehler.
Führe die Worktrees am Ende zusammen.
```
**Szenario 3: Produktionsüberwachung über Nacht**
```
/loop 30m Alle 30 Minuten https://your-app.example.com/api/health prüfen.
Wenn der Status nicht 200 ist, lies die Logs, finde die Ursache, behebe sie und stelle die Anwendung erneut bereit.
Protokolliere jede Iteration in /tmp/night-monitor.log.
```
**Szenario 4: Großen Datensatz mit Deduplizierung importieren**
```
/goal Importiere die CSV-Datei /tmp/import.csv (12,000 Zeilen) in die Tabelle clients.
Prüfe für jede Zeile anhand der E-Mail-Adresse, ob es ein Duplikat gibt; füge die Zeile ohne Duplikat ein, aktualisiere sie bei einem vorhandenen Duplikat.
Protokolliere Konflikte in /tmp/conflicts.log. Stoppe, wenn die letzte Zeile verarbeitet wurde.
```
**Szenario 5: Artikel-Pipeline (typisches Setup)**
Für einen Onlinedienst oder eine Agentur, die regelmäßig SEO-Artikel benötigt, sieht das Szenario so aus:
```
/loop 8h Alle 8 Stunden: Öffne die Backlog-Datei für Themen mit dem Status 'queued'.
Wenn ein Thema verfügbar ist, führe den Skill zum Schreiben eines Leitfadens aus.
Veröffentliche auf dev. Ändere den Status zu 'review'. Benachrichtige die zuständige Person in Telegram.
```
## Was du in jeder Iteration bereitstellen solltest: CLAUDE.md und das Second Brain als Zustand
Das Wichtigste
Ohne Gedächtnis beginnt Claude jede Iteration von vorn – öffnet das Projekt erneut, liest Dateien und vergisst die Entscheidungen der vorherigen Iteration. Ohne `CLAUDE.md` kennt es die Architektur nicht; ohne `business/` (das Second Brain) fehlt ihm der Produktkontext; ohne Skills erinnert es sich nicht an deine Regeln und deinen Stil. Der Zustand zwischen den Iterationen wird in diesen drei Dateischichten gespeichert. Ohne sie baut die Schleife ab Iteration 5 ab.
Drei Schichten des Projektgedächtnisses machen aus einem einmaligen Prompt eine kontrollierte Schleife:
**1. CLAUDE.md** – die Verfassung des Projekts. Was das Produkt ist, welcher Stack verwendet wird, welche Regeln gelten und was niemals getan werden darf. Claude liest diese Datei beim Start jeder Sitzung und jeder Schleifeniteration. Ohne sie muss Claude das Projekt jedes Mal „neu öffnen“ – das verbraucht Kontext und erhöht das Halluzinationsrisiko. Eine fertige Vorlage und 6 Regeln findest du im [CLAUDE.md](https://ailoot.ai/blog/de/claude-md-template/)-Leitfaden.
**2. Second Brain** – ein Ordner mit Geschäftswissen: Produkt, Zielgruppe, Ziele, Wirtschaftlichkeit, Marketing. Kein Code, sondern Bedeutung. Wenn die Schleife einen Artikel schreibt oder nach einer Antwort für den Support sucht, liest sie das Second Brain und antwortet im Projektkontext statt aus dem Nichts.
**3. Context Engineering** – was genau du Claude in jeder Iteration bereitstellst. Nicht den gesamten Second-Brain-Ordner, nicht das ganze Repository, sondern nur das Relevante. Der Plan Mode hilft dabei: Claude ermittelt, welche Dateien für die Aufgabe benötigt werden, und liest nur diese. Mehr dazu im [Plan-Mode](https://ailoot.ai/blog/de/claude-code-plan-mode/)-Leitfaden.
Das wichtigste operative Prinzip, das ich mir durch Fehler einhämmern musste:
Diese drei Schichten bilden die **drei Säulen** der Methodik: KI-Klon (du hast Claude mit Skills und CLAUDE.md deinen Stil und deine Regeln beigebracht), Second Brain (geschäftliche Zusammenhänge in Dateien) und Context Engineering (was du in jeder Anfrage bereitstellst). Ohne alle drei wird die Schleife zu einem endlosen Zyklus mit einer immer höheren Rechnung.
Das Wichtigste
Was läuft in jeder Sitzung? Unterschiedliche Aufgaben: Eine Schleife behebt Fehler, eine andere schreibt neue Funktionen, eine dritte prüft die PRs des Teams, eine vierte optimiert die Leistung und eine fünfte bereitet Dokumentation vor. Kein großer Allzweck-Agent. Dutzende spezialisierte Agenten, jeder mit eigenem Skill, Ziel und Verifier.
Die entscheidende Neubewertung:
Für einen Unternehmer ohne Programmierer bedeutet das etwas Konkretes. Du hast ein Claude-Konto für 200 $/Monat und einen gewöhnlichen Laptop. Du kannst **5 Schleifen parallel** starten – Support, Artikel, Metriken, Test eines neuen Produkts und Wettbewerbsüberwachung. Jede läuft in einem eigenen Claude-Code-Tab. Am Morgen liest du die Zusammenfassung. Das ist bereits der Arbeitsstandard im Sommer 2026.
## Vier häufige Fehler bei autonomen Schleifen
Das Wichtigste
Die meisten Fehler autonomer Schleifen passen in vier Muster: kein Verifier – der Agent entscheidet selbst, dass er fertig ist; keine Budgetgrenze – die Schleife verbraucht ihr Budget über Nacht; kein Zustand zwischen den Iterationen – Entscheidungen widersprechen einander; eine vage Stoppbedingung – die Schleife weiß nicht, wann sie stoppen soll.
**Fehler 1: „Halluzinationsschleife“**
Der Agent entscheidet, dass er fertig ist, obwohl der Verifier nicht ausgelöst wurde. Oder es gibt überhaupt keinen Verifier. Drei Stunden später sagt Claude: „Alles erledigt!“ – aber die Tests schlagen fehl, die Seite lässt sich nicht öffnen und nichts funktioniert. Du hast bereits 80 $ für sinnlose Iterationen ausgegeben.
**Lösung:** ein strikter Verifier (der `exit code` des Befehls), keine verbale Prüfung.
**Fehler 2: „Das Budget über Nacht verbrannt“**
Ohne Budgetgrenze wird eine Schleife zu einer Granate ohne Sicherungsstift.
**Lösung:** `/usage limit` oder ein externes Skript, das `claude usage --json` verwendet, um die Schleife beim Erreichen eines Schwellenwerts zu stoppen.
**Fehler 3: „Die Schleife hat den Kontext zwischen den Iterationen verloren“**
In Iteration 1 traf Claude eine Architekturentscheidung. In Iteration 7 hatte es sie vergessen und entschied sich für das Gegenteil. Nach 15 Iterationen ist der Code ein einziges Durcheinander.
**Lösung:** eine Zustandsschicht mit `CLAUDE.md` und dem Second-Brain-Ordner. Die Schleife **schreibt** jede Architekturentscheidung in eine Datei, die sie in der nächsten Iteration liest.
**Fehler 4: „Die Stoppbedingung ist ungenau – die Schleife läuft für immer“**
`/goal
## Fragen und Antworten
### Warum kann unverändertes HEAD fälschlich fehlenden Schleifenfortschritt anzeigen?
HEAD bezeichnet einen Commit. Nützliche Änderungen im Arbeitsverzeichnis verändern es erst mit einem Commit. Der Beispieldetektor setzt deshalb nach jeder Iteration mit Codeänderungen einen lokalen Checkpoint-Commit voraus. Fehlt diese Vereinbarung, halte an und prüfe nicht committete Arbeit, statt Stillstand festzustellen.
### Belegt ein neuer Commit eine Verbesserung durch die Schleife?
Nein. Er belegt nur eine aufgezeichnete Änderung. Bewahre das Verifier-Ergebnis beim Checkpoint auf und stoppe anhand der tatsächlichen Abnahmebedingung. Die vom Runner abhängigen Aufruf- und Kostenschnittstellen des Wrappers müssen vor dessen Einsatz geprüft werden.
## Ailoot · Das Unternehmen und sein Projektportfolio
Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle.
Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe.
Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.