AI Agent Loops: Wie sich selbst korrigierende Coding-Agents die Arbeit zu Ende bringen

So, wie die meisten Leute einen KI-Coding-Agent immer noch benutzen, sieht es aus wie Ping-Pong. Du promptest, er antwortet, du erkennst, was schiefläuft, du promptest erneut. Du bist der Korrektur-Motor, und du steckst bei jedem einzelnen Zug in der Schleife.

Ein Loop dreht das um. Du beschreibst, was du willst, der Agent legt los, schreibt seine eigene Checkliste, findet seine eigenen Schwachstellen und läuft erneut, bis das Ergebnis hält. Du bist nicht mehr derjenige, der die Fehler abfängt. Der Agent fängt seine eigenen ab.

Diese Verschiebung ist kein Hype. Die Leute, die diese Tools gebaut haben, setzen darauf. Boris Cherny und Cat Wu, die Macher von Claude Code, reden davon, in Agent Loops zu coden. Geoffrey Huntley, der den "Ralph loop" getauft hat, lässt Agents nachts in einer schlichten while-Schleife laufen. Das Muster hat inzwischen einen Namen, und es lohnt sich, es zu verstehen, bevor du drei Prompts von Instagram abschreibst.

Vom Prompt-Ping-Pong zum Loop

Ein einzelner Prompt ist ein Einmalschuss. Du fragst, du bekommst eine Antwort, die Sache ist erledigt. Um sie zu verbessern, musst du die Lücke bemerken und erneut prompten. Skaliere das auf ein echtes Feature, und schon machst du Dutzende Mikro-Korrekturen von Hand.

Ein AI Agent Loop schließt diese Lücke im Agent selbst. Du setzt ein Ziel, der Agent plant, handelt, schaut sich das Ergebnis an und korrigiert, immer wieder, bis das Ziel erreicht ist. Du bist nicht verschwunden, du prüfst am Ende. Aber du bist nicht länger der Flaschenhals bei jeder Iteration.

Prompt-Ping-Pong steckt dich bei jedem Zug in die Schleife. Ein echter Loop steckt den Agent hinein.

Was ein AI Agent Loop wirklich ist

Jeder agentische Loop läuft auf denselben vier Takten: planen, handeln, beobachten, korrigieren. Der Agent entscheidet über den nächsten Schritt, macht ihn (schreibt Code, führt einen Befehl aus, liest eine Datei), liest, was passiert ist, und passt an. Claude schreibt Code, führt die Tests aus, sieht einen Fehlschlag, korrigiert ihn, führt die Tests erneut aus. Diese Rückkopplung ist der ganze Trick. Sie macht den Loop selbstkorrigierend statt bloß repetitiv.

Die stärkste Variante des Loops verteilt diese Takte auf drei Rollen: eine, die plant, eine, die baut, eine, die prüft. Sie getrennt zu halten ist genau das, was den Agent davon abhält, im selben Atemzug, in dem er schreibt, auch seine eigene Hausaufgabe zu benoten.

Der Drei-Befehle-Loop, den du heute kopieren kannst

Hier ist das Setup, das gerade die Runde macht, neu aufgebaut als drei Claude-Code-Slash-Befehle. Du fügst jeden einmal ein, der Agent legt den Befehl an, dann führst du sie der Reihe nach aus.

Der Planer, /spec:

Befrage mich eine Frage nach der anderen, bis du vollständig verstehst,
was ich will. Schreibe dann einen präzisen Plan nach specs/project.md:
das Ziel, die genauen Anforderungen, die Randfälle und was im Scope ist
versus außerhalb des Scopes. Halte ihn kurz und knackig, keinen Roman.

Der Builder, /build:

Lies specs/project.md und baue genau das, was darin beschrieben ist,
nicht mehr. Wenn du fertig bist, liste jede Anforderung aus dem Plan auf
und markiere, welche du abgedeckt hast.

Der Reviewer, /review:

Vergleiche das Gebaute mit specs/project.md, Anforderung für Anforderung.
Sag für jede, ob sie abgedeckt ist. Schreibe die nötigen Korrekturen auf
und gib sie an /build zurück. Gib erst grünes Licht, wenn der ganze Plan
abgedeckt ist.

Drei Befehle, ein Loop: spec schreibt den Plan, build setzt ihn um, review vergleicht ihn mit dem Plan und schickt die Korrekturen an build zurück. Das dreht sich weiter, bis jede Anforderung erfüllt ist.

Der Plan ist die Quelle der Wahrheit. Das Review misst den Build daran, nicht an einem Bauchgefühl.

Unter der Haube ist das Spec-driven Coding: nicht der Chat-Verlauf, sondern die geschriebene Spec ist das, woran der Agent gemessen wird. GitHubs Open-Source Spec Kit gießt dieselbe Idee in Form mit /specify, /plan, /tasks und /implement, und es läuft auf Claude Code, Copilot, Cursor, Codex CLI und Gemini CLI gleichermaßen.

Warum ein frischer Kontext den Loop zum Laufen bringt: der Ralph loop

Geoffrey Huntley hat die roheste Variante davon Mitte 2025 getauft: den Ralph loop. Die Idee ist eine schlichte Shell-Schleife, die dem Agent immer wieder denselben Prompt gegen eine geschriebene Spec serviert, ihn eine Aufgabe auswählen und ausliefern lässt und dann einen brandneuen Agent mit sauberem Kontext startet und ihm denselben Prompt erneut serviert.

while hat_weitere_todos; do
  agent --prompt "Bearbeite die nächste Aufgabe aus todo.md" --non-interactive
done

Der nicht offensichtliche Teil ist der Kontext-Reset. Eine lange Session fault vor sich hin: Das Fenster füllt sich mit altem Denken, Sackgassen und veralteten Dateiinhalten, und das Modell fängt leise an, Anweisungen fallenzulassen. Jede Ralph-Iteration ist ein neuer Agent, der das aktuelle Repo und die Todo-Liste von der Platte liest, eine Arbeitseinheit erledigt, committet und sauber rausgeht. Huntley hat ihn mit Absicht nach der Figur aus den Simpsons benannt: Er sieht zu dumm aus, um zu funktionieren, und er funktioniert. Wenn du schon mal eine lange Session anfangen sehen hast zu halluzinieren, weißt du bereits, warum ein frisches Fenster ein überladenes schlägt.

/loop und /goal in Claude Code

Claude Code bringt Loop-Primitive direkt mit. /goal setzt einen dauerhaften Endzustand, also wie "fertig" aussieht, und Claude bewertet den Fortschritt nach jedem Durchlauf daran, statt nur den nächsten Schritt auszuführen. /loop wiederholt eine Aufgabe in einer Taktung oder bis eine Bedingung erfüllt ist, in Formen wie /loop every 10m oder /loop until: <Bedingung>. Zusammen erzeugen sie einen selbststeuernden, selbstbeendenden Loop: Claude arbeitet an der Differenz zwischen aktuellem Zustand und Ziel und stoppt, wenn das Ziel erfüllt ist oder du Ctrl+C drückst.

Das Detail, das zählt: Ein Loop wahrt die Kontinuität. Er erinnert sich, was er versucht hat und warum es gescheitert ist, sodass jeder Durchlauf auf dem vorigen aufbaut, statt dieselbe Sackgasse zu wiederholen. Das ist der umgekehrte Kompromiss zu Ralphs Reset auf sauberen Kontext, und beide sind legitim. Kontinuität für eng geführte Selbstkorrektur, frischer Kontext, wenn das Fenster fault. Zu wissen, wann man wonach greift, das ist die eigentliche Kunst.

Derselbe Loop, bei jedem Provider

Loops sind kein Claude-Feature, sie sind die Richtung, in die sich das gesamte Feld bewegt. Die Namen unterscheiden sich, die Form nicht.

Codex CLI hat den Loop öffentlich am weitesten getrieben. OpenAIs Team hat sein /goal als seine Variante des Ralph loop vorgestellt, und Andrew Chen von a16z hat es über Nacht an einem Gerätetreiber laufen lassen, 14 Stunden am Stück ohne Eingriff. Er merkte außerdem an, es würde "den Token-Verbrauch um das 10.000-Fache hochtreiben", was der ehrliche Preis dafür ist, einen Agent einen halben Tag lang malmen zu lassen.

Der Haken: ein Loop verstärkt alles

Ein Loop verstärkt nicht nur guten Output, er verstärkt auch einen schlechten Plan. Richte einen selbstkorrigierenden Agent auf eine vage Spec, und er wird mit voller Überzeugung das Falsche bauen, es gegen dieselbe vage Spec prüfen und absegnen. Der Plan ist der Hebel. Eine scharfe Spec spart dir zehn Prompts, eine schwammige verschwendet hundert.

Zwei Fehlermodi, auf die du achten solltest. Die Kosten laufen davon: Jede Iteration verbrennt Tokens, und ein unbegrenzter Loop auf einem unklaren Ziel kann eine Menge verbrennen. Und der Loop kann ewig drehen, indem er Sieg verkündet oder ein Ziel jagt, das er nie erfüllen kann. Begrenze ihn: eine klare until-Bedingung, eine Token-Obergrenze oder ein menschlicher Checkpoint vor dem Merge. Ein Loop ohne Stopp ist keine Autonomie, sondern ein Durchgehen.

Loops über eine ganze Flotte fahren

Einen einzelnen selbstkorrigierenden Agent zu beaufsichtigen, ist leicht. Der Hebel zeigt sich, wenn du mehrere gleichzeitig laufen lässt, jeden auf seiner eigenen Aufgabe loopend, und genau da hört das Beobachten eines Terminals auf zu skalieren.

Genau dafür ist AgentsRoom gebaut. Es ist ein Multi-Agent-Cockpit: Jeder Agent hat eine Rolle, einen Live-Statuspunkt und seine eigene Farbe, und du überwachst die ganze Flotte aus einem einzigen Fenster. Leg ein Ticket auf das Backlog, und ein Agent greift es sich, fährt seinen plan-build-review-Loop und reicht dir ein sauberes Diff. Das ist Spec-driven AI Coding in der Praxis: Das Ticket ist die Spec, der Agent fährt den Loop, du prüfst das Ergebnis.

Weil lange Loops den Kontext faulen lassen, hat AgentsRoom ein Auge darauf. Jeder Agent schreibt am Ende jedes Zugs einen einzeiligen Status, und wenn ein Agent ihn zwei Züge in Folge nicht mehr aktualisiert, erscheint eine Warnung mit einem Ein-Klick-Neustart auf sauberem Kontext, genau derselbe Reset auf ein frisches Fenster, auf den sich der Ralph loop stützt. Lies auf der Seite Erkennung von Kontext-Drift, wie das funktioniert.

Und weil der Loop provider-agnostisch ist, bist du an keinen gebunden. Fahr ein Ticket auf Claude Code, das nächste auf Codex, ein weiteres auf Gemini CLI, alles im selben Dashboard, jedes loopend in seinem eigenen git worktree, damit sich parallele Agents nie ins Gehege kommen. Setz sie los, bevor du dich abmeldest, und prüf die Diffs am Morgen, das ist der ganze Sinn von Coding-Agents im Hintergrund und der Nachtschicht.

Setz das Ziel einmal, lass den Loop es schließen, prüf am Ende. Lade AgentsRoom herunter, wirf einen Blick auf die Provider-Kompatibilitätsmatrix und lies mehr über das Review pro Agent und den Multi-Provider-Support.