Zum Inhalt springen

Wissensbasis

Disciplined Compounding Loop

Wie ihr jede Agentenaufgabe als Plan, testgetriebenen Build, Prüfung und Retrospektive fahrt und warum unstrukturierte Generierung Delivery-Stabilität kostet.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Geht ein Lauf schief, korrigieren wir nicht sein Ergebnis. Wir ändern den Skill oder die Regel, nach der der Agent gehandelt hat, damit der nächste Lauf den Fehler nicht wiederholt. A harness does not remember what you tell it (öffnet in einem neuen Tab): Jede Korrektur muss zu einer Regel, einem Skill oder einem Hook werden.

Der größte Hebel liegt vor dem Build. Ein Plan, den ein zweiter Durchgang angegriffen hat und der in testbare Features geschnitten ist, hält den Agenten im Scope. Jede Phase bekommt ein kleines Budget an Instruktionen.

Wie macht ein strukturierter Zyklus jede Änderung billiger?

Rohe Generierung ist noch keine Auslieferung. Laut Googles DORA-Report 2024 ging jede Steigerung der KI-Nutzung um 25 % mit 7,2 % weniger Delivery-Stabilität einher. GitClear analysierte 211 Millionen Zeilen und fand zehnmal so viele duplizierte Codeblöcke wie zuvor. Erstmals übertraf kopierter Code den verschobenen Code. Der Output stieg, während das System schwerer wartbar wurde (A Plan-Do-Check-Act Framework for AI Code Generation (öffnet in einem neuen Tab), 20. Oktober 2025).

Die Antwort darauf ist, den Agenten in einen strukturierten Zyklus zu packen. Der PDCA-Loop des Artikels umfasst Working Agreements, eine projektweite Analyse, eine atomare testgetriebene Umsetzung, einen Abschlusscheck und eine Mikro-Retrospektive. Er ist auf Aufgaben von einer bis drei Stunden zugeschnitten und erzeugt Artefakte zum Nachverfolgen. Im direkten Vergleich verbrauchte der unstrukturierte Lauf 80 % seiner Tokens erst, nachdem der Agent die Aufgabe für erledigt erklärt hatte, und zwar für Troubleshooting. PDCA lieferte dagegen weniger Produktionszeilen mit mehr Tests und erkannte Fehler früher. Unabhängig davon hat PDCA in einer kontrollierten Studie die Defekte um 61 % gesenkt (A Plan-Do-Check-Act Framework for AI Code Generation (öffnet in einem neuen Tab), 20. Oktober 2025).

Die Strenge des Prozesses sollte mit der Kritikalität der Aufgabe wachsen, statt überall gleich zu gelten. Das erinnert an die Crystal-Familie agiler Methoden. Die Variante PDCVR erweitert dasselbe Gerüst um einen ausdrücklichen Vollständigkeitscheck, denn sonst hört ein Modell auf, bevor der Plan fertig ist. Dazu kommt ein delegierter Verifikationsagent (Plan-Do-Check-Verify-Retrospect (öffnet in einem neuen Tab), 3. Januar 2026).

Eine ergänzende Sicht fasst die ganze Praxis als Spektrum von Feedback-Loops auf, die man je nach Aufgabe enger oder lockerer zieht. Dabei besteht sie darauf, dass die Loops auch geschlossen werden. Das Elastic-Loop-Framework ordnet die Optionen von eng nach locker: Autocomplete, eine Kette kleiner überwachter Schritte, Rapid Prototyping, Best-of-n, aufgeschobenes asynchrones Prototyping und Ambient Agents. Best-of-n heißt, ein Feature auf fünf bis zehn Arten umzusetzen und die beste Variante zu wählen. Ambient Agents beobachten Domain Events wie ein neues Issue oder einen Ordner mit Nutzerinterviews und handeln ungefragt. KI ist in diesem Bild ein Rohstoff, den man nach Menge bezahlt, wie Strom. Für den Ertrag muss man aber Leitungen legen, also Kontext und Plattform. Entscheidend ist dabei nicht die Zahl der Merge Requests. Es zählen die nicht geschlossenen Loops: liegengebliebene, nicht gemergte PRs und Sitzungen, die entnervte Nutzer:innen weggeworfen haben.

Der Talk trennt Autonomie von Agency, also der Fähigkeit, Autonomie tatsächlich zu nutzen. Organisationen mit viel Autonomie erleben oft, dass niemand sie ergreift, weil die Leute wenig Agency mitbringen. Expertise wird demokratisiert, Erfahrung dagegen nicht. Zu den Belegen gehört METRs Befund vom Mai 2025: Erfahrene Open-Source-Maintainer:innen erwarteten von KI-Tools 24 Prozent mehr Tempo, arbeiteten aber 19 Prozent langsamer. Dazu kommt eine Studie von Procter & Gamble mit rund 760 Personen. Darin erreichte eine Person mit KI das Niveau eines Zweierteams ohne KI und baute dabei Silos ab. Schließlich nennt der Talk den METR-Trend, nach dem sich die Aufgabenlänge, die ein Frontier-Modell bewältigt, etwa alle sechs bis sieben Monate verdoppelt (INNOQ – Agentic Engineering as Feedback Loops (öffnet in einem neuen Tab), 2. Dezember 2025).

Die Planungshälfte des Zyklus trägt den größten Hebel und hat ihre eigene Disziplin. Der Prompt selbst bestimmt vielleicht 5 % der Qualität. Die übrigen 95 %, also Architektur, Konventionen, Plan und Review-Kriterien, sind ein Problem des Systemdesigns und keines des Prompt Engineering (The Vibes Don’t Scale (öffnet in einem neuen Tab), 13. April 2026). Bevor Code entsteht, sollte ein Plan ein adversariales Review durchlaufen, bei dem ein zweiter Durchgang fehlende Edge Cases und Scope Creep sucht. Das hält auch den Scope im Griff. Ohne Vertrag löst der Agent benachbarte Probleme, über die er stolpert. Jede dieser Lösungen ist für sich vertretbar, zusammen sind sie verheerend (The Vibes Don’t Scale (öffnet in einem neuen Tab), 13. April 2026). Pläne sollten vertikal geschnitten werden, also ein testbares Feature von Ende zu Ende. Ein horizontaler Schnitt (erst die ganze Datenbank, dann alle Services) hinterlässt Tausende ungetesteter Zeilen und keinen Checkpoint (RPI to CRISPY (öffnet in einem neuen Tab), 24. März 2026).

Außerdem ist das Budget für Instruktionen endlich. Laut dem Talk befolgen Frontier-Modelle zuverlässig etwa 150 bis 200 Instruktionen. Ein einzelner Mega-Prompt mit CLAUDE.md, Tool-Dokumentation und MCP-Definitionen wird deshalb nicht vollständig befolgt. Teilt ihn in kleine Phasen mit jeweils unter vierzig Instruktionen. Steuert den Ablauf mit Kontrollfluss, etwa mit einem Classifier, der an fokussierte Prompts weiterleitet, statt mit einem einzigen verzweigten Prompt (RPI to CRISPY (öffnet in einem neuen Tab), 24. März 2026).

Ein echter Zyklus zahlt sich aus, weil sich sein Ertrag aufsummiert: Jedes Feature sollte das nächste billiger machen. Etwa 80 % der Arbeit sind Planung und Review, 20 % der Build. Die Disziplin, die sich aufsummiert, hält jede Lektion fest, etwa einen Verstoß gegen eine Konvention, einen Irrweg oder eine Entscheidung, die der Code nicht klären kann. Daraus wird eine dauerhafte Regel oder ein Prompt im Repository, der den nächsten Lauf und die nächste Neueinstellung ausstattet (Compound Engineering (öffnet in einem neuen Tab), 11. Dezember 2025).

Ehrlich bleibt das, wenn ihr unterscheidet, was ihr aufschreibt. Diese Unterscheidung stammt aus 240 aufgezeichneten Planungsversuchen. Wissen, das das Modell aus sauberem Code ableiten kann (Dateiorte, vorherrschende Muster), gehört in den Code. Eine Karte davon spart nur 10 bis 20 % der Erkundung. Eine Entscheidung, die der Code nicht zeigen kann, muss in die Anleitung für den Agenten. Das betrifft etwa die Frage, welches von zwei lebenden Mustern kanonisch ist, eine laufende Migration oder ein aufgegebenes Experiment. Dort kippte eine einzige Zeile die Wahl des Agenten jedes Mal, gegen eine Mehrheit von vierzehn zu zwei. Wirklich offene Entscheidungen gehören in keins von beiden. Sie sollten im Plan auftauchen, damit ein Mensch sie klärt (AGENTS.md: Write Down What the Code Can’t Say (öffnet in einem neuen Tab), 11. Juli 2026). Prüft, was der Code beweisen kann. Schreibt auf, was er nicht beweisen kann. Fragt nach, was noch offen ist.

Das Team von Every hat den Loop später als Tool ausgeliefert statt als Absicht. Die ausgelieferte Form ergänzt zwei Dinge, die im Essay fehlen. Sechs benannte Schritte laufen nacheinander: Anforderungen brainstormen, die Umsetzung planen, den Plan abarbeiten, das Geschriebene vereinfachen, das Ergebnis reviewen und das Gelernte festhalten. Der Simplify-Schritt sitzt bewusst zwischen Schreiben und Review. So richtet der Reviewer seine Aufmerksamkeit auf einen gestrafften Diff statt auf das Rauschen eines ersten Entwurfs. Und der Rückweg ist ein Vertrag über Artefakte statt einer Gewohnheit. Der Compound-Schritt schreibt jede Erkenntnis in einen eingecheckten Ordner. Das nächste Brainstorming und der nächste Plan lesen ihn als Grundlage zurück, zusammen mit einem dauerhaften Strategiedokument und den früheren Plänen. Der nächste Lauf lädt also die Lektion, statt dass sich jemand an sie erinnern muss. Rund um den Loop liegen Skills für Eingaben, die nicht in ihn passen. Ideation hilft, wenn es noch kein Feature zum Planen gibt. Ein Debug-Pfad ersetzt Brainstorm, Plan und Work, wenn die Eingabe ein kaputtes Verhalten ist und kein gewünschtes. Ein Nutzungsbericht je Zeitfenster speist beobachtetes Produktionsverhalten in die nächste Ideenrunde zurück (EveryInc - Compound Engineering plugin (öffnet in einem neuen Tab)).

Eine Formalisierung auf Forschungsniveau setzt auf dieselbe Wette, die Vorbereitung zuerst. Sie benennt drei Phasen, die abgeschlossen sind, bevor ein Agent Code schreibt. Kontextuelle Verankerung lagert Domänenexpertise und implizites Wissen in Briefing-Dokumente in Markdown aus. Gemeinsame Spezifikation ist ein Dialog zwischen Mensch und Agent, der Werturteile als Constraints festhält, auch das, was wegbleiben soll. Aufgabenzerlegung macht aus der Spec Task-Records, die ihre Abhängigkeiten kennen, sodass mehrere Agenten ohne Koordinationsaufwand parallel laufen. In einem kompetitiven Hackathon dauerte die Vorbereitung etwa zwei Stunden, die aktive Umsetzung rund einundzwanzig Minuten pro Agent. Das ergibt ein Verhältnis von Vorbereitung zu Ausführung von 5,7:1. Heraus kam eine Full-Stack-Anwendung mit 8.496 Zeilen, fast ohne Nacharbeit an der Architektur. Die aufgetretenen Bugs betrafen Integration und Styling, nicht Fehlausrichtung (Mise en Place for Agentic Coding (öffnet in einem neuen Tab), 6. Mai 2026).

Das Paper nennt die zugrunde liegende Fähigkeit Context Fluency: reichhaltigen, strukturierten Kontext zu erzeugen, mit dem Agenten arbeiten können. Es verortet sie vor dem Prompting. Dazu gehören Zerlegung, neben dem Was auch das Warum zu spezifizieren, Constraints zu definieren und implizites Domänenwissen zu kodieren, das der Agent nicht selbst erzeugen kann. Den Vorbehalt des Einzelfalls nennt das Paper ausdrücklich: ein Hackathon, ein:e Praktiker:in, keine Kontrollgruppe. Die Verhältnisse sind also Beobachtungen, keine gemessenen Effekte gegenüber einer Baseline.

Verwandte Seiten

Quellen

Artikel

Papers und Berichte

Posts

Talks und Videos

Tools und Repositories