---
title: Loops statt Prompts — das System tippt die nächste Runde.
description: "Boris Cherny baut Loops statt Einzelprompts. Was ein Loop ist, warum manuelles Prompten dich ausbremst — und wie du in Claude Code mit fünf Komponenten startest."
category: workflows
date: 2026-08-21
canonical: https://thanisch.co/wissen/workflows/loops-statt-prompts
url: https://thanisch.co/wissen/workflows/loops-statt-prompts
---

# Loops statt Prompts — das System tippt die nächste Runde.

- Warum Cherny Loops schreibt statt Einzelprompts

- Was ein Loop tut: Ziel wählen, ausführen, prüfen, wiederholen

- Die fünf Komponenten in Claude Code

- Einen ersten Loop-Brief zum Copy-Pasten

> **Kurz gesagt**
> Du definierst ein Ziel. Die KI wählt die nächste Aufgabe, führt sie aus, prüft das Ergebnis und wiederholt — bis fertig oder Stop. In Claude Code baust du das mit *fünf Komponenten*.

Wenn du Claude noch einzelne Prompts schickst, bist du hinterher.

Boris Cherny, Gründer und Head of Claude Code bei Anthropic, sagt es so: Er promptet Claude nicht mehr. Er hat Loops, die laufen — und die prompten Claude und finden heraus, was als Nächstes dran ist. Seine Arbeit: Loops schreiben, nicht jede Runde tippen.

## Das Problem mit manuellem Prompten

Beim manuellen Prompten bleibst du im Hin und Her stecken. Ein Loop übernimmt genau das.

### 1. Nachfragen

Die Antwort ist halb fertig. Du fragst nach. Nochmal. Nochmal.

### 2. Korrigieren

Etwas ist schief. Du kopierst den Fehler zurück und erklärst, was anders soll.

### 3. Die nächste Aufgabe vorgeben

Sobald etwas sitzt, tippst du den nächsten Schritt. Du bist der Scheduler — Prompt für Prompt.

Immer wieder von vorn. Das ist Babysitting, kein System.

## Was ein Loop eigentlich ist

Ein Loop ist kein besserer Prompt. Es ist ein Zyklus: Sense → Decide → Act → Check. Das Modell trifft selbst Entscheidungen, statt einem festen Skript zu folgen.

Du definierst ein **prüfbares Ziel**. Die KI wählt eine Aufgabe, führt sie aus, prüft das Ergebnis und wiederholt den Ablauf, bis das Ziel erreicht ist — oder eine harte Stop-Regel greift.

### 1. Trigger

Was den Lauf auslöst: ein Befehl, ein Zeitplan, ein Hook, ein Ticket.

### 2. Scope

Der abgesteckte Arbeitsbereich — Dateien, Branch, Repo, nicht „irgendwas im Projekt“.

### 3. Action

Was der Agent ausführt: lesen, ändern, Tools bedienen, Tests laufen lassen.

### 4. Budget

Ressourcen- und Iterationslimit. Ohne Cap wird der Loop zum Token-Ofen.

### 5. Stop-Bedingung

Wann fertig ist: Ziel erreicht, kein Fortschritt, Eskalation an dich.

### 6. Report

Wie das Ergebnis dokumentiert wird — State-Datei, Diff, Ticket-Update.

> **Merke**
> Generator und Evaluator trennen. Wer die Arbeit macht, benotet sie nicht selbst. Das macht Loops zuverlässig genug, um ohne dich in jeder Runde zu laufen.

## Fünf Komponenten in Claude Code

Dieselbe Idee steckt in Claude Code nativ. Fünf Bausteine — zusammen ergeben sie den Loop, den Cherny meint.

### 1. Automationen

Sie starten den Loop selbstständig — ohne dass du jede Runde tippst.

In der Praxis: `/loop` wiederholt auf einem Intervall, `/goal` läuft bis eine verifizierbare Bedingung wahr ist, dazu geplante Tasks, Hooks und bei Bedarf GitHub Actions. Cloud-Automationen brauchen den Rechner nicht an; Desktop und `/loop` schon. Wähle den Weg nach dem Job, nicht nach dem Buzzword.

### 2. Getrennte Arbeitsgruppen (Worktrees)

Mehrere Agenten parallel, ohne sich gegenseitig die Dateien zu überschreiben.

Jede Session bekommt einen eigenen Git-Worktree: eigenes Arbeitsverzeichnis, eigener Branch, dieselbe Historie. Session A rührt Session B nicht an — wie zwei Entwickler auf getrennten Branches.

**Worktree**

```
claude --worktree feature-auth
```

### 3. Skills

Sie speichern den nötigen Projektkontext, damit du ihn nicht immer neu erklären musst.

Eine `SKILL.md` hält Konventionen, Checklisten und Abläufe fest. Der Agent lädt sie, wenn die Aufgabe passt — statt bei jedem Lauf von null zu raten. Wissen kompoundiert; der Prompt nicht.

### 4. Verbindungen zu deinen Tools (MCP)

So kann der Loop deine Werkzeuge tatsächlich bedienen — nicht nur Dateien umschreiben.

Über das Model Context Protocol (MCP) hängt Claude Code an Issue-Tracker, Monitoring, Datenbanken, Browser. Ohne MCP: Diffs und Shell. Mit MCP: Ticket lesen, Sentry prüfen, PR öffnen, Notion updaten.

### 5. Sub Agents

Ein anderer Agent prüft die Arbeit als derjenige, der sie ausgeführt hat.

Agent A (Generator) schreibt und löst. Agent B (Evaluator) prüft unabhängig gegen Ziel und Checks. Dieselbe Trennung steckt in `/goal`: nicht der Macher entscheidet allein, ob fertig ist.

> **Die Reihenfolge**
> Erst Ziel und Stop. Dann Automation. Dann Isolation (Worktree), Wissen (Skill), Tools (MCP) und erst danach parallele Sub Agents — sonst multiplizierst du Chaos.

## Loop-Brief zum Einstieg

Ob in Claude Code, Cursor oder im Chat: derselbe Brief. Ersetze die Platzhalter.

**Loop-Brief**

```
Ziel: [prüfbares Ergebnis, z. B. drei Tests grün / fünf Quellen mit Link]
Check: [Pass/Fail — Test, Checkliste, zweiter Agent]
Stop: nach max. [N] Runden ODER kein Fortschritt → an mich eskalieren
State: nach jeder Runde in progress.md: erledigt / offen / blockiert
Regeln: kleine Schritte. Keine Selbstbenotung ohne Check.
Aufgabe: [konkrete Aufgabe heute]
```

Auch ohne IDE: Recherche (Quellen → gegen Links prüfen), Text (Entwurf → zweite Runde gegen Checkliste), wiederkehrende Jobs (fester Trigger, festes Format, „fertig wenn“).

## Wann kein Loop

- Vage Ziele: „mach es besser“, „denk mit“

- Geschmack und Strategie — da brauchst du die Entscheidung, nicht die Wiederholung

- Einmalige Fragen und Überblicke — ein Prompt reicht

- Kein Check möglich — dann darf der Loop nicht allein laufen

## Wenn es schiefgeht

> **Token-Ofen**
> Ohne Budget und ohne „kein Fortschritt → stop“ verbrennt der Loop Credits, bevor er konvergiert.

> **Thrashing**
> Derselbe Bereich zehnmal ohne Bewegung: Ziel zu groß oder Check zu weich. Verkleinern oder eskalieren.

> **Reward Hacking**
> Den fehlschlagenden Test löschen statt den Bug fixen. Deshalb: Evaluator getrennt, Regeln hart.

> **Merke**
> Der Loop holt dich aus dem Babysitting. Er entlässt dich nicht aus der Verantwortung. Lies, was er gebaut hat.

### Welches prüfbare Ziel legst du heute in einen Loop?

Nimm eine Komponente zuerst — oft reicht Automation plus Stop. Die anderen vier kommen, wenn Parallelität oder Tools wirklich nötig sind.

## Dein Aktionsplan

Hak ab, was du erledigt hast:

- [ ] Ein prüfbares Ziel in einem Satz formulieren

- [ ] Check und Stop festlegen (Cap + kein Fortschritt → du)

- [ ] Den Loop-Brief einmal durchlaufen — im Chat oder in Claude Code

- [ ] Eine Automation setzen (/loop, /goal oder Zeitplan)

- [ ] Bei Parallelität: Worktree statt denselben Checkout teilen

- [ ] Einen Skill für den Kontext anlegen, den du sonst jedes Mal tippst

- [ ] Generator und Evaluator trennen — Sub Agent oder zweite Runde

Der Prompt tippt die Runde. Der Loop entscheidet, ob die nächste noch nötig ist.