Von Prompting-Agents zu Loop Engineering

In KI-Coding-Kreisen kursiert eine Behauptung: Hör auf, deine Coding-Agenten zu prompten, und entwirf stattdessen Schleifen, die sie für dich prompten. Wie bei allem Neuen wird dies oft wiederholt und selten erklärt. Hier ist die praktische Version: Was eine Agenten-Schleife ist, warum sie wichtig ist und wie eine in der Produktion aussieht.

Unten kannst du einige meiner Gedanken lesen (mit Hilfe von Claude verfasst), die aus Experimenten, Recherchen und Gesprächen mit einigen unserer Studierenden, technischen Gründern, KI-Ingenieuren und Startups stammen.

Auch unsere kürzliche Live-Session zu "Autonome langlebige Coding-Agenten" könnte ein guter Ausgangspunkt für das Ganze sein.*

Woher die Behauptung stammt

„Du solltest Coding-Agenten nicht mehr prompten. Du solltest Schleifen entwerfen, die deine Agenten prompten."Peter Steinberger (

@steipete ), 7. Juni 2026. 2,2 Mio. Aufrufe.

Ursprünglicher Tweet

Boris Cherny, der Erfinder von Claude Code, macht denselben Punkt von der anderen Seite.

„Ich prompte Claude nicht mehr. Ich lasse Schleifen laufen. Sie sind es, die Claude prompten und herausfinden, was zu tun ist. Meine Aufgabe ist es, Schleifen zu schreiben."Boris Cherny (

@bcherny ).

Ursprünglicher Tweet

Es geht nicht darum, dass Prompt-Engineering tot ist. Beim Loop-Engineering verlagert sich die Arbeit eine Ebene nach oben: vom Schreiben des Codes zum Schreiben des Systems, das den Code schreibt. Die am weitesten fortgeschrittenen Entwickler berichten von Monaten, in denen sie Hunderte von PRs ausgeliefert haben, ohne eine IDE zu öffnen, wobei jede Zeile vom Agenten geschrieben wurde.

Was eine Schleife eigentlich ist

Eine Schleife ist ein kleines Programm, das du schreibst und das vier Dinge tut:

• den Coding-Agenten für dich prompter,
• liest, was er produziert hat,
• entscheidet, ob er fertig ist,
• und wenn nicht, ihn erneut mit dem Fehler oder dem nächsten Schritt prompter.

Du hörst auf, in der Schleife zu sitzen und Prompts zu tippen; du schreibst die Schleife, und das Modell wird zu einer Unterroutine, die sie aufruft.

Die Form ist immer dieselbe: ein Ziel setzen, handeln, prüfen, den Fehler zurückmelden und wiederholen, bis die Prüfung bestanden ist oder die Schleife sich selbst stoppt.

„Schleife“ bedeutet mindestens fünf Dinge

Ein Großteil der Meinungsverschiedenheiten rührt daher, dass Leute ein Wort für fünf verschiedene Ideen verwenden. Hier ist die Entwicklung, von der ältesten zur neuesten.

• ReAct (2022). Das ursprüngliche Forschungsmuster: denken, handeln, beobachten, wiederholen.
• AutoGPT (2023). Eine sich selbst promptende Zielschleife, berüchtigt dafür, nicht zu wissen, wann sie aufhören soll.
• ralph loop. Ein bewusster Kontext-Reset zwischen den Iterationen, damit der Agent nicht in seiner eigenen Geschichte ertrinkt.
• /loop und /goal. Kadenz und Abschlussbedingungen sind im Agenten eingebaut und tragen den Zustand über mehrere Durchläufe hinweg.
• Orchestrierung. Ein Autor fächelt viele Agenten auf, die dein GitHub, Slack und Chat lesen und entscheiden, was als Nächstes gebaut werden soll.

Die Teile, die du tatsächlich zusammenbaust

Die Entwicklung erklärt, was die Leute mit Schleife meinen; dies ist, woraus eine Schleife gebaut ist. Dieselben sechs Teile tauchen jedes Mal auf, und die meisten sind jetzt in den Coding-Tools integriert, anstatt dass du sie selbst als benutzerdefinierte Skripte pflegen musst.

• Ein Auslöser. Etwas, das die Schleife startet, ohne dass du auf „Los“ drücken musst: ein Zeitplan, ein Webhook, eine Dateiänderung, ein Label, das auf einer PR landet. Das unterscheidet eine echte Schleife von einem einmaligen Durchlauf, den du von Hand wiederholst.
• Isolation. Ein privater Checkout pro Agent, normalerweise ein git worktree, damit zwei gleichzeitig laufende Agenten sich nicht gegenseitig die Dateien überschreiben. Sobald du mehr als einen ausführst, ist dies nicht mehr optional.
• Schriftlich festgehaltener Kontext. Die Konventionen, Build-Schritte und projektspezifischen Regeln werden dort aufbewahrt, wo der Agent sie bei jedem Durchlauf liest. Überspringe das, und die Schleife leitet dein Projekt bei jedem Durchlauf von Grund auf neu ab und rät bei den Lücken.
• Zugriff auf deine Werkzeuge. Verbindungen zu Issue-Tracker, CI, Datenbank und Chat, damit die Schleife die PR öffnen, das Ticket verlinken und das Ergebnis posten kann, anstatt einen Fix auszugeben und darauf zu warten, dass du ihn den Rest des Weges trägst.
• Ein zweiter Agent prüft. Ein separater Arbeiter, der die Ausgabe bewertet, wird von dem getrennt, der sie produziert hat, weil ein Modell, das seine eigene Arbeit überprüft, fast alles durchlässt.
• Zustand auf der Festplatte. Eine Markdown-Datei, ein Board oder eine Warteschlange: alles außerhalb des Gesprächs, das aufzeichnet, was erledigt ist und was als Nächstes ansteht. Das Modell vergisst zwischen den Durchläufen; die Datei nicht.

Baue diese sechs Teile zusammen, und du hast einen guten Ausgangspunkt für Loop-Engineering. Früher hast du alles von Hand gebaut; jetzt werden die meisten Teile als integrierte Funktionen ausgeliefert, weshalb das Muster von einer Randtechnik in den allgemeinen Gebrauch übergegangen ist.

Eine konkrete Schleife: der PR-Babysitter

Ein konkretes Beispiel, das du heute bauen kannst:

• Auslöser. Alle 15 Minuten.
• Umfang. Offene PRs mit dem Label agent-watch.
• Aktion. Wenn CI aus einem deterministischen Grund rot ist, versuche einen Fix. Wenn sich der Hauptzweig verschoben hat, rebase einmal.
• Budget. Ein Fixversuch pro PR, fünf Minuten, zehn geänderte Dateien.
• Stoppbedingung. CI grün oder Budget erschöpft, dann stoppen und einen Menschen benachrichtigen.

Du bekommst gemergte PRs statt eines Rückstaus kaputter Builds. Die gleiche Form deckt die meisten Betriebsaufgaben ab:

• CI-Gesundheit. Alle 30 Minuten fehlgeschlagene Läufe abrufen und nach Signatur gruppieren, sodass zehn rote PRs mit einer Ursache zu einer Sache werden, die du dir ansehen musst.
• Deploy-Verifizierung. Nach einem Push deine Endpunkte abfragen, 200er und den erwarteten Inhalt bestätigen und Regressionen markieren, bevor die Nutzer es tun.
• Feedback-Clustering. Alle 30 Minuten Kommentare aus deinen Kanälen abrufen, nach Themen gruppieren und jedes Cluster der Datei oder dem Dokument zuordnen, das dafür verantwortlich ist.

Eine konkrete Claude-Code-Schleife mit /goal

Der Babysitter ist eine Schleife, die du selbst zusammenbaust; es hilft auch, eine zu sehen, die im Agenten integriert ist. In Claude Code ist die kleinste vollständige Schleife /goal: du übergibst ihr einen überprüfbaren Endzustand, und sie macht so lange weiter, bis dieser Zustand wahr ist.

Hier ist ein Beispiel für /goal, das als In-Session-Befehl in Claude Code verwendet wird. Du startest die Sitzung und setzt dann das Ziel innerhalb dieser:

1$ claude  # Claude Code starten
2$ /goal tests in test/auth pass   # Ziel in der Sitzung setzen

Es ist die gleiche Form aus Handeln, Prüfen und Wiederholen wie zuvor, mit integriertem Verifizierer.

An dieser Stelle wird klar, dass ein starkes /goal weniger wie ein Prompt und mehr wie ein Vertrag klingt. Die guten spezifizieren vier Dinge: den Endzustand, den du haben willst, den Nachweis, der belegt, dass du ihn erreicht hast, die Einschränkungen, die der Agent auf dem Weg dorthin nicht verletzen darf, und das Budget an Arbeit, das er ausgeben darf. Wenn du eines davon vage lässt, füllt das Modell die Lücke mit der einfachsten Interpretation: es hört früh auf, nimmt eine Abkürzung oder definiert Erfolg so um, dass das Protokoll nach Fertigstellung aussieht, während das eigentliche System kaputt ist.

• Setze die Bedingung. Tippe /goal plus einen überprüfbaren Endzustand, z. B. /goal tests in test/auth pass. Der erste Durchlauf beginnt sofort.
• Der Agent arbeitet einen Durchlauf. Er bearbeitet, führt die Tests aus und zeigt die Ergebnisse in der Sitzung an.
• Ein Evaluator prüft. Ein schnelles Modell liest das Protokoll und entscheidet, ob die Bedingung erfüllt ist oder nicht, sodass der Agent seine eigene Arbeit nicht selbst bewertet.
• Schleife fortsetzen oder beenden. Nicht erfüllt bedeutet einen weiteren Durchlauf mit Anleitung; erfüllt bedeutet, dass das Ziel sich selbst löscht und der Lauf stoppt.

Der Zustand wird über Durchläufe hinweg getragen, sodass er nicht vorzeitig abbricht oder zwischendurch eine Einschränkung fallen lässt. Ein paar Steuerungselemente sorgen für Zuverlässigkeit:

• Mache die Prüfung messbar. Ein Testergebnis, ein Exit-Code, eine Dateianzahl oder eine leere Warteschlange. npm test endet mit Exit 0 ist ein Ziel; „mach es besser“ ist keins.
• Grenze den Lauf ein. Füge etwas wie „oder stoppe nach 20 Durchläufen“ hinzu, damit eine feststeckende Schleife anhält, anstatt Durchläufe zu verbrennen.
• Kombiniere es mit dem Automatikmodus, sodass Durchläufe unbeaufsichtigt ablaufen, und verwende /goal clear, um das Ziel vorzeitig abzubrechen.

Der Schritt des Evaluators enthält eine nützliche Feinheit: der Prüfer muss nicht dasselbe Modell sein wie der Programmierer. Sobald die Schleife verschiedene Rollen hat (Planer, Ausführender, Evaluator, visueller Reviewer), kann jede Rolle auf einem anderen Modell laufen, und die Wahl, welches Modell welche Rolle übernimmt, wird zu einer Architekturentscheidung und nicht zu einer einzigen Wette auf einen „besten“ Coding-Agenten. Einige Modelle planen besser, einige führen günstiger aus, einige beurteilen einen Screenshot genauer, und ein guter Orchestrator ermöglicht es dir, sie pro Rolle auszutauschen, anstatt darauf zu warten, dass ein Anbieter jede Kategorie gewinnt.

Es funktioniert gut für API-Migrationen (verschiebe jede Aufrufstelle, bis es kompiliert und die Tests bestanden sind), Refactorings (teile eine Datei, bis jedes Modul unter dem Budget liegt), Issue-Backlogs (arbeite eine gekennzeichnete Warteschlange ab, bis sie leer ist) und Eval-Schleifen (stimme einen Prompt ab, bis die Punktzahl einen Schwellenwert überschreitet). /loop ist das Gegenstück für Arbeiten ohne einzelne Ziellinie: anstatt einer Abschlussbedingung wird zu einem Zeitplan erneut gepromptet, was eine Schleife wie der PR-Babysitter am Laufen hält.

Viele Schleifen unbeaufsichtigt ausführen

Eine einzelne /goal-Schleife ist ein Agent, der auf eine Ziellinie hinarbeitet. Viele unbeaufsichtigte Prozesse auszuführen, erhöht den Einsatz, denn eine Schleife ist nur so vertrauenswürdig wie ihre Fähigkeit, ihre eigene Arbeit zu überprüfen. Chernys Einrichtung für den autonomen Betrieb von Opus über Stunden läuft auf fünf Schritte hinaus:

1. Berechtigungen automatisch genehmigen, damit der Agent nicht bei jedem Tool-Aufruf anhalten muss, um nachzufragen.
2. Dynamische Arbeitsabläufe verwenden (Ultracode in den Prompt einfügen), um auf viele Agenten zu verzweigen, anstatt einen einzigen seriellen Thread zu verwenden.
3. /goal oder /loop verwenden, um es am Laufen zu halten. /goal setzt eine Abschlussbedingung, /loop promptet zu einem Zeitplan erneut, und beide tragen den Zustand, sodass es nicht vorzeitig abbricht.
4. In der Cloud ausführen (Desktop- oder mobile App), damit die Sitzung überlebt, wenn du den Laptop schließt.
5. Ihm eine Möglichkeit zur Selbstverifizierung Ende-zu-Ende geben. Claude in Chrome für das Web, ein Simulator-MCP für Mobilgeräte und ein Live-Server für das Backend. Dies ist der Schritt, der die anderen vier sicher macht.

Die vollständige Sequenz:

1claude --permission-mode auto                          # 1 · keine Genehmigungsaufforderungen
2ultracode  orchestrate sub-agents to ship the feature  # 2 · Verzweigung
3/goal all tests pass and the demo loads clean          # 3 · weiterlaufen
4→ cloud / desktop app                                  # 4 · Laptop schließen
5→ chrome ext · sim MCP · live server                   # 5 · selbst verifizieren, dann anhalten

crabfleet: Orchestrierung als Produkt

Orchestrierung ist mit einem konkreten Werkzeug leichter vorstellbar. Peter Steinbergers crabfleet, ein OpenClaw-Projekt mit dem Titel „Mission Control für Agentenläufe“, ist eine als Produkt verpackte Schleife, und seine Form bildet alles oben Genannte ab.

• Arbeit als Karten auf einem Board. Aufgaben werden als Karten erfasst, die aus einem Prompt, einem GitHub-Issue oder einer PR erstellt werden, und durchlaufen dann die Phasen „zu erledigen“, „in Bearbeitung“, „menschliche Überprüfung“ und „erledigt“. Dieses Board ist die Warteschlange der Schleife und ihr Stopp-und-Melde-Schritt, sichtbar gemacht.
• Dauerhafte Läufe, nicht „Feuer und vergiss“. Jeder Lauf ist ein nachverfolgter Versuch mit Heartbeats, sodass er weiterläuft, wenn du wegschaust, und einen geschlossenen Laptop überlebt. Du übernimmst nur, wenn die Laufzeitumgebung angibt, dass sie Übergabe unterstützt.
• Agenten, die Agenten spawnen. Ein Lauf kann Kindersitzungen starten, Nachrichten senden, Protokolle lesen und seine eigene Zusammenfassung innerhalb einer Sandbox aktualisieren: Speicher auf der Festplatte und Verzweigung an einem Ort, ein Autor und viele Agenten.

Es läuft auf wegwerfbaren Cloud-Sandboxen mit browserbasierten Terminals, was das Weggehen von einem unbeaufsichtigten Lauf sicher macht. Der Punkt ist nicht das spezifische Werkzeug, sondern dass die Schleife zur Infrastruktur geworden ist: eine Warteschlange, dauerhafte Ausführung, Verzweigung und ein menschliches Prüf-Gate sind jetzt Dinge, die du konfigurierst, anstatt sie jedes Mal von Hand zu skripten.

Wohin die Kosten jetzt gehen

Zwei Jahre lang war die Kostenfrage beim KI-Coding einfach: welches Modell und wie viele Token. Innerhalb einer Schleife zielt dieser Instinkt auf die falsche Ebene. Die Ausgabe ist nicht mehr ein einzelner Aufruf, sondern wie oft die Schleife durchläuft, sodass eine Schleife, die sechsmal wiederholt, bevor sie konvergiert, sechsmal so viel kostet wie eine, die beim ersten Versuch landet, beim gleichen Modell.

Das ändert, was optimierungswürdig ist:

• Iterationen sind die Budgetposition, nicht Token. Ein billigeres Modell, das doppelt so oft schleift, ist nicht billiger. Verfolge daher die Kosten pro erledigter Aufgabe, nicht die Kosten pro Aufruf.
• Ein schwacher Verifizierer ist der teuerste Bug, den du ausliefern kannst. Wenn die Prüfung, die „erledigt“ bestimmt, locker ist, stoppt die Schleife entweder frühzeitig bei kaputter Arbeit oder arbeitet an Arbeit, die bereits in Ordnung war, und beides verschwendet ganze Iterationen. Ziehe dies vor allem anderen an.
• Schnelles Scheitern ist eine Kostenkontrolle. Eine Schleife ohne Obergrenze für aufeinanderfolgende Fehlschläge wird nicht irgendwann erfolgreich sein; sie wird irgendwann das Konto leeren, daher schützt die Stoppbedingung die Rechnung genauso wie die Codebasis.

Früher hast du den Prompt optimiert; jetzt optimierst du die Schleife, denn dort summieren sich die Kosten.

Wann nicht schleifen

Schleifen zahlen sich aus, wenn eine Aufgabe sich wiederholt und eine Maschine erkennen kann, wann sie erledigt ist. Außerhalb davon automatisiert eine Schleife nur unnötige Arbeit. Überspringe sie in diesen Fällen:

• Einmalige Bearbeitungen. Wenn du es in einem einzigen Durchlauf erledigen kannst, ist eine Schleife reiner Overhead.
• Unabgegrenzte oder explorative Arbeit. „Finde heraus, warum Nutzer abwandern“ hat keine Bestehensbedingung, daher konvergiert die Schleife nie.
• Alles ohne eine billige automatisierte Prüfung. Wenn der einzige Verifizierer deine eigenen Augen sind, bist du immer noch in der Schleife. Baue zuerst die Prüfung oder erledige die Aufgabe von Hand.

Was schiefgehen kann

Eine Schleife, die läuft, während du schläfst, macht auch Fehler, während du schläfst, und die Fehlermodi sind vorhersehbar.

• Die Verifikationslast bleibt menschlich. Die Schleife schreibt schneller, als du überprüfen kannst. Wenn du aufhörst, die Diffs zu lesen, hast du die Arbeit nicht entfernt, sondern nur aufgeschoben.
• Verständnislücken werden größer. Code auszuliefern, den du nicht geschrieben hast, schneller, als du ihn aufnehmen kannst, untergräbt das Modell deines eigenen Systems, und diese Schuld wird beim nächsten Vorfall fällig.
• Stille Drift bei lockerer Prüfung. Ein schwacher Verifizierer lässt falsche, aber bestehende Arbeit bei jeder Iteration durch, sodass die Schleife produktiv aussieht, während sie ein Loch gräbt.

Nichts davon ist ein Argument gegen Schleifen; es ist der Grund, warum der Ingenieur, der die Schleife entwirft, mehr zählt, nicht weniger.

Wie du deine eigene bauen kannst

1. Wähle eine wiederholbare Aufgabe. PRs beaufsichtigen, CI reparieren, Deployments verifizieren: beginne mit Routinearbeit.
2. Setze einen engen Rahmen. „Repariere die Validierung des Billing-Webhooks, ändere nur app/api/billing und lib/billing“ ist besser als „repariere den Bug“. Eine lockere Schleife schweift ab.
3. Gib ihr ein Budget und eine Stoppbedingung. Maximale Versuche, maximale Laufzeit, maximale Dateien, maximale Ausgaben, maximale aufeinanderfolgende Fehlschläge. Eine unbeaufsichtigt laufende Schleife ist auch eine Schleife, die unbeaufsichtigt Fehler macht.
4. Füge einen unabhängigen Verifizierer hinzu. Ein separater Sub-Agent bewertet die Arbeit, denn der Agent, der den Code geschrieben hat, ist der schlechteste Richter darüber, ob er fertig ist.
5. Lass sie in einer Kadenz laufen. /loop für ein Intervall, cron für einen Zeitplan, Hooks an Lebenszykluspunkten oder GitHub Actions, damit sie einen geschlossenen Laptop überlebt.
6. Halte den Speicher auf der Festplatte. Das Modell vergisst zwischen den Durchläufen, daher lebt der Zustand in Markdown oder auf einem Board, nicht im Kontextfenster.

Die Erkenntnis: Die Schleife, nicht das Modell, ist jetzt der teure und fehleranfällige Teil. Baue sie wie jemand, der vorhat, der Ingenieur zu bleiben, der für die Ausgabe verantwortlich ist, nicht nur die Person, die den Lauf startet.

Wenn du Fehler siehst oder Dinge, die einer weiteren Klärung bedürfen, zögere nicht, dich zu melden.

Weitere nützliche Referenzen

• Addy Osmani (@addyosmani), über KI-gestützte Coding-Loops
• Matt Van Horn (@mvanhorn), „WTF Is a Loop?“
• Peter Steinberger (@steipete), über das Entwerfen von Schleifen
• Boris Cherny (@bcherny), über den autonomen Betrieb von Agenten