Mob Elaboration: el ritual que reemplaza al sprint planning

El sprint planning pregunta qué puede hacer el equipo en dos semanas. Mob Elaboration le pide al equipo que decida, en una sola sesión, todo lo que el agente tendría que adivinar.

Mob Elaboration es el ritual de requisitos de AI-DLC. Las personas que pueden tomar decisiones sobre un trabajo se sientan en una sesión con un agente de IA. El agente propone la descomposición y hace las preguntas. El equipo responde, corrige y aprueba. Nadie escribe código. Lo que sale de ahí es la spec desde la que el agente va a construir: requisitos, user stories, unidades de trabajo y las decisiones de arquitectura detrás de ellas, todo guardado en archivos dentro del repositorio. En términos de AI-DLC, es el corazón de la Inception, la fase en la que se deciden requisitos y diseño antes de que la Construction escriba código.

Reemplaza al sprint planning y al refinamiento del backlog en el AI-Driven Development Life Cycle. El whitepaper de AWS lo describe como una sala, una pantalla compartida, un facilitador y una IA que propone user stories, criterios de aceptación y Units mientras el mob corrige lo que salió subdimensionado o sobredimensionado. La promesa del paper es condensar semanas o meses de trabajo secuencial en unas pocas horas.

La promesa es cierta, y también es lo menos útil que puedes saber del ritual. El paper te dice qué es Mob Elaboration. No te dice quién debería estar en la sala, qué hacer antes de la sesión, cómo responder las preguntas del agente ni por qué la tercera hora sale tan mal. Aprendí esas cosas viendo a equipos correrlo dentro de una gran organización de ingeniería, en pilotos y en una formación de varios días para las personas que lo van a llevar a todos los equipos. Esta es la guía que me hubiera gustado que recibieran el primer día.

Mob Elaboration comprime semanas de refinamiento en una sola sesión

Piensa en cómo se refina una feature en un equipo ágil normal. El PM escribe un ticket. Un dev tiene una duda y la pregunta en un canal de chat. El diseñador responde dos días después. Alguien decide algo en un pasillo, y la decisión vive en la cabeza de una persona hasta que aparece como bug. El refinamiento no es lento porque alguien sea perezoso. Es lento porque ocurre en fragmentos, a lo largo de días, y cada fragmento espera a una persona.

Con un agente que genera un conjunto completo de requisitos en minutos, esa espera se vuelve todo el costo. Mob Elaboration ataca la espera de frente. Pone a todos los que pueden responder en la misma sesión y deja que la IA conduzca las preguntas en orden, así que una decisión que tomaba una semana de ida y vuelta toma cinco minutos de conversación.

El nombre viene del mob programming, la práctica que el equipo de Woody Zuill popularizó hacia 2012: todo el equipo trabaja en lo mismo, al mismo tiempo, en una sola computadora. La diferencia importa. Un mob de programación escribe código en conjunto. Un mob de elaboración decide en conjunto, y la IA escribe.

Solo quien puede decidir tiene silla

La regla que más diferencia hizo en las sesiones que vi: solo entra quien tiene poder de decisión sobre alguna dimensión del trabajo. Producto decide alcance y reglas de negocio. Ingeniería decide arquitectura y trade-offs. Diseño decide la experiencia. Datos decide qué se mide. Todos los demás son observadores, y los observadores encarecen la sesión sin sumar contexto.

Suena duro hasta que haces la cuenta. Un mob de ocho personas durante tres horas es un día completo de trabajo de una persona. Si tres de esos ocho no pueden responder ninguna pregunta del agente, un tercio de ese día no compró nada.

El mob correcto cambia según el trabajo. El patrón que se asentó:

Quién se sienta en el mob

Entre tres y cinco personas es el punto justo. Cada una debería poder responder al menos un tipo de pregunta que el agente va a hacer.

Tipo de trabajo	Quién entra
Feature con usuario final	Ingeniería, producto, diseño
Datos o machine learning	Ingeniería, datos, producto
Cambio puramente técnico	Ingeniería y un arquitecto
Optimización algorítmica	Ingeniería y un especialista de dominio

AI-DLC 2 incluso tiene una etapa para esto. En los perfiles Feature y Enterprise, Team Formation (etapa 1.5) hace que el agente de entrega evalúe disponibilidad y habilidades y escriba un plan de composición del mob antes de que empiece la Inception. Es una buena etapa. Aun así, no puede saber que tu tech lead se va de vacaciones la semana que viene.

Corre la ingeniería inversa antes de que entre alguien

Si el trabajo toca una codebase existente, el agente tiene que leerla antes de poder hacer buenas preguntas. AI-DLC llama a esto ingeniería inversa: el agente recorre los módulos que la feature va a tocar, mapea cómo se comunican entre sí y anota el stack, los patrones y la arquitectura. Cada pregunta que hace después pasa por ese modelo. Sin él, el agente propone cambios que duplican lógica que ya existe o rompen contratos que nadie escribió.

En un repositorio chico esa pasada tomó unos veinte minutos en las sesiones que vi. En uno grande toma más. De cualquier forma, son veinte minutos de un mob mirando una barra de progreso, que es la forma más cara de gastar veinte minutos.

Así que quien conduce la corre antes. Instala el workflow, inicia la intent, deja que la ingeniería inversa termine, revisa y aprueba lo que produjo, y recién ahí llama al equipo. La gente entra con un archivo de preguntas listo para responder. Los detalles de hacer esto en una codebase grande, incluido cuánto contexto consume, están en AI-DLC en brownfield.

El archivo de preguntas es la reunión

Después de la ingeniería inversa, el agente escribe un archivo de preguntas. Es un documento markdown simple, con preguntas numeradas, opciones de selección múltiple y una etiqueta de respuesta vacía debajo de cada una. En una sesión que vi, el agente produjo quince preguntas para una feature chica de backoffice. Cubrían alcance, comportamiento, términos de negocio y decisiones técnicas que el ticket original nunca mencionó.

Una pregunta se ve así:

## Question 4

How should a cancelled order affect stock that was already reserved?

A) Release the reservation immediately
B) Release it after a grace period
C) Keep it until someone confirms the cancellation
X) Other (please describe)

[Answer]:

Este es el cambio de enfoque que hizo que los equipos dejaran de odiar el archivo. Cada una de esas preguntas es una pregunta que un dev se habría encontrado en medio de la implementación. Sin el ritual, habría dejado de programar, le habría escrito a alguien y habría esperado. Con el ritual, la pregunta se responde antes de que exista código, y a veces la respuesta cambia todo el enfoque. El archivo no agrega trabajo. Lo mueve al punto más barato para hacerlo.

Los equipos también tuvieron que desaprender a tratar el archivo como un examen. Estos cuatro hábitos arreglaron casi todo, y cada uno viene con las palabras que puedes escribir:

Cómo responder las preguntas del agente

1. 01

   Responde fuera de las opciones cuando las opciones están mal.

   Al principio, los equipos se sentían atados a A, B o C. Las opciones son conjeturas del agente, no restricciones. Lee una respuesta libre igual de bien.

   Escribe esto

   None of these. Reservations stay until the warehouse system confirms the cancellation, because a manual refund can still reverse it.

2. 02

   Posterga lo que no bloquea, y dale un dueño.

   Una pregunta que depende de una decisión externa no debería frenar la sesión. El agente la salta y la vuelve a preguntar después. Las preguntas que bloquean, como un contrato de API del que dependen las Units, no te las deja saltar, y no debería.

   Escribe esto

   We don't know yet. Mark it TBD, owner: the payments lead, and ask again before Units Generation.

3. 03

   Cambia de opinión en voz alta. Las respuestas son reversibles.

   El agente reconstruye los documentos a partir de las respuestas actuales. Cambiar una respuesta devuelve el workflow a la etapa que dependía de ella. Nunca necesitas matar la sesión y empezar de cero.

   Escribe esto

   Change question 4 from A to B and update every document that depended on it.

4. 04

   Pregunta antes de elegir.

   Cuando nadie en la sala entiende una opción, pídele al agente que la explique en el contexto de este proyecto. El prefijo evita que trate tu pregunta como una orden de edición.

   Escribe esto

   Do not update any documents. What would option C mean for the current reservation flow?

Vale la pena adoptar un hábito más: lleva una lista de las preguntas del agente que el ticket original ya respondía. Esa lista te dice qué le falta a la entrada. Llévala de vuelta a la forma en que tu equipo escribe la próxima intent, y la próxima sesión se acorta. De dónde debería salir esa entrada es otro problema, que se trata en el punto ciego de AI-DLC.

Producto entra en las preguntas de negocio, no en toda la sesión

La agenda es lo primero que mata a Mob Elaboration en una empresa real. Juntar a un PM, un diseñador y tres ingenieros en la misma sala durante tres horas, cada vez que empieza una feature, no sobrevive a la semana de nadie.

La solución vino de alguien de producto en el piloto, y era simple. La mayoría de las preguntas después de la ingeniería inversa son técnicas. Los ingenieros responden esas por su cuenta. Cuando llegan a una pregunta sobre reglas de negocio, llaman a producto. En el caso que esa persona contó, producto dedicó diez minutos en lugar de una tarde. La frase, más o menos: no hace falta que todos estén en la sala al mismo tiempo.

Producto sigue siendo dueño de dos cosas que nadie más puede firmar. La primera es si las preguntas son siquiera relevantes, porque a veces el agente pregunta por cosas que el ticket ya resolvió. La segunda es el criterio de éxito, que es lo que el agente más se equivoca. Esa trampa tiene una sección entera en el punto ciego de AI-DLC.

Decide cuánto de la spec escribe la IA

Un equipo que seguí hacía explícita esta elección al principio de cada tarea, y creo que todos los equipos deberían hacerlo. Hay tres formas de repartir la autoría de la spec entre las personas y la IA:

Tres formas de repartir la autoría de la spec

Collaborative es el valor por defecto correcto. Strict y Off son excepciones deliberadas, elegidas en voz alta.

Modo	Quién escribe	Úsalo cuando	El riesgo
Strict	Las personas escriben cada línea. La IA solo valida.	Dominios muy regulados o sensibles.	Lento. Renuncias a casi toda la velocidad.
Collaborative	La IA pregunta, el equipo responde, la IA redacta, el equipo aprueba.	El valor por defecto para casi todo.	Los gates se degradan cuando la gente está cansada.
Off	Sin spec. El agente va directo al código.	Un spike que vas a tirar.	Es vibe coding con pasos extra.

AI-DLC 2 tiene una elección parecida pero distinta, y la gente las confunde. Cada etapa que recoge información ofrece tres modos de interacción: Guide Me (el agente hace una pregunta a la vez), Edit File (tú mismo completas el archivo de preguntas) y Chat (conversación libre, con el agente escribiendo las decisiones de vuelta en el archivo). Eso es sobre cómo respondes. Los tres modos de arriba son sobre quién escribe la spec. Puedes estar en Collaborative y responder en modo Edit File. Los dos convergen en el mismo archivo de preguntas.

Una hora, y después para

Esta es la parte de Mob Elaboration que la documentación nunca menciona, y es donde fallan la mayoría de las sesiones.

La IA produce un documento de requisitos, un conjunto de user stories y una lista de Units en minutos. Una persona necesita tiempo de verdad para leer cada uno con cuidado. La brecha entre la velocidad de generación y la de lectura es más ancha que con cualquier herramienta anterior, porque la IA no te da una sugerencia, te da un artefacto terminado. Después de más o menos una hora, la gente deja de leer y empieza a aprobar.

Alguien de ingeniería lo dijo en voz alta durante la formación, cerca del final de una Inception larga: cuando las Units de trabajo llegaron a revisión, ya no le quedaba nada con qué revisarlas, y sabía que si seguía iba a aprobar cualquier cosa. Paró y volvió otro día. Fue la decisión correcta, y la mayoría de la gente no la toma.

Reglas de ritmo que se sostuvieron

• ✓Obligatorio:
  Limita cada sesión a más o menos una hora.Divide una Inception grande en dos o tres sesiones, en días distintos.
• ✓Obligatorio:
  Pausa en los gates, nunca en medio de una etapa.El archivo de estado registra dónde paraste, así que retomar no cuesta nada.
• ✓Obligatorio:
  Haz commit y push antes de limpiar el contexto.El trabajo vive en los archivos. La conversación es descartable.
• ✓Obligatorio:
  El manager se sienta en los dos o tres primeros mobs.No para observar. Para cortar cuando las aprobaciones empiezan a llegar sin preguntas.
• ✗Anti-pattern:
  Aprobar sin poder decir por qué el artefacto está bien.Si no puedes explicarlo en una frase, no terminaste de leer.

La versión más profunda de este argumento, con las otras formas en que fallan los gates de aprobación, está en los gates son una función de pérdida.

Qué automatiza AI-DLC 2, y qué te deja a ti

AI-DLC 2 metió parte del mob dentro de la máquina. La fase de Inception ahora corre nueve etapas, de la ingeniería inversa a la planificación de entrega, y una de ellas está armada como un mob de agentes. En User Stories (etapa 2.4), el agente de producto redacta las personas y las historias. Después los agentes de diseño, desarrollo y calidad revisan ese borrador en paralelo, sin ver las notas de los otros, y escriben sus objeciones. El agente de producto las incorpora. Las decisiones de criterio donde ambas posiciones son legítimas te llegan como una pregunta estructurada. Las disputas factuales tienen una ronda más, acotada, entre los agentes. Un revisor de producto separado verifica el resultado antes de que llegue a tu gate.

Un Mob Elaboration en AI-DLC 2, de principio a fin

Entrada

Una intent aprobada y un repositorio que el agente puede leer

↓

1. 2.1Ingeniería inversa, antes de que entre el equipo

   Un agente de desarrollo recorre el código, un agente de arquitectura escribe la síntesis. Una pasada completa por repositorio cuando el trabajo abarca varios.

   ↓
2. 2.3El archivo de preguntas

   Los ingenieros responden las preguntas técnicas. Producto entra en las de negocio. Las respuestas pueden ser libres, postergadas o cambiadas después.

   ↓
3. 2.4User stories, redactadas por un mob de agentes

   El agente de producto redacta; los agentes de diseño, desarrollo y calidad objetan en paralelo; tú resuelves las decisiones de criterio.

   ↓
4. 2.7Units de trabajo

   El agente descompone las historias en Units con un grafo de dependencias. Aquí es donde limitas su tamaño.

   ↓
5. GATEAprueba o pide cambios, y para

   Un gate de verificación comprueba que cada requisito se conecte con una historia antes de que empiece la Construction.

↓

Salida

Una spec en el repositorio desde la que el agente puede construir, y un equipo de acuerdo con lo que dice.

Es un avance real. Agentes discutiendo entre sí antes de que veas el borrador atrapan una clase de errores que antes llegaban al gate. Pero mira lo que el motor todavía no puede hacer. No elige quién se sienta en la sala. No nota que el PM dejó de leer. No sabe que la regla de negocio que acaba de escribir es la que la empresa abandonó el trimestre pasado. Las partes difíciles del ritual son humanas, y siguieron siendo humanas.

El planning no es Mob Elaboration

Cuando un equipo adopta el ritual, el resto de su agenda cambia, y los equipos que no la cambian terminan con dos reuniones de planificación.

El planning decide en qué trabajar después. Mob Elaboration decide cómo se va a comportar un trabajo ya elegido. Son reuniones distintas, con gente distinta. La daily se reduce a unos minutos, porque el estado de cada trabajo está en sus archivos. Kanban encaja mejor que los sprints, porque el trabajo ahora llega en porciones de horas o días, no en paquetes de dos semanas.

El backlog en sí tomó una de tres formas en los equipos que vi:

Tres formas de backlog con AI-DLC

La tercera forma sigue siendo AI-DLC. Es solo un mob de una persona, más el agente.

Forma	Cómo funciona	Cuándo encaja
Una iniciativa grande por semana	Todo el squad elabora junto, después construye.	Una feature grande con muchas preguntas abiertas.
Varias tareas chicas	Una mañana de elaboración, después la construcción corre de forma asíncrona en branches aisladas.	Tareas independientes que necesitan algunas decisiones cada una.
Una tarea, en solitario	Un ingeniero con experiencia y el agente, sin mob.	Trabajo bien acotado, sin decisiones entre equipos.

Y ten presente el piso. Un ingeniero del piloto corrió el ritual completo para cambiar una sola línea de código. Si ya sabes exactamente qué cambiar, cámbialo. Mob Elaboration se paga cuando el trabajo necesita decisiones de más de una persona. Por debajo de eso, es ceremonia.

Si tu equipo todavía no escribe specs, la sesión se va a sentir como un interrogatorio, porque cada pregunta deja en evidencia una decisión que nadie tomó. Es el método funcionando, pero también es una señal para construir el hábito primero, como describe Spec-Driven Development para equipos, antes de correr 33 etapas.

Preguntas frecuentes

¿Qué es Mob Elaboration?+

Mob Elaboration es el ritual de requisitos de AI-DLC, el AI-Driven Development Life Cycle. Las personas que pueden decidir sobre un trabajo se reúnen con un agente de IA, el agente propone la descomposición y hace preguntas estructuradas, y el equipo responde y aprueba. El resultado son requisitos, user stories, Units de trabajo y decisiones de arquitectura guardados como archivos en el repositorio. No se escribe código.

¿Cuánto dura un Mob Elaboration?+

El whitepaper habla de horas en lugar de semanas, y eso coincide con lo que vi para una feature. Pero no lo corras como un solo bloque largo.

Después de más o menos una hora, quienes revisan empiezan a aprobar sin leer. Divide una Inception grande en sesiones de una hora, prepara la ingeniería inversa antes de que entre el equipo y pausa en los gates.

¿Quién debería participar en un Mob Elaboration?+

Solo personas con poder de decisión sobre alguna parte del trabajo: normalmente ingeniería y producto, más diseño para trabajo con usuario final, datos para trabajo de datos, un arquitecto para cambios puramente técnicos o un especialista de dominio para trabajo algorítmico. Entre tres y cinco personas es el punto justo. Los observadores lo encarecen sin sumar respuestas.

¿Mob Elaboration es lo mismo que mob programming?+

No. Comparten la idea de un grupo entero trabajando en una cosa al mismo tiempo. Un mob de programación escribe código en conjunto, en un solo teclado. Un mob de elaboración toma decisiones en conjunto mientras la IA escribe, y termina antes de que exista código.

¿Mob Elaboration puede ser remoto o asíncrono?+

Sí. La sesión funciona bien en una llamada con pantalla compartida. Partes de ella pueden ser asíncronas: los ingenieros responden las preguntas técnicas por su cuenta y producto responde las de negocio cuando lo llaman. Lo que no se puede saltar es que cada respuesta termine en el archivo de preguntas.

¿Mob Elaboration reemplaza al sprint planning?+

Reemplaza al refinamiento y cambia el planning. El planning sigue eligiendo en qué trabajar después. Mob Elaboration decide cómo se comporta ese trabajo. La mayoría de los equipos encuentra que Kanban encaja mejor que los sprints de dos semanas cuando el trabajo llega en porciones de horas o días.

A dónde ir ahora

Mob Elaboration es donde AI-DLC se paga o se vuelve teatro. El agente es bueno haciendo preguntas. El ritual solo funciona si las responden las personas correctas, a un ritmo que les permita leer de verdad lo que aprueban. Prepara la sesión, mantenla corta y escribe cada decisión.