Loop Engineering – Ein System entwerfen, das Agents promptet

• Statt Coding-Agents in jeder Runde direkt selbst zu prompten, geht der Trend dahin, ein System zu entwerfen, das die Agents an deiner Stelle promptet
• Ein Loop ist ein rekursives Ziel, bei dem die AI nach Definition des Ziels so lange iteriert, bis es abgeschlossen ist, und er besteht aus etwa fünf Komponenten
• Die fünf Komponenten sind Automations, Worktrees, Skills, Plugins·Connectors, Sub-Agents; sowohl Claude Code als auch Codex verfügen derzeit über alle fünf
• Die sechste Komponente, Memory, ist eine Markdown-Datei oder ein Linear-Board, das Zustand außerhalb eines einzelnen Gesprächs speichert und so Modelle ergänzt, die bei jedem Lauf alles vergessen
• Das Ganze steckt noch in den Anfängen, und Token-Kosten erfordern zwingend Aufmerksamkeit; Validierung und Verständnis bleiben weiterhin Aufgabe des Menschen (build the loop, stay the engineer)

---

Definition von Loop Engineering und warum es jetzt auftaucht

• Loop Engineering bedeutet, die Person, die den Agenten promptet, durch ein System zu ersetzen und dieses System selbst zu entwerfen
  • Ein Loop ist ein rekursives Ziel (recursive goal): Definiere das Ziel, und die AI iteriert, bis es erledigt ist
  • Es könnte die künftige Art sein, mit Coding-Agents zu arbeiten, steckt aber noch in einer frühen Phase; Token-Kosten brauchen daher besondere Aufmerksamkeit (je nachdem, ob man token rich oder token poor ist, ändern sich die Nutzungsmuster stark)
• Zitate
  • Peter Steinberger: „Promptet Coding-Agents nicht länger direkt, sondern entwerft Loops, die die Agents prompten.“
  • Boris Cherny (verantwortlich für Claude Code bei Anthropic): „Ich prompte Claude nicht mehr direkt, sondern lasse einen Loop laufen, der Claude promptet und entscheidet, was zu tun ist. Meine Arbeit ist es, den Loop zu schreiben.“
• In den letzten rund zwei Jahren bestand der typische Ansatz darin, gute Prompts und ausreichend Kontext zu geben und turn-by-turn mit dem Agenten zu arbeiten, also den Agenten direkt als Werkzeug in der Hand zu halten – dieses Modell läuft nun aus
• Stattdessen baut man nun ein kleines System, das Aufgaben findet und verteilt, validiert, Erledigtes protokolliert und die nächste Aufgabe bestimmt – und dieses System stößt dann den Agenten an
  • Es steht über früheren Konzepten wie agent harness engineering (die Laufumgebung für einen einzelnen Agenten) und dem factory model (ein System, das Software produziert)
  • Ein Harness, das per Timer läuft, kleine Helfer erzeugt und sich selbst füttert
• Es ist kein Tool-Problem mehr – noch vor einem Jahr musste man, wenn man Loops wollte, eigene Bash-Konstrukte schreiben und pflegen; heute sind die nötigen Bausteine direkt in Produkte eingebaut
  • Steinbergers Liste deckt sich fast exakt mit der Codex-App und nahezu vollständig mit Claude Code; statt darüber zu streiten, welches Tool besser ist, sollte man Loops entwerfen, die auf beiden Seiten funktionieren

Die fünf Komponenten eines Loops plus Memory

• Ein Loop braucht fünf Dinge, dazu kommt ein Ort, an dem Zustand erhalten bleibt
  • Automations — werden nach Zeitplan ausgelöst und übernehmen selbst Discovery und Triage
  • Worktrees — verhindern, dass zwei parallel arbeitende Agents einander in die Quere kommen
  • Skills — halten Projektwissen fest, das der Agent sonst mit Vermutungen auffüllen würde
  • Plugins·Connectors — verbinden den Agenten mit den bereits genutzten Tools
  • Sub-Agents — einer entwickelt Ideen, ein anderer prüft sie
• Die sechste Komponente ist Memory, zum Beispiel eine Markdown-Datei oder ein Linear-Board, das außerhalb eines einzelnen Gesprächs lebt und speichert, was erledigt ist und was als Nächstes ansteht
  • Das wirkt fast zu simpel, ist aber derselbe Trick, auf dem alle lang laufenden Agents basieren (siehe der frühere Beitrag zu long-running agents)
  • Modelle vergessen zwischen Runs alles, deshalb muss Memory nicht im Kontext, sondern auf der Platte liegen – der Agent vergisst, das Repo nicht
• Beide Produkte verfügen aktuell über alle fünf Komponenten; nur die Namen unterscheiden sich leicht, die Fähigkeiten sind dieselben

Automations – der Herzschlag des Loops

• Automations sind das Element, das einen Loop nicht nur zu einem einzelnen Run, sondern zu einem echten Loop macht
  • In der Codex-App werden sie im Tab „Automations“ erstellt; man wählt Projekt, auszuführenden Prompt, Intervall und ob lokal im Checkout oder in einem Hintergrund-Worktree gearbeitet wird
  • Läufe, die etwas finden, landen in der Triage Inbox; Läufe ohne Ergebnis archivieren sich selbst
  • OpenAI nutzt das intern für langweilige Aufgaben wie tägliche Issue-Triage, Zusammenfassungen von CI-Fehlern, Commit-Briefings oder das Aufspüren von Bugs aus der letzten Woche
  • Eine Automation kann Skills aufrufen; statt eine riesige Wand aus Instruktionen einzufügen, löst man $skill-name aus und hält wiederkehrende Arbeit wartbar
• Claude Code erreicht denselben Punkt über Scheduling und Hooks
  • Mit /loop lassen sich Prompts oder Befehle in festen Intervallen ausführen, Cron-Jobs planen und zu bestimmten Zeitpunkten im Agent-Lifecycle per Hooks Shell-Befehle starten
  • Soll der Prozess weiterlaufen, auch wenn das Notebook geschlossen ist, kann man alles an GitHub Actions übergeben
• Als zweites Primitive innerhalb der Session gibt es eine Funktion, die dem Kern dieses Artikels besonders nahekommt
  • /loop startet in festgelegten Intervallen neu
  • /goal läuft weiter, bis eine von dir formulierte Bedingung tatsächlich erfüllt ist; nach jedem Turn prüft ein separates kleines Modell, ob die Aufgabe abgeschlossen ist, damit nicht der Agent, der den Code geschrieben hat, auch noch der Bewerter ist
    • Beispiel: Eine Bedingung wie „alle Tests in test/auth bestehen, lint clean“ setzen und dann weggehen
  • Codex bietet ebenso /goal; es arbeitet turnweise weiter, bis eine verifizierbare Stop-Bedingung erfüllt ist, und unterstützt pause, resume und clear

Worktrees – damit Parallelität nicht im Chaos endet

• In dem Moment, in dem mehr als ein Agent läuft, beginnen Dateikonflikte – genau dort scheitert es oft
  • Wenn zwei Agents dieselbe Datei schreiben, ist das derselbe Kopfschmerz, als würden zwei Engineers ohne Absprache dieselbe Zeile committen
  • git worktree löst das Problem – die Historie des Repos wird geteilt, aber jeder arbeitet in einem eigenen Arbeitsverzeichnis auf seinem Branch; Änderungen eines Agents berühren also nicht den Checkout des anderen
• Codex hat Worktree-Support eingebaut, sodass mehrere Threads gleichzeitig in einem Repo arbeiten können, ohne zu kollidieren
• Claude Code bietet dieselbe Isolation über git worktree, das Flag --worktree, mit dem eine Session in ihrem eigenen Checkout geöffnet wird, und die Sub-Agent-Einstellung isolation: worktree (jeder Helfer bekommt einen frischen Checkout, der nach Abschluss selbst wieder aufgeräumt wird)
• Worktrees beseitigen mechanische Kollisionen, aber der Engpass bleibst immer noch du selbst – wie viele parallele Läufe realistisch sind, bestimmt nicht das Tool, sondern deine Review-Bandbreite (siehe den früheren Beitrag zur orchestration tax)

Skills – damit das Projekt nicht jedes Mal neu erklärt werden muss

• Ein Skill ist die Methode, um nicht in jeder Session wieder wie einem Goldfisch denselben Projektkontext erklären zu müssen
  • Beide Tools nutzen dasselbe Format – ein Ordner mit SKILL.md, das Instruktionen und Metadaten enthält, plus optionale Skripte, Referenzen und Assets
  • In Codex werden Skills mit $ oder /skills aufgerufen oder automatisch ausgeführt, wenn die Aufgabe zur Skill-Beschreibung passt; deshalb funktionieren knappe, nüchterne Beschreibungen besser als besonders clevere Formulierungen
  • Claude Code arbeitet auf dieselbe Weise (siehe den früheren Beitrag zu agent skills)
• Skills sind der Ort, an dem Intent nicht jedes Mal wieder Kosten erzeugt
  • Ein Agent startet jede Session kalt und füllt Lücken im Intent mit selbstbewussten Vermutungen (siehe den früheren Beitrag zur intent debt)
  • Ein Skill schreibt diesen Intent nach außen: Konventionen, Build-Schritte, Dinge wie „seit diesem Vorfall machen wir es nicht mehr so“ – einmal aufgeschrieben, wird das bei jedem Run wieder gelesen
  • Ohne Skills leitet der Loop in jedem Zyklus das gesamte Projekt von null neu her; mit ihnen akkumuliert Wissen und wirkt wie Zinseszins
• Skill ist das Autorenformat, Plugin ist die Distributionsmethode – wenn man Skills über mehrere Repos teilen oder bündeln will, verpackt man sie als Plugin (bei Codex und Claude Code gleichermaßen)

Plugins·Connectors – damit der Loop echte Tools erreicht

• Ein Loop, der nur das Dateisystem sehen kann, bleibt ein kleiner Loop
  • MCP-basierte Connectors ermöglichen es dem Agenten, Issue-Tracker zu lesen, Datenbanken abzufragen, Staging-APIs aufzurufen oder Slack-Nachrichten zu senden
  • Sowohl Codex als auch Claude Code sprechen MCP, deshalb funktioniert ein Connector für die eine Seite meist auch auf der anderen unverändert
  • Ein Plugin bündelt Connector und Skill, sodass Kolleginnen und Kollegen alles in einem Schritt installieren können, statt es aus dem Gedächtnis neu zusammenzubauen
• Das ist der Unterschied zwischen einem Agenten, der sagt: „Hier ist ein möglicher Fix“, und einem Loop, der einen PR öffnet, ein Linear-Ticket verknüpft und in den Channel pingt, sobald CI grün ist
  • Connectors sorgen dafür, dass ein Loop nicht nur Möglichkeiten beschreibt, sondern in der realen Umgebung tatsächlich handelt

Sub-Agents – Bauen und Prüfen voneinander trennen

• Die nützlichste Struktur in einem Loop ist ganz klar die Trennung zwischen dem Teil, der Code schreibt, und dem Teil, der ihn überprüft
  • Das Modell, das den Code geschrieben hat, ist beim Bewerten der eigenen Arbeit zu nachsichtig
  • Ein zweiter Agent mit anderen Instruktionen und manchmal sogar einem anderen Modell findet Dinge, die der erste bereits für überzeugend hält
• Codex erstellt Sub-Agents auf Anfrage, lässt sie parallel laufen und führt die Ergebnisse anschließend zu einer Antwort zusammen
  • Eigene Agents werden in .codex/agents/ als TOML-Dateien definiert (name, description, instructions, optional model und reasoning effort)
  • Beispiel: ein Security-Reviewer mit starkem Modell und high effort, ein Explorer mit schnellem Read-only-Modell
• Claude Code löst das genauso über Subagents in .claude/agents/ und Agent Teams, die sich Aufgaben gegenseitig übergeben
  • Die übliche Aufteilung in beiden Tools: ein Agent erkundet, einer implementiert, einer prüft gegen Spezifikation und Tests (siehe frühere Beiträge wie the code agent orchestra und adversarial code review)
• Da ein Loop läuft, während man nicht hinsieht, braucht er einen vertrauenswürdigen Verifier, damit man sich überhaupt vom Platz entfernen kann
  • Sub-Agents nutzen jeweils eigene Modell- und Tool-Arbeit und verbrauchen deshalb mehr Tokens; man sollte sie dort einsetzen, wo eine zweite Meinung wirklich Wert schafft
  • Genau das macht auch Claude Codes /goal intern: Ein neues Modell beurteilt den Abschluss statt des Modells, das die Arbeit ausgeführt hat, und wendet die Trennung von Maker und Checker auf die Stop-Bedingung selbst an

Wie ein einzelner Loop aussehen kann

• Zusammengesetzt verwandelt sich ein einzelner Thread in ein kleines Kontrollpult; eine wiederverwendbare Form sieht so aus
  • Eine Automation läuft jeden Morgen im Repo, ihr Prompt ruft einen Triage-Skill auf, liest die CI-Fehler von gestern, offene Issues und aktuelle Commits und schreibt das Ergebnis in eine Markdown-Datei oder ein Linear-Board
  • Für jeden lohnenden Punkt öffnet der Thread einen isolierten Worktree, lässt von einem Sub-Agenten einen Fix-Entwurf erstellen und von einem zweiten Sub-Agenten diesen Entwurf gegen den Projekt-Skill und bestehende Tests reviewen
  • Ein Connector ermöglicht dem Loop, PRs zu öffnen und Tickets zu aktualisieren; was er nicht sauber verarbeiten kann, landet in der Triage Inbox
  • Eine State File bildet das Rückgrat des Ganzen – sie merkt sich, was versucht wurde, was bestanden hat und was noch offen ist, sodass der nächste Lauf am Morgen dort weitermacht, wo der heutige aufgehört hat
• Der entscheidende Punkt ist, dass keiner dieser Schritte jedes Mal neu gepromptet wird, sondern einmal entworfen wurde – egal ob in Codex oder Claude Code, die Komponenten sind gleich, also ist auch der Loop derselbe

Was Loops weiterhin nicht für dich übernehmen

• Loops verändern die Arbeit, sie entfernen den Menschen nicht; und je besser Loops werden, desto schärfer treten drei Probleme hervor
• Validierung bleibt weiterhin deine Aufgabe
  • Ein unbemannt laufender Loop ist auch ein unbemannt Fehler machender Loop
  • Man trennt Verifier-Sub-Agent und Maker, damit „fertig“ im Loop überhaupt eine Bedeutung hat, aber auch dann ist „done“ kein Beweis, sondern eine Behauptung (siehe den früheren Beitrag code review in the age of AI – die eigentliche Arbeit ist, Code auszuliefern, dessen Verhalten überprüft wurde)
• Verständnis verrottet, wenn man es vernachlässigt
  • Je schneller ein Loop Code ausliefert, den du nicht selbst geschrieben hast, desto größer wird die Lücke zwischen dem, was existiert, und dem, was du tatsächlich verstehst
  • Das ist comprehension debt; ein reibungsloser Loop vergrößert diese Lücke noch schneller, wenn du nicht liest, was er gebaut hat
• Die bequeme Haltung ist die gefährliche Haltung
  • Wenn der Loop von selbst läuft, ist es leicht, keine eigene Meinung mehr zu haben und einfach zu akzeptieren, was zurückkommt (cognitive surrender)
  • Loop-Design ist ein Gegenmittel, wenn es mit Urteilsvermögen geschieht, und ein Beschleuniger, wenn es dazu dient, Denken zu vermeiden – die gleiche Handlung, das gegenteilige Ergebnis

Baue den Loop, aber bleibe Engineer

• Es wirkt wie ein Vorgeschmack darauf, wie sich Arbeit weiterentwickeln wird; wenn man den Code aber nicht selbst reviewt oder sich nur auf automatische Loops verlässt, kann man in eine Abwärtsspirale aus sinkender Produktqualität und immer tieferem Verheddern geraten
• Loops einzurichten ist sinnvoll, aber Agents direkt zu prompten bleibt weiterhin effektiv – entscheidend ist das richtige Gleichgewicht
• Loops können bei verschiedenen Menschen zu völlig gegensätzlichen Ergebnissen führen – von zwei Personen mit demselben Loop arbeitet die eine schneller an Dingen, die sie tief versteht, während die andere ihn nutzt, um Dinge gerade nicht verstehen zu müssen
  • Der Loop kennt diesen Unterschied nicht, du aber schon
• Deshalb ist Loop-Design nicht einfacher als Prompt Engineering, sondern schwieriger – Cherrnys Punkt ist nicht, dass die Arbeit leichter geworden ist, sondern dass sich der Hebelpunkt verschoben hat
• Fazit: Baue den Loop, aber tue es wie jemand, der Engineer bleibt – nicht wie jemand, der nur noch auf den Startknopf drückt

[shakespeares]

Verifikation bleibt weiterhin die eigene Aufgabe

Verständnis verfällt, wenn man es vernachlässigt

Eine bequeme Haltung ist eine gefährliche Haltung

=> Letztlich braucht es also Prompting, mit dem man selbst direkt überprüft und wiederkehrende Arbeit minimiert.