Come utilizzare Fable per orchestrare un progetto di grandi dimensioni con 40 sotto-agenti

La scorsa settimana, presso @HelloUntangle, abbiamo completato il programma di ingegneria più grande e rischioso della nostra storia.

• 834 file
• Mutazione di dati in produzione
• Aggiornamento dello schema del database
• 31 PR
• Iniziato venerdì -> completato lunedì
• Zero incidenti in produzione

Il tutto con una singola sessione del genitore orchestratore Fable.

Una singola sessione genitore @DevinAI ha pianificato il lavoro, generato quaranta sessioni figlie per eseguirlo, applicato i gate di regressione e i controlli di backup tra le fasi, e ha sottoposto alla mia attenzione solo le decisioni che richiedevano veramente un responsabile: decisioni sull'ambito e via libera/stop per i passaggi irreversibili.

Ciò che ha reso possibile tutto questo è un insieme di pattern di gestione del programma che migliorerebbero qualsiasi migrazione su larga scala.

Ecco come abbiamo fatto...

L'architettura: un orchestratore, molti worker

• Una sessione genitore possedeva l'intero programma dall'inizio alla fine. Il suo unico compito era pianificare, generare sessioni figlie, rivedere i loro output, sequenziare le fasi e segnalare a me quando una decisione richiedeva un intervento umano. Non ha scritto una riga di codice.
• ~40 sessioni figlie hanno svolto tutto il lavoro effettivo: undici sessioni di audit parallele nella Fase 0, sessioni di esecuzione per ogni ondata e sessioni dedicate all'esecuzione dei gate il cui unico compito era eseguire le suite di regressione.

Questa suddivisione è importante perché la modalità di fallimento dei progetti a lungo termine — siano essi basati su AI o umani — è il collasso del contesto: la cosa che sta facendo il lavoro perde gradualmente di vista il quadro generale del programma.

Mantenere il genitore come un puro orchestratore mantiene il suo contesto pulito; contiene il piano, le decisioni sull'ambito e lo stato di ogni ondata. Ogni figlio riceve un contesto nuovo e focalizzato con esattamente un compito.

I sette pattern che hanno fatto funzionare il tutto

1. Prima l'audit, e congela i risultati in un unico manifest

La Fase 0 consisteva in undici sessioni di audit parallele, ognuna delle quali copriva una fetta del codebase: route dell'app, route API e cron, schema del database, librerie e workflow condivisi, script e documentazione. I loro risultati sono stati sintetizzati in un unico file e committati nel repository.

Il manifest assegna a ogni unità di codice un verdetto e un numero d'ondata. Due regole lo hanno reso potente:

• Nessun worker ridefinisce l'ambito. Ogni prompt di esecuzione diceva, in sostanza: il manifest è la fonte della verità. Senza questo, ognuna delle quaranta sessioni si sarebbe fatta una propria opinione su cosa fosse in ambito — e sarebbero state in disaccordo.
• UNKNOWN significa fermati e chiedi. Qualsiasi cosa su cui gli audit non si erano espressi era esplicitamente marcata come sconosciuta, con l'istruzione: non indovinare; chiedi una decisione. Le decisioni del responsabile venivano registrate direttamente nel manifest, in modo che le sessioni successive le ereditassero.

2. Ordina il lavoro per rischio, non per comodità

Le ondate sono state sequenziate dalla più sicura alla più irreversibile.

Ondata

Cosa

Rischio

0

Audit + manifest + git tag del punto di ripristino

nessuno

1

Modifiche verificate senza dipendenti live

quasi zero

2

Interventi di "entanglement" sull'infrastruttura condivisa

medio

3–4

La maggior parte delle modifiche al codice

medio

5

Modifiche ai dati di produzione (con inventario dry-run + snapshot)

alto

6

Migrazioni dello schema

alto

7

Pulizia delle dipendenze, riscrittura di agents.md, audit della knowledge base degli agenti

basso

Le modifiche ai dati di produzione (Ondata 5) vengono prima delle modifiche allo schema (Ondata 6), ed entrambe arrivano solo dopo che ogni percorso di codice che toccava le tabelle interessate è stato verificabilmente aggiornato. Quando le migrazioni sono state eseguite, nulla poteva più dipendere dallo stato precedente.

3. Confini di file disgiunti rendono il parallelismo sicuro

All'interno di un'ondata, le sessioni figlie venivano eseguite in parallelo — un'ondata ha avuto quattro sessioni che lavoravano contemporaneamente su diverse parti dell'albero. La disciplina: ogni prompt includeva un confine di file esplicito, e i confini erano disgiunti. Nessun conflitto di merge, nessun agente che modificava lo stesso file, nessuna necessità di coordinamento tra i figli.

Questa è la classica scomposizione dei compiti — la stessa cosa che faresti suddividendo il lavoro tra ingegneri — ma gli agenti hanno bisogno che sia dichiarata esplicitamente, nel prompt, ogni volta.

4. Gate di sicurezza tra le ondate

Nessuna ondata iniziava finché la precedente non superava un gate. I gate erano essi stessi sessioni figlie:

• Una suite di regressione end-to-end guidata dal browser che copriva il flusso cliente principale della piattaforma veniva eseguita dopo l'Ondata 2 e di nuovo dopo le Ondate 3–4, su un ramo del database isolato e fresco.
• Prima di qualsiasi modifica ai dati di produzione: una sessione dedicata ha verificato il nostro inventario dei backup del database (conteggio, intervallo di date, conservazione), e abbiamo effettuato un nuovo snapshot point-in-time.
• Il passaggio in produzione stesso è stato eseguito prima in dry-run, ha prodotto i conteggi delle righe per l'approvazione del responsabile, e ha riverificato i conteggi dopo l'esecuzione.
• Un git tag segna il punto di ripristino per ogni riga modificata.

Quando un gate falliva, produceva una sessione di fix con ambito limitato. La suite di regressione ha catturato, ad esempio, un flusso rivolto al cliente che era stato interrotto da una modifica troppo zelante; una sessione di fix lo ha ripristinato nel giro di poche ore. Questo è il sistema che funziona — il gate ha trasformato quello che sarebbe stato un bug segnalato dal cliente in un fix risolto in giornata.

5. Gli umani approvano; gli agenti propongono

Non ho mai scritto codice, eseguito una migrazione o lanciato uno script di produzione in questo progetto. Ma ogni passo irreversibile richiedeva il mio esplicito via libera: ogni merge su main, le modifiche ai dati di produzione, le migrazioni dello schema e ogni decisione sugli elementi UNKNOWN dell'ambito.

Il pattern per il lavoro distruttivo: l'agente propone un inventario, l'umano approva l'inventario, poi l'agente esegue esattamente quell'inventario. La sessione di produzione ha prodotto l'elenco preciso delle righe che avrebbe toccato prima di toccare qualsiasi cosa. Ho approvato un elenco specifico, non un'intenzione vaga.

6. Un protocollo di escalation per le sorprese

Ai figli è stato detto cosa fare quando la realtà non corrispondeva al manifest: fermarsi, riferire al genitore, non improvvisare. Esempi reali:

• Un modulo che l'audit aveva definito sicuro si è rivelato avere un dipendente live altrove → il figlio lo ha segnalato, e l'unità è stata declassata a un'ondata successiva con l'entanglement annotato.
• Un secondo round di audit ha invertito i verdetti del primo round su cinque intere aree → le inversioni sono state scritte nel manifest come override espliciti, piuttosto che risolte ad hoc dalla sessione che le incontrava.

Il genitore ha assorbito queste sorprese nel piano. I singoli worker non hanno mai preso decisioni sull'ambito.

7. Lascia il campeggio più pulito di come l'hai trovato: insegna al sistema cosa è cambiato

L'Ondata 7 potrebbe essere la fase più sottovalutata. Dopo che la modifica è stata rilasciata, le sessioni hanno riscritto il nostro AGENTS.md, le skill del repository e la knowledge base degli agenti per descrivere la nuova architettura — in modo che ogni futura sessione agente parta dalla verità, non da istruzioni obsolete. Se la tua ingegneria è guidata da agenti, la tua documentazione è un'infrastruttura portante.

Quanto è costato

Ogni sessione del programma è stata taggata, quindi il registro è completo: un genitore e trentanove figli, tutti su Devin's Ultra Agent, da venerdì pomeriggio a lunedì mattina. Questi sono i costi effettivi misurati dalla nostra dashboard di utilizzo.

Fase

Sessioni

Costo

Orchestratore genitore (multi-giorno)

1

$115.26

Audit Fase 0 (due round) + sintesi del manifest

12

$85.56

Ondata 1

4

$37.55

Ondata 2 (intervento entanglement)

4

$299.34

Gate di regressione Ondate 2–4 + fix

4

$244.69

Ondate 3–4

5

$130.84

Ondata 5 (produzione) + audit backup

2

$15.20

Ondata 6 (migrazioni schema)

3

$118.83

Ondata 7 (dipendenze, documentazione, knowledge) + gate finale

4

$96.64

Fix infrastruttura

1

$11.47

Totale

40

$1,155.38

Tre cose spiccano nella suddivisione.

1. L'intera fase di audit di dodici sessioni che ha prodotto il manifest è costata meno di $90 — l'assicurazione più economica che abbiamo mai comprato.
2. Le voci di costo più alte si trovano esattamente dove c'era il lavoro intellettuale più complesso: l'intervento di entanglement ($299) e i gate di regressione ($245) che hanno tenuto tutto sotto controllo.
3. Il passo con la posta in gioco più alta — la modifica ai dati di produzione — è costato $15, perché quando è stato eseguito, tutto il rischio era già stato ingegnerizzato fuori.

Nota: L'intero progetto avrebbe potuto essere molto più economico se Devin mi avesse permesso di scegliere un modello diverso per i sub-agenti. La maggior parte del lavoro di codifica avrebbe potuto essere completata con successo con gpt 5.5 o opus 4.8. Sarebbe stato semplice istruire Fable per scegliere il modello appropriato in base al compito del sub-agente.

Anche senza questo, però: $1K è incredibilmente economico per il lavoro che abbiamo completato - e la velocità con cui è stato fatto e verificato - wow.

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

Il messaggio chiave

Il punto non è che l'AI ha scritto molto codice — gli agenti che eseguono modifiche ben specificate sono ormai all'ordine del giorno.

Il punto è che la gestione del programma stessa è stata delegata: scomposizione, sequenziamento, parallelizzazione, gating ed escalation sono avvenuti tutti all'interno dell'orchestratore, e il ruolo umano si è compresso esattamente alle decisioni che richiedono un responsabile.

Se hai intenzione di provare questo approccio, ruba i pattern, non gli strumenti:

1. Prima l'audit; congela i risultati in un manifest che nessun worker possa ridefinire.
2. Sequenza le ondate per rischio; i passi irreversibili per ultimi.
3. Dai ai worker paralleli confini di file esplicitamente disgiunti.
4. Metti un gate a ogni ondata con una vera suite di regressione e veri backup.
5. Richiedi inventari proposti prima delle modifiche distruttive; approva l'elenco, non l'idea.
6. Definisci il percorso di escalation prima che arrivino le sorprese.
7. Aggiorna la tua documentazione e la knowledge base degli agenti come parte del progetto, non dopo.

Alla felice orchestrazione! :)