Loop Engineering: Von Prompts zu dauerhaften Agent-Loops
🇬🇧 Read in English~10 min read
DevOpsAIloop-engineeringai-agentsgitopsautomationmcpworktreesclaude-codecodex
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Nix ist kein Alles-oder-Nichts-Prinzip. Von einer gepinnten devShell bis hin zu immutablen A/B-OTA-Appliances – sechs Stufen der Einführung des Nix-Geistes, basierend auf praktischen Erfahrungen mit K3s-Clustern, Air-Gapped-Registries und mit Nix erstellten Mailserver-Containern.
Peter Steinberger (PSPDFKit) brachte es auf den Punkt: "Man sollte Coding-Agenten nicht mehr prompten. Man sollte Loops entwerfen, die die Agenten prompten." Boris Cherny, der Claude Code bei Anthropic leitet, arbeitet genauso: "Ich prompte Claude nicht mehr. Ich habe Loops laufen, die Claude prompten und herausfinden, was zu tun ist. Mein Job ist es, Loops zu schreiben."
Das ist Loop Engineering — man ersetzt sich selbst als die Person, die den Agenten promptet, durch ein kleines System, das die Arbeit findet, sie verteilt, prüft, dokumentiert, was erledigt wurde, und den nächsten Schritt festlegt. Sie definieren einen Zweck; die KI iteriert, bis dieser erfüllt ist. Der Hebel hat sich verschoben: weg vom Entwerfen einzelner Prompts hin zum Design von Steuerungssystemen, die Agenten über einen längeren Zeitraum orchestrieren.
Das Überraschende ist, dass dies keine reine Tooling-Übung mehr ist. Vor einem Jahr bedeutete ein Loop noch einen Haufen benutzerdefinierter Bash-Skripte, die man ewig warten musste. Heute sind die Bausteine direkt in den Produkten enthalten — Codex und Claude Code haben sie beide in nahezu identischer Form. Sobald man bemerkt, dass die Struktur dieselbe ist, hört man auf, über das Tool zu streiten, und entwirft einfach einen Loop, der funktioniert, egal in welcher Umgebung man sich gerade befindet.
Ein Loop benötigt fünf Bausteine und einen Ort, um Dinge zu speichern. Jeder hat eine spezifische Aufgabe:
| Baustein | Aufgabe im Loop |
|---|---|
| Automations | Discovery + Triage in einem festen Rhythmus |
| Worktrees | Sichere parallele Ausführung |
| Skills | Persistentes Projektwissen |
| Connectors | Zugriff auf echte Tools (MCP) |
| Sub-agents | Trennung von Maker und Checker |
| State (6.) | Dauerhaftes Rückgrat außerhalb jeder Konversation |
Automations sind das, was einen Loop zu einem tatsächlichen Loop macht und nicht zu einem einmaligen Durchlauf. Ein geplanter Task, ein CI-Job, der weiterläuft, nachdem man den Laptop geschlossen hat, ein Hook, der an einem bestimmten Punkt im Lebenszyklus des Agenten feuert — all das qualifiziert sich.
In der Codex-App erstellen Sie eine Automation im Automations-Tab: wählen Sie das Projekt, den auszuführenden Prompt, die Häufigkeit und ob sie in Ihrem lokalen Checkout oder in einem Hintergrund-Worktree laufen soll. Durchläufe, die etwas finden, landen in einem Triage-Posteingang; Durchläufe, die nichts finden, archivieren sich selbst. OpenAI nutzt diese intern für die tägliche Issue-Triage, die Zusammenfassung von CI-Fehlern, das Schreiben von Commit-Briefings und die Jagd nach Bugs, die letzte Woche eingeführt wurden.
Claude Code erreicht dasselbe über Scheduling und Hooks:
/loop 5m /babysit — einen Prompt in einem Intervall erneut ausführen/loop 30m /slack-feedback — einen Kanal pollen und reagieren/loop 1h /pr-pruner — veraltete PRs bereinigenChernys eigene laufende Loops lesen sich wie eine To-do-Liste: /loop 5m /babysit, /loop 30m /slack-feedback, /loop /post-merge-sweeper, /loop 1h /pr-pruner. Sein kanonischer "Babysit-Loop" in ausführlicher Form: "Überwache alle meine PRs. Behebe Build-Probleme automatisch, und wenn Kommentare eingehen, nutze einen Worktree-Agenten, um sie zu korrigieren."
In dem Moment, in dem man mehr als einen Agenten laufen lässt, beginnen Dateien zu kollidieren. Zwei Agenten, die in dieselbe Datei schreiben, verursachen genau die gleichen Kopfschmerzen wie zwei Engineers, die ohne Absprache in dieselben Zeilen committen.
Ein Git-Worktree löst dies: ein separates Arbeitsverzeichnis auf einem eigenen Branch, das dieselbe Repository-Historie teilt. Die Edits eines Agenten können den Checkout eines anderen buchstäblich nicht berühren.
git worktree, einem --worktree-Flag, um eine Session in einem eigenen Checkout zu öffnen, und isolation: worktree für Sub-Agenten, sodass jeder Helfer einen frischen Checkout erhält, der sich selbst bereinigt.Die mechanische Kollision verschwindet, aber Sie bleiben der Flaschenhals: Ihre Kapazität für Reviews entscheidet darüber, wie viele parallele Agenten Sie tatsächlich betreiben können, nicht das Tool.
Ein Skill ist die Methode, mit der man verhindert, in jeder Session den gleichen Projektkontext erneut erklären zu müssen. Beide großen Tools nutzen dasselbe Format: ein Ordner mit einer SKILL.md darin, die Anweisungen und Metadaten enthält, plus optionale Skripte, Referenzen und Assets.
Zwei Eigenschaften machen Skills in Loops effektiv:
$name oder /skills aus, oder eigenständig, wenn ein Task mit der Skill-Beschreibung übereinstimmt — weshalb eine präzise, nüchterne Beschreibung besser ist als eine clevere.Cherny checkt Slash-Commands in .claude/commands/ ein für jeden Inner-Loop-Workflow, den er mehrmals täglich ausführt, damit sowohl sein Team als auch Claude sie wiederverwenden können.
Ein Loop, der nur das Dateisystem sehen kann, ist ein winziger Loop. Connectors, basierend auf MCP (Model Context Protocol), ermöglichen es dem Agenten, Ihren Issue-Tracker zu lesen, eine Datenbank abzufragen, eine Staging-API aufzurufen oder eine Nachricht in Slack zu posten.
Sowohl Codex als auch Claude Code sprechen MCP, sodass ein Connector, den Sie für das eine schreiben, normalerweise auch im anderen funktioniert. Plugins bündeln Connectors und Skills, sodass ein Teamkollege Ihr gesamtes Setup auf einmal installieren kann, anstatt es aus dem Gedächtnis nachzubauen.
Die übliche Aufteilung in beiden Tools: ein Agent exploriert, einer implementiert, einer verifiziert gegen die Spezifikation. Codex definiert Agenten als TOML-Dateien in .codex/agents/; Claude Code nutzt .claude/agents/ und Agent-Teams, die Arbeit untereinander weitergeben.
Die Verifizierung ist die effektivste Ergänzung für jeden Loop. Cherny: "Geben Sie Claude eine Möglichkeit, seine Arbeit zu verifizieren. Wenn Claude diesen Feedback-Loop hat, wird sich die Qualität des Endergebnisses verdoppeln oder verdreifachen." Der Loop läuft, während Sie nicht zusehen, daher ist ein Verifizierer, dem Sie wirklich vertrauen, der einzige Grund, warum Sie den Platz verlassen können.
Dasselbe Prinzip gilt für die Stop-Bedingung: /goal läuft so lange weiter, bis eine von Ihnen geschriebene Bedingung tatsächlich wahr ist — nach jedem Durchgang prüft ein frisches, kleines Modell, ob die Bedingung erfüllt ist. Das ist die Maker/Checker-Trennung angewandt auf das "Fertigsein" selbst: Der Agent, der die Arbeit erledigt hat, entscheidet nicht mehr, wann die Arbeit abgeschlossen ist.
Kostenhinweis: Sub-Agenten verbrauchen mehr Token — jeder führt seine eigenen Modell- und Tool-Operationen aus. Setzen Sie sie dort ein, wo eine zweite Meinung den Preis wert ist.
Eine Markdown-Datei, ein Linear-Board, irgendetwas, das außerhalb der einzelnen Konversation existiert und festhält, was erledigt ist und was als Nächstes ansteht. Es klingt zu simpel, um wichtig zu sein — und doch ist es derselbe Trick, auf den jeder langlebige Agent angewiesen ist. Das Modell vergisst zwischen den Durchläufen alles, daher muss das Gedächtnis auf der Disk liegen, nicht im Kontext. Der Agent vergisst; das Repo nicht.
In einem Loop ist die State-Datei das Rückgrat: Sie merkt sich, was versucht wurde, was bestanden hat und was noch offen ist, sodass der Durchlauf am nächsten Morgen dort anknüpft, wo der heutige aufgehört hat.
Chernys Regel für langfristige Arbeit: "Jedes Mal, wenn Claude einen Fehler macht, sage ich ihm nicht, dass er es anders machen soll. Ich sage ihm, er soll es in die CLAUDE.md schreiben, einen Skill erstellen oder Ähnliches. Wenn man das tut, kann Claude einfach ewig weiterlaufen." Beachten Sie den Unterschied: CLAUDE.md ist Kontext, keine Erzwingung — um eine Aktion hart zu blockieren, benötigen Sie einen PreToolUse-Hook.
Hier trifft Loop Engineering auf klassisches DevOps. Die Plattform — insbesondere GitOps — wird zur Runtime des Loops:
Teams in großem Maßstab setzen heute bereits Variationen davon ein. Das ist der Unterschied zwischen einem Agenten, der sagt "hier ist der Fix", und einem Loop, der den Fix ausliefert, verifiziert und das Ergebnis kommuniziert.
Osmani ist explizit hinsichtlich der Risiken: Token-Verbrauchsmuster können stark variieren, je nachdem, ob man "token-reich" oder "token-arm" ist, und Loops laufen, während man schläft. Setzen Sie die Guardrails vor dem ersten Durchlauf des Loops:
Dies ist derselbe Loop in Codex, Claude Code oder opencode, da die Bausteine identisch sind. Eine morgendliche Automatisierung ruft einen Triage-Skill auf, der die CI-Fehler von gestern, die offenen Issues und die letzten Commits liest und die Ergebnisse in eine Markdown-Datei schreibt. Für jeden relevanten Befund öffnet ein Thread einen isolierten Worktree und sendet einen Subagenten, um den Fix zu entwerfen; ein zweiter Subagent prüft den Entwurf anhand der Projekt-Skills und bestehender Tests. Connectors öffnen den PR und aktualisieren das Ticket. Alles Unbehandelte landet im Triage-Posteingang. Die State-Datei speichert alles, sodass der nächste Durchlauf dort fortsetzt, wo er aufgehört hat.
Sie haben dies einmal entworfen. Sie müssen keinen dieser Schritte erneut prompten.
Cherny berichtet, in 30 Tagen 259 PRs gelandet zu haben – jede Zeile geschrieben von Claude Code –, nachdem er Ende November 2025 seine IDE deinstalliert hatte. Die Zahl ist als Richtwert zu verstehen: Seine dramatischen Behauptungen zur Skalierung (Hunderte von Agenten, sein Anteil an GitHub-Commits) sollte man mit Skepsis betrachten, und die oft zitierte Zahl von „~4 % der öffentlichen GitHub-Commits“ ist eine Schätzung von SemiAnalysis ohne veröffentlichte Methodik. Aber der implementierbare Kern ist real und heute verfügbar: /goal, /loop, /schedule, Worktrees, Agent View, Hooks, Skills und CLAUDE.md, eingebettet in Loops, die Sie schreiben und verifizieren.
Das praktische Muster, das den Kontakt mit der Realität übersteht: Ein kleiner morgendlicher Loop, der CI-Fehler zusammenfasst und Fixes entwirft, spart die erste Stunde des Tages. Das PR-Review erfolgt immer noch durch einen Menschen – nur eben beim Kaffee statt davor.