Dos semanas después de la sesión de Mob Elaboration que describí en mi publicación anterior, el mismo equipo de servicios financieros se sentó para su primera sesión de Mob Construction. Contaban con una especificación validada: doce historias de usuario con criterios de aceptación, un modelo de dominio con niveles de verificación, requisitos no funcionales con umbrales medibles, y un registro de riesgos que incluía las restricciones regulatorias que habían revelado durante la elaboración.

La IA generó la primera implementación del modelo de dominio en menos de diez minutos. Un desarrollador lo revisó y dijo: «Esto en realidad encaja con la lógica de negocio.» Esa reacción te dice todo sobre el estado del desarrollo asistido por IA. «Esto realmente encaja» fue una sorpresa, porque todas las experiencias previas con código generado por IA habían enseñado al equipo a esperar resultados plausibles que no daban en el clavo. La diferencia no era un modelo mejor. Estaban usando la misma IA que llevaban meses usando. La diferencia era que la IA tenía una especificación que valía la pena ejecutar.

Una semana antes, un equipo diferente pidió a la misma IA que construyera un servicio interno de alertas para incidentes operativos. Sin proceso estructurado, sin especificaciones validadas. El prompt era de dos párrafos. La IA generó un servicio completo en cuarenta minutos: endpoints de la API, esquema de la base de datos, plantillas de alerta, configuración de despliegue. Se compilaba, las pruebas pasaban y el equipo lo enviaba a stagging.

Tres días después, descubrieron que el servicio no tenía concepto de preferencias de enrutamiento de alertas. Los ingenieros no podían suprimir alertas de sistemas de los que no eran responsables. El equipo de guardia lo señaló. La reestructuración duró dos semanas, más de lo que habría llevado construirla desde cero, porque la IA había generado una arquitectura coherente a partir de supuestos erróneos, y cada capa tuvo que desmontarse.

Si asocias ese fracaso a las cuatro etapas que describo a continuación, las lagunas se hacen evidentes. La ausencia de modelado de dominio significaba que el concepto de preferencias de enrutamiento de alertas nunca surgió como entidad de negocio; la IA infirió un modelo más sencillo y nadie lo detectó. La ausencia de registros de decisiones de arquitectura significaba que la suposición de que todos los ingenieros recibían todas las alertas nunca se documentaba ni debatía; era simplemente lo que generaba la IA. Sin validación estructurada, las pruebas confirmaron que el código funcionó tal y como se construyó, no que funcionara como se esperaba. Cada laguna que habría detectado un proceso de construcción estructurado se convirtió en dos semanas de retrabajo porque nada en el flujo de trabajo obligaba al equipo a parar a verificar.

Misma IA, mismo nivel de equipo, metodología diferente y resultados radicalmente distintos.

El problema del cemento rápido

La IA genera código a una velocidad que crea un modo de fallo específico que he empezado a llamar quick-cement. La salida se solidifica antes de que nadie verifique que es correcta.

En el desarrollo tradicional, el código se acumula gradualmente. Un desarrollador escribe una función, la prueba, y escribe la siguiente. Hay puntos de pausa naturales donde se cuestionan las suposiciones. El ritmo de la escritura humana crea fricciones que también funcionan como tiempo de reflexión. Cuando algo parece mal, el desarrollador se detiene y lo reconsidera.

La IA elimina esa fricción. Un modelo de dominio, un diseño lógico, un módulo completo con pruebas: todo generado en minutos. Cada artefacto parece pulido. Cada uno es internamente coherente con los anteriores. El equipo revisa cuidadosamente el primer artefacto, lo aprueba y sigue adelante. En el tercer artefacto, aprueban más rápido, no porque haya mejorado la calidad, sino porque la consistencia crea confianza en que todo encaja.

Entonces alguien encuentra un error en los límites del modelo de dominio. Ese error ahora está incrustado en el diseño lógico, el código, las pruebas y la configuración de infraestructura. Cada capa de aprobación que pasaba sin detectarla hacía que el error fuera más caro de corregir.

Esta es la versión en fase de construcción de un principio de desarrollo Lean de software identificado hace décadas: los costes de defectos se duplican aproximadamente con cada nivel que avanzan. Mary y Tom Poppendieck lo calificaron como «calidad de construcción desde el principio.» La IA comprime tanto el calendario que un error de requisitos puede propagarse por el diseño, el código, las pruebas y el despliegue en una sola tarde. La duplicación sigue vigente; Simplemente ocurre más rápido.

Mob Construction está diseñado en torno a este problema. Cuatro etapas, ejecutadas en secuencia, con validación humana en cada etapa actuando como lo que la metodología AI-DLC llama función de pérdida. El término proviene del aprendizaje automático, donde una función de pérdida mide hasta qué punto la salida del modelo se desvía de la respuesta correcta. En Mob Construction, cada punto de control mide hasta qué punto el artefacto de la IA se desvía de la intención validada del equipo y detecta la desviación antes de que se propague río abajo.

La capa de gobernanza subyacente

Antes de describir las cuatro etapas, existe una base que da forma a todo lo que la IA genera en todas ellas: la Especificación de Protección Empresarial, o EGS. En la sesión de servicios financieros, el EGS significaba que la IA conocía los requisitos de cifrado de la PII y las restricciones regulatorias antes de que nadie las mencionara durante la construcción; ya formaban parte de su contexto. El EGS es un documento que se mantiene como código junto al proyecto que define los principios, restricciones y estándares innegociables que cada sesión debe cumplir.

El EGS cubre las líneas base de seguridad, restricciones de cumplimiento, lineamientos arquitectónicos, estándares de codificación, preparación operativa, salvaguardas de costes y normas específicas de IA. Cada regla tiene un nivel de gravedad: obligatorio (la infracción bloquea el Bolt), requerido(las excepciones requieren un ADR documentado con aceptación de riesgos) o recomendado (buenas prácticas, desviación señalada pero no bloqueada). Se instruye a la IA para validar cada artefacto que genere frente a las barreras antes de presentarlo al equipo, señalar cualquier conflicto entre un diseño propuesto y una barrera de seguridad, y proponer una alternativaque cumpla von las restricciones .

Esto cambia la dinámica de la construcción de una manera difícil de apreciar hasta que la ves. En el caso de preferencias de notificaciones al cliente que describo en Reimagine, Don’t Retrofit, el EGS especificaba los requisitos de manejo de PII. Durante Mob Elaboration, la IA marcó el cifrado en reposo para los datos de preferencias desde el principio, porque la barrera de seguridad formaba parte de su contexto. Luego, durante Mob Construction, esa barrera siguió moldeando cada artefacto: la IA aplicaba cifrado a nivel de campo para las PII en el código generado, los eventos del dominio llevaban marcas de tiempo de consentimiento para fines de auditoría, y la configuración de la infraestructura incluía cifrado KMS en reposo. El equipo validó todo esto en el mismo Bolt, no en una revisión de cumplimiento semanas después. En el modelo tradicional de sprint para la misma función, el requisito de cifrado del RGPD apareció durante una revisión de cumplimiento tres semanas después de iniciar el desarrollo, lo que desencadenó una reestructuración que consumió casi un sprint completo.

Wells refleja bien el principio en Enabling Microservice Success (2024): las barreras de seguridad deberían ser «un sustituto para una conversación con un experto, evitando la necesidad de coordinación con personas externas al equipo.» En Mob Construction, el EGS es exactamente eso. Los requisitos del equipo de seguridad, las interpretaciones del equipo de cumplimiento, los estándares del equipo de arquitectura: todo codificado en un documento que la IA consulta en cada etapa. El experto en seguridad no necesita estar presente en la sala de cada Bolt, porque su experiencia está integrada en las barreras que la IA impone.

La visión más profunda, que exploro en profundidad en el capítulo 10 del libro, es que el proceso de creación del EGS suele ser más valioso que el propio documento. Obliga al equipo de seguridad, al equipo de cumplimiento, al equipo de arquitectura y al equipo de desarrollo a reunirse juntos en una sala, a veces por primera vez. Descubren requisitos que los desarrolladores nunca han visto, interpretaciones de regulaciones con las que los arquitectos discrepan y limitaciones prácticas que el equipo de seguridad no ha tenido en cuenta. Ese entendimiento compartido se convierte en la base de cada sesión de construcción que sigue. El EGS convierte el cumplimiento de una fase en una propiedad de generación.

Cuatro etapas, cuatro puntos de control

El ritual se desarrolla a través de cuatro etapas. Cada uno tiene un propósito específico, una salida concreta y una condición de salida que el equipo debe cumplir antes de avanzar. No se salta ninguna etapa, por muy confiado que se sienta el equipo.

Etapa 1: Modelado de dominios

Valida que la estructura del software representa correctamente el negocio antes de tomar decisiones técnicas.

La IA toma las historias validadas y el modelo de dominio de Mob Elaboration y genera el modelo de dominio a nivel de implementación: entidades, objetos de valor, raíces agregadas, eventos de dominio y las relaciones entre ellos. Esto es lógica de negocio modelada como estructura de software, independiente de cualquier decisión de infraestructura.

El trabajo del equipo es verificar que el modelo representa correctamente al negocio, no solo que compile o que sea internamente consistente, sino que coincide con cómo funciona realmente el negocio.

En la sesión de servicios financieros, la IA generó un modelo de dominio que incluía correctamente los niveles de verificación, el concepto que el equipo había surgido durante la elaboración. Pero había modelado la relación entre el cliente y el nivel de verificación como uno a uno. Un desarrollador senior lo detectó: «Un cliente puede estar en diferentes niveles para distintos tipos de producto. Un cliente verificado para cuentas básicas puede no estar verificado para productos de inversión.» La IA ajustó el modelo en dos minutos. Si ese error hubiera llegado a la generación de código, habría requerido reestructurar el esquema de la base de datos, los contratos de la API y todos los servicios que tocaban la verificación del cliente.

Cuando varios equipos trabajan en diferentes Unidades en la misma sesión, esta etapa incluye algo que la programación de IA en solitario nunca produce: el intercambio de contratos. El Equipo A comparte sus definiciones de entidades con el Equipo B si sus Unidades tienen dependencias. El facilitador fuerza este intercambio antes de que ningún equipo avance a Diseño Lógico. Los conflictos se resuelven aquí, cuando el coste del cambio es una conversación, no una carrera de refactorización. Como argumentan Ford y Richards en Software Architecture: The Hard Parts (2022), «Documentar una decisión es importante para un arquitecto, pero gobernar el uso de la decisión es un tema aparte.» En Mob Construction, la gobernanza ocurre en tiempo real, con las personas que entienden el negocio en la sala.

Etapa 2: Diseño lógico

Documenta cada decisión arquitectónica y sus trade-offs antes de que la IA genere una sola línea de código.

La IA traduce el modelo de dominio validado en arquitectura técnica: patrones de diseño, selección de servicios, decisiones de infraestructura. Cada decisión se documenta como un Registro de Decisión de Arquitectura antes de que el equipo pase al código. El papel del facilitador aquí es insistir: cuando la IA propone un servicio y el equipo asiente, el facilitador pregunta: «¿Por qué esto en vez de la alternativa? Documenta el intercambio.»

Los ADR no son nuevos. Michael Nygard propuso el concepto en 2011 y, como documenta Read en Communication Patterns (2023), se han convertido en una práctica eficaz para captar no solo lo que se decidió, sino también el porqué. Ford y Richards dedicaron un capítulo entero a las ADR en Fundamentals of Software Architecture (2021), argumentando que «la sección de Decisión describe las razones por las que se toma una decisión concreta, que es, con diferencia, la mejor forma de documentación de arquitectura.»

Lo nuevo es hacer obligatorios los ADR antes de que la IA genere una sola línea de código.

Cuando la IA propone Lambda en lugar de ECS, el equipo no solo aprueba o rechaza. Documentan por qué: el patrón de carga de trabajo es variable, la latencia de arranque en frío es aceptable para este caso de uso, el modelo de coste favorece el pago por invocación en el volumen proyectado. Cuando alguien dentro de seis meses pregunte por qué el servicio usa Lambda, la respuesta no es «la IA lo eligió» o «simplemente lo aceptamos». La respuesta es un análisis documentado de compensación que el equipo debatió y aprobó.

Aquí es donde veo el contraste más marcado con la codificación de IA no estructurada. Un desarrollador que trabaja solo con un asistente de IA consigue que las decisiones de arquitectura se tomen implícitamente. La IA elige una base de datos, un servicio de cómputo, una estrategia de caché. El desarrollador las acepta o cambia según el instinto. No se ha registrado las alternativas consideradas, ni documentación de los sacrificios, ni rastro del razonamiento. Seis meses después, otro desarrollador hereda la base de código y no tiene ni idea de por qué se eligió DynamoDB en lugar de Aurora, ni si la elección sigue teniendo sentido dado cómo evolucionó la carga de trabajo.

Un hilo de Reddit lo resumió con precisión: «¿Estamos perdiendo el código del ‘por qué’ que existe?» (r/ExperiencedDevs, abril de 2026). El código generado por IA no lleva el razonamiento. Las decisiones se dispersan entre comentarios en pull requests, hilos de Slack, registros de conversación de IA. El coste real, como dijo un comentarista, «aparece seis meses después cuando alguien necesita modificar ese código y no tiene ningún contexto.» Los ADRs escritos durante la Construcción de Mob resuelven esto haciendo que el razonamiento sea un artefacto explícito y versionado que convive junto al código.

Etapa 3: Generación de código

Genera código ejecutable solo después de que el modelo y la arquitectura del dominio hayan sido validados y documentados.

Solo ahora la IA genera código ejecutable. Cuenta con un modelo de dominio validado, decisiones arquitectónicas aprobadas documentadas como ADRs y requisitos no funcionales con umbrales medibles. El espacio generacional está restringido. La IA implementa lo que el equipo ya ha decidido, en lugar de inferir la intención a partir de un prompt de dos párrafos.

El equipo revisa el código generado para comprobar su calidad, seguridad y mantenibilidad. La tarea del facilitador en esta etapa es evitar aprobaciones automáticas. «Cuéntame qué hace este módulo» es la pregunta que separa una revisión genuina de echar un vistazo a un código que parece limpio.

En esta etapa ocurren dos cosas que casi nunca ocurren en la programación de IA no estructurada.

Primero, Infraestructura como Código se genera junto con el código de la aplicación, no como algo posterior. La IA produce configuraciones de CloudFormation, CDK o Terraform que coinciden con las decisiones arquitectónicas de la Etapa 2. La infraestructura vive en la misma sesión de construcción, revisada por las mismas personas que entienden la lógica de la aplicación. Cuando el equipo eligió Lambda en la Etapa 2, el IaC en la Etapa 3 refleja esa elección con la asignación correcta de memoria, ajustes de tiempo de espera y permisos IAM. Cuando documentaron una latencia NFR inferior a 200 milisegundos, la configuración de la infraestructura incluye la monitorización y alerta que la harán cumplir.

Segundo, la revisión de seguridad ocurre durante la generación, no después. Validación de entrada, permisos IAM, configuración de cifrado: estos se revisan a medida que se genera el código, no se descubren en un escaneo de seguridad semanas después. El EGS hace que esto sea estructural en lugar de aspiracional: cuando las barreras especifican «no hay permisos comodines en las políticas de identidad para cuentas de producción», la IA genera por defecto roles IAM de menor privilegio, y el equipo los valida en la misma sesión. Esta es la realidad operativa de lo que la Seguridad como Limitación de Desarrollo argumentaba conceptualmente: la seguridad como una restricción de desarrollo, incrustada en el proceso de construcción en lugar de añadida como una puerta.

Fase 4: Prueba y validación

Verifica que el código cumpla con lo que el negocio pretendía, no solo lo que hace la implementación.

La IA genera y ejecuta tres categorías de pruebas: funcionales, de seguridad y de rendimiento. El equipo valida que las pruebas son significativas, no solo aprobadas.

«Significativo» es la palabra clave. Las pruebas generadas por IA tienen un modo de fallo específico: prueban lo que hace el código, no lo que el código debería hacer. Una suite de pruebas que logra una cobertura del 90% probando la implementación en lugar de los requisitos da falsa confianza. El facilitador asigna las pruebas a los criterios de aceptación de las historias originales: «Esta historia dice que los clientes en Nivel 3 requieren aprobación manual. ¿Dónde está la prueba para eso?»

El cumplimiento contractual es un obstáculo en esta etapa. El contrato API definido en la Etapa 2 es la fuente de la verdad. Si las respuestas del backend, las llamadas de frontend o los mocks de prueba no coinciden con el contrato, el Bolt no se cierra. Esto detecta errores de integración que de otro modo surgirían semanas después cuando los equipos intentan conectar sus Unidades.

A estas alturas, el patrón debería quedar claro: la Construcción de Mob no ralentiza la IA. Ralentiza el compromiso para la validación del alineamiento. Cada etapa existe porque el coste de detectar un error allí es una fracción del coste de detectarlo una etapa después. Los cuatro puntos de control no son burocracia; Son el mecanismo que impide que el cemento rápido se asiente antes de que alguien verifique que la base está sólida. La construcción de mob es un sistema de restricciones para la construcción asistida por IA, no una práctica de programación.

El cerrojo como time-box

Cada paso por las cuatro etapas se asigna a un Bolt: aproximadamente un día de trabajo de construcción enfocado. Una Unidad puede requerir dos o tres Bolts para completarse. Los Independent Bolts pueden funcionar en paralelo cuando hay varios subequipos disponibles.

El time-box cumple dos propósitos. Evita el aumento de alcance: si una historia no encaja en el Bolt actual, pasa a la siguiente en lugar de ampliar la sesión. Y mantiene la energía del equipo. La construcción de mob es cognitivamente exigente. La combinación de artefactos generados por IA y validación en tiempo real requiere atención sostenida. Tras ocho horas, el escrutinio se degrada independientemente de lo disciplinado que sea el equipo. Es mejor cerrar un Bolt con tres módulos completamente validados que avanzar cinco módulos con una calidad de revisión decreciente.

Un hilo de Reddit de un responsable de ingeniería capturó el problema desde el otro lado: «Las funcionalidades que tardaron un sprint ahora tardan uno o dos días, pero nuestro lanzamiento se retrasó tres semanas porque la validación no pudo seguir el ritmo» (r/EngineeringManagers, abril de 2026). El equipo había construido una estrategia de productividad sin una estrategia de calidad que la igualara. La estructura de Bolt es la estrategia de calidad: limita el ritmo de generación al ritmo de la validación significativa.

Lo que descubren los equipos

Las fases describen la mecánica. Lo que sorprende a los equipos es lo que revelan las mecánicas.

Los ADRs sacan a la luz desacuerdos que el equipo no sabía que tenía. Cuando la IA propone una arquitectura y el equipo tiene que documentar por qué la aceptó, las suposiciones ocultas chocan. «Supuse que usaríamos una cola de mensajes aquí.» «Supuse que usaríamos llamadas API directas.» Sin el requisito de ADR, ambas suposiciones habrían sobrevivido hasta que las pruebas de integración revelaran el conflicto. La ADR fuerza la conversación cuando el coste de la resolución es un debate de quince minutos, no un esfuerzo de refactorización de dos semanas.

Generar IaC junto con los cambios en el código de la aplicación, quién es el responsable del despliegue. Los equipos esperan que la infraestructura sea problema de otra persona. Cuando el desarrollador que revisó la función Lambda también revisa el rol IAM que rige sus permisos en el mismo Bolt, la brecha entre «funciona localmente» y «funciona en producción» se desvanece. El cambio de propiedad es la sorpresa: los desarrolladores dejan de considerar la infraestructura como una preocupación separada porque el proceso de construcción nunca la separó.

La fatiga por aprobación es medible, y el facilitador es el instrumento que la mide. He visto a equipos dedicar veinte minutos a debatir rigurosamente el primer modelo de dominio, y luego aprobar el tercero en cuatro minutos. La intervención del facilitador: «Estamos aprobando más rápido. ¿Es porque la calidad mejoró, o porque estamos cansados?», ha detectado errores reales en cada sesión que he facilitado. El modelo de rotación progresiva significa que esta capacidad se transfiere al equipo durante seis a ocho sesiones. En la novena sesión, los miembros del equipo detectan su propio cansancio sin que se les pida.

La planta de construcción cambió

La comunidad de desarrolladores está convergiendo de forma independiente en la idea de que la generación de código por IA sin estructura genera deuda técnica más rápido que cualquier equipo humano. Un desarrollador senior en Reddit lo describió sin rodeos: «Rescatar proyectos desafiantes era mi nicho, pero las bases de código de IA me están haciendo infeliz» (r/ExperiencedDevs, abril 2026). El código generado por IA que carece de intención arquitectónica humana crea una nueva categoría de deuda que es más difícil de rescatar que el código heredado tradicional, porque no hay razonamiento que rastrear, ni decisiones que entender, ni «por qué» detrás del «qué».

Mob Construction aborda esto asegurándose de que el «por qué» exista antes de que se genere el «qué». El modelo de dominio captura la lógica de negocio, los ADRs capturan el razonamiento arquitectónico, los NFRs capturan las expectativas de calidad y las pruebas capturan los criterios de aceptación. Cuando el siguiente desarrollador hereda esta base de código, o cuando el equipo original la revisa tras otros tres proyectos, no solo hereda el código, sino la cadena documentada de decisiones que lo produjo.

Mob Elaboration mostró lo que ocurre en la sala de requisitos: cómo los equipos transforman intenciones vagas en especificaciones precisas. Esta publicación muestra lo que ocurre cuando esas especificaciones llegan al suelo de construcción: cómo cuatro etapas de generación y validación estructuradas producen código que la IA no podría haber producido solo con un prompt. Juntos, operacionalizan el cambio de la codificación vibe al desarrollo basado en especificaciones que la metodología pretendía permitir.

La industria está invirtiendo miles de millones para resolver la calidad del código de IA con mejores modelos. Este equipo lo resolvió con mejores restricciones. El modelo, los tokens, la configuración de temperatura: todo idéntico entre el prompt de dos párrafos y la especificación validada. Lo que cambió fue la metodología, el proceso de construcción y la relación del equipo con la producción de la IA. El resto de la industria sigue esperando el lanzamiento del próximo modelo. Estos equipos se entregaron la semana pasada.

Ricardo