100 PRs am Tag: Die 4 Loop-Typen für autonome KI-Agenten

Hunderte dynamische KI-Agenten klingen in der Theorie nach grenzenloser Skalierung. In der Praxis erntet man Architekturschulden, wenn man dem ausführenden KI-Modell erlaubt, die eigene Arbeit für gut zu befinden. Erfolgreiches agentisches Coding skaliert nicht durch klügere Sprachmodelle, sondern durch die Wahl der passenden Schleifen-Architektur und maschinell erzwungene Abbruchbedingungen.

Key Takeaways (TL;DR)

• Delegation ohne Urteil: Übergebe die Ausführung einer Aufgabe an Agenten, behalte aber stets die Kontrolle über die maschinellen Kriterien der Verifikation.
• Trennung der Instanzen: Der Agent, der einen Code-Vorschlag generiert, darf niemals dessen Freigabe erteilen.
• Pilotläufe erzwingen: Skaliere dynamische Workflows zunächst im kleinen Rahmen. Hundert gestartete Agenten ohne funktionierende Abbruchbedingung verbrennen lediglich Budget.
• Skripte über Argumentation: Nutze für deterministische Abläufe fest codierte Skripte anstelle von Agenten, die Handlungsstränge jedes Mal theoretisch neu herleiten.

Basiert auf “Practical Loop Engineering” von Addy Osmani und “Getting started with loops” von Delba Oliveira (Claude Code Team). Die Originale findest du hier: https://addyosmani.com/blog/practical-loop-engineering und https://x.com/ClaudeDevs

Addy Osmani koordiniert bei seiner Arbeit täglich zwischen fünf und zehn Agenten gleichzeitig. Bei einer solchen Auslastung wird manuelle Kontrolle unmöglich. Vor wenigen Monaten bestand Loop Engineering noch aus handgeschriebenen Bash-Skripten, die versuchten, autonome Agenten wie den Ralph Loop von Geoff Huntley im Takt zu halten. Inzwischen stellen sowohl Osmani als auch das Entwicklerteam hinter Claude Code fest, dass diese Primitiven direkt in die Werkzeuge gewandert sind. Ein Loop ist definiert als ein Agent, der Arbeitszyklen wiederholt, bis eine deterministische Abbruchbedingung eintritt. Das Claude Code Team unterteilt diese Architektur in vier spezifische Typen, die je nach Codebasis skaliert werden müssen. Auf einer grünen Wiese lässt man Agenten freier laufen als in der alten Codebasis einer Bank.

Der Turn-based Loop: Das Skill-Nadelöhr

Jeder einzelne Prompt startet einen Turn-based Loop. Der Auslöser ist die menschliche Eingabe, der Abbruch erfolgt, sobald das Modell glaubt, die Aufgabe erfüllt zu haben. Ein typisches Beispiel ist die Anweisung, einen Like-Button zu bauen. Der Agent liest den Code, integriert den Button, führt grundlegende Tests aus und meldet Vollzug.

Der Flaschenhals ist hier die menschliche Verifikation nach jedem Zyklus. Die Lösung besteht darin, Prüfschritte fest in einer SKILL.md zu codieren. Statt dem Modell zu erlauben, nach einer Code-Änderung einfach eine Erfolgsmeldung auszugeben, zwingt ein Skill den Agenten, externe Prüfwerkzeuge zu bedienen.

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
# Verifying frontend changes
Never report a UI change as complete based on a successful edit alone. Verify it the way a human reviewer would:
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input, toggle): click it, confirm the expected state change, and screenshot before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome Devtools MCP, run a performance trace and audit Core Web Vitals.
If any step fails, fix the issue and rerun from step 1.

Solche quantitativen Vorgaben übersetzen manuelle Überprüfungen direkt in maschinell erzwingbare Endzustände.

Goal-based Loops: Die Arbeit deterministisch auslagern

Wenn eine einzige Iteration nicht ausreicht, übernimmt der Goal-based Loop (/goal). Er zwingt den Agenten zu arbeiten, bis ein exakt messbarer Zustand erreicht ist. Das Modell entscheidet dabei explizit nicht selbst, wann eine Leistung ausreicht, um verfrühte Erfolgsmeldungen zu unterbinden. Ein Evaluator-Modell prüft stattdessen harte Metriken nach jeder Iteration.

/goal Refactor the data-fetching layer in Dashboard.tsx until Lighthouse score is >= 92. Stop after 10 turns.

Osmani nutzt diese Struktur auch für teiloffene Aufgaben wie das Abarbeiten von GitHub-Issues. Ein Agent erhält den Befehl, die letzten zehn Issues zu sichten und bei Vorliegen aller relevanten Informationen selbstständig zu schließen.

Time-based Loops für den Open-Source-Alltag

Ein Time-based Loop verhält sich wie ein klassischer Cronjob. Er überwacht externe Zustände in festen Intervallen. Osmani nutzt dies für sein Projekt “Agent Skills”, das bei 80.000 Sternen phasenweise 90 Pull Requests am Tag verarbeitet. Eine Schleife sichtet dort stündlich eintreffende Issues, adressiert Kommentare und schließt automatisch Pull Requests, die den Beitragsrichtlinien widersprechen. Wenn beispielsweise Übersetzungen eingereicht werden, die das Kernteam nicht warten kann, lehnt der Agent diese direkt ab.

Loops lassen sich nahtlos mit Zielen kombinieren, um komplett autonome Entwicklungszyklen zu schaffen.

/loop every 24h "Check GitHub for issues labeled 'bug'. If one exists, use /goal to implement a fix until all local tests pass and push the branch."

Entwickler müssen hierbei den Ausführungsort beachten. Der Befehl /loop läuft lokal auf dem Rechner und bricht ab, wenn der Prozess gestoppt wird. Der Befehl /schedule verlagert diese Routinen dauerhaft in die Cloud. Solche Cloud-Schleifen verfallen aus Sicherheitsgründen nach sieben Tagen, lassen sich aber über eine Wiederaufnahme der Sitzung jederzeit reaktivieren.

Proaktive Loops und die Gefahr der blinden Delegation

Die vierte Eskalationsstufe, der proaktive Loop, benötigt keinen Menschen mehr in Echtzeit. Ereignisse triggern ganze Workflows. Hier entsteht die höchste Hebelwirkung, aber auch das absolut größte Risiko.

Osmani ließ Agenten Konkurrenzprodukte analysieren und Code für vermeintlich fehlende Funktionen vorschlagen. Die Agenten waren von ihren Lösungen vollkommen überzeugt. Der menschliche Abgleich offenbarte jedoch, dass die generierten Features massive architektonische Komplexität ohne echten Nutzen für die Anwender einführten. Die Modelle können Code produzieren, sie besitzen jedoch keinen Sinn für echtes Produktdesign.

Erschwert wird dies durch eindimensionale Zuversicht. Ein Agent baut eine Benutzeroberfläche und bewertet die Performance basierend auf Desktop-Metriken als exzellent. Er übersieht dabei völlig, dass das Projekt primär für mobile Endgeräte konzipiert ist. Die Lösung besteht in der strikten Trennung der Agenten. Ein Subagent entwirft die Änderung, während ein komplett separater Agent mit frischem Kontext die strenge Überprüfung übernimmt.

Das klassische Symptom einer fehlerhaften Loop-Architektur ist ein Agent, der exakt denselben Befehl mehrfach hintereinander ohne signifikante Veränderung abfeuert. Ein solches Spinnen auf der Stelle erfordert einen sofortigen Abbruch.

Ein dynamischer Workflow orchestriert 50 Agenten in parallelen Git-Worktrees für ein komplexes Datenbank-Refactoring, bei dem Lösungsansätze kompetitiv gegeneinander antreten. Wer exakt dieselbe Architektur nutzt, um Agenten autonom simple Features erfinden zu lassen, bezahlt den Gegenwert eines Monatsservers für unbrauchbaren Code. Man darf die handwerkliche Aufgabe auslagern, niemals aber das architektonische Urteilsvermögen.

Ein berechtigter Einwand lautet, dass nicht jede Softwareentwicklung in harte Metriken gepresst werden kann. Kreative Exploration und exploratives Coden entziehen sich einer direkten maschinellen Messbarkeit. Doch überall dort, wo klare Anforderungen existieren, ersetzen strukturierte Loops das unsichere Bauchgefühl des Sprachmodells.

3 Schritte zur Umsetzung

1. Externe Prüfinstanzen etablieren: Binde Tools wie Linter oder Performance-Scanner direkt an die Abbruchbedingung deiner Agenten, um Selbstbewertungen der Modelle zu blockieren.
2. Rollen strikt trennen: Nutze für die Code-Generierung und die anschließende Überprüfung immer getrennte KI-Sitzungen mit isoliertem Kontext. Die KI, die den Code schreibt, darf ihn niemals selbst freigeben.
3. Schleifen zeitlich begrenzen: Definiere harte Limits für Iterationen. Ein ausgeführtes Bash-Skript zur Verifikation ist deutlich günstiger als ein Agent, der seinen eigenen Code theoretisch herleitet. Überprüfe die Ausgaben regelmäßig mit dem Befehl /usage.

Wer Agenten ohne präzise Metriken iterieren lässt, automatisiert keine Entwicklung, sondern delegiert die architektonische Kontrolle an einen Zufallsgenerator.