Hace unas semanas, un desarrollador en Reddit publicó sobre un flujo de trabajo que había creado para Claude Code (r/ClaudeAI, marzo de 2026). Habían dividido su desarrollo asistido por IA en tres agentes distintos: un Arquitecto que definía el diseño del sistema y las restricciones, un Constructor que generaba el código y un Revisor que evaluaba la salida frente a la especificación original. La publicación recibió 287 votos positivos. Los comentarios estaban llenos de desarrolladores que compartían configuraciones similares.

El desarrollador nunca había oído hablar del desarrollo estructurado impulsado por IA. Nunca habían leído sobre separar la elaboración de la construcción, ni sobre incrustar puertas de calidad en el flujo de trabajo de generación. Llegaron a la misma estructura de forma independiente, por prueba y error, después de que su enfoque no estructurado dejara de funcionar.

Esa misma semana, un hilo titulado «Por qué fracasan los proyectos de vibe coding» se volvió viral con 324 votos positivos (r/ClaudeCode, marzo de 2026). Ingenieros experimentados explicaron lo que llamaban la regla del 90/10: la IA te lleva al 90% rápido, y luego el último 10% tarda más de lo que habría llevado construir todo manualmente. Los comentarios convergieron en una conclusión familiar: el problema nunca fue la IA. El problema era empezar sin especificación.

Y en un tercer hilo, una empresa descubrió que sus 45 agentes de IA gastaban 12.000 dólares al mes hablando entre ellos, produciendo trabajos que nadie había pedido ni revisado (r/AI_Agents, marzo de 2026).

Tres hilos, una semana, tres ángulos diferentes con la misma realización. La comunidad de desarrolladores está convergiendo en los principios que formaliza el desarrollo estructurado impulsado por IA. Simplemente aún no tienen un nombre compartido para ello.

Una revelación antes de continuar: el DLC de IA es una metodología que no he originado, pero que he ido ampliando y operacionalizando desde 2025, construyendo guías para facilitadores, barreras de seguridad empresariales y otros artefactos que convierten el ciclo de vida central en un marco de entrega. Eso me convierte tanto en una parte interesada como en alguien que ha estado siguiendo estos patrones de cerca.

La Convergencia Nadie Planeó

Los biólogos tienen un término para esto: evolución convergente. Diferentes linajes llegando a estructuras similares, no por un ancestro común, sino por evolución independiente bajo presiones similares. Marsupiales y placentarias convergían en formas corporales similares a lo largo de nichos ecológicos. Los depredadores dientes de sable evolucionaron en múltiples linajes distintos de mamíferos. Como observó Richard Dawkins, «la convergencia no es total», porque los orígenes y la historia del desarrollo siempre difieren. Pero las presiones selectivas producen estructuras reconocibles.

La misma dinámica se está repitiendo en la comunidad de desarrolladores. Nadie lo coordinó. Nadie publicó un manifiesto. Los desarrolladores se toparon con los mismos muros y llegaron a las mismas conclusiones.

Por qué la IA crea esta presión

El mecanismo subyacente es sencillo. La IA comprime el tiempo entre la intención y la salida. Cuando la intención es clara, la compresión es un regalo: consigues que el software funcione más rápido. Cuando la intención es vaga, la compresión es una trampa: recibes un software equivocado más rápido, y el coste de descubrir que era incorrecto llega antes de que hayas tenido tiempo de notarlo.

Esta compresión desplaza el cuello de botella. Para un número creciente de equipos, la restricción ya no es la generación de código sino la definición de intención. Los equipos que lo reconocieron pronto estructuraron sus flujos de trabajo en torno a especificaciones, separación de roles y puertas de calidad. Los equipos que no lo hicieron son los que escriben las autopsias.

Los patrones son consistentes. El código de vibración produce demos, no software de producción. Los agentes de IA sin roles claros generan expansión urbana, no productividad. La generación de código sin puertas de calidad acumula deuda más rápido de lo que cualquier equipo puede pagarla. Y cuanto más rápido genera la IA el código, más caro resulta descubrir que el código era incorrecto.

Las conclusiones convergen en el mismo conjunto de principios. Necesitas una especificación antes de empezar a generar código. Necesitas separar roles entre la entidad que diseña y la que construye. Necesitas un proceso de revisión que evalúe la salida en función de la intención, no solo si se compila. Y necesitas una gobernanza que escale con la velocidad de la generación.

Estos son los principios fundamentales de los DLC de IA tal y como los he ampliado: definir la intención antes de la generación, separar la elaboración de la construcción, incrustar puertas de calidad en el flujo de trabajo y gobernar el proceso a la velocidad a la que opera. La comunidad los está redescubriendo cada vez más, proyecto doloroso a proyecto.

La trampa prototipo

La convergencia de la comunidad en estos principios está impulsada por un modo de fallo específico que Dino Esposito diagnosticó con precisión en Clean Architecture with .NET (2024): «Un prototipo construido rápidamente no está ni pensado ni diseñado para uso en producción. El punto engañoso para gestores y partes interesadas es que un prototipo es una prueba de concepto y no solo carece de toda la funcionalidad de la aplicación final. Le faltan muchos otros aspectos invisibles, cruciales para una aplicación sólida y lista para la producción.»

Este es el ciclo de vida del código de vibra en un solo párrafo. La IA genera una demo funcional, esta impresiona a los interesados y, antes de que nadie haya evaluado lo que falta, se empuja hacia la producción. Entonces, las lagunas invisibles, la robustez, la seguridad, la mantenibilidad, el rendimiento, se revelan incidente a incidente.

Esposito identifica cuatro tipos de deuda técnica: intencionada (atajos conscientes), no intencionada (errores por falta de conocimiento), evitable (ignorar prácticas establecidas) e inevitable (cambios en los requisitos).

El vibe coding es notable porque genera los cuatro simultáneamente. El desarrollador toma un atajo consciente saltándose la especificación. La IA introduce deuda no intencionada porque carece de contexto del dominio. El flujo de trabajo evita las prácticas establecidas porque no existe una metodología para hacerlas cumplir. Y los requisitos cambian porque nadie los definió con suficiente precisión para mantenerse estables.

Un hilo de Reddit lo resumió perfectamente: «Ahorramos 6 semanas recortando gastos y luego pasamos 11 semanas arreglando las consecuencias» (r/ExperiencedDevs, abril 2026). La curva de deuda técnica del Agile Samurai se aplica con fuerza acelerada: lo que costó 1 dólar para fijar durante la elaboración cuesta 10 dólares durante la construcción y 100 dólares en producción. La IA no cambia la curva. Comprime la línea temporal.

Lo que la comunidad hace bien

Los instintos de la comunidad son sólidos. Los principios en los que convergen son los correctos, y reflejan ideas que la literatura de ingeniería de software ha articulado durante décadas.

La separación de roles funciona. El desarrollador que construyó la cadena de Arquitecto/Constructor/Revisor reportó una calidad de salida mucho mejor que la generación de un solo agente. La literatura sobre sistemas multiagente formaliza esto como el principio de especialización: «los agentes asignados a roles que coinciden con sus fortalezas» producen mayor precisión que los agentes monolíticos que intentan todo, como documenta Albada en Building Applications with AI Agents (2025). El mismo libro nombra el principio que la comunidad aprendió a 12.000 dólares al mes: la parsimonia. «Cada agente añadido al sistema introduce una sobrecarga adicional de comunicación, complejidad de coordinación y demandas de recursos.» Menos agentes con roles claros superan a una enorme pila de agentes intentando parecer ocupados. En AI-DLC, esto se corresponde con la estructura trifásica: Elaboración define la intención, Construcción genera el código, Elevación lo valida y mejora.

El desarrollo centrado en la especificación funciona. Todos los hilos sobre fallos en el Vibe coding llegan a la misma conclusión: el problema no era la IA, sino la ausencia de una especificación clara. Forbes informó que los investigadores analizaron 5.600 aplicaciones públicas de vibe code y encontraron más de 2.000 vulnerabilidades de alto impacto y 400 secretos expuestos. Una de cada tres aplicaciones se lanzaba con un grave fallo de seguridad. La especificación es la restricción que impide esto.

Hunt y Thomas publicaron The Pragmatic Programmer en 1999, y pocos libros han influido tan profundamente en mi pensamiento sobre el software. Su observación sobre los requisitos solo se ha agudizado con el tiempo: «El mundo real es caótico, conflictuado y desconocido. 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.» Lo escribieron para desarrolladores humanos. Se aplica con aún más fuerza cuando el desarrollador es un agente de IA.

Las puertas de calidad funcionan. El desarrollador con la pipeline de habilidades en 7 etapas (Researcher → Auditor → Creator → Optimizer → Critic → Tester → Register) reportó una mejora notable en la calidad (r/claudeskills, abril de 2026). La autopsia de la producción de agentes de 8 meses encontró que una puerta de aprobación humana en cada salida orientada al cliente detectó aproximadamente 8 salidas defectuosas durante todo el periodo (r/AI_Agents, abril de 2026). La puerta era barata; la alternativa era el daño reputacional. Albada describe esto como el enfoque actor-crítico: «el actor genera resultados candidatos mientras el crítico actúa como una puerta de calidad, aceptando o rechazando resultados basándose en una rúbrica predefinida.» La comunidad lo construyó desde cero. El enfoque ya tenía un nombre.

La conciencia sobre la gobernanza está creciendo. El núcleo de Linux formalizó una política de gobernanza del código de IA: los agentes de IA no pueden firmar contribuciones, los humanos asumen toda la responsabilidad legal y se requiere una etiqueta «Asistido por» para cada contribución asistida por IA. El proyecto de código abierto más fundamental del mundo llegó al mismo modelo de rendición de cuentas desde el que parte el desarrollo estructurado impulsado por IA: los humanos son los dueños de la intención, la revisión y la responsabilidad.

La evidencia está por todas partes

La señal está en todas partes, a través de comunidades, herramientas y informes de analistas simultáneamente.

Comunidad de desarrolladores

Un ingeniero principal con 14 años de experiencia publicó una comparación detallada entre Claude Code y Codex (r/ClaudeCode, abril de 2026). Su flujo de trabajo: primero el modo planificación, luego ocho subagentes especializados, revisión por commit y desarrollo guiado por pruebas durante todo el proceso. Su conclusión: «Ambos van a dar una mala salida si no sabes nada de ingeniería de software.» Después de que Anthropic lanzara su modelo Mythos, un comentario destacado en r/ClaudeCode decía: «Esperad a que volvamos a descubrir el desarrollo basado en especificaciones.» La comunidad lo sabe. Simplemente tienen que redescubrirlo una y otra vez.

Análisis independiente

William Collins recopiló los datos concretos: Veracode descubrió que el 45% del código generado por IA contiene vulnerabilidades de seguridad; el ensayo controlado aleatorizado METR encontró que los desarrolladores experimentados eran un 19% más lentos con las herramientas de IA, mientras creían que eran un 24% más rápidos. Su conclusión: «El problema nunca fue el desarrollo asistido por IA. El problema era el desarrollo no estructurado asistido por IA.» Bilgin Ibryam mapeó todo el ecosistema de codificación de IA 2026 en tres fases: Planificar, Construir, Revisión, y observó: «La planificación dejó de ser opcional.» Marc Gasser lo planteó así: «Especificaciones antes de los prompts. La salida de la IA no es de fiar por defecto. El foso es el flujo de trabajo, no el modelo.»

Herramientas e industria

AWS creó Kiro, un IDE completo organizado alrededor del desarrollo basado en especificaciones con un flujo de trabajo en tres fases: Requisitos para Diseño según Tareas. GitHub lanzó Spec Kit, un kit de herramientas de código abierto con 71.000 estrellas que trabaja con más de 20 agentes de IA. Ahora todas las principales herramientas de codificación por IA incluyen un modo de planificación: Claude Code, Cursor, Windsurf, Cline, Codex. Hace un año, estas herramientas competían en velocidad de generación de código. Ahora compiten por lo bien que ayudan a los desarrolladores a definir la intención antes de generar nada.

Thoughtworks Technology Radar Volumen 34 (abril de 2026) nombra explícitamente el desarrollo basado en especificaciones como un «control de avance» para agentes codificadores y advierte sobre la acumulación de «deuda cognitiva» por generación no estructurada de código de IA. El Informe DORA 2025, con un 90% de adopción de IA por parte de desarrolladores, encontró que la IA amplifica lo que ya existe: los equipos estructurados mejoran, los equipos no estructurados empeoran.

Lo que le falta a la comunidad

La comunidad está resolviendo los problemas adecuados con soluciones improvisadas. Lo que le falta es la estructura que convierte los descubrimientos individuales en una metodología repetible y escalable. Como dijo un profesional de pruebas sin rodeos: «La metodología responde a las preguntas sobre cómo deberían hacerse las cosas. Sin ella, improvisamos, obteniendo una lista de lo que debería construirse de algún sitio, una fecha límite de otro sitio y haciendo ‘algunas pruebas’. Con este enfoque, se pasan cosas por alto.»

Destacan tres huecos.

Sin apoyo de brownfield. La mayoría de los flujos de trabajo comunitarios asumen un proyecto en terreno nuevo. Pero la realidad empresarial es un terreno contaminado: bases de código existentes, arquitecturas heredadas, deuda técnica acumulada a lo largo de los años. AI-DLC aborda esto con Code Elevation, una prefase estructurada que prepara las bases de código existentes para el desarrollo asistido por IA. El consejo de la comunidad de «arreglar lo que ve el agente» es correcto pero incompleto. La elevación de código proporciona el marco diagnóstico, el modelo de priorización y el proceso facilitado para hacerlo de forma sistemática.

Sin barreras empresariales. Los flujos de trabajo comunitarios funcionan a nivel individual o de pequeños equipos. No abordan las restricciones empresariales que determinan si el desarrollo asistido por IA es viable a gran escala: políticas de seguridad, requisitos de cumplimiento, estándares arquitectónicos, gobernanza de costes. La Enterprise Guardrails Specification, una extensión de AI-DLC, proporciona un marco estructurado para integrar estas restricciones en el propio proceso de desarrollo, no como una puerta de revisión después de que el código está escrito. La metodología original define las fases, rituales y artefactos; La capa de Guardrails añade la gobernanza empresarial que la hace desplegable en entornos regulados.

Sin rituales facilitados. Los flujos de trabajo de la comunidad son individuales o en pareja. Los rituales de los DLC de IA, especialmente la Elaboración de Mobs, están diseñados para equipos. La fase de elaboración funciona precisamente porque es una sesión facilitada donde el product owner, arquitectos, desarrolladores y el colaborador de IA definen la intención juntos. La dimensión colaborativa es lo que impide que la especificación se convierta en la suposición de una sola persona sobre lo que el sistema debe hacer.

La brecha entre los flujos de trabajo improvisados de la comunidad y una metodología estructurada es la diferencia entre un desarrollador que descubrió que las pruebas ayudan y un equipo que practica el desarrollo guiado por pruebas con estándares compartidos, aplicación de CI/CD y requisitos de cobertura. La idea es la misma. La madurez operativa es diferente. El DLC de IA es una forma de cerrar esa brecha; otros enfoques estructurados pueden cerrarla de forma diferente. Lo importante es que se cierre la brecha.

Por qué importa esta convergencia

Esto no es una vuelta de victoria. El hecho de que la comunidad llegue a estos principios de forma independiente es la validación más fuerte posible de que los principios son correctos, pero también revela cuánto trabajo queda por hacer.

Ford, Parsons y Kua observaron en Building Evolutionary Architectures (2022) que «sin guía, la arquitectura evolutiva se convierte simplemente en arquitectura reaccionaria.» Aquí se aplica lo mismo. Sin una metodología, la convergencia de la comunidad sigue siendo reactiva: cada equipo redescubriendo las mismas lecciones tras los mismos fracasos, construyendo el mismo andamiaje desde cero, sin un vocabulario compartido que acelere la adopción del siguiente equipo.

La metodología, las guías de facilitadores y el apoyo en brownfield existen hoy en día. El argumento más amplio sobre por qué los enfoques estructurados de transformación tecnológica superan a la improvisación, en la nube, la IA y el cambio organizacional, es el tema de Reimagine, Don’t Retrofit.

Pero esto es lo que la evolución convergente nos enseña: estructuras similares surgen bajo presiones similares, pero la evolución convergente no produce vocabulario compartido, herramientas compartidas ni gobernanza compartida. Los marsupiales y los placentarios llegaron a formas corporales similares, pero no pueden cruzarse entre sí.

La comunidad está convergiendo en las estructuras adecuadas. Lo que necesita ahora es el lenguaje compartido y la disciplina compartida para dejar de redescubrirlos equipo a equipo. Cada equipo que redescubre estos principios por sí solo es prueba de que los principios son correctos. Cada equipo que tiene que redescubrirlos solo es prueba de que la metodología ya está retrasada.

Ricardo