Hör auf zu prompten. Bau Loops.

Es gibt einen Satz, der gerade unter den Leuten kursiert, die Coding-Agents beruflich bauen: „Ich prompte Claude nicht mehr. Ich habe Loops laufen, die Claude prompten und selbst rausfinden, was zu tun ist. Mein Job ist es, Loops zu schreiben." Das ist Boris Cherny, Head of Claude Code (DEV Community).

Im Juni 2026 bekam dieser Shift einen Namen. Addy Osmani nennt es Loop Engineering. Und es könnte die wichtigste Veränderung in der Arbeit mit KI-Agents seit Prompt Engineering sein. Wenn du immer noch einen Prompt nach dem anderen tippst, benutzt du Agents wie einen Spielautomaten. Hier ist das Upgrade.

Was ist Loop Engineering?

Loop Engineering ist die Praxis, das System zu designen, das einen KI-Agent promptet, prüft, sich erinnert und neu startet, statt jede nächste Instruktion selbst zu tippen (Tosea.ai).

Die Arbeitseinheit ist nicht mehr der einzelne Prompt, nicht mal die einzelne Konversation. Es ist ein Loop: ein wiederkehrender Zyklus, in dem das Modell eine Aktion ausführt, Feedback aus seiner Umgebung bekommt, damit den nächsten Schritt entscheidet und weitermacht, bis eine definierte Stop-Bedingung erfüllt ist.

Die einfachste brauchbare Definition: etwas tun, Ergebnis prüfen, entscheiden, ob weiter oder Stopp. Das ganze Handwerk steckt darin, den Check echt zu machen und das Ende sauber zu definieren. Es macht aus einem KI-Agent etwas, mit dem du nicht mehr chattest, sondern das rund um die Uhr selbstständig arbeitet: Pull Requests reviewen, Dependencies aktualisieren oder deine Logs beobachten, während du schläfst (Loop Engineering, YouTube).

Die Anatomie eines Loops

Jeder gut gebaute Loop hat dasselbe Skelett:

1. Trigger: Ein Zeitplan oder ein Event startet ihn.
2. Arbeit finden: Der Agent identifiziert das nächste Stück Arbeit.
3. Handeln: Er führt eine begrenzte Aktion aus, meist über Tool-Calls.
4. Verifizieren: Er prüft das Ergebnis gegen einen festen Standard.
5. Erinnern: Er schreibt, was er getan hat, in externen State.
6. Wiederholen: zurück zu Schritt 2, nächster Task.
7. Stoppen oder eskalieren: Entscheidend: Er weiß, wann er fertig ist. Und wann ein Mensch übernehmen muss.

Dieser innere Zyklus (wahrnehmen, denken, handeln, beobachten, wieder denken) läuft in jedem Coding-Agent sowieso bei jedem Turn. Den Inner Loop baust du nicht; den liefert der Harness. Was du baust, ist der Outer Loop: das System, das den Inner Loop nach Zeitplan startet, ihm Arbeit zuführt, das Ergebnis prüft und den nächsten Schritt entscheidet, ohne dass du jeden Prompt tippst.

Warum jetzt? Die Fable-5-Verbindung

Loop Engineering kam nicht aus dem Nichts. Die Diskussion zündete direkt nach dem Release von Fable 5, als Praktiker wie Lance Martin und Peter Steinberger darauf hinwiesen, dass Modelle gut genug geworden sind, um lange Strecken unbeaufsichtigt zu laufen (Loop Engineering in 9 Minutes, YouTube). Steinberger sagt es unverblümt: „Du solltest keine Coding-Agents mehr prompten. Du solltest Loops designen, die deine Agents prompten."

Das Tooling folgte der Erkenntnis. Claude Code und Codex shippen inzwischen Features, die im Grunde Loops in der Box sind:

• goal: ein Task, der autonom bis zur Fertigstellung läuft.
• /loop: intervallbasierte Runs, zum Beispiel alle fünf Minuten.

An der experimentellen Front stehen Karpathys Auto Research und Ideen wie „Parameter Golf": Loops, die ihre eigenen Experimente steuern. Das Spektrum reicht vom Fünf-Zeilen-Validierungsloop bis zu selbststeuernden Research-Systemen.

Der Loop-Stack

Loop Engineering ist eigentlich die dritte Ebene eines Stacks, der seit Jahren wächst. LangChain framet es als Loops, die du übereinander stapelst (LangChain):

• Level 1, der Agent-Loop: Gib dem Modell Kontext und Tools, lass es in einer Schleife handeln, bis es fertig ist. Es klont ein Repo, liest Dateien, schreibt Code, öffnet einen PR.
• Level 2, der Verification-Loop: Wickle den Agent in einen Grader, der den Output gegen eine Rubrik prüft und ihn mit Feedback zurückschickt, wenn er nicht reicht. Der Grader kann deterministisch sein oder ein LLM-as-Judge. Kostet Latenz und Tokens, lohnt sich immer dann, wenn Qualität wichtiger ist als Speed.
• Level 3, der Event-Driven-Loop: Verbinde den Agent mit deinem Ökosystem, sodass er auf Trigger aufwacht (ein neues Dokument landet, ein Schedule feuert, ein Webhook kommt an) und im Hintergrund läuft.

Osmanis vollständigere Anatomie ergänzt die Strukturteile, die Loops in der Praxis komponierbar machen: Automations, die Runs triggern; Worktrees, in denen parallele Agents arbeiten, ohne zu kollidieren; Skills, die wiederverwendbare Fähigkeiten verpacken; Connectors zu externen Systemen; Sub-Agents, die große Ziele zerlegen; und externer State, der Memory über Runs hinweg persistiert.

Was einen Loop wirklich funktionieren lässt

Der Unterschied zwischen einem Loop, der dir die Woche rettet, und einem, der endlos Tokens verbrennt, liegt in drei Engineering-Disziplinen:

• Context Management. Weil jeder Schritt den nächsten füttert, läuft ein langer Loop über das Context Window hinaus, außer er fasst zusammen, kürzt und lagert State aus. Hier lebt Context Engineering innerhalb von Loop Engineering.
• Terminierungs- und Eskalationslogik. Explizite Erfolgs- und Fehler-Exits, plus ein Weg, an einen Menschen zu eskalieren, wenn er feststeckt. Statt ewig dieselbe Sackgasse zu drehen.
• Error Handling, das recoverable von fatal unterscheidet. Ein fehlschlagender Test ist Feedback zum Handeln. Ein fehlendes Credential ist ein harter Stopp.

Ein konkretes Beispiel: Die Loop-engineerte Version von „fix diesen Bug" spezifiziert den Zyklus einmal, und du gehst. Das Ziel hat eine prüfbare Erfolgsbedingung (CI ist grün). Der Agent bekommt einen eigenen Git-Worktree, damit er nicht mit deiner Arbeit kollidiert, dazu Terminal, Test-Runner und Type-Checker. Er führt ein externes Log darüber, was er schon probiert hat, damit er keine Sackgassen wiederholt. Und er eskaliert nach drei gescheiterten Versuchen am selben Test an dich, statt endlos Tokens zu verbrennen.

Wie du anfängst

Du brauchst nicht den vollen Stack an Tag eins. Die meisten Teams adaptieren das inkrementell: erst ein einzelner Validierungsloop, parallele Worktrees später.

1. Nimm einen repetitiven Task mit prüfbarem Ergebnis (Tests grün, Lint sauber, Doc baut).
2. Schreib die Erfolgsbedingung explizit auf. Wenn du „fertig" nicht definieren kannst, kannst du keinen Loop bauen.
3. Gib dem Agent die nötigen Tools und einen isolierten Workspace.
4. Bau eine Stop-Bedingung und eine Eskalationsschwelle ein, bevor er je unbeaufsichtigt läuft.
5. Ergänze ein externes Log, damit er sich erinnert, was er probiert hat.
6. Erst dann: Trigger drumherum und laufen lassen.

Häufige Fragen

Wie unterscheidet sich das von Prompt Engineering?

Prompt Engineering optimiert eine einzelne Instruktion. Loop Engineering designt das System, das wiederholt Instruktionen ausgibt, Ergebnisse prüft und den nächsten Schritt entscheidet. Du skalierst dich selbst, statt jeden Prompt zu babysitten.

Wann Loop, wann One-shot-Task?

Nimm einen Loop, wenn das Ergebnis eines Schritts den nächsten verändern soll. Wenn nicht, ist ein einmaliger Task simpler und billiger.

Was hindert einen Loop daran, ewig zu laufen und Geld zu verbrennen?

Ein gut designter Loop hat explizite Terminierungslogik, ein Budget-Cap und eine Eskalationsschwelle. Zum Beispiel: nach drei gescheiterten Versuchen am selben Check an einen Menschen übergeben.

Wer hat den Begriff geprägt?

Addy Osmani hat „Loop Engineering" im Juni 2026 benannt und damit kristallisiert, was Claude-Code-Chef Boris Cherny und Peter Steinberger vorher beschrieben haben.

Brauche ich ein spezielles Framework?

Nein. Den Inner Loop liefert dein Harness (Claude Code, Codex oder das Claude Agent SDK). Den Outer Loop baust du aus Triggern, Verification und State. Das kann so simpel sein wie ein Cron-Job plus Log-Datei.