La IA no funciona sin un modelo de dominio

Tomás Ruiz, Solutions Architect en Agility, sostiene en esta charla de Nerdearla 2026 que el problema de la IA generativa en el desarrollo de software no es la herramienta, sino el sistema en el que la metemos. Su propuesta: en lugar de darle a los agentes especificaciones cada vez más detalladas, darles un modelo de dominio estructural, construido con Domain-Driven Design y Event Storming, que se traduzca a código de forma determinística.

La promesa y los números

Ruiz abre con un estudio de 2025 (la lámina cita METR, arXiv:2507.09089): a desarrolladores de proyectos de software libre se les preguntó cuánto esperaban aumentar su productividad usando IA en su propio repositorio. Estimaron un 20–25 %. En la práctica fueron un 19 % menos productivos.

La lámina suma otros indicadores:

El dato de Stack Overflow es el que más le interesa: la sensación generalizada de que la IA "lo hace bien, pero no exactamente bien", y de que hacerlo a mano habría sido incluso más rápido que iterar con ella.

El fallo es estructural: la bicicleta rosa

La tesis central, en palabras de Ruiz: el fallo de una LLM es estructural. Produce código sintácticamente impecable con el significado equivocado.

Para ilustrarlo plantea un ejercicio de Spec-Driven Development, la forma de trabajo más habitual hoy: una especificación muy detallada que luego pasa a implementación y revisión. La spec pide una fotografía de estudio de una bicicleta minimalista con cuadro rosa pastel, llantas, asiento y puños blancos, componentes metálicos plateados, etc.

El resultado es visualmente impecable, pero la bicicleta no sirve: le falta la pieza que va del eje trasero al cuadro, sin la cual no soportaría el peso de una persona. Es sintácticamente correcta y estructuralmente equivocada.

Detectar eso es difícil. En un PR de 8.000 líneas —hoy los PR pueden tener cualquier tamaño— hay que darse cuenta de que el cambio toca otro subdominio que quizás ni conoces.

Tesla y Fanuc: automatizar un proceso pensado para humanos

¿El problema es la herramienta? Para Ruiz, no: como cualquier herramienta, es tan eficiente como la capacidad de quien la usa. Lo ilustra con dos fábricas del mismo año.

En 2018 Tesla automatizó de punta a punta la línea de producción del Model 3. Fue un desastre: cerraron la planta, apagaron las máquinas, montaron una carpa en el estacionamiento y terminaron los autos a mano.

Mientras tanto, la fábrica de Fanuc en el monte Fuji funcionaba 100 % sin humanos desde 2001: una lights out factory, sin luz operativa, calefacción, aire acondicionado ni pasillos, porque está hecha para máquinas.

La diferencia, que Ruiz retoma más adelante: Fanuc diseñó toda su línea, sin excepción, para ser usada por máquinas; hasta las piezas que fabrica están hechas para ser ensambladas por máquinas. Tesla tomó un proceso pensado para personas e intentó automatizarlo entero.

¿Cómo sería una lights out software factory?

Nadie la ha logrado todavía, pero Ruiz imagina cómo sería sobre un tablero de Jira: un ticket en Ready for implementation se asigna a un agente, pasa solo a In Progress, el agente lo implementa en algún servidor y el ticket termina en una de dos columnas: Ready for review, con un PR listo para revisar, o Needs a human, para que alguien lo destrabe. Al final, el desarrollador a cargo lo pasa a Done.

Con más de 20 años de experiencia, Ruiz dice no conocer ningún código que haya tocado que soporte ese flujo. Pasaría una de dos cosas: o Ready for review se llena de "bicicletas rosas", o todo se estanca en Needs a human, que es el proceso manual de siempre con más ceremonia.

Desarrollar software no es solo un problema técnico

En el flujo tradicional, el mercado lo escucha alguien de negocio, que se lo pasa a producto, que se lo pasa al equipo de desarrollo, que lo convierte en código. Cada flecha es un espacio de interpretación y traducción.

Con la IA, le estamos poniendo más músculo justo a la parte que genera código, y multiplicando esas flechas. El resultado es familiar: el PR no está bien y el agente responde con un "You're absolutely right."

A eso se suma la presión desde arriba: los CEO escuchan a OpenAI y Anthropic prometer equipos 10X y compiten por velocidad. La consecuencia, según Ruiz, es que generamos más código del que podemos revisar. Tenemos un sistema que pierde resolución en cada traducción y que naturalmente decae en extensibilidad a medida que crece la complejidad accidental; usar IA para acelerarlo es acelerar contra una pared.

Diseñar el ambiente: un framework opinionado

A partir de aquí Ruiz aclara que habla desde su posición y opinión. Desarrollar software es un problema sociotécnico, y en la parte técnica el objetivo es diseñar el ambiente de modo que la decisión óptima sea también la más obvia. Toma el principio de James Clear (Hábitos atómicos) y lo considera simétrico: sirve para liderarse a uno mismo, a equipos, a hijos, a perros y a agentes.

La traducción práctica es un framework opinionado: un canal estrecho por el que canalizar toda la capacidad de producción de la IA sin el drift que genera bicicletas rosas.

• Pocas formas válidas de hacer cada cosa. Cuantas menos, mejor: menos decisiones que tomar.
• Estructura sobre convenciones. Una convención depende de la cultura, y la cultura de decisiones conscientes cada vez que alguien enfrenta el caso. La estructura, en cambio:
• se genera automáticamente,
• se valida mecánicamente,
• y si falla, falla escandalosamente.
• Un audit log de cada cambio de estado.

Dar un modelo, no una especificación

Volviendo a Fanuc: ¿y si en lugar de darle a la IA la especificación más detallada posible le damos un modelo que ya sea estructuralmente correcto, sobre el que tenemos control, y dejamos que ponga todo su poder de ejecución en llenar los espacios vacíos?

El prompt deja de ser una especificación y pasa a ser algo como: "Por favor, colorea esta imagen siguiendo los colores de la leyenda. Si le puedes dar una terminación sutilmente fotorrealista, sería mejor." El resultado sí se parece a la estructura que uno tiene en mente.

Con una bicicleta es fácil porque es tangible. El software es abstracto y muchas veces se descubre mientras se construye, así que hace falta que la estructura sea determinística.

La parte socio: acuerdo y coordinación

La parte social del problema tiene dos piezas. La primera es el acuerdo: que, en lugar de las flechas de traducción, negocio reúna a todos y señale la oportunidad, y que producto, negocio, stakeholders y desarrolladores vean lo mismo. Así cada uno ocupa su lugar: el CEO mira dos años adelante, producto enfoca el problema e ingeniería enfoca la solución. Ruiz admite que es un ideal que no siempre se logra.

La segunda es la coordinación: aun viendo lo mismo, cada uno lo mira desde su perspectiva, y eso es positivo si se aprovecha.

Para ambas usan Event Storming (la técnica de Alberto Brandolini, dentro de Domain-Driven Design). Una secuencia de stickies cuenta una historia —un usuario entra a la cafetería, pide un café, paga…— y a la vez es un modelo del negocio. Para un ingeniero, cada sticky es un cambio de estado: se establece un puente entre el lenguaje de negocio y algo implementable.

El proceso que describe:

1. Cada stakeholder cuenta por separado la historia del negocio, con su propia línea de tiempo coherente.
2. Se hace un merge sort de todas las líneas en una sola.
3. Se valida con todos, incluidos ingeniería, producto y UX.

El resultado es una narrativa acordada por toda la organización. En su experiencia, esto toma en promedio 4 horas.

Con ese lenguaje de negocio se aplica una rúbrica para trazar límites (boundaries) entre los significados de las palabras, lo que da los subdominios. Con subdominios se pueden formar equipos que evolucionen de forma autónoma —no independiente— a su propia velocidad y con menos coordinación, que es lo más difícil del trabajo entre humanos.

De Event Storming a código, sin traducción

Ruiz lleva la idea un paso más allá: de un framework opinionado a uno terco. Lo resume con su propia versión de la cita de Clear, escrita "algún sábado a las 2 a. m." lleno de frustración.

Para eso expanden el Event Storming en una sintaxis donde cada color tiene un significado. En el ejemplo, desde una interfaz de Candidates se ejecuta el comando Hire Candidate en el HR System, que emite el evento Candidate Hired. Una política (en morado), Welcome Email Sending Policy, dispara otro comando, Send Welcome Email, en otro sistema (Gmail), con su propio resultado: Welcome Email Sent.

Según Ruiz, con esos seis colores alcanza para mapear cualquier sistema, sin importar su complejidad. Lo muestra con un sistema de facturación real.

Ese modelo se transforma en código de forma determinística, y también al revés: desde el código se puede regenerar la representación visual del modelo. Eso permite validar lo que genera la IA contra el modelo, igual que el plano con la leyenda servía para validar la bicicleta. Si el diseño ya está estructuralmente validado cuando un agente toma un ticket del tablero, se reducen las chances de que el error que llega al PR sea estructural y rompa producción.

Ruiz afirma que en Agility ya implementan esta automatización y este framework para sus clientes.

El futuro de los devs: Forward Deployed Engineers

Desde Agility, con clientes en Asia, Europa y Estados Unidos, Ruiz dice ver cambiar el mercado: en lugar de equipos de diez desarrolladores, piden dos o tres FDE (Forward Deployed Engineers). "El mercado está colapsando", dice: no se necesitan tantos devs, sino más de este rol nuevo que todavía nadie sabe definir bien. Para él, esto significa profundizar menos en lo técnico y ampliar capacidades hacia producto, negocio y UX, incluida la de resolver una conversación con alguien de negocio.

Agility creó una aplicación experimental, accesible por un QR en la charla, para probar qué se siente ser FDE, con un premio de 1.000 dólares para la mejor puntuación. También ofreció hacer una sesión para mostrar el framework en detalle si al menos unas 20 personas lo pedían en los comentarios del QR. Ruiz cierra con una frase de Richard Bach: "Lo que la oruga llama el fin del mundo, el maestro lo llama mariposa."

Preguntas del público

¿Qué diferencia hay entre un FDE y un AI Engineer? Ruiz admite que no lo sabe: todo es muy nuevo y nadie tiene un título de FDE; "los FDE hoy somos los desarrolladores del mes pasado". Para él es un desarrollador que resuelve problemas y puede desbloquear algo que no conoce. Ante la sugerencia de que se parece a Solutions Architect, discrepa: ese rol va por otro lado.

¿Cómo afecta esto a producto y a los líderes técnicos? Cree que depende de cada proyecto. Alguien tiene que seguir ordenando: puede haber menos personas, pero el problema es cuánto fluye hacia producción. Negocio ya hace prototipos todo el tiempo ("a mí me tomó un día, solo tienes que hacer que funcione en producción"). Con "gorra de futurólogo", y aclarando que no tiene base para afirmarlo, apuesta a que ambos roles colapsen, y más probablemente de ingeniería hacia producto que al revés.

Startup pre-seed de salud con el dominio documentado pero sin equipo técnico: ¿qué perfil buscar primero? Una persona con fortaleza técnica. Un sistema de salud probablemente tenga requisitos de integridad de datos, y a esta velocidad los fundamentos tienen que ser sólidos: "eso no lo vas a vibecodear, por lo menos no en 2026".

¿Cómo se garantiza que la estructura se respete en el código? Es un trade-off consciente. Un practicante de DDD diría que modelar todos los subdominios con DDD es overkill, y Ruiz le da la razón, pero argumenta que las prioridades de los atributos de calidad cambiaron. En sus 15 años como arquitecto priorizó mantenibilidad, luego extensibilidad; pero "ya no mantenemos el código, ni lo extendemos". Su decisión: priorizar extensibilidad primero, porque hay que soportar PRs que llegan a producción a mansalva, y luego auditabilidad.

De los cuatro patrones canónicos que describe Vlad Khononov en Learning Domain-Driven Design (Transaction Script, Active Record, agregados de modelo de dominio y agregados Event Sourced), eligió usar agregados para todo. A cambio obtiene auditabilidad completa y un mapeo uno a uno entre los stickies y el código: el mapeo es estructural, "ahí no hay tokens". Lo que negocio dijo con su boca se refleja en el código, no se traduce: si buscas el sticky en el código, está. Advierte que no se puede hacer con cualquier framework; este, como la línea de Fanuc, está diseñado para la automatización.

Recursos

Solo la guía de Augment Code aparece como URL en las láminas; el resto se menciona sin enlace.

Conclusiones

Ruiz presenta esto como su mejor apuesta, no como una certeza: "no es que yo sé", y pide a quien crea que no va a funcionar que se lo diga. Para él, la IA amplifica el sistema donde se usa: sobre un proceso pensado para humanos y lleno de traducciones, acelera la deuda técnica. La salida es hacer lo que hizo Fanuc: diseñar el sistema para que lo usen máquinas.

• Según Ruiz, el fallo típico de una LLM no es sintáctico sino estructural: código correcto con el significado equivocado.
• Su propuesta: darle al agente un modelo que completar, no una especificación que interpretar.
• Prefiere estructura que se genera, se valida mecánicamente y falla ruidosamente, antes que convenciones.
• Event Storming alinea a la organización en un lenguaje común y define subdominios y equipos autónomos; con una sintaxis de colores, el modelo se refleja uno a uno en código.
• Con código generado por IA, Ruiz prioriza extensibilidad y auditabilidad por encima de mantenibilidad.

Fuente

• Video: La IA no funciona... sin un modelo de dominio. - Tomás Ruiz, Nerdearla, 28/09/2026, 33:45.
• Texto basado en la transcripción automática del video, reescrita como artículo; nombres y cifras verificados contra las láminas.