Cómo usar Fable para orquestar un proyecto masivo con 40 subagentes

La semana pasada en @HelloUntangle completamos el programa de ingeniería más grande y riesgoso de nuestra historia.

• 834 archivos
• Mutación de datos en producción
• Actualización del esquema de base de datos
• 31 PRs
• Iniciado el viernes -> completado el lunes
• Cero incidentes en producción

Todo con una sola sesión del orquestador principal de Fable.

Una sesión principal de @DevinAI planificó el trabajo, generó cuarenta sesiones hijas para ejecutarlo, aplicó controles de regresión y verificaciones de respaldo entre fases, y solo elevó las decisiones que realmente requerían un responsable: decisiones de alcance y aprobación/rechazo de pasos irreversibles.

Lo que hizo que esto funcionara fue un conjunto de patrones de gestión de programas que mejorarían cualquier migración grande.

Así es como lo hicimos...

La arquitectura: un orquestador, muchos trabajadores

• Una sesión principal fue dueña del programa de principio a fin. Su única tarea era planificar, generar sesiones hijas, revisar su producción, secuenciar las fases y escalarme a mí cuando una decisión necesitaba a un humano. No escribió ni una línea de código.
• ~40 sesiones hijas hicieron todo el trabajo real: once sesiones de auditoría paralelas en la Fase 0, sesiones de ejecución para cada oleada y sesiones dedicadas a ejecutar pruebas de regresión cuya única tarea era ejecutar los conjuntos de regresión.

La división es importante porque el modo de fallo de los proyectos de larga duración —ya sean de IA o humanos— es el colapso del contexto: la entidad que hace el trabajo pierde gradualmente el hilo del programa general.

Mantener al principal como un orquestador puro mantiene su contexto limpio; contiene el plan, las decisiones de alcance y el estado de cada oleada. Cada hijo recibe un contexto nuevo y enfocado con exactamente una tarea.

Los siete patrones que lo hicieron funcionar

1. Auditar primero y congelar los hallazgos en un único manifiesto

La Fase 0 consistió en once sesiones de auditoría paralelas, cada una cubriendo una parte del código base: rutas de la aplicación, rutas de API y crons, el esquema de la base de datos, bibliotecas compartidas y flujos de trabajo, scripts y documentación. Sus hallazgos se sintetizaron en un solo archivo y se confirmaron en el repositorio.

El manifiesto asigna a cada unidad de código un veredicto y un número de oleada. Dos reglas lo hicieron poderoso:

• Ningún trabajador vuelve a litigar el alcance. Cada instrucción de ejecución decía, en efecto: el manifiesto es la fuente de la verdad. Sin esto, cada una de las cuarenta sesiones habría derivado su propia opinión sobre lo que está dentro del alcance — y habrían discrepado.
• DESCONOCIDO significa detenerse y preguntar. Cualquier cosa sobre la que las auditorías no se pronunciaran se marcaba explícitamente como desconocida, con una instrucción: no adivines; obtén una resolución. Las resoluciones del responsable se registraban directamente en el manifiesto, para que las sesiones posteriores las heredaran.

2. Ordenar el trabajo por riesgo, no por conveniencia

Las oleadas se secuenciaron de lo más seguro a lo más irreversible.

Oleada

Qué

Riesgo

0

Auditoría + manifiesto + etiqueta git de punto de restauración

ninguno

1

Cambios verificados sin dependencias activas

casi nulo

2

Cirugía de enredos en infraestructura compartida

medio

3–4

El grueso de los cambios de código

medio

5

Cambios en datos de producción (con inventario de prueba + instantánea)

alto

6

Migraciones de esquema

alto

7

Poda de dependencias, reescritura de agents.md, auditoría de base de conocimiento de agentes

bajo

Los cambios en datos de producción (Oleada 5) vienen antes que los cambios de esquema (Oleada 6), y ambos vienen solo después de que cada ruta de código que tocaba las tablas afectadas se haya actualizado de forma verificable. Para cuando se ejecutaron las migraciones, nada podía seguir dependiendo del estado anterior.

3. Los límites de archivos disjuntos hacen que el paralelismo sea seguro

Dentro de una oleada, las sesiones hijas se ejecutaban en paralelo — una oleada tuvo cuatro sesiones trabajando diferentes partes del árbol simultáneamente. La disciplina: cada instrucción incluía un límite de archivos explícito, y los límites eran disjuntos. Sin conflictos de fusión, sin que dos agentes editaran el mismo archivo, sin necesidad de coordinación entre los hijos.

Esta es la descomposición clásica de tareas — lo mismo que harías al dividir el trabajo entre ingenieros — pero los agentes necesitan que se les indique explícitamente, en la instrucción, cada vez.

4. Puertas de seguridad entre oleadas

Ninguna oleada comenzaba hasta que la anterior pasaba una puerta. Las puertas eran en sí mismas sesiones hijas:

• Un conjunto de regresión integral impulsado por navegador que cubría el flujo de trabajo principal del cliente de la plataforma se ejecutó después de la Oleada 2 y nuevamente después de las Oleadas 3–4, en una rama de base de datos aislada y nueva.
• Antes de cualquier cambio en datos de producción: una sesión dedicada auditó nuestro inventario de respaldo de base de datos (recuento, rango de fechas, retención), y tomamos una nueva instantánea puntual.
• El paso de producción en sí se ejecutó primero en seco, produjo recuentos de filas para la aprobación del responsable y volvió a verificar los recuentos después de la ejecución.
• Una etiqueta git marca el punto de restauración para cada línea modificada.

Cuando una puerta fallaba, producía una sesión de corrección con alcance limitado. El conjunto de regresión detectó, por ejemplo, un flujo orientado al cliente que había sido roto por un cambio demasiado entusiasta; una sesión de corrección lo restauró en cuestión de horas. Eso es el sistema funcionando: la puerta convirtió lo que habría sido un error reportado por el cliente en una corrección el mismo día.

5. Los humanos aprueban; los agentes proponen

Nunca escribí código, ejecuté una migración ni ejecuté un script de producción en este proyecto. Pero cada paso irreversible requirió mi aprobación explícita: cada fusión a main, los cambios en datos de producción, las migraciones de esquema y cada resolución sobre elementos de alcance DESCONOCIDO.

El patrón para el trabajo destructivo: el agente propone un inventario, el humano aprueba el inventario, luego el agente ejecuta exactamente ese inventario. La sesión de producción produjo la lista precisa de filas que tocaría antes de tocar nada. Aprobé una lista específica, no una intención vaga.

6. Un protocolo de escalamiento para sorpresas

A los hijos se les dijo qué hacer cuando la realidad discrepaba del manifiesto: detenerse, informar al principal, no improvisar. Ejemplos reales:

• Un módulo que la auditoría consideró seguro resultó tener una dependencia activa en otro lugar → el hijo lo señaló, y la unidad fue degradada a una oleada posterior con el enredo anotado.
• Una segunda ronda de auditoría revirtió los veredictos de la primera ronda en cinco áreas completas → las reversiones se escribieron en el manifiesto como anulaciones explícitas en lugar de resolverse ad hoc por la sesión que las encontrara.

El principal absorbió estas sorpresas en el plan. Los trabajadores individuales nunca tomaron decisiones de alcance.

7. Dejar el campamento más limpio: enseñar al sistema lo que cambió

La Oleada 7 puede ser la fase más infravalorada. Después de que el cambio se implementó, las sesiones reescribieron nuestro AGENTS.md, las habilidades del repositorio y la base de conocimiento del agente para describir la nueva arquitectura — para que cada futura sesión de agente comience desde la verdad, no desde instrucciones obsoletas. Si tu ingeniería está impulsada por agentes, tu documentación es infraestructura de carga.

Lo que costó

Cada sesión en el programa fue etiquetada, por lo que el registro está completo: un principal y treinta y nueve hijos, todos en el Ultra Agent de Devin, desde el viernes por la tarde hasta el lunes por la mañana. Estos son los costos reales medidos de nuestro panel de uso.

Fase

Sesiones

Costo

Orquestador principal (varios días)

1

$115.26

Auditorías de Fase 0 (dos rondas) + síntesis del manifiesto

12

$85.56

Oleada 1

4

$37.55

Oleada 2 (cirugía de enredos)

4

$299.34

Puertas de regresión de Oleadas 2–4 + correcciones

4

$244.69

Oleadas 3–4

5

$130.84

Oleada 5 (producción) + auditoría de respaldo

2

$15.20

Oleada 6 (migraciones de esquema)

3

$118.83

Oleada 7 (dependencias, docs, conocimiento) + puerta final

4

$96.64

Corrección de infraestructura

1

$11.47

Total

40

$1,155.38

Tres cosas destacan en el desglose.

1. Toda la fase de auditoría de doce sesiones que produjo el manifiesto costó menos de $90 — el seguro más barato que jamás hayamos comprado.
2. Las partidas más caras se encuentran exactamente donde estaba el pensamiento difícil: la cirugía de enredos ($299) y las puertas de regresión ($245) que mantuvieron todo honesto.
3. El paso con mayor riesgo — el cambio de datos de producción — costó $15, porque para cuando se ejecutó, todo el riesgo ya había sido eliminado mediante ingeniería.

Nota: Todo este proyecto podría haber sido mucho más asequible si Devin me permitiera elegir un modelo diferente para los subagentes. La mayor parte del trabajo de codificación podría haberse completado con éxito con gpt 5.5 u opus 4.8. Sería simple indicarle a Fable que elija el modelo apropiado para que coincida con la tarea del subagente.

Incluso sin eso: $1K es increíblemente barato para el trabajo que completamos - y la velocidad a la que se hizo y verificó - vaya.

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

La conclusión

El titular no es que la IA escribió mucho código — los agentes que ejecutan cambios bien especificados son algo común ahora.

El titular es que la gestión del programa en sí fue delegada: descomposición, secuenciación, paralelización, control de acceso y escalamiento, todo se ejecutó dentro del orquestador, y el rol humano se comprimió exactamente a las decisiones que requieren un responsable.

Si vas a intentar esto, roba los patrones, no las herramientas:

1. Audita primero; congela los hallazgos en un manifiesto que ningún trabajador pueda volver a litigar.
2. Secuencia las oleadas por riesgo; los pasos irreversibles al final.
3. Dale a los trabajadores paralelos límites de archivos explícitamente disjuntos.
4. Protege cada oleada con un conjunto de regresión real y respaldos reales.
5. Exige inventarios propuestos antes de cambios destructivos; aprueba la lista, no la idea.
6. Define la ruta de escalamiento antes de que lleguen las sorpresas.
7. Actualiza tus documentos y el conocimiento del agente como parte del proyecto, no después.

¡Salud por una feliz orquestación! :)