Wie man Fable nutzt, um ein Großprojekt mit 40 Sub-Agents zu orchestrieren

Letzte Woche haben wir bei @HelloUntangle das größte und riskanteste Engineering-Programm unserer Geschichte abgeschlossen.

• 834 Dateien
• Mutation von Produktionsdaten
• DB-Schema-Update
• 31 PRs
• Gestartet am Freitag → abgeschlossen am Montag
• Null Produktionsvorfälle

Alles mit einer einzigen Fable-Parent-Orchestrator-Sitzung.

Eine einzige @DevinAI Parent-Sitzung plante die Arbeit, startete vierzig Child-Sitzungen zur Ausführung, setzte zwischen den Phasen Regression-Gates und Backup-Prüfungen durch und zeigte mir nur die Entscheidungen an, die tatsächlich einen Verantwortlichen erforderten: Scope-Entscheidungen und Go/No-Go bei irreversiblen Schritten.

Was dies ermöglichte, ist eine Reihe von Programm-Management-Mustern, die jede große Migration verbessern würden.

So haben wir es gemacht ...

Die Architektur: Ein Orchestrator, viele Worker

• Eine Parent-Sitzung hatte das gesamte Programm von Anfang bis Ende unter Kontrolle. Ihre einzige Aufgabe war es, zu planen, Child-Sitzungen zu starten, deren Ergebnisse zu überprüfen, die Phasen zu sequenzieren und mich zu eskalieren, wenn eine Entscheidung einen Menschen benötigte. Sie hat null Code geschrieben.
• ~40 Child-Sitzungen erledigten die gesamte tatsächliche Arbeit: elf parallele Audit-Sitzungen in Phase 0, Ausführungssitzungen für jede Welle und dedizierte Gate-Runner-Sitzungen, deren einzige Aufgabe es war, Regression-Suiten auszuführen.

Die Aufteilung ist wichtig, weil die Fehlerart von langlaufenden Projekten – ob KI oder Mensch – der Kontextkollaps ist: Die ausführende Instanz verliert allmählich den Überblick über das Gesamtprogramm.

Wenn der Parent ein reiner Orchestrator bleibt, bleibt sein Kontext sauber; er hält den Plan, die Scope-Entscheidungen und den Status jeder Welle. Jedes Child erhält einen frischen, fokussierten Kontext mit genau einer Aufgabe.

Die sieben Muster, die es zum Funktionieren brachten

1. Zuerst auditieren und die Ergebnisse in einem einzigen Manifest einfrieren

Phase 0 bestand aus elf parallelen Audit-Sitzungen, die jeweils einen Teil des Codebestands abdeckten: App-Routen, API-Routen und Cronjobs, das Datenbankschema, gemeinsame Bibliotheken und Workflows, Skripte und Dokumentation. Ihre Ergebnisse wurden in einer Datei zusammengeführt und in das Repository eingespielt.

Das Manifest weist jeder Code-Einheit ein Urteil und eine Wellennummer zu. Zwei Regeln machten es wirkungsvoll:

• Kein Worker stellt den Scope erneut in Frage. Jeder Ausführungs-Prompt sagte im Wesentlichen: Das Manifest ist die Quelle der Wahrheit. Ohne dies würde jede der vierzig Sitzungen ihre eigene Meinung darüber ableiten, was im Scope ist – und sie würden sich widersprechen.
• UNKNOWN bedeutet anhalten und nachfragen. Alles, worüber die Audits keine Aussage trafen, wurde explizit als unbekannt markiert, mit der Anweisung: nicht raten; eine Entscheidung einholen. Entscheidungen des Verantwortlichen wurden direkt im Manifest festgehalten, sodass spätere Sitzungen sie übernahmen.

2. Die Arbeit nach Risiko ordnen, nicht nach Bequemlichkeit

Die Wellen wurden vom sichersten bis zum irreversibelsten sequenziert.

Welle

Was

Risiko

0

Audit + Manifest + Restore-Point-Git-Tag

keines

1

Änderungen, die nachweislich keine Live-Abhängigkeiten haben

nahezu null

2

Entflechtungs-Operationen an gemeinsamer Infrastruktur

mittel

3–4

Der Großteil der Codeänderungen

mittel

5

Änderungen an Produktionsdaten (mit Trockenlauf-Inventar + Snapshot)

hoch

6

Schema-Migrationen

hoch

7

Abhängigkeitsbereinigung, Neuschreiben von agents.md, Audit der Agenten-Wissensdatenbank

niedrig

Änderungen an Produktionsdaten (Welle 5) kommen vor Schemaänderungen (Welle 6), und beide kommen erst, nachdem jeder Codepfad, der die betroffenen Tabellen berührte, nachweislich aktualisiert wurde. Als die Migrationen liefen, konnte nichts mehr vom alten Zustand abhängen.

3. Datei-disjunkte Grenzen machen Parallelität sicher

Innerhalb einer Welle liefen Child-Sitzungen parallel – eine Welle hatte vier Sitzungen, die gleichzeitig an verschiedenen Teilen des Baums arbeiteten. Die Disziplin: Jeder Prompt enthielt eine explizite Dateigrenze, und die Grenzen waren disjunkt. Keine Merge-Konflikte, keine zwei Agenten, die dieselbe Datei bearbeiten, keine Koordination zwischen den Kindern erforderlich.

Dies ist klassische Aufgabenzerlegung – dasselbe, was man tun würde, wenn man Arbeit auf Ingenieure verteilt – aber Agenten müssen es explizit im Prompt haben, jedes Mal.

4. Sicherheits-Gates zwischen den Wellen

Keine Welle begann, bevor die vorherige ein Gate bestanden hatte. Die Gates waren selbst Child-Sitzungen:

• Eine browserbasierte, End-to-End-Regression-Suite, die den zentralen Kunden-Workflow der Plattform abdeckte, lief nach Welle 2 und erneut nach den Wellen 3–4 auf einem frischen, isolierten Datenbank-Zweig.
• Vor Änderungen an Produktionsdaten: Eine dedizierte Sitzung auditierte unser Backup-Inventar der Datenbank (Anzahl, Datumsbereich, Aufbewahrung), und wir erstellten einen frischen Point-in-Time-Snapshot.
• Der Produktionsschritt selbst lief zuerst als Trockenlauf, erstellte Zeilenanzahlen zur Genehmigung durch den Verantwortlichen und überprüfte die Anzahlen nach der Ausführung erneut.
• Ein Git-Tag markiert den Restore-Point für jede geänderte Zeile.

Wenn ein Gate fehlschlug, erzeugte es eine eingegrenzte Fix-Sitzung. Die Regression-Suite fing beispielsweise einen kundenorientierten Ablauf, der durch eine übereifrige Änderung unterbrochen worden war; eine Fix-Sitzung stellte ihn innerhalb von Stunden wieder her. Das ist das System in Aktion – das Gate verwandelte das, was ein kundengemeldeter Fehler gewesen wäre, in eine Behebung am selben Tag.

5. Menschen genehmigen; Agenten schlagen vor

Ich habe in diesem Projekt nie Code geschrieben, eine Migration durchgeführt oder ein Produktionsskript ausgeführt. Aber jeder irreversible Schritt erforderte mein explizites Go: jeder Merge auf main, die Änderungen an Produktionsdaten, die Schema-Migrationen und jede Entscheidung zu UNKNOWN-Scope-Elementen.

Das Muster für destruktive Arbeit: Der Agent schlägt ein Inventar vor, der Mensch genehmigt das Inventar, dann führt der Agent genau dieses Inventar aus. Die Produktionssitzung erstellte die genaue Liste der Zeilen, die sie berühren würde, bevor sie etwas berührte. Ich genehmigte eine spezifische Liste, keine vage Absicht.

6. Ein Eskalationsprotokoll für Überraschungen

Kindern wurde gesagt, was zu tun ist, wenn die Realität nicht mit dem Manifest übereinstimmte: anhalten, dem Parent melden, nicht improvisieren. Reale Beispiele:

• Ein Modul, das das Audit als sicher bezeichnete, stellte sich als mit einer Live-Abhängigkeit an anderer Stelle heraus → das Child meldete dies, und die Einheit wurde unter Notiz der Verflechtung in eine spätere Welle verschoben.
• Eine zweite Audit-Runde kehrte die Urteile der ersten Runde für fünf ganze Bereiche um → die Umkehrungen wurden als explizite Überschreibungen im Manifest festgehalten, anstatt ad hoc von der Sitzung gelöst zu werden, die darauf stieß.

Der Parent absorbierte diese Überraschungen in den Plan. Einzelne Worker trafen nie Scope-Entscheidungen.

7. Den Lagerplatz sauberer hinterlassen: Dem System beibringen, was sich geändert hat

Welle 7 ist vielleicht die am meisten unterschätzte Phase. Nachdem die Änderung ausgeliefert war, schrieben Sitzungen unsere AGENTS.md, Repository-Fähigkeiten und die Agenten-Wissensdatenbank neu, um die neue Architektur zu beschreiben – sodass jede zukünftige Agentensitzung von der Wahrheit ausgeht, nicht von veralteten Anweisungen. Wenn Ihr Engineering agentengesteuert ist, ist Ihre Dokumentation tragende Infrastruktur.

Was es gekostet hat

Jede Sitzung im Programm wurde getaggt, sodass das Konto vollständig ist: ein Parent und neununddreißig Kinder, alle auf Devins Ultra Agent, von Freitagnachmittag bis Montagmorgen. Dies sind die tatsächlichen gemessenen Kosten aus unserem Nutzungs-Dashboard.

Phase

Sitzungen

Kosten

Parent-Orchestrator (mehrtägig)

1

115,26 $

Phase 0 Audits (zwei Runden) + Manifest-Synthese

12

85,56 $

Welle 1

4

37,55 $

Welle 2 (Entflechtungs-Operationen)

4

299,34 $

Wellen 2–4 Regression-Gates + Fixes

4

244,69 $

Wellen 3–4

5

130,84 $

Welle 5 (Produktion) + Backup-Audit

2

15,20 $

Welle 6 (Schema-Migrationen)

3

118,83 $

Welle 7 (Abhängigkeiten, Doku, Wissen) + finales Gate

4

96,64 $

Infrastruktur-Fix

1

11,47 $

Gesamt

40

1.155,38 $

Drei Dinge stechen in der Aufschlüsselung hervor.

1. Die gesamte zwölf Sitzungen umfassende Audit-Phase, die das Manifest erstellte, kostete unter 90 $ – die günstigste Versicherung, die wir je gekauft haben.
2. Die teuersten Posten sitzen genau dort, wo das harte Denken stattfand: die Entflechtungs-Operationen (299 $) und die Regression-Gates (245 $), die alles ehrlich hielten.
3. Der Schritt mit dem höchsten Risiko – die Änderung der Produktionsdaten – kostete 15 $, weil zu dem Zeitpunkt, als er ausgeführt wurde, das gesamte Risiko bereits aus ihm herausentwickelt worden war.

Hinweis: Dieses gesamte Projekt hätte viel günstiger sein können, wenn Devin mir erlaubt hätte, ein anderes Modell für die Sub-Agenten zu wählen. Der Großteil der Programmierarbeit hätte erfolgreich mit gpt 5.5 oder opus 4.8 erledigt werden können. Es wäre einfach, Fable anzuweisen, das passende Modell für die Sub-Agenten-Aufgabe auszuwählen.

Aber selbst ohne das: 1.000 $ ist unglaublich günstig für die Arbeit, die wir erledigt haben – und die Geschwindigkeit, mit der sie erledigt und verifiziert wurde – wow.

https://x.com/ryancarson/status/2072694425365426344

Die Erkenntnis

Die Schlagzeile ist nicht, dass KI viel Code geschrieben hat – Agenten, die gut spezifizierte Änderungen ausführen, sind heute Standard.

Die Schlagzeile ist, dass das Programm-Management selbst delegiert wurde: Zerlegung, Sequenzierung, Parallelisierung, Gating und Eskalation liefen alle innerhalb des Orchestrators, und die menschliche Rolle wurde auf genau die Entscheidungen komprimiert, die einen Verantwortlichen erfordern.

Wenn Sie dies versuchen möchten, übernehmen Sie die Muster, nicht die Werkzeuge:

1. Zuerst auditieren; Ergebnisse in einem Manifest einfrieren, das kein Worker erneut in Frage stellen darf.
2. Wellen nach Risiko sequenzieren; irreversible Schritte zuletzt.
3. Parallelen Workern explizit disjunkte Dateigrenzen geben.
4. Jede Welle mit einer echten Regression-Suite und echten Backups absichern.
5. Vorgeschlagene Inventare vor destruktiven Änderungen anfordern; die Liste genehmigen, nicht die Idee.
6. Den Eskalationspfad definieren, bevor die Überraschungen eintreffen.
7. Ihre Dokumentation und Ihr Agentenwissen als Teil des Projekts aktualisieren, nicht danach.

Auf ein fröhliches Orchestrieren! :)