Loop Engineering – Addy Osmani

Der nächste Schritt für AI-Coding-Agenten: „Loop Engineering“

Dieser Text behandelt ausgehend von Addy Osmanis „Loop engineering“ die Sichtweise, dass sich Coding-Agenten von einem Modell lösen könnten, bei dem Menschen jedes Mal direkt Anweisungen geben, hin zu einem Ansatz, bei dem wiederholbare Systeme entworfen werden, in denen Agenten selbst Arbeit finden, aufteilen, verifizieren und den nächsten Schritt festlegen. Der Begriff Loop meint hier eher einen „Arbeitsablauf, den die AI mehrfach in Richtung eines festgelegten Ziels ausführt“. Der Text betrachtet das jedoch nicht als Allheilmittel. Er betont zugleich reale Kosten wie Token-Kosten, die Verantwortung für Verifikation und einen möglichen Rückgang des Verständnisses bei Entwicklerinnen und Entwicklern.

Kernzusammenfassung

Bedeutung von Loop Engineering

Bisher schrieben Entwicklerinnen und Entwickler Prompts für Coding-Agenten, lasen die Ergebnisse und gaben erneut Anweisungen. Das im Text beschriebene Loop Engineering ist ein Ansatz, diesen Prozess in eine automatisierte Struktur zu überführen. Anstatt also jedes Mal manuell Anweisungen zu geben, wird als System entworfen, „wonach gesucht wird, wie es verarbeitet wird und wann gestoppt wird“.

Bestandteile

Der Autor nennt als Bausteine für Loops automatische Ausführung, Worktrees, Skills, Plugins und Konnektoren, Subagenten sowie externen Speicher. Worktrees sind eine Git-Funktion, die dasselbe Repository in mehrere Arbeitsbereiche aufteilt, um Konflikte zu reduzieren. Skills dienen dazu, Projektregeln und Wissen zu dokumentieren, damit der Agent nicht jedes Mal neu raten muss. Konnektoren sind die Verbindung zu externen Tools wie Linear, Slack oder Datenbanken.

Vorteile

Bei der Reduzierung wiederkehrender Arbeit lassen sich Aufgaben wie die Zusammenfassung von CI-Fehlschlägen, die Klassifizierung von Issues oder die Prüfung jüngster Commits automatisieren. Im Hinblick auf Parallelisierung können mehrere Agenten jeweils in unterschiedlichen Worktrees arbeiten und so Dateikonflikte verringern. Für die Wiederverwendung von Wissen können Projektkonventionen und Build-Abläufe als Skills erhalten bleiben, sodass dieselben Erklärungen nicht in jeder Sitzung erneut gegeben werden müssen.

Nachteile und Risiken

Der Verifikationsaufwand verschwindet nicht. Ergebnisse, die ein Loop erzeugt, müssen weiterhin von Menschen geprüft werden. Auch die Token-Kosten können steigen. Wenn die Zahl der Subagenten zunimmt, verwendet jeder Agent separat Modelle und Tools. Problematisch ist auch eine Verständnisschuld. Wenn Entwicklerinnen und Entwickler Ergebnisse übernehmen, ohne sie zu lesen, kann die Codebasis zwar wachsen, aber der Bereich, den Menschen tatsächlich verstehen, kleiner werden.

Unterscheidungsmerkmal

Während klassisches Prompt Engineering auf „eine gute einzelne Frage“ fokussiert ist, liegt Loop Engineering näher am Entwurf eines „wiederholbaren Arbeitssystems“. Der Autor sieht, dass Codex und Claude Code mit Automatisierung, Skills, MCP-basierten Verbindungen und Subagenten ähnliche Bausteine bereitstellen und dass dadurch die Gestaltung des Loops wichtiger wird als das Tool selbst.

Besondere Merkmale

Ein wichtiges Merkmal ist die Trennung von Autor und Prüfer. Wenn der Agent, der den Code erstellt hat, das Ergebnis selbst bewertet, kann er zu nachsichtig sein; deshalb wird eine Struktur mit einem separaten prüfenden Subagenten vorgeschlagen. Ebenfalls zentral ist die Pflege externen Speichers. Zustände müssen außerhalb der Unterhaltung erhalten bleiben, etwa in Markdown-Dateien oder Issue-Boards, damit sie bei der nächsten Ausführung wieder aufgenommen werden können.

Loop Engineering liest sich weniger als Erzählung über den Ersatz von Entwicklerinnen und Entwicklern, sondern eher als Verschiebung der Eingriffspunkte. Das Gewicht verlagert sich weg vom ständigen direkten Schreiben von Prompts hin zum Entwurf von Wiederholungsstrukturen, Prüfbedingungen, Aufgabenverteilung und Dokumentationsformen. Gute Loops ersetzen jedoch kein gutes Urteilsvermögen. Ohne die Engineering-Fähigkeit, Code zu lesen, zu verifizieren und die Grenzen des Systems zu verstehen, kann Automatisierung eher Risiken als Geschwindigkeit vergrößern.