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: definiciones de alcance y autorizaciones para pasos irreversibles.

Lo que hizo que esto funcionara es 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 trabajo, secuenciar las fases y escalarme 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.

Esta división es importante porque el modo de falla 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 la visión general del programa.

Mantener al padre 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 cron jobs, 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 discutir 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 formaría su propia opinión sobre lo que está dentro del alcance — y no estarían de acuerdo.
• "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 decisión. Las decisiones 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 desde lo más seguro hasta 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 cero

2

Cirugía de enredos en infraestructura compartida

medio

3–4

La mayor parte de los cambios de código

medio

5

Cambios en datos de producción (con inventario simulado + 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 de 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 las migraciones se ejecutaron, nada podía seguir dependiendo del estado anterior.

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

Dentro de una oleada, las sesiones hijas se ejecutaron en paralelo — una oleada tuvo cuatro sesiones trabajando en 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 dos agentes editando 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 de seguridad. Las puertas eran en sí mismas sesiones hijas:

• Una suite de regresión integral, impulsada por navegador y de extremo a extremo 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 se ejecutó primero en modo simulado, 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 específica. La suite de regresión detectó, por ejemplo, un flujo orientado al cliente que había sido dañado 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 un cliente en una corrección del mismo día.

5. Los humanos aprueban; los agentes proponen

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

El patrón para 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 no coincidía con el manifiesto: detenerse, informar al padre, 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 se degradó 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 padre 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 qué cambió

La Oleada 7 puede ser la fase más subestimada. 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 crítica.

Lo que costó

Cada sesión en el programa fue etiquetada, por lo que el registro está completo: un padre 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. Los elementos de mayor costo se encuentran exactamente donde estaba el trabajo duro: 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 en 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 económico si Devin me hubiera permitido elegir un modelo diferente para los subagentes. La mayor parte del trabajo de codificación podría haberse completado con éxito usando gpt 5.5 u opus 4.8. Sería sencillo indicarle a Fable que elija el modelo apropiado para 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 ejecutando cambios bien especificados ya es algo común.

El titular es que la gestión del programa en sí fue delegada: descomposición, secuenciación, paralelización, control de puertas 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 discutir.
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 una suite 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 tu documentación y el conocimiento del agente como parte del proyecto, no después.

¡A orquestar felizmente! :)