La agilidad sacó a muchos equipos de los proyectos eternos. Entregas cortas, conversación con negocio y software que funciona antes de que el plan se quede viejo. Nadie sensato quiere volver atrás.
Pero en muchos equipos pasó algo más por el camino. «Iterar» fue ocupando el sitio del análisis funcional y del diseño técnico. El trabajo no desapareció: cambió de sitio. Menos pensar antes, más corregir después de entregar.
La tesis de esta pieza: con agentes que leen la especificación, el análisis y el diseño vuelven a compensar, y la entrega puede seguir siendo corta. El rigor de antes con la cadencia de ahora. Es una tesis, no un resultado medido, y al final contamos dónde puede fallar.
Lo que dice el Manifiesto (y lo que no)
Conviene empezar por el texto original, de 2001. El Manifiesto Ágil valora a las personas y sus interacciones por encima de los procesos y las herramientas, el software que funciona por encima de la documentación exhaustiva, la colaboración con el cliente por encima de la negociación del contrato y la respuesta al cambio por encima de seguir un plan.
Y añade la frase que más se olvida: aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda. «Más» no es «en lugar de». La documentación y el plan tienen valor; solo pesan menos.
Los doce principios lo dejan todavía más claro. Uno pide entregar software que funcione con frecuencia, entre un par de semanas y un par de meses, con preferencia por el plazo más corto. Otro, que negocio y desarrollo trabajen juntos cada día. Y el noveno dice que la atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
Dónde se perdió el análisis
Que pensar antes no sobra lo han dicho, desde dentro, dos de los firmantes del Manifiesto.
Martin Fowler escribió «Is Design Dead?» para una conferencia de 2000 y lo revisó en 2004. Su respuesta era que no: la programación extrema implica mucho diseño, pero hecho de otra manera. También reconocía el riesgo. En su uso común, decía, el diseño que crece mientras se construye es un desastre, y sus detractores lo veían como una vuelta al «programar y arreglar». Y cerraba con un equilibrio: el diseño planificado no desaparece del todo y hay sitio para diseñar antes de programar.
Dave Thomas, otro de los diecisiete firmantes, fue más lejos en 2014 con «Agile is Dead (Long Live Agility)». Para él, la palabra «agile» se había vaciado de significado al convertirse en un término de marketing. Proponía quedarse con la agilidad como forma de trabajar: averiguar dónde estás, dar un paso pequeño hacia el objetivo, ajustar lo que has entendido con lo que has aprendido y repetir.
Ninguno de los dos pide más documentos. Los dos piden pensar. El problema no era el Manifiesto; era que, en el día a día, pensar antes de construir se volvió caro de justificar. Con un sprint de dos semanas por delante, un análisis de tres días parece un lujo.
Por qué la especificación vuelve a compensar
Aquí está el cambio de fondo. Hasta ahora, quien leía el análisis era una persona que iba a programar. Si el análisis era flojo, esa persona preguntaba, suponía o lo descubría a mitad del trabajo. El coste de un mal análisis se repartía en conversaciones y retrabajo.
Con un agente que construye, la especificación es la entrada del trabajo. La especificación de spec-kit, el kit de GitHub para Spec-Driven Development (SDD, desarrollo guiado por especificaciones), lo describe así: los documentos de requisitos eran el andamio que se construía y se tiraba en cuanto empezaba el trabajo «de verdad», el de programar. En SDD, la especificación pasa a ser el artefacto principal y el código, su expresión en un lenguaje y un framework concretos.
Dicho de forma práctica: lo que no está escrito, el agente lo supone. Un análisis funcional bueno, con casos y criterios, y un diseño técnico que diga dónde va cada cosa ya no son un lujo. Son lo que necesita el que construye. Si quieres la definición de SDD con calma, está en SDD: la metodología que convierte la IA en código controlado.
Por qué no es volver al waterfall
La objeción es obvia: si volvemos a escribir antes de construir, ¿no estamos volviendo al waterfall? La diferencia está en el tamaño y en el ritmo.
El waterfall escribía el análisis de todo el proyecto antes de construir nada y entregaba al final. Con SDD se especifica la siguiente pieza de trabajo, el agente la construye y la entrega llega pronto. El análisis vuelve; los meses de espera, no.
Birgitta Böckeler, de Thoughtworks, lo vigila desde el otro lado. Después de probar tres herramientas de SDD, escribe que la experiencia ha demostrado que la mejor forma de mantener el control de lo que construimos son los pasos pequeños e iterativos. Duda de que mucho diseño de especificación por adelantado sea buena idea. Y advierte que una buena herramienta de SDD tendría que permitir trabajar de forma iterativa, aunque las piezas de trabajo pequeñas casi parecen ir contra la idea misma de SDD. En alguno de sus casos, el proceso le pareció excesivo para el tamaño del problema.
| Pregunta | Waterfall | Iterar sin análisis (la deriva) | Especificación y agente (la tesis) |
|---|---|---|---|
| ¿Cuándo se piensa qué construir? | Todo al principio | Durante y después de entregar | Antes de cada pieza, a su medida |
| ¿Quién lee el análisis? | Personas, a veces meses después | Casi nadie: una historia de una línea | El agente que construye y la persona que lo revisa |
| ¿Cada cuánto se entrega? | Al final | Cada pocas semanas | Cada pocas semanas o antes |
| ¿Dónde aparece el desacuerdo con negocio? | En la entrega final | En la revisión del sprint, como retrabajo | Al revisar la especificación, antes del código |
| ¿Cuál es el riesgo principal? | Un documento enorme que se queda viejo | Entregar mucho y alinear poco | Una especificación pesada o sin criterios comprobables |
Elaboración propia de onext. La última columna es una tesis, no un resultado medido.
La fila que más importa es la cuarta. En la deriva, el desacuerdo con negocio se descubre cuando ya hay software: se enseña, no era eso, se rehace. Con la especificación delante, el desacuerdo puede aparecer al leerla, cuando corregir cuesta una conversación. Por eso tiene sentido que una persona firme la especificación antes de que el agente genere nada, como contamos en la especificación es donde se firma.
Lo que la especificación tiene que llevar para no ser un documento largo
Volver al análisis no es volver a los documentos de cien páginas. Una especificación que el agente lee y nadie puede comprobar es solo prosa. Lo que la convierte en análisis útil son los criterios de aceptación: frases concretas que dicen qué tiene que pasar y que una máquina puede verificar. Cómo pasar de criterio a puerta del merge lo explicamos en tu spec ya es un eval, y cómo encajan ahí las pruebas, en SDD, TDD y BDD: qué aporta cada uno.
El diseño técnico funciona igual. No hace falta un diseño de todo el sistema antes de empezar. Hace falta que la especificación de cada pieza diga dónde va, qué toca y qué no debe romper. Es el equilibrio de Fowler llevado a cada tarea: algo de diseño planificado, mucho diseño que evoluciona.
Riesgo Una especificación sin criterios comprobables no recupera el análisis: lo imita. Si la especificación crece y nadie puede decir si el código la cumple, has vuelto al documento que se queda viejo, ahora con un agente que lo interpreta a su manera.
La alineación con negocio, con sus límites
La promesa de fondo es la alineación entre TI y negocio a una velocidad razonable: el análisis de antes para entender qué se pide y la cadencia de ahora para comprobarlo pronto. Es la parte más atractiva de la tesis y también la que más fácil se exagera.
El informe de DORA de 2025 sobre desarrollo de software asistido por IA lo resume en una frase: el papel principal de la IA es el de amplificador, que magnifica las fortalezas y las debilidades que la organización ya tiene. Si negocio y desarrollo no se hablan, un agente rápido no lo arregla; entrega más deprisa lo que nadie había acordado. Lo vimos desde otro ángulo en el gap del 70 %: la adopción de IA en desarrollo es un problema organizativo.
Lo que todavía no sabemos
Tres límites que conviene decir en voz alta.
- Es una tesis. No tenemos un estudio que mida la alineación con negocio antes y después de trabajar con especificaciones y agentes. Lo que hay son argumentos y fuentes que apuntan en esa dirección.
- El punto de equilibrio no está escrito. Cuánto especificar antes de cada pieza depende del riesgo, del equipo y del cambio. Böckeler lo vio en sus pruebas: el mismo proceso sobraba para un problema pequeño. Y Böckeler plantea una duda de fondo: las piezas pequeñas casi parecen ir contra la idea de SDD.
- La disciplina no viene con la herramienta. Escribir buenos criterios es un hábito. Si el equipo no lo tiene, la especificación será tan floja como la historia de una línea, solo que más larga.
Y una pregunta para tu próxima planificación: de la última funcionalidad que se rehízo, ¿el desacuerdo se podría haber visto leyendo una especificación de una página? Si la respuesta es sí, el análisis que te falta no es un documento. Es una conversación con fecha, antes del código. Si te interesa el lado incómodo de esa conversación, el de la presión por enseñar algo cuanto antes, lo tratamos en MVP frente a especificación.
Preguntas frecuentes
¿Spec-Driven Development es volver al waterfall?
No, si se hace bien. El waterfall escribía todo el análisis y el diseño antes de construir y entregaba al final. Con Spec-Driven Development (SDD, desarrollo guiado por especificaciones) se escribe la especificación de la siguiente pieza de trabajo, la lee el agente que construye y la entrega sigue siendo corta. El riesgo de parecerse al waterfall existe cuando la especificación crece sin medida: Birgitta Böckeler, de Thoughtworks, recuerda que los pasos pequeños e iterativos siguen siendo la mejor forma de mantener el control.
¿El Manifiesto Ágil está en contra de la documentación y del diseño?
No. El Manifiesto dice que, aunque hay valor en los elementos de la derecha (procesos, documentación, contratos y planes), valora más los de la izquierda. Y uno de sus doce principios dice que la atención continua a la excelencia técnica y al buen diseño mejora la agilidad. Lo que se perdió en muchos equipos fue una práctica, no una regla del Manifiesto.
¿Por qué la IA hace que vuelva a compensar el análisis funcional?
Porque el agente construye con lo que lee. Durante años, los documentos de requisitos eran, en palabras de la especificación de spec-kit (el kit de GitHub para SDD), un andamio que se construía y se tiraba cuando empezaba el trabajo de verdad. Con un agente, la especificación es la entrada del trabajo: lo que no está escrito, el agente lo supone.
¿Cuánto hay que especificar antes de que el agente empiece?
Lo justo para la siguiente pieza de trabajo, con criterios que se puedan comprobar. No hay una cifra universal. Böckeler probó varias herramientas de SDD y en algunos casos el proceso le pareció excesivo para el tamaño del problema. La medida la pone una persona, pieza a pieza.
¿La IA arregla la falta de alineación entre TI y negocio?
No por sí sola. El informe de DORA de 2025 sobre desarrollo de software asistido por IA concluye que la IA actúa sobre todo como amplificador: magnifica las fortalezas y las debilidades que la organización ya tiene. Escribir mejor qué se construye es una condición para alinear; no es una garantía.
¿Qué es el diseño evolutivo y qué tiene que ver con SDD?
Es la idea de que el diseño de un sistema crece mientras se construye. Martin Fowler, en «Is Design Dead?», explica que la programación extrema (XP) implica mucho diseño, pero hecho de otra forma, y que el diseño planificado no desaparece del todo: hay sitio para diseñar antes de programar. SDD encaja en ese equilibrio: se diseña antes de cada pieza, no antes de todo el proyecto.
Fuentes
- Kent Beck, Martin Fowler, Dave Thomas y otros, «Manifesto for Agile Software Development», 2001, y sus doce principios (consultados el 11 de octubre de 2026).
- Martin Fowler, «Is Design Dead?», martinfowler.com, presentado en XP 2000 y revisado en mayo de 2004.
- Dave Thomas, «Agile is Dead (Long Live Agility)», pragdave.me, 4 de marzo de 2014.
- Birgitta Böckeler (Thoughtworks), «Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl», martinfowler.com, 15 de octubre de 2025.
- GitHub spec-kit, «Specification-Driven Development (SDD)» (sin fecha visible; consultada el 11 de octubre de 2026).
- DORA (Google Cloud), «State of AI-assisted Software Development 2025».
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →