Loop Engineering: hör auf zu prompten, entwickle Schleifen.

Du fragst, das Modell antwortet einmal und hört auf. Das ist ein Prompt. Du steuerst alles, das Modell ist nur dein Werkzeug, und ohne dich bewegt sich nichts. Loop Engineering dreht genau das um. Du legst ein Ziel ein einziges Mal fest, und der Agent iteriert selbstständig, bis das Ziel wirklich erreicht ist. Dieser Guide zeigt dir, was ein Loop wirklich ist, woran fast alle scheitern und wie du heute noch deinen ersten sauberen Loop entwickelst.

Was Loop Engineering ist#

Ein Prompt ist eine einzelne Anweisung. Du fragst, bekommst eine Antwort, fertig. Egal ob die Antwort gut war. Ein Loop ist ein rekursives Ziel. Du sagst einmal, was am Ende herauskommen soll, und der Agent plant, arbeitet, prüft sein eigenes Ergebnis, bessert die schwächste Stelle nach und wiederholt das so lange, bis das Ziel erfüllt ist.

Der Hebel verschiebt sich also weg von der Frage, wie gut dein einzelner Prompt ist, hin zur Frage, wie gut dein Loop aufgesetzt ist. Addy Osmani von Google bringt es auf den Punkt: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

Das ist keine Theorie aus dem luftleeren Raum. Boris Cherny, der bei Anthropic Claude Code mitentwickelt hat, beschreibt seinen eigenen Arbeitstag im Lenny-Podcast so: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops." Er fährt rund fünf Agenten parallel und kommt damit auf zehn bis dreißig Pull Requests am Tag. Wichtig ist, dass das sein persönlicher Workflow ist und keine offizielle Neudefinition von irgendwas. Aber es zeigt, wohin die Reise geht.

Ein Hinweis noch, weil das Zitat gerade überall falsch herumgereicht wird. Den Satz "Niemand schreibt mehr Prompts, der neue Job ist Schleifen schreiben" hat Jensen Huang so nie gesagt. Das gehört Cherny und Peter Steinberger. Wenn du das Thema weitergibst, lass Huang raus, sonst verlierst du Glaubwürdigkeit.

Der Loop-Zyklus#

Ein echter Loop fährt fünf Schritte selbst, immer wieder:

1. Discover. Herausfinden, was zu tun ist.
2. Plan. Entscheiden, wie.
3. Execute. Die Arbeit machen.
4. Verify. Gegen das Ziel prüfen.
5. Iterate. Noch nicht da? Ergebnis zurückspeisen und von vorne.

Drei Stellen tragen die ganze Last, und genau an denen scheitern die meisten Loops.

Verify ist das Herz. Ohne echte Prüfung hast du keinen Loop, sondern einen Agenten, der sich selbst zustimmt. Der Check macht aus Wiederholung erst Fortschritt. Das kann ein harter Test sein, also läuft der Code durch. Eine messbare Bedingung, also Zahl über X. Oder eine klare Rubrik. Fehlt dieses Gate, benotet das Modell seine eigenen Hausaufgaben. Und das Modell, das die Arbeit gemacht hat, ist ein viel zu großzügiger Prüfer.

State macht das Lernen möglich. Jeder Durchlauf muss sich merken, was schon versucht wurde, sonst dreht der Loop ewig denselben Fehler. Ein guter Loop führt ein kleines Seitenprotokoll: was erledigt ist, was gescheitert ist, was als Nächstes kommt. Der Lauf am nächsten Morgen setzt dann fort, statt bei null zu starten. Genau hier wird es übrigens auch teuer, dazu unten mehr.

Die Stop-Condition ist die Vernunft. Ein Loop ohne Ausgang läuft, bis er gewinnt, abstürzt oder dein Konto leer ist. Jeder ernsthafte Loop hat deshalb zwei Stopps: Erfolg und ein hartes Limit, etwa nach acht Versuchen anhalten und berichten.

Die fünf Bausteine in Claude Code und Codex#

Ein Loop wird aus fünf Blöcken zusammengesetzt. Claude Code und Codex liefern alle fünf mit.

1. Automation oder Heartbeat. Der Trigger, der aus einem einmaligen Lauf einen Loop macht. In Claude Code ist /loop ein echter eingebauter Skill, der einen Prompt wiederholt ausführt, mit oder ohne Intervall. /goal ist ebenfalls eingebaut und hält eine Session am Laufen, bis eine von dir geschriebene Bedingung wahr ist. Dazu Hooks, die an Lifecycle-Events feuern, und cron oder GitHub Actions, damit der Loop weiterläuft, nachdem du den Laptop zugeklappt hast.
2. Skill. Wiederverwendbare Anweisungen als Datei, die der Loop jedes Mal liest. Regeln, Muster und eine harte Liste, was er nie anfassen darf. Spart das ständige Neu-Erklären deines Projekts.
3. Sub-Agents. Trenne den Agenten, der die Arbeit macht, von dem, der sie prüft. Der zweite bekommt andere Anweisungen, oft ein stärkeres Modell, und fängt das ab, was sich der erste schöngeredet hat. Osmani nennt das adversarial code review.
4. Connectors. Der Unterschied zwischen "hier ist der Fix" und einem Loop, der selbst den Pull Request öffnet, das Ticket verlinkt und den Channel pingt, sobald der Build grün ist. Technisch läuft das über MCP.
5. Verifier. Das Gate. Der Test, Type-Check oder Build, der schlechte Arbeit automatisch ablehnt. Der eine Block, der entscheidet, ob der Loop dir hilft oder nur Geld ausgibt.

Wann sich ein Loop lohnt#

Es gibt einen einfachen Test, und alle vier Punkte müssen zutreffen.

1. Die Aufgabe wiederholt sich, mindestens wöchentlich. Bei selteneren Aufgaben zahlt sich der Aufbau nie aus. Ein einmaliger Job ist mit einem guten Prompt besser bedient.
2. Etwas kann schlechten Output automatisch ablehnen. Test, Type-Check, Build, Linter, harte Regel. Kann nichts die Arbeit durchfallen lassen, dreht der Loop nur leer.
3. Der Agent kann die Arbeit wirklich selbst von Anfang bis Ende machen. Nicht die Hälfte an dich zurückreichen.
4. Fertig ist objektiv. Ist Qualität Geschmackssache, gewinnt der Mensch.

Fehlt nur ein Punkt, behalte die Aufgabe als manuellen Prompt.

Wo ein Loop zur Falle wird#

Der bekannteste Fall ist der Ralph-Wiggum-Loop von Geoffrey Huntley. In Reinform ist das eine Bash-Schleife, die denselben Prompt in jeder Runde neu füttert, während der Fortschritt in Dateien und der Git-History lebt. Huntley selbst nennt die Schwachstelle beim Namen: Nichtdeterminismus. Manchmal wachst du auf und der Code kompiliert nicht mehr. Schutz dagegen sind harte Test-Gates und menschliches Mitschauen.

Dann das leise Geldverbrennen. Loops stürzen nicht ab, sie rechnen still weiter. Wenn ein Agent sich festfährt, crasht er nicht, er loopt. Es gibt belegte Fälle von 6000 Dollar über Nacht. Uber hat seine Engineers nach einem Budget-Crash auf 1500 Dollar im Monat gedeckelt. Im Extremfall liefen 847 Reasoning-Schritte für rund 47 Dollar pro Minute, ohne Ergebnis.

Und es gibt das Verständnisproblem. Du lässt den Loop laufen und verstehst irgendwann nicht mehr, was er entwickelt hat. Osmani: "The loop doesn't know the difference. You do. That's what makes loop design harder than prompt engineering, not easier."

Warum die Kosten kompoundieren#

Loops laufen auf Tokens, und Tokens sind Geld. Das Problem ist nicht, dass jeder Schritt etwas kostet. Das Problem ist, wie die Kosten sich aufschaukeln.

In jeder Runde liest der Agent seinen ganzen Kontext neu: Ziel, Code, letztes Ergebnis, was gescheitert ist. Dieser Stapel geht jedes Mal komplett durchs Modell und wächst mit jedem Durchlauf. Ein Loop, der zehnmal läuft, kostet dich nicht zehn Prompts. Er kostet dich zehn Prompts, von denen jeder immer größer wird. Trennst du dann noch Maker und Checker, verdoppelst du die Rechnung gleich mit. Und eine ganze Flotte parallel multipliziert alles.

Die eine Metrik, die wirklich zählt, ist nicht der Token-Verbrauch und nicht die Zahl der Läufe, sondern die Kosten pro akzeptierter Änderung. Gibt dir der Loop zehn Ergebnisse und du wirfst sechs weg, machst du genau die Review-Arbeit, die er dir sparen sollte. Unter fünfzig Prozent Akzeptanzrate kostet der Loop mehr, als er zurückbringt. Eine saubere Faustformel: monatlicher KI-Spend geteilt durch gemergte Pull Requests. Also zum Beispiel 1200 Dollar durch 38 ergibt rund 32 Dollar pro PR.

Deshalb gehört die schwere Variante in Teams mit Budget und Leitplanken: Iterations-Caps, Token-Budgets, billige Modelle auf den langweiligen Schritten, Monitoring.

Die richtige Reihenfolge#

Das ist die wichtigste Praxisregel, und fast jeder hochgegangene Loop hat genau hier den Fehler gemacht.

1. Mach einen manuellen Lauf zuverlässig.
2. Entwickle daraus einen Skill, also speichere die Anweisungen ab.
3. Wickel den Skill in einen Loop, mit Gate und Stop-Condition.
4. Erst danach setzt du das Ganze auf einen Schedule.

Etwas zu schedulen, das du nicht vorher von Hand zuverlässig hinbekommen hast, ist genau die Art, wie Loops nachts hochgehen. Beweise es einmal, härte es ab, dann automatisiere es.

Leicht oder schwer#

Die schwere Version sind Tools, Hosting, Code, Gates und eine echte Rechnung. Sub-Agent-Flotten, cron oder CI, Connectors, Maker plus Checker. Das gehört Teams mit Budget.

Die leichte Version ist ein einzelner selbstprüfender Loop in Claude oder ChatGPT, den du selbst startest. Und ganz ehrlich, für 99 Prozent der Alltagsaufgaben reicht genau diese leichte Version. Loop Engineering ist real, aber die meisten brauchen die schwere Variante noch nicht.

Der Loop zum Kopieren#

Diesen Block kannst du in jedes Modell geben. Du lieferst alle drei Loop-Teile auf einmal: ein Ziel, strenge Erfolgskriterien und ein Protokoll, das das Modell zwingt, sich selbst zu prüfen, bevor es stoppen darf.

You will work in a loop until the task meets the bar.
TASK: [...]
SUCCESS CRITERIA (be strict, no soft passes): [...]
LOOP PROTOCOL, repeat every turn:
  1. PLAN   - state the single next step.
  2. DO     - produce or improve the work.
  3. VERIFY - score the result 1-10 on each criterion. Be brutally honest.
              List exactly what is still weak.
  4. DECIDE - if every criterion is 8+, print FINAL and stop.
              Otherwise print ITERATING and go again, fixing the weakest point first.
RULES: Never call it done until every criterion is 8 or higher.
       Each pass must fix the weakest score. Do not ask me questions.
Begin. Run the loop until FINAL.

Wichtig dabei ist, dass das Ziel harte Zahlen, Prozente oder Checklisten braucht, an denen sich das Modell ehrlich messen kann. Nie "mach es gut", sonst kann es sich nicht selbst benoten. Und denk dran, in dieser leichten Variante bist du der Trigger. Tab zu heißt weg. Für alles, was ohne dich weiterlaufen soll, brauchst du dann die schwere Welt.

Wenn du ehrlich sein willst#

Es gibt auch Gegenstimmen, und die solltest du kennen. Manche nennen den ganzen Trend einen Mechanismus, mit dem Anbieter mehr Tokens verkaufen. Fast.ai hat in einer Messung sogar 19 Prozent weniger Tempo gefunden, gefühlt schneller heißt eben nicht gemessen schneller. Firecrawl spottet, das sei "a cron job wearing a hat". Dem stehen reale Erfolge gegenüber. Jarred Sumner, der Schöpfer von Bun, hat die Bun-Runtime per Claude-Code-Loops von Zig nach Rust umgeschrieben und in sechs Tagen 99,8 Prozent der bestehenden Tests bestanden. Sein Satz dazu: "Dynamic workflows and adversarial code review was part of what made it possible to rewrite Bun in Rust in 6 days." Vorausgegangen ist dem allerdings viel manuelle Vorbereitung. Schlechter Output kommt meistens von schlechten Specs, nicht vom Loop selbst.

So fängst du an#

Nimm dir eine Aufgabe, die du mindestens einmal pro Woche machst und die ein Computer eindeutig prüfen kann. Mach sie einmal sauber von Hand. Schreib die Schritte als Skill auf. Pack ein hartes Gate und ein Limit drumherum. Und schalte den Schedule erst ein, wenn alles davor steht. Wenn du dabei Hilfe willst oder dein erstes echtes Loop-Setup gemeinsam aufsetzen möchtest, buch dir einen Termin.