Comment utiliser Fable pour orchestrer un projet d'envergure avec 40 sous-agents

La semaine dernière chez @HelloUntangle, nous avons mené à bien le programme d'ingénierie le plus vaste et le plus risqué de notre histoire.

• 834 fichiers
• Mutation de données en production
• Mise à jour du schéma de base de données
• 31 PRs
• Commencé vendredi -> terminé lundi
• Zéro incident en production

Le tout avec une seule session orchestratrice Fable.

Une seule session parente @DevinAI a planifié le travail, engendré quarante sessions enfants pour l'exécuter, imposé des contrôles de régression et des vérifications de sauvegarde entre les phases, et n'a remonté que les décisions nécessitant réellement un propriétaire : les arbitrages de périmètre et les décisions go/no-go sur les étapes irréversibles.

Ce qui a permis cela, c'est un ensemble de modèles de gestion de programme qui amélioreraient n'importe quelle migration importante.

Voici comment nous avons procédé...

L'architecture : un orchestrateur, de nombreux travailleurs

• Une session parente possédait le programme de bout en bout. Son seul travail était de planifier, de lancer des sessions enfants, de revoir leur production, de séquencer les phases et de me solliciter lorsqu'une décision nécessitait un humain. Elle n'a écrit aucune ligne de code.
• Environ 40 sessions enfants ont effectué tout le travail concret : onze sessions d'audit parallèles dans la Phase 0, des sessions d'exécution pour chaque vague, et des sessions dédiées aux contrôles dont le seul travail était d'exécuter les suites de régression.

Cette répartition est importante car le mode de défaillance des projets de longue durée — qu'ils soient menés par l'IA ou par des humains — est l'effondrement du contexte : l'entité qui effectue le travail perd progressivement la vision d'ensemble du programme.

En maintenant le parent comme un pur orchestrateur, son contexte reste clair ; il détient le plan, les décisions de périmètre et l'état de chaque vague. Chaque enfant reçoit un contexte frais et ciblé avec exactement une seule tâche.

Les sept modèles qui ont fait la différence

1. Auditer d'abord, et figer les résultats dans un manifeste unique

La Phase 0 a consisté en onze sessions d'audit parallèles, chacune couvrant une partie du code : les routes de l'application, les routes API et les tâches cron, le schéma de base de données, les bibliothèques partagées et les workflows, les scripts et la documentation. Leurs conclusions ont été synthétisées dans un seul fichier et commitées dans le dépôt.

Le manifeste attribue à chaque unité de code un verdict et un numéro de vague. Deux règles l'ont rendu puissant :

• Aucun travailleur ne remet le périmètre en question. Chaque invite d'exécution disait, en substance : le manifeste est la source de vérité. Sans cela, chacune des quarante sessions aurait eu sa propre opinion sur ce qui est dans le périmètre — et elles auraient divergé.
• INCONNU signifie stop et demande. Tout ce sur quoi les audits étaient silencieux était explicitement marqué comme inconnu, avec une instruction : ne devine pas ; obtiens une décision. Les décisions du propriétaire étaient enregistrées directement dans le manifeste, afin que les sessions ultérieures les héritent.

2. Ordonner le travail par risque, pas par commodité

Les vagues ont été séquencées de la plus sûre à la plus irréversible.

Vague

Quoi

Risque

0

Audit + manifeste + tag git de point de restauration

aucun

1

Modifications vérifiées sans dépendants actifs

quasi nul

2

Chirurgie des enchevêtrements sur l'infrastructure partagée

moyen

3–4

Le gros des modifications de code

moyen

5

Modifications des données de production (avec inventaire dry-run + snapshot)

élevé

6

Migrations de schéma

élevé

7

Élagage des dépendances, réécriture d'agents.md, audit de la base de connaissances des agents

faible

Les modifications des données de production (Vague 5) viennent avant les modifications de schéma (Vague 6), et les deux n'interviennent qu'après que chaque chemin de code touchant les tables concernées a été vérifié comme mis à jour. Au moment où les migrations ont été exécutées, rien ne pouvait encore dépendre de l'ancien état.

3. Des limites de fichiers disjointes rendent le parallélisme sûr

Au sein d'une vague, les sessions enfants s'exécutaient en parallèle — une vague avait quatre sessions travaillant simultanément sur différentes parties de l'arborescence. La discipline : chaque invite incluait une limite de fichier explicite, et ces limites étaient disjointes. Pas de conflits de fusion, pas de deux agents modifiant le même fichier, aucune coordination nécessaire entre les enfants.

C'est une décomposition de tâche classique — la même chose que vous feriez en répartissant le travail entre ingénieurs — mais les agents ont besoin que cela soit énoncé explicitement, dans l'invite, à chaque fois.

4. Des contrôles de sécurité entre les vagues

Aucune vague ne commençait tant que la précédente n'avait pas passé un contrôle. Les contrôles étaient eux-mêmes des sessions enfants :

• Une suite de régression de bout en bout, pilotée par navigateur, couvrant le workflow client principal de la plateforme, a été exécutée après la Vague 2 et à nouveau après les Vagues 3–4, sur une branche de base de données isolée et fraîche.
• Avant toute modification des données de production : une session dédiée a audité notre inventaire de sauvegarde de base de données (nombre, plage de dates, rétention), et nous avons pris un snapshot ponctuel frais.
• L'étape de production elle-même a d'abord été exécutée en dry-run, a produit des comptages de lignes pour approbation du propriétaire, et a revérifié les comptages après exécution.
• Un tag git marque le point de restauration pour chaque ligne modifiée.

Lorsqu'un contrôle échouait, il produisait une session de correction ciblée. La suite de régression a par exemple détecté un flux client qui avait été cassé par une modification trop zélée ; une session de correction l'a rétabli en quelques heures. C'est le système qui fonctionne — le contrôle a transformé ce qui aurait été un bug signalé par un client en une correction le jour même.

5. Les humains approuvent ; les agents proposent

Je n'ai jamais écrit de code, exécuté de migration ou lancé de script de production dans ce projet. Mais chaque étape irréversible nécessitait mon feu vert explicite : chaque fusion dans main, les modifications des données de production, les migrations de schéma, et chaque décision sur les éléments de périmètre INCONNU.

Le modèle pour le travail destructeur : l'agent propose un inventaire, l'humain approuve l'inventaire, puis l'agent exécute exactement cet inventaire. La session de production a produit la liste précise des lignes qu'elle toucherait avant de toucher quoi que ce soit. J'ai approuvé une liste spécifique, pas une intention vague.

6. Un protocole d'escalade pour les imprévus

Les enfants ont reçu pour instruction de faire quoi faire lorsque la réalité contredisait le manifeste : s'arrêter, le signaler au parent, ne pas improviser. Exemples concrets :

• Un module que l'audit considérait comme sûr s'est avéré avoir une dépendance active ailleurs → l'enfant l'a signalé, et l'unité a été rétrogradée à une vague ultérieure avec l'enchevêtrement noté.
• Un deuxième cycle d'audit a inversé les verdicts du premier cycle sur cinq zones entières → les inversions ont été écrites dans le manifeste comme des surcharges explicites plutôt que résolues de manière ad hoc par la session qui les rencontrait.

Le parent a absorbé ces imprévus dans le plan. Les travailleurs individuels n'ont jamais pris de décisions de périmètre.

7. Laisser le campement plus propre : enseigner au système ce qui a changé

La Vague 7 est peut-être la phase la plus sous-estimée. Après le déploiement du changement, des sessions ont réécrit notre AGENTS.md, les compétences du dépôt et la base de connaissances des agents pour décrire la nouvelle architecture — afin que chaque future session d'agent parte de la vérité, et non d'instructions obsolètes. Si votre ingénierie est pilotée par des agents, votre documentation est une infrastructure porteuse de charge.

Ce que cela a coûté

Chaque session du programme a été étiquetée, donc le registre est complet : un parent et trente-neuf enfants, tous sur Devin's Ultra Agent, du vendredi après-midi au lundi matin. Voici les coûts réels mesurés depuis notre tableau de bord d'utilisation.

Phase

Sessions

Coût

Orchestrateur parent (multi-jours)

1

115,26 $

Audits Phase 0 (deux cycles) + synthèse du manifeste

12

85,56 $

Vague 1

4

37,55 $

Vague 2 (chirurgie des enchevêtrements)

4

299,34 $

Contrôles de régression Vagues 2–4 + corrections

4

244,69 $

Vagues 3–4

5

130,84 $

Vague 5 (production) + audit de sauvegarde

2

15,20 $

Vague 6 (migrations de schéma)

3

118,83 $

Vague 7 (dépendances, docs, connaissances) + contrôle final

4

96,64 $

Correction d'infrastructure

1

11,47 $

Total

40

1 155,38 $

Trois choses ressortent de cette répartition.

1. La phase d'audit entière de douze sessions qui a produit le manifeste a coûté moins de 90 $ — l'assurance la moins chère que nous ayons jamais achetée.
2. Les postes de dépense les plus élevés se situent exactement là où se trouvait la réflexion difficile : la chirurgie des enchevêtrements (299 $) et les contrôles de régression (245 $) qui ont maintenu l'intégrité de l'ensemble.
3. L'étape la plus risquée — la modification des données de production — a coûté 15 $, car au moment de son exécution, tout le risque avait déjà été éliminé par l'ingénierie.

Remarque : L'ensemble de ce projet aurait pu être beaucoup plus abordable si Devin m'avait permis de choisir un modèle différent pour les sous-agents. La majorité du travail de codage aurait pu être réalisée avec succès avec gpt 5.5 ou opus 4.8. Il serait simple d'instruire Fable de choisir le modèle approprié pour correspondre à la tâche du sous-agent.

Même sans cela : 1 000 $ est incroyablement bon marché pour le travail que nous avons accompli - et la vitesse à laquelle il a été fait et vérifié - wow.

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

L'essentiel à retenir

Le titre n'est pas que l'IA a écrit beaucoup de code — des agents exécutant des changements bien spécifiés est désormais la norme.

Le titre est que la gestion du programme elle-même a été déléguée : la décomposition, le séquencement, la parallélisation, le contrôle et l'escalade ont tous été gérés à l'intérieur de l'orchestrateur, et le rôle humain s'est réduit exactement aux décisions qui nécessitent un propriétaire.

Si vous voulez essayer cela, volez les modèles, pas les outils :

1. Auditez d'abord ; figez les résultats dans un manifeste qu'aucun travailleur ne peut remettre en question.
2. Séquencez les vagues par risque ; les étapes irréversibles en dernier.
3. Donnez aux travailleurs parallèles des limites de fichiers explicitement disjointes.
4. Contrôlez chaque vague avec une véritable suite de régression et de véritables sauvegardes.
5. Exigez des inventaires proposés avant les modifications destructrices ; approuvez la liste, pas l'idée.
6. Définissez le chemin d'escalade avant l'arrivée des imprévus.
7. Mettez à jour votre documentation et la connaissance des agents dans le cadre du projet, pas après.

À vos orchestrations heureuses ! :)