Loop Engineering
Definition
Eine Praxis, die Anfang 2026 Konjunktur bekommen hat: Wer einen Coding-Agenten produktiv einsetzt, gibt ihm keine Einzelaufträge mehr, sondern baut das System, das den Agenten beauftragt. Ein Loop ist dabei ein wiederkehrendes Ziel — man legt einen Zweck fest, und das System läuft so lange, bis eine prüfbare Abbruchbedingung erfüllt ist.
Fünf Bausteine tragen den Loop. Geplante Automatisierungen geben den Takt und stoßen Durchläufe nach Zeitplan an. Git-Worktrees halten parallel arbeitende Agenten auseinander, damit ihre Änderungen sich nicht überschreiben. Skills halten Projektwissen einmal schriftlich fest, das sonst in jeder Sitzung neu erklärt werden müsste. Über MCP angebundene Plugins und Connectors verdrahten den Loop mit den real genutzten Werkzeugen: Ticketsystem, Datenbank, Slack, Pull Request. Sub-Agenten trennen schließlich das Schreiben vom Prüfen; der Agent, der den Code verfasst hat, gibt ihn nicht selbst frei.
Ein sechstes Element entscheidet, ob das Ganze überhaupt funktioniert: eine Markdown-Datei als Gedächtnis außerhalb der laufenden Sitzung, weil das Modell zwischen zwei Durchläufen alles "vergisst". Claude Code und Codex bringen alle fünf Bausteine inzwischen ab Werk mit; Befehle wie `/loop` (Wiederholung in fester Taktung) und `/goal` (läuft, bis eine extern geprüfte Bedingung erfüllt ist) verlagern die Steuerung eine Ebene nach oben. Der Begriff geht zurück auf Peter Steinberger und auf Boris Cherny, Head of Claude Code bei Anthropic ("my job is to write loops").
Noise — Signal
Loop Engineering wird als nächste Stufe nach dem Prompt Engineering vermarktet — als Beleg dafür, dass ein Team nicht mehr am Werkzeug schraubt, sondern bereits die Fertigung entwirft. Die Fähigkeit ist real und vermutlich ein Vorgeschmack darauf, wohin sich diese Arbeit entwickelt. Drei Punkte werden mit einem besseren Loop allerdings nicht leichter, sondern schärfer.
Erstens die Token-Rechnung. Ein Loop läuft unbeaufsichtigt — und er rechnet auch unbeaufsichtigt ab. Sub-Agenten vervielfachen die Kosten, weil jeder von ihnen sein eigenes Modell anstößt und seine eigenen Werkzeuge bedient. Der Anreiz der Anbieter ist hier nicht neutral: Mehr Loops bedeuten mehr Tokens, und Tokens sind das, womit Hersteller von Foundation Models unmittelbar Geld verdienen.
Zweitens die Verifikation. Ein Loop, der unbeaufsichtigt arbeitet, macht auch seine Fehler unbeaufsichtigt. "Fertig" ist eine Behauptung, die der Loop über sich selbst aufstellt — kein Beleg. Dass der schreibende Sub-Agent vom prüfenden getrennt wird, ist keine Hygienemaßnahme; es ist der einzige Grund, weshalb man den Raum überhaupt verlassen kann.
Drittens das Menschliche. Derselbe Loop macht denjenigen schneller, der die Aufgabe tief verstanden hat — und er erlaubt es einem anderen, das Verstehen ganz zu umgehen. Identischer Aufbau, gegensätzliches Ergebnis. Loop-Design ist deshalb anspruchsvoller als Prompt Engineering, nicht einfacher: Der Hebel hat sich verschoben, die Arbeit ist nicht verschwunden.
Die richtige Frage
Nicht: "Können unsere Teams Loops bauen, die die Agenten für uns arbeiten lassen?" Sondern: Wer kontrolliert, was der Loop ausliefert, solange er unbeaufsichtigt läuft — und ist seine Abbruchbedingung von außen prüfbar? Was kostet ein unbemerkter Fehler, und wie bleibt die Token-Rechnung steuerbar, wenn Sub-Agenten sich vervielfachen? Und vor allem: Dient der Loop dazu, verstandene Arbeit schneller zu erledigen — oder dazu, das Verstehen zu umgehen?