Stop Prompting. Start Designing Loops.

Stop making prompts. Start designing loops.

Ein Prompt gibt dir eine Antwort. Ein Loop gibt dir ein System, das weiterarbeitet, auch wenn du den Laptop zuklappst.

Boris Cherny, der bei Anthropic Claude Code leitet, hat es klar gesagt: Er promptet Claude nicht mehr selbst. Er lässt Loops laufen, die Claude prompten, Ergebnisse auswerten und entscheiden, was als Nächstes passiert. Sein Job ist es, Loops zu schreiben.

Peter Steinberger hat es aus einem anderen Blickwinkel formuliert: Du solltest keine Coding-Agents mehr prompten – du solltest Loops designen, die deine Agents prompten. Der Hebel hat sich verschoben. Es geht nicht mehr darum, die perfekte Nachricht zu schreiben. Es geht darum, ein System zu bauen, das Nachrichten für dich sendet, Ergebnisse prüft und entscheidet, was weiter passiert.

Was ein Loop eigentlich ist

Addy Osmani (Google Engineer und Autor des Essays, der diese Praxis bekannt gemacht hat) zerlegt einen Loop in sechs Teile: Automations, Worktrees, Skills, Connectors, Sub-Agents und Memory. Jeder funktionierende Loop ist eine Kombination aus diesen sechs Elementen.

• Automations machen aus einem Loop einen echten Loop statt eines einmaligen Laufs. Das ist ein Cron-Job, ein Webhook oder ein Hook in Claude Code, der ohne dein Zutun auslöst. Der Agent sucht sich Arbeit und triagiert sie, bevor du fragst.
• Worktrees verhindern, dass parallele Agents sich gegenseitig behindern.
• Skills sind Verfahrensanleitungen, die der Agent liest, statt jedes Mal von Null an erklärt zu bekommen.
• Memory ist eine State-Datei auf der Festplatte (meist Markdown), die zwischen den Läufen überlebt. Der Agent vergisst – die Datei nicht.

Starte mit einem einzigen Trigger

Jeder Loop beginnt mit etwas, das ohne dich auslöst. Die einfachste Version ist ein Cron-Job, der einen Claude-Code-Prompt nach Zeitplan ausführt. Die nächste Stufe ist ein Hook, der bei einem bestimmten Ereignis startet (Commit, Datei-Änderung etc.).

Nimm eine wiederkehrende Aufgabe, die du aktuell manuell machst, und mache daraus den ersten Trigger. Beispiel: „Jeden Morgen um 8 Uhr liest der Loop die CI-Fehler von gestern, offene Issues und aktuelle Commits und schreibt die Erkenntnisse in eine Markdown-Datei.“

Das allein ist bereits ein kompletter, funktionierender Loop. Versuche nicht, am ersten Tag das volle Sechs-Komponenten-System zu bauen. Eine einzige Automation, die eine State-Datei schreibt, bringt mehr Hebelwirkung als hundert gut formulierte Prompts – weil sie ohne dich läuft.

Gib dem Loop eine Memory-Datei

Lege eine Markdown-Datei an, nenne sie STATE.md oder PROGRESS.md und platziere sie so, dass jede Iteration des Loops sie lesen und schreiben kann. Diese Datei ist das einzige Gedächtnis des Loops.

Am Anfang jedes Laufs liest der Agent diese Datei zuerst. Am Ende schreibt er hinein, was passiert ist und was als Nächstes kommt. Das ist das PROGRESS.md-Pattern – die wichtigste Datei jedes Loops. Ohne sie startet jeder Lauf bei null.

Strukturiere die Datei mit klaren Abschnitten: Was wurde letzten Lauf erledigt, was ist in Bearbeitung, was ist blockiert, was soll als Nächstes versucht werden. Halte sie kurz. Eine 2000-Zeilen-Memory-Datei ist schlechter als gar keine.

Trenne Writer und Checker

Das Modell, das den Code geschrieben hat, ist (in Osmanis Worten) zu nett, um seine eigene Hausaufgabe zu benoten. Ein einzelner Agent, der schreibt und dann sich selbst bewertet, wird seine Arbeit zu oft als „fertig“ abhaken.

Die Lösung ist das Evaluator-Optimizer-Pattern (von Anthropic beschrieben): Ein Agent generiert, ein zweiter Agent kritisiert anhand objektiver Kriterien, und der Loop wiederholt sich, bis der Check besteht. Der Check muss hart sein: Test-Suite grün, Type-Checker sauber, Build erfolgreich, Linter happy.

Ein zweiter Agent, der nur „review das mal“ bekommt, ohne objektives Signal, ist nur ein zweiter Optimist und wird meist zustimmen.

Isoliere parallele Arbeit mit Worktrees

Sobald mehr als ein Agent am selben Codebase arbeitet, wird Isolation essenziell. Mit git worktree add ../agent-1-branch bekommt jeder Agent sein eigenes Arbeitsverzeichnis auf einem eigenen Branch.

Typisches paralleles Setup:

• Ein Sub-Agent erstellt einen Plan
• Ein zweiter implementiert den Plan in seinem eigenen Worktree
• Ein dritter verifiziert gegen Tests in einem weiteren Worktree

Jeder sieht nur seine eigene Kopie. So skaliert ein Loop von „eine Aufgabe im Hintergrund“ zu einer ganzen Pipeline.

Definiere eine harte Stopp-Bedingung

Ein Loop ohne echte Exit-Bedingung scheitert leise („Ralph Wiggum Loop“). Die Stopp-Bedingung muss von etwas anderem als der Behauptung des Agents geprüft werden können: „Die Test-Suite läuft durch“, „Der Build ist grün“, „Das Ticket ist mit erfolgreichem CI auf Done“.

Setze zusätzlich immer eine maximale Iterationsanzahl (10–20) als Backstop. Wird diese erreicht, ohne dass die echte Bedingung erfüllt ist, soll der Loop stoppen und dich flaggen.

Baue einen Human-Review-Checkpoint ein

Nicht jeder Loop sollte von Tag eins komplett unbeaufsichtigt laufen. Nutze die Autonomy-Ladder:

• Level 1: Nur Vorschläge
• Level 2: Entwürfe, die ein Mensch anwendet
• Level 3: Wendet risikoarme Änderungen selbst an, braucht aber Approval vor Merge/Publish
• Level 4: Vollautomatisch mit Audit-Logs

Starte neu bei Level 1 oder 2, lass den Loop eine Woche laufen, korrigiere Fehler, und erhöhe die Autonomie schrittweise. Level 4 muss man sich verdienen.

Achte auf die Token-Kosten

Ein schlechter Loop, der nachts durchläuft, wird teuer. Teste manuell 3–5 Iterationen, messe den Token-Verbrauch, multipliziere mit max. Iterationen und mit der Häufigkeit der Automation.

Erstelle außerdem eine Command-Allowlist für Shell-Befehle (nur git, npm, ls, cat etc. – was der Task wirklich braucht). Unbeschränkter Shell-Zugriff in einem unattended Loop ist der schnellste Weg von Token-Kosten zu Sicherheitsproblemen.

Baue den zweiten Loop anders als den ersten

Der erste Loop sollte klein, einzelzweckig und stark beaufsichtigt sein. Der zweite Loop sollte sich mit dem ersten verbinden. Dann beginnen Automations, Skills und Memory zusammenzuwirken.

Ein täglicher Triage-Loop schreibt Erkenntnisse in eine gemeinsame State-Datei. Ein zweiter Loop liest diese Datei und nimmt sich das höchstpriorisierte Item vor. Zusammen bilden sie eine Pipeline.

Die Veränderung deines Jobs

Sobald mehrere Loops laufen, verändert sich dein Alltag. Du öffnest nicht mehr ein Chat-Fenster, um Fragen zu stellen, sondern einen Triage-Inbox, um zu sehen, was die Loops über Nacht gefunden haben.

Deine To-do-Liste besteht nicht mehr aus statischen Aufgaben, sondern aus Agents, Routinen und Loops, die Ideen in Drafts, Fixes und Reviews verwandeln.

Du triffst weiterhin die wichtigen Entscheidungen – nur jetzt auf der Ebene des Loop-Designs statt auf Task-Ebene. Du schreibst weniger Prompts, weil die Loops sie für dich schreiben. Deine Aufmerksamkeit gehört den wirklich menschlichen Teilen: dem Review-Checkpoint, der Stopp-Bedingung und dem nächsten Loop, den es sich zu bauen lohnt.