La primera vez que facilité una sesión de Mob Elaboration, el Product Owner leyó en voz alta la Intención: un nuevo flujo de incorporación de clientes para una plataforma de servicios financieros. En cuatro minutos, la IA había generado doce user stories, criterios de aceptación para cada una, un modelo de dominio propuesto y una descomposición en tres unidades de trabajo independientes.

Un desarrollador senior se quedó mirando la pantalla y no dijo nada durante unos diez segundos. Luego: «La mitad de estos están mal.»

Tenía razón. La IA generó un conjunto limpio y coherente internamente de historias que pasó por alto por completo la restricción regulatoria que regula cómo funciona la verificación de identidad del cliente en esa jurisdicción. El modelo de dominio no tenía concepto de niveles de verificación. Los criterios de aceptación asumían una única vía de aprobación donde la empresa realmente requería tres, dependiendo del perfil de riesgo del cliente.

Lo interesante no era que la IA se equivocara. Lo interesante fue lo que ocurrió después. El equipo pasó los siguientes noventa minutos haciendo algo que nunca habían hecho en una sesión de planificación tradicional: interrogaron sistemáticamente cada suposición que la IA había hecho, sacaron a la luz conocimientos de dominio que llevaban años viviendo en la cabeza de las personas y produjeron una especificación más precisa que cualquier cosa que hubieran escrito antes.

Esa sesión cambió su forma de pensar sobre los requisitos. Además, se lanzó tres semanas antes de la estimación original, porque el equipo pasó noventa minutos discutiendo sobre la especificación en lugar de tres sprints descubriendo que era errónea.

El cambio: Por qué los requisitos tradicionales se rompen cuando la IA se ejecuta

Durante décadas, los requisitos se han redactado con una suposición implícita: un desarrollador humano los leerá, rellenará los vacíos con juicio, hará preguntas aclaratorias cuando algo sea ambiguo y tomará decisiones razonables sobre casos límite. Los requisitos podían permitirse ser imprecisos porque la persona que los ejecutaba compensaría.

La IA no compensa, ejecuta. Cuando escribes «el sistema debe manejar los casos límite con elegancia» para un desarrollador humano, saben que deben preguntar cuáles son los casos límite. Cuando un agente de IA interpreta el mismo requisito, genera código que gestiona los casos límite que infiere del contexto, que pueden o no parecerse a los que importan a tu empresa. Los requisitos ya no son solo un artefacto de comunicación entre personas. Se están convirtiendo en una entrada ejecutable: cuanto más cerca estén del código en precisión, más predecible se vuelve el sistema.

Este es el cambio que la comunidad de desarrolladores ya está descubriendo de forma independiente. La especificación es lo único que limita lo que la IA va a fallar con confianza. Pero la propia especificación necesita un proceso diferente cuando la IA es tanto el consumidor como el autor del primer borrador.

Hunt y Thomas lo expresaron bien en The Pragmatic Programmer: «El mundo real es caótico, conflictuado e incógnito. En ese mundo, las especificaciones exactas de cualquier cosa son raras, si no directamente imposibles. Ahí es donde entramos los programadores. Nuestro trabajo es ayudar a la gente a entender lo que quiere.» Cuando el desarrollador es un agente de IA, ese trabajo se convierte en toda la propuesta de valor de la sala de requisitos. Como advierte Coding with AI (2025): «Sin requisitos precisos y bien definidos, las herramientas te ayudarán a construir un mal proyecto más rápido.» La velocidad que hace valiosa a la IA es la misma que hace peligrosa la ambigüedad.

Mob Elaboration (elaboración en multitud) es el ritual que estructura esta conversación: el proceso mediante el cual un equipo transforma una intención empresarial vaga en una especificación lo suficientemente precisa para que un agente de IA la ejecute correctamente.

El ritual en acción

Una sesión dura entre dos y cuatro horas con cinco a ocho personas: el Product Owner, dos o tres desarrolladores, un representante de QA y el facilitador. La IA es un participante, no una herramienta que se ejecuta en segundo plano. El facilitador gestiona la interacción entre el equipo y la IA, aplicando la disciplina del tiempo y desafiando tanto las suposiciones humanas como los artefactos generados por la IA.

La sesión se desarrolla a través de cinco fases, cada una con un propósito específico y una condición clara de salida.

La Aclaración de Intención abre la sesión. El Product Owner lee en voz alta una declaración de Intención de una a tres frases. La IA hace preguntas aclaratorias. El trabajo del facilitador en esta fase es asegurarse de que la IA haga preguntas lo suficientemente profundas y que el equipo responda con contexto real, no con abstracciones. En una sesión, un PO describió la intención como «automatizar el flujo de trabajo de aprobación de facturas». Las tres primeras preguntas de la IA eran genéricas. El facilitador insistió: «Pregunta por las excepciones.» Esa única redirección dio lugar a un proceso manual de anulación que gestionaba aproximadamente un tercio de todas las facturas y que nadie había mencionado porque «simplemente lo hacemos nosotros». Cuando las preguntas de la IA se vuelven repetitivas, el valor marginal del contexto adicional ha disminuido. Esta fase suele durar entre quince y treinta minutos, y saltársela es la causa más común de fallo en la sesión.

Story Generation sigue a continuación. La IA genera historias de usuario con criterios de aceptación basados en la intención aclarada. El facilitador lee cada historia en voz alta junto con el equipo. El Product Owner confirma si cada historia coincide con su expectativa; Los desarrolladores confirman si cada historia es construible. El peligro aquí es aprobarlo sin escrutinio: aprobar la salida de la IA sin escrutinio porque parece pulida y coherente internamente. La consistencia no es la corrección. Un equipo sanitario aprobó una descomposición limpia de programación de citas sin darse cuenta de que el modelo no tenía concepto de los tipos de cita; las visitas presenciales, la telemedicina y las citas de laboratorio tenían reglas de programación diferentes que la IA había reducido silenciosamente en una sola.

Los grupos de la División de Unidad validaron las historias en unidades de trabajo independientes y de tamaño equipo. La pregunta clave es la dependencia: ¿se puede construir la Unidad A sin esperar a la Unidad B? Si no, la división es errónea. Las dependencias ocultas entre unidades son la segunda fuente más común de rework.

El análisis de riesgos y NFR es la fase que la mayoría de los equipos quiere saltarse y que menos puede permitirse. El facilitador insiste en al menos tres riesgos identificados y requisitos no funcionales medibles antes de continuar. «Debería ser rápido» no es un NFR. «Tiempo de respuesta inferior a 200 ms en el percentil 95» es. En una sesión, el equipo intentó superar esta fase en cinco minutos. El facilitador sostuvo la sala: «¿Qué pasa si este servicio se cae durante las horas punta?» Silencio. Entonces el arquitecto dijo: «No tenemos un plan B.» Esa conversación añadió cuarenta minutos a la sesión y salvó al equipo de desplegar un servicio sin ruta de degradación. El plan B que diseñaron en esa sala habría tardado dos semanas en adaptarse tras el lanzamiento. Esta fase también define cómo sabrá el equipo que la Intención ha tenido éxito, qué métricas se mueven.

Planificación de Pernos cierra la sesión dividiendo las unidades en bloques de ejecución con caja de tiempo, cada uno con un alcance aproximado de un día de trabajo de Construcción de Mafias. El equipo identifica qué tornillos pueden funcionar en paralelo, asigna la propiedad y se compromete con una línea temporal.

La sesión termina con un resumen, confirmación de la orden de venta y una fecha programada para la primera sesión de Construcción de la Mafia.

Lo que descubren los equipos

Tres patrones emergen de forma constante a lo largo de las sesiones, independientemente del sector o del tamaño del equipo.

Las historias se vuelven más precisas que cualquier cosa que el equipo haya escrito antes. La combinación de primeros borradores generados por IA y validación humana sistemática produce especificaciones que son simultáneamente más detalladas y más precisas que las historias de usuario tradicionales. La IA fuerza la completitud generando criterios de aceptación para cada historia. El equipo fuerza la corrección desafiando cada suposición. Ninguno de los dos pudo producir el resultado por sí solo. Como argumenta Vlad Khononov en Learning Domain-Driven Design, «DDD consiste en dejar que tu dominio empresarial impulse las decisiones de diseño de software.» Mob Elaboration lo operacionaliza: los expertos del dominio están en la sala, la IA plantea las preguntas y el facilitador se asegura de que las respuestas se capturen.

Los modelos de dominio se vuelven explícitos antes. En el desarrollo tradicional, los modelos de dominio surgen gradualmente a través del código. Las suposiciones implícitas sobre cómo funciona el negocio se codifican en jerarquías de clase, esquemas de bases de datos y contratos de API, a menudo de forma inconsistente entre diferentes partes del sistema. Schwentner describe este problema con precisión en Domain-Driven Transformation (2025): la ingeniería clásica de requisitos funciona como un juego telefónico, con entrevistas realizadas por separado y requisitos derivados de forma aislada, lo que lleva a malentendidos que se acumulan a lo largo del sistema. Los métodos de modelado colaborativo resuelven esto reuniendo a personas de negocios y técnicas para intercambiar ideas directamente. En el ritual, la IA genera un modelo de dominio explícito durante la generación de la historia. El equipo lo ve, debate y lo corrige antes de que exista una sola línea de código. Las decisiones que el ágil tradicional pospone hasta que se vuelven caras de cambiar se toman cuando son baratas de cambiar.

Los equipos detectan suposiciones arquitectónicas que habrían pospuesto. El primer borrador de la IA es un espejo. Refleja lo que el equipo le contó, incluyendo los huecos. Cuando el equipo de servicios financieros vio el modelo de dominio de la IA sin niveles de verificación, no añadieron simplemente el concepto que faltaba. Se dieron cuenta de que llevaban años llevando una suposición implícita sobre la verificación de identidad, una que nunca se había escrito porque todo el mundo «simplemente lo sabía». Como observa Hohpe en The Software Architect Elevator (2020), el conocimiento tácito «solo existe en la cabeza de los empleados pero no está documentado ni codificado en ningún sitio», y codificarlo en artefactos explícitos «elimina reglas no escritas y variaciones no deseadas.» La incapacidad de la IA para leer mentes obligó al equipo a hacer explícito su conocimiento.

Estos descubrimientos no son accidentales. Son consecuencias estructurales del diseño del ritual: la IA propone, los humanos validan, el facilitador impone rigor. La combinación produce artefactos que ninguna de las partes podría producir de forma independiente.

El papel del facilitador

El facilitador no es un gestor de proyecto, ni un Scrum Master, ni un líder técnico. El facilitador gestiona la conversación entre el equipo y la IA, y esa conversación tiene modos de fallo para los que la facilitación tradicional no te prepara.

El modo de fallo más peligroso es la fatiga por aprobación. Los artefactos generados por IA son internamente coherentes: las historias se alinean con el modelo de dominio, el diseño lógico se deduce del modelo de dominio, el código implementa el diseño lógico. Esa consistencia crea una falsa sensación de corrección. Todo encaja, así que debe ser lo correcto. Wells describe el mecanismo subyacente en Enabling Microservice Success (2024) a través de la teoría de la carga cognitiva: los equipos tienen una capacidad finita para la carga cognitiva pertinente, del tipo que produce una comprensión real. Cada artefacto generado por IA que revisa el equipo consume esa capacidad. Para el tercer o cuarto modelo, la capacidad del equipo para examinar genuinamente está agotada, pero los artefactos siguen apareciendo. Lo vi en tiempo real: un equipo pasó veinte minutos debatiendo rigurosamente el primer modelo de dominio que produjo la IA, detectó dos errores y se sintió bien con su diligencia. Para el tercer modelo, ya lo llevaban asentiendo en cuatro minutos. El facilitador detuvo la sala: «Estamos aprobando más rápido. ¿Es porque la calidad ha mejorado o porque estamos cansados?» Era lo segundo. Encontraron una entidad desaparecida en el modelo que estaban a punto de aprobar. El trabajo del facilitador es romper periódicamente el marco interno: «Olvida lo que generó la IA. Por lo que sabes de este negocio, ¿falta algo o está mal?»

El segundo modo de fallo son los puntos ciegos de dominio. El equipo valida lo que propone la IA sin preguntar qué IA omitió. La IA se descompone en función de la información que tiene; No sabe lo que no sabe. El facilitador debe preguntar explícitamente al final de cada fase: «¿Qué falta en este modelo? ¿Qué reglas de negocio no están representadas aquí?»

El tercero es el problema de la voz más fuerte, amplificado por la IA. Cuando la IA genera un primer borrador, la persona que habla primero sobre él es el punto de apoyo a la evaluación del equipo. El facilitador gestiona la participación: observaciones escritas antes de la discusión en grupo, rotación explícita de quién dirige la revisión, preguntas dirigidas a los miembros del equipo más callados.

Esta es una habilidad emergente de liderazgo. Adkins escribió en Coaching Agile Teams que «el coach crea el contenedor; el equipo crea el contenido.» En Mob Elaboration, el facilitador crea el contenedor para una conversación que no existía antes de que la IA entrara en la sala. El contenido, la especificación validada, surge de la colisión entre la velocidad de la IA y el conocimiento del dominio del equipo.

El objetivo no es un papel permanente de facilitador. Tras seis u ocho sesiones, el equipo debería asimilar la capacidad. El éxito del facilitador se mide por la rapidez con la que se vuelve innecesario.

La sala de requerimientos no desapareció

La comunidad de desarrolladores está convergiendo de forma independiente en la especificación previa a la generación, la separación de roles y las puertas de calidad. Lo que les falta es la dimensión de equipo facilitado.

Los desarrolladores en solitario que construyen pipelines de tres agentes están resolviendo el problema adecuado a nivel individual. Pero una especificación escrita por una persona, incluso una experta, lleva consigo las suposiciones y puntos ciegos de esa persona. Mob Elaboration funciona precisamente porque es un ritual de equipo: el Product Owner aporta la intención de negocio, los desarrolladores aportan las restricciones técnicas, QA aporta los escenarios de fallo y la IA aporta velocidad y completitud. El facilitador se asegura de que ninguna de estas perspectivas se pierda. Como documenta Helfand en Dynamic Reteaming (2020), la programación de la multitud crea una «memoria de grupo» donde «el contexto se construyó a partir de las comunicaciones que habíamos tenido todo el día.» En Mob Elaboration, ese contexto compartido no solo ayuda al equipo; se convierte en la especificación que ejecuta la IA.

La sala de requerimientos no ha desaparecido. Se ha convertido en la sala más importante del edificio, porque la calidad de lo que sale de esa sala determina la calidad de todo lo que la IA produce aguas abajo. Una intención vaga produce historias vagas, que producen código vago, que producen errores vagos que son caros de diagnosticar y costosos de corregir. Una intención precisa, refinada mediante la elaboración estructurada del equipo, produce especificaciones que los agentes de IA pueden ejecutar correctamente a la primera.

El cuello de botella en el desarrollo impulsado por IA nunca fue la generación de código. Siempre fue la definición de la intención. La diferencia ahora es que la ambigüedad no te frena; se acumula al instante, porque la IA generará con confianza a partir de lo que tenga. Mob Elaboration es cómo los equipos eliminan esa ambigüedad antes de que la primera línea de código lo haga caro.

Ricardo