Loop Engineering: Warum der Entwickler von Claude Code keine Prompts mehr schreibt

Ich gebe Claude keine Prompts mehr. Ich habe Loops am Laufen, die Claude prompten und herausfinden, was zu tun ist. Meine Aufgabe ist es, Loops zu schreiben.

– Boris Cherny, Entwickler und Leiter von Claude Code bei Anthropic.

Etwa zwei Jahre lang war Prompt Engineering die Fähigkeit, die alle verfolgten. Einen guten Prompt schreiben, genügend Kontext bereitstellen, die Ausgabe lesen, den nächsten Prompt schreiben. Du hast den Agenten wie ein Werkzeug benutzt, einen Schritt nach dem anderen.

Diese Ära geht leise zu Ende.

Mitte 2026 kamen innerhalb weniger Tage drei Stimmen auf dieselbe Idee. Boris Cherny (Claude Code) sagte, seine Aufgabe sei es jetzt, Loops zu schreiben. Peter Steinberger (Entwickler von OpenClaw) sagte Millionen von Entwicklern: "Du solltest Coding-Agenten keine Prompts mehr geben. Du solltest Loops entwerfen, die deine Agenten prompten." Und Addy Osmani (Google) gab dem Muster in einem viel geteilten Beitrag seinen Namen: Loop Engineering. Dieser Artikel erklärt, was Loop Engineering eigentlich ist, welche Probleme es löst, wie es sie löst, eine funktionierende Code-Demo, die du heute ausführen kannst, und die ehrlichen Kompromisse, die niemand in die Hype-Threads schreibt.

Was ist Loop Engineering?

Loop Engineering bedeutet, sich selbst als die Person zu ersetzen, die den Agenten promptet. Du entwirfst ein System, das das Prompting übernimmt.

Ein Loop ist ein rekursives Ziel: Du definierst einen Zweck und eine überprüfbare Abbruchbedingung, und die KI iteriert, entdeckt Arbeit, implementiert sie, verifiziert sie, zeichnet Fortschritte auf – bis die Bedingung erfüllt ist. Du bist nicht mehr im Loop. Du bist darüber.

Stell dir die Hierarchie so vor:

1. Prompt Engineering: Du schreibst eine gute Anweisung.
2. Context Engineering: Du stellst die richtigen Informationen um die Anweisung herum zusammen.
3. Agent-Harness-Engineering: Du baust die Umgebung, in der ein Agent läuft.
4. Loop Engineering: Du baust das System, das den Harness auf einem Timer ausführt, Helfer spawnen lässt, die Arbeit überprüft und den Zustand aufzeichnet.

Der alte Workflow: Prompt schreiben → Ausgabe lesen → nächsten Prompt schreiben (du bist der Loop).

Der neue Workflow: Loop einmal entwerfen → Loop entdeckt Arbeit → Loop weist Agenten zu → Loop verifiziert → Loop zeichnet Zustand auf → wiederholen (du überprüfst und steuerst).

Die Probleme, die Loop Engineering löst

Problem 1: Du bist der Engpass

Beim manuellen Prompting passiert nichts, solange du nicht tippst. Jeder Schritt wartet auf einen Menschen. Agenten im Jahr 2026 können stundenlang autonom laufen – Claude-Opus-Klasse-Modelle liefen bei schwierigen Aufgaben fast fünf Stunden unbeaufsichtigt – aber ein menschlich gesteuerter Chat begrenzt sie auf deine Tippgeschwindigkeit und Aufmerksamkeitsspanne. Der Agent ist 95 % der Zeit untätig und wartet auf dich.

Problem 2: Agenten vergessen alles zwischen den Sitzungen

Jede Sitzung beginnt kalt. Das Modell leitet die Konventionen, Build-Schritte und mühsam erlernten Lektionen deines Projekts von Null ab – oder schlimmer noch, es füllt die Lücken mit selbstbewussten Vermutungen. Das nennt Osmani Intent Debt: nicht ausgesprochene Absicht, die bei jedem Durchlauf neu bezahlt (oder erraten) wird.

Problem 3: Der Agent benotet seine eigenen Hausaufgaben

Ein Agent, der den Code geschrieben hat, ist bei der Überprüfung viel zu großzügig. "Es ist fertig" ist eine Behauptung, kein Beweis. Ohne unabhängige Verifikation häufen autonome Läufe Fehler an, anstatt sie zu beheben.

Problem 4: Parallele Agenten kollidieren

Sobald du mehr als einen Agenten in einem Repository ausführst, überschreiben sie gegenseitig ihre Dateien – dieselbe Katastrophe wie zwei Entwickler, die ohne Absprache in dieselben Zeilen committen.

Problem 5: Wiederkehrende Arbeit wird nie automatisiert

CI-Fehleranalyse, Abhängigkeitsupdates, Suche nach flaky Tests, Issue-Labeling, tägliche Bug-Durchläufe – diese Arbeit ist langweilig, endlos und perfekt für Agenten geeignet. Aber niemand promptet einen Agenten jeden Morgen dafür, weil du jeden Morgen da sein müsstest, um das Prompting zu erledigen.

Wie Loop Engineering sie löst: Die sechs Bausteine

Ein Loop, der tatsächlich unbeaufsichtigt läuft, ist kein langer Prompt. Es ist ein kleines System mit fünf Fähigkeiten plus einem Gedächtnis. Bemerkenswerterweise liefern sowohl Claude Code als auch OpenAIs Codex jetzt alle sechs nativ – die Loop-Form ist tool-agnostisch geworden.

1. Automatisierungen: Der Herzschlag

Geplante Ausführungen, die selbstständig Entdeckungen und Triage durchführen. Das löst Problem 5.

• Claude Code: /loop führt einen Prompt in einem Rhythmus erneut aus (von Ein-Minuten-Intervallen bis zu mehrtägigen Fenstern), Cron-geplante Tasks, Routinen für cloud-geplante Automatisierungen, Lifecycle-Hooks oder GitHub Actions für Läufe, die das Schließen deines Laptops überleben.
• Codex: Der Reiter Automatisierungen – wähle ein Projekt, einen Prompt, einen Rhythmus; Ergebnisse landen in einem Triage-Posteingang, leere Läufe archivieren sich selbst.

Das entscheidende In-Session-Primitiv ist /goal: arbeite über mehrere Schritte hinweg weiter, bis eine von dir geschriebene Bedingung überprüfbar wahr ist – "alle Tests in test/auth bestehen und Lint ist sauber" – und geh weg.

1. Worktrees: Isolation für Parallelität

Git-Worktrees geben jedem Agenten sein eigenes Arbeitsverzeichnis in einem eigenen Branch, wobei die Repository-Historie geteilt wird. Bearbeitungen können buchstäblich nicht kollidieren. Das löst Problem 4.

• Claude Code: git worktree, das Flag --worktree oder isolation: worktree auf einem Subagenten, sodass jeder Helfer einen frischen, sich selbst bereinigenden Checkout erhält.
• Codex: integrierter Worktree pro Thread.

Power-User berichten, dass sie auf diese Weise 10–15 parallele Agenten ausführen.

1. Skills: Kodifiziertes Projektwissen

Ein Skill ist ein Ordner mit einer SKILL.md – deine Konventionen, Build-Schritte und "das machen wir nicht so, wegen dieses einen Vorfalls" einmal geschrieben, vom Agenten bei jedem Durchlauf gelesen. Das löst Problem 2. Ohne Skills leitet der Loop dein Projekt bei jedem Zyklus von Null ab. Mit ihnen baut er darauf auf.

1. Plugins & Connectors (MCP): Zugriff auf echte Werkzeuge

Ein Loop, der nur das Dateisystem sieht, ist ein kleiner Loop. MCP-Connectors lassen ihn dein Issue-Tracker lesen, eine Datenbank abfragen, den PR öffnen, das Linear-Ticket aktualisieren und Slack benachrichtigen, wenn CI grün wird. Das ist der Unterschied zwischen einem Agenten, der sagt "hier ist der Fix", und einem Loop, der den Fix ausliefert.

1. Sub-Agenten: Trenne den Macher vom Prüfer

Die wichtigste strukturelle Idee im gesamten Muster. Ein Agent (oder Modell) schreibt; ein anderer Agent mit anderen Anweisungen verifiziert. Das löst Problem 3. Claude Codes /goal integriert dies: Ein separates Modell bewertet, ob die Abbruchbedingung erfüllt ist, sodass der Arbeiter nie seine eigenen Hausaufgaben benotet.

• Claude Code: Subagenten in .claude/agents/, Agententeams.
• Codex: Subagenten als TOML in .codex/agents/ – z. B. ein starkes Modell mit hohem Reasoning-Aufwand als dein Sicherheitsprüfer, ein schnelles, schreibgeschütztes Modell als dein Explorer.

1. Zustand: Das Gedächtnis-Rückgrat

Eine Markdown-Datei, ein Fortschrittsprotokoll oder ein Linear-Board – alles, was außerhalb des Gesprächs lebt und aufzeichnet, was erledigt ist und was als nächstes ansteht. Klingt zu dumm, um wichtig zu sein. Es ist der einzige Trick, auf den jeder langlaufende Agent angewiesen ist: Das Modell vergisst zwischen den Läufen; das Repository nicht. Das löst Problem 2 auch auf Aufgabenebene und ermöglicht es dem morgigen Lauf, genau dort weiterzumachen, wo der heutige aufgehört hat. Zusammen mit Automatisierungen löst es Problem 1 auf – der Loop arbeitet, während du schläfst.

Wie ein echter Loop aussieht

Hier ist die Referenzform (angepasst von Osmanis eigenem täglichen Loop):

1. Eine Automatisierung wird im Repository ausgelöst. Ihr Prompt ruft einen Triage-Skill auf, der die CI-Fehler von gestern, offene Issues und aktuelle Commits liest und die Ergebnisse in STATE.md schreibt.
2. Für jeden lohnenswerten Fund öffnet der Loop einen isolierten Worktree und weist einen Macher-Sub-Agenten an, den Fix zu entwerfen.
3. Ein Prüfer-Sub-Agent überprüft den Entwurf anhand der Projekt-Skills und vorhandenen Tests.
4. Connectors öffnen den PR, verknüpfen das Ticket und posten in Slack.
5. Alles, was der Loop nicht bewältigen kann, landet in einem Triage-Posteingang – für dich.
6. STATE.md zeichnet auf, was versucht wurde, was bestanden hat und was noch offen ist. Der morgige Lauf setzt dort fort.

Quellen & weiterführende Literatur: Addy Osmani, "Loop Engineering" (addyosmani.com); The New Stacks Berichterstattung über Loop Engineering; Boris Chernys Fireside-Chat auf Metas Scale-Konferenz und CNBC-Interview; Claude Code-Dokumentation zu Routinen (code.claude.com/docs/en/routines); OpenAI Codex Automations-Dokumentation.

Wenn du aus diesem Artikel einen Loop baust, würde ich ihn gerne sehen! Antworte mit dem, was du zuerst automatisiert hast.