Warum du aufhören solltest, AI Agents zu promoten – und stattdessen Loops bauen

Letzte Woche postete Peter Steinberger einen Tweet, der acht Millionen Views bekam: „Du solltest keine Coding Agents mehr promoten. Du solltest Loops designen, die deine Agents promoten." Kurz darauf sagte Boris Cherny – der Erfinder von Claude Code – etwas Ähnliches bei Acquired Unplugged: „Ich prompt Claude nicht mehr. Ich habe Loops laufen. Die promoten Claude."

Und dann passierte, was im Internet immer passiert: Alle stritten sich, niemand sah einen Loop, und die Diskussion versank im Abstraktionsnebel.

Ich betreibe seit mehreren Monaten echte Loops. Nicht weil ichahead of the curve war – ich hatte einfach keine Lust mehr auf manuelle Sortierarbeit und habe sie automatisiert. Was ich herausfand: Der Loop-Gedanke ist keine Fortgeschrittenentechnik für AI-Poweruser. Es ist eine natürliche Evolution, die passiert, sobald du aufhörst, AI Agents als superclevere Copy-Paster zu behandeln, und anfängst, sie als Systeme zu sehen, die überwachen, entscheiden und in deinem Namen handeln können.

Die drei Loop-Typen, über die sich niemand einig ist

Hier liegt das Problem dieser Diskussion: Wenn Leute „Loop" sagen, meinen sie eine von drei Sachen – und die Unterschiede sind entscheidend.

Erstens gibt es den autonomen Task-Loop – im Grunde „mach weiter, bis fertig". Denk an Geoffrey Huntleys Ralph-Script (while :; do cat PROMPT.md | claude-code; done) oder den /goal-Befehl, den Codex und Claude Code mittlerweile nativ mitliefern. Das ist der „einmal anstoßen und vergessen"-Modus.

Zweitens gibt es den geplanten oder ereignisgesteuerten Loop – Arbeit, die läuft, während du nicht am Schreibtisch sitzt. Peter Steinbergers eigene HEARTEBEAT.md in OpenClaw ist das Musterbeispiel: eine Checkliste, die der Agent alle 30 Minuten nochmal durchgeht. Nachkommen dieses Patterns sind Codex-Automationen und Claude Codes geplante Routinen.

Drittens gibt es Orchestration Fan-Out – dynamische Workflows mit mehreren Agents, die gleichzeitig laufen. Claude Codes Map/Reduce-artige Operationen fallen hier rein. Das ist näher am Actor-Modell als an einem einfachen Loop.

Meine Einschätzung? Steinberger und Cherny beschreiben den zweiten Typ, eingebettet in den ersten. Die Loops, die ich laufen lasse, sind außen geplant und ereignisgesteuert – und einige von ihnen führen einmal ausgelöst Experiment-Inner-Loops aus. Diese Kombination ist da, wo der echte Hebel sitzt.

Der PR-Babysitter: Mein Einstieg ins Loop-Design

Ich hatte bereits AI Code Review auf jedem Pull Request. Claude prüfte zuerst, dann Codexs eingebaute Review, dann eine eigene GitHub Action, wo ich kontrollierte, was das Modell sah – komplette Konversationskontexte plus Patch-Diff.

Mein eigentlicher Workflow war absurd: PR einreichen, auf Reviews warten, dann Review-Kommentare in den Agent copy-pasten. Manchmal Screenshots. Manuell, repetitiv, seelentötend.

Eines Tages fragte ich meinen Agenten: „Kannst du nicht einfach den gh-Client nutzen und den Review-Status selbst abfragen?" Er konnte. Also fragte ich folgerichtig: „Kannst du nicht einfach immer wieder nachschauen und mir Bescheid sagen, wenn fertig?"

Diese eine Anfrage veränderte meinen Workflow komplett. Der Agent überwacht jetzt Änderungen beim Review-Status, holt sich neuen Kontext, analysiert das Feedback und erledigt die eigentliche Arbeit, es umzusetzen. Der Loop endet, wenn er zu einer Triage-Entscheidung kommt: Feedback akzeptieren, dagegen argumentieren, oder es an mich eskalieren.

Das Pattern lässt sich wunderbar verallgemeinern: Beobachte Zustandsänderungen in externen Systemen, wache auf, wenn sie passieren, hole frischen Kontext, analysiere, handle, triagiere. Sobald du diese Form erkennst, siehst du sie überall. Das Codex-Team liefert mittlerweile selbst ein babysit-pr-Skill, und Claude Codes Docs listen PR-Babysitting als Hauptanwendungsfall für ihren /loop-Befehl.

Inner Loops: Den Agent eigene Experimente durchführen lassen

Es gibt noch ein Loop-Pattern, das ich erst später zu schätzen lernte: den Experiment-Loop. Andrej Karpathys Autoresearch-Konzept brachte mich darauf – viele Iterationen durchlaufen, Ergebnisse messen, behalten was funktioniert. Ich richtete das auf einen langsamen Python-Pfad und ließ 49 Experimente in einer Stunde laufen. Das drückte die p95 Latenz von 339ms auf 34ms – für etwa 24 Dollar.

Dasselbe Pattern funktioniert bei härteren Problemen: Debugging von Agent-Verhalten in Produktion. Wenn etwas schiefläuft – ein seltsamer Trace in Braintrust, User-Feedback in Slack, oder etwas, das mir selbst auffällt – starte ich einen Worktree, füge den Trace ein und rufe den Test-Loop auf.

Was diesen Loop anders macht: Er zwingt zu einer Disziplin, gegen die die naive Intuition des Modells sich wehrt. Wenn man es machen lässt, wird ein Modell „tu nie X, Y, Z" in den System Prompt einbrennen und auf den einen Trace overfitten, den man gezeigt hat. Die Skill-Referenzen destillieren die Forschung, warum dieser Ansatz scheitert, und der Loop-Vertrag erfordert eine Hypothese und eine Testmatrix.

Ich brauche drei Fälle: den ursprünglichen Fehlerfall, ein benachbartes Positiv, das denselben Weg nehmen sollte, und ein Gegenbeispiel, das einen anderen Weg nehmen sollte. Drei oder vier Probes laufen parallel gegen lokales Dev, reconstituieren den exakten User-Kontext aus dem Trace. Jeder Lauf wird auf Tool-Calls, Latenz, Input-Token-Delta und Korrektheit bewertet. Das Modell kann nicht mogeln, indem es auswendig lernt – es muss tatsächlich verstehen.

Was sich wirklich ändert, wenn du Loops baust

Die größte Veränderung ist nicht technisch – sie ist konzeptionell. Wenn du einen Agent promotest, fährst du immer noch. Du bist Gaspedal, Navigator, Qualitätsprüfer. Loops kehren das um. Du wirst zum Architekten von Systemen, die sich selbst steuern.

Das bedeutet nicht, dass vollständige Autonomie das Ziel ist. Bei allem Wichtigen bin ich immer noch am Triage-Gate. Die Loops kümmern sich um die Monotonie, die Überwachung, die Wiederholung. Ich kümmere mich um die Urteile, die wirklich zählen.

Der zweite Shift: Loops zwingen dich, Erfolgskriterien explizit zu machen. Ein guter Loop hat klare Exit-Bedingungen, klare Entscheidungspunkte, klare Eskalationspfade. Du kannst keinen Loop bauen, ohne zu definieren, was „fertig" bedeutet. Diese Disziplin überträgt sich auf alles andere.

Drittens: Loops sind composable. Der PR-Babysitter arbeitet neben dem Experiment-Loop. Geplante Checks triggern On-Call-Reaktionen. Du baust eine Bibliothek von Verhaltensweisen, die zusammenarbeiten – statt einem Haufen einzelner Prompts.

Der praktische Einstieg

Wenn du mit Loops experimentieren willst, starte mit etwas, das du bereits schlecht automatisiert hast. Du hast wahrscheinlich eine GitHub Action, die periodisch etwas tut, oder eine Claude-Code-Session, die du manuell neu startest, oder einen Review-Prozess, bei dem du Outputs zwischen Tools hin und her copy-pastest.

Nimm den nervigsten Fall. Frag dich: Auf welche Zustandsänderung warte ich eigentlich? Welchen Kontext braucht der Agent, wenn die Änderung passiert? Welche Entscheidung muss er treffen?

Dann baue den Loop. Er muss nicht elegant sein. Er muss funktionieren und dich zurück in die Kontrolle über deine eigene Zeit bringen.

Die vollständigen Configs, Skills und CI-Workflows hinter meinen Loops gibt es in einem öffentlichen Snapshot-Repo: camwest/agent-skills. Das ist kein poliertes Produkt – es ist ein funktionierendes System, das sich mit meinem Lernen weiterentwickelt. Und genau darum geht es. Loops sind kein Ziel; sie sind eine Praxis.

Die Diskussion um AI Agents ertrinkt in Abstraktion. Hier ist die konkrete Version: Hör auf zu promoten, fang an Loops zu bauen, und sieh was passiert, wenn du die Maschine die Überwachung erledigen lässt, während du die Bedeutung klärst.