Loop Engineering: Schleifen bauen statt prompten

Peter Steinberger formuliert es sinngemäß so: Man solle Coding-Agents nicht mehr prompten, sondern Schleifen entwerfen, die die Agents prompten. Boris Cherny, Head of Claude Code bei Anthropic, legt nach:

Ich prompte Claude nicht mehr. Ich habe Schleifen laufen, die Claude prompten und entscheiden, was zu tun ist. Mein Job ist, Schleifen zu schreiben.

Das nennt sich Loop Engineering, und es beschreibt eine Verschiebung, die ich ernst nehme und bei der ich skeptisch bleibe. Eine Schleife ist im Kern ein rekursives Ziel: Sie definieren den Zweck, die KI iteriert, bis er erreicht ist. Eines vorweg, die Token-Kosten können wild schwanken. Das muss man im Blick behalten.

Was sich ändert

Zwei Jahre lang lief es so: Sie schreiben einen guten Prompt, geben genug Kontext, lesen die Antwort, schreiben den nächsten Prompt. Sie halten das Werkzeug die ganze Zeit in der Hand, Zug um Zug. Loop Engineering dreht das um. Sie bauen ein kleines System, das die Arbeit findet, sie verteilt, das Ergebnis prüft, festhält, was erledigt ist, und das Nächste entscheidet. Dann stößt dieses System die Agents an, nicht mehr Sie.

Das Überraschende: Es ist kaum noch eine Werkzeugfrage. Vor einem Jahr war so eine Schleife ein Haufen Bash-Skripte, den nur Sie gepflegt haben. Heute stecken die Bausteine in den Produkten, fast deckungsgleich in der Codex-App und in Claude Code. Sobald man sieht, dass die Form dieselbe ist, hört man auf, über das Werkzeug zu streiten, und entwirft die Schleife so, dass sie in beidem läuft.

Die Bausteine

Eine Schleife braucht im Wesentlichen sechs Dinge:

• Automationen, die nach Zeitplan laufen und selbst Arbeit finden und sortieren. Das ist der Takt. Ohne sie ist es ein einmaliger Lauf, keine Schleife.
• Worktrees, damit zwei Agents parallel arbeiten, ohne sich in dieselben Dateien zu schreiben.
• Skills, die das Projektwissen festhalten, das der Agent sonst jedes Mal neu errät.
• Connectors über MCP, damit die Schleife Ihre echten Werkzeuge erreicht: Issue-Tracker, Datenbank, Slack.
• Sub-Agents, getrennt in einen, der baut, und einen, der prüft. Das Modell, das den Code schreibt, benotet die eigene Arbeit zu nett.
• Ein Speicher außerhalb des Gesprächs: eine Markdown-Datei, ein Linear-Board. Klingt zu simpel, ist aber der Kern. Das Modell vergisst zwischen den Läufen alles, also muss der Zustand auf der Platte liegen, nicht im Kontext. Der Agent vergisst, das Repo nicht.

Dazu zwei Kommandos, die den Punkt treffen: /loop läuft im Takt wieder an, /goal läuft, bis eine prüfbare Bedingung wirklich erfüllt ist, und nach jeder Runde prüft ein separates Modell, ob fertig wirklich fertig ist. Der, der schreibt, ist nicht der, der benotet.

Was die Schleife nicht für Sie erledigt

Hier wird es interessant, denn drei Probleme werden schärfer, nicht leichter, je besser die Schleife läuft.

Die Prüfung bleibt bei Ihnen. Eine Schleife, die unbeaufsichtigt läuft, ist auch eine Schleife, die unbeaufsichtigt Fehler macht. Genau deshalb trennt man den Prüfer vom Macher. Und selbst dann ist „fertig“ eine Behauptung, kein Beweis.

Ihr Verständnis erodiert, wenn Sie es zulassen. Je schneller die Schleife Code liefert, den Sie nicht geschrieben haben, desto größer die Lücke zwischen dem, was existiert, und dem, was Sie wirklich durchdrungen haben. Eine glatte Schleife vergrößert die Lücke schneller, außer Sie lesen, was sie gebaut hat.

Und die bequeme Haltung ist die gefährliche. Wenn die Schleife sich selbst dreht, ist es verlockend, keine Meinung mehr zu haben und einfach zu nehmen, was zurückkommt. Die Schleife zu entwerfen ist die Lösung, wenn Sie es mit Urteil tun, und der Brandbeschleuniger, wenn Sie es tun, um nicht mehr nachzudenken. Dieselbe Handlung, das gegenteilige Ergebnis.

Die Schleife bauen, Ingenieur bleiben

Ich halte das für einen Vorgeschmack darauf, wie sich unsere Arbeit verschiebt. Aber: Würde ich den Code nicht selbst prüfen und mich ganz auf automatische Schleifen verlassen, würde die Qualität meiner Produkte leiden, und ich würde mich Stück für Stück tiefer eingraben.

Bauen Sie also ruhig Ihre Schleifen, aber vergessen Sie nicht, dass direktes Prompten weiter funktioniert. Es geht um die Balance.

Zwei Leute bauen dieselbe Schleife und bekommen gegenteilige Ergebnisse. Der eine wird schneller bei Arbeit, die er versteht. Der andere vermeidet, die Arbeit überhaupt zu verstehen. Die Schleife kennt den Unterschied nicht. Sie schon.

Das macht Loop-Design schwerer als Prompt-Engineering, nicht leichter. Chernys Punkt ist nicht, dass die Arbeit leichter wird. Der Hebelpunkt hat sich verschoben. Bauen Sie die Schleife. Aber bauen Sie sie wie jemand, der Ingenieur bleiben will, nicht nur der, der auf Start drückt.