La objeción más repetida al Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, es que es papeleo: escribir un documento antes de cada cambio frena al equipo. Un estudio reciente ha mirado cómo lo practican los equipos que ya lo usan, y la respuesta es más útil que un sí o un no.
La idea que defiende este insight: el SDD no se defiende diciendo que vale para todo, sino eligiendo dónde se usa. Funcionalidades nuevas o con riesgo, sí; un cambio trivial, no. La especificación dice qué y por qué, no cómo. Y se comprueba contra el código en cada cambio, no al final. Una especificación que nadie comprueba es documentación que caduca.
El primer estudio sobre cómo se practica el SDD
Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu y Travis Breaux (Carnegie Mellon University y Google) han comparado lo que prescriben las herramientas de SDD con lo que hacen de verdad quienes las usan. La versión más reciente del trabajo es del 15 de octubre de 2026. Juntan tres fuentes: un análisis de conversaciones en Reddit, entrevistas a 21 profesionales (8 de ellos fabricantes de herramientas) y SpecMine, un corpus de 470.795 archivos de especificación de 73.030 repositorios públicos de GitHub, del que analizan a fondo una muestra de 266 repositorios activos y populares (36.890 archivos). Tres cifras de esa muestra:
Riesgo Es un preprint sin revisión por pares. Los repositorios son públicos y populares, y en la muestra domina una herramienta (OpenSpec, el 78,4 %): pueden no parecerse a los de tu empresa. Las cifras son porcentajes de archivos, no de equipos. Los entrevistados están probablemente más implicados con el SDD que la media, el estudio encuentra asociaciones y no causas, y los propios participantes no podían separar lo que ganaban con el SDD de lo que mejoraban los modelos.
Lo que hacen los equipos que ya lo usan
Cuatro hallazgos del estudio, contados por separado porque cada uno cambia una decisión distinta:
- Lo usan de forma selectiva. Sobre todo en funcionalidades nuevas y más grandes. Para bugs, hotfixes y tareas pequeñas, los entrevistados no escribían especificación.
- El agente es más fiable, pero cuesta más. Los participantes contaban un comportamiento del agente más fiable y una intención más clara, a cambio de más planificación y más revisión. Un equipo explicó que con SDD gastaba de dos a tres veces más tokens y tardaba el doble que pidiéndoselo directamente al agente: es un caso contado, no una estadística.
- La especificación acaba llevando el cómo. Todos coinciden en que debe decir qué hay que construir, pero la mayoría de quienes usan las herramientas también escribe cómo construirlo, sobre todo en tareas complejas o cuando el agente no tiene el conocimiento. Los fabricantes de herramientas, en cambio, separan el cómo en documentos de diseño o de tareas.
- La comprobación llega al final. Los participantes comprobaban que especificación y código coincidían sobre todo al terminar el cambio, no con el tiempo. Quienes querían detectar la deriva después se montaron sus propias comprobaciones.
Los autores ponen nombre a lo que pasa entonces: la especificación caduca (spec decay), se queda vieja a medida que cambia el código, sobre todo cuando un cambio altera un comportamiento que describen otras especificaciones. Es la misma pérdida de la que hablamos en deuda de comprensión: lo que nadie mantiene deja de explicar el código.
Dónde compensa la especificación y dónde sobra
Si el coste es real (más planificación y más revisión), la pregunta no es si se usa el SDD, sino en qué cambios. La tabla es nuestra propuesta a partir de lo que hacen los equipos del estudio, no un resultado del estudio.
| Tipo de cambio | ¿Especificación? | Por qué |
|---|---|---|
| Funcionalidad nueva | Sí | Hay que fijar qué se construye antes de que el agente lo decida por su cuenta |
| Cambio con riesgo (cobros, permisos, datos personales) | Sí | Los criterios de aceptación son lo que luego comprueba la máquina y firma una persona |
| Cambio que pasa por varias personas o roles | Sí | La especificación es lo que todos entienden igual; el estudio ve ahí el beneficio compartido |
| Bug acotado | No, un test | Un test que reproduce el fallo ya dice qué debe pasar |
| Hotfix | Después, si cambia un comportamiento | Primero se arregla; si altera lo que describe otra especificación, se actualiza esa |
| Texto, estilo o cambio trivial | No | El coste de escribirla supera lo que aclara |
Elaboración de onext a partir de Agarwal y otros (2026)
El criterio de fondo es el mismo que en una issue no es una especificación: hace falta especificación cuando, si no se escribe, el agente rellena los huecos con lo que cree. Y no sustituye a lo que ya hacen bien los tests: cómo se reparten SDD, TDD y BDD está en qué aporta cada uno cuando el código lo escribe un agente.
Qué va en la especificación y qué no
Nuestra lectura del hallazgo del cómo: el detalle de implementación ayuda al agente hoy y caduca mañana. La especificación que dura dice qué hay que construir, para quién, por qué y con qué criterios de aceptación. El cómo (qué librería, qué estructura, qué pasos) va aparte, en un documento de diseño o en las tareas, como hacen los fabricantes de herramientas del estudio. Así, cuando el cómo cambia, la especificación sigue siendo verdad.
Hay una excepción razonable, que el propio estudio recoge: lo que el agente no puede saber. Las decisiones que el equipo ya tomó y que no están en el código deben quedar escritas, como contamos en decisiones de arquitectura, pero en su sitio, no repetidas en cada especificación.
Comprobarla en cada cambio, no al final
Si la especificación solo se compara con el código cuando el cambio está terminado, la deriva aparece en el siguiente. La forma de evitarlo no es releerla más, sino hacer que se compruebe sola: que los criterios de aceptación se conviertan en tests que corren en cada integración, como explicamos en tu spec ya es un eval. El propio estudio apunta en esa dirección: revisiones programadas o tests de extremo a extremo en la integración continua pueden mostrar que código y especificación ya no coinciden.
DORA lo dice de forma más general en su modelo de capacidades de IA (septiembre de 2025): trabajar en lotes pequeños, un principio de siempre, es especialmente potente cuando se trabaja con IA. Un cambio pequeño con su especificación y su comprobación es fácil de revisar; uno grande, comprobado al final, no.
Una especificación que nadie comprueba es documentación que caduca. Si no hay un test que falle cuando el código se aparta de ella, no está guiando el desarrollo.
La respuesta honesta a «el SDD es burocracia»
Lo es si se aplica a todo y nadie mantiene lo escrito. El coste existe: el estudio lo encuentra en esfuerzo de planificación y de revisión, y un equipo lo contó también en tokens y en tiempo. Lo que cambia la cuenta es dónde se gasta.
El estudio lo resume en dos planos: el beneficio individual puede venir de aclarar la intención antes de delegar en el agente, y el del equipo depende de que el SDD sea un proceso compartido. Un marco conceptual publicado en agosto de 2026 (Díaz, Gayoso, Cimminio y Pérez) lo plantea igual desde la teoría: las especificaciones son el contrato entre las personas y los agentes, y distingue lo técnico que rodea al agente de las prácticas del equipo. Es un análisis basado en literatura, no un estudio empírico, pero coincide en lo importante: una plantilla no hace el proceso. Es lo que contamos en las plantillas de SDD ya son gratis.
Lo que nos quedamos para un equipo que empieza: decidir por escrito qué tipos de cambio llevan especificación, qué va en ella y qué comprobación automática la acompaña. Con esas tres decisiones, el SDD deja de ser un documento más y pasa a ser la forma de trabajar del equipo.
Si quieres ver con alguien de fuera dónde compensa en tu equipo, el diagnóstico es gratuito, y si en el diagnóstico no vemos diferencia, no hay Quick-start. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD. Cómo es el resto del camino está en AI-Accelerated Development. El método completo está en Spec-Driven Development con IA.
Preguntas frecuentes
¿Hay que escribir una especificación para cada cambio con Spec-Driven Development?
No, y los equipos que lo practican tampoco lo hacen. En el estudio de Carnegie Mellon y Google sobre cómo se practica el SDD, los entrevistados lo usaban de forma selectiva, sobre todo en funcionalidades nuevas, y no lo usaban para bugs, hotfixes ni tareas pequeñas. En la muestra analizada, se estima que el 82,0 % de las especificaciones describe funcionalidades nuevas.
¿Cuándo compensa escribir una especificación antes de dársela a un agente de código?
Nuestra propuesta: cuando el cambio es una funcionalidad nueva, cuando toca algo con riesgo (cobros, permisos, datos personales) o cuando pasa por varias personas o roles que tienen que entender lo mismo. Un bug acotado suele bastar con un test que lo reproduzca, y un cambio de texto o de estilo no necesita especificación.
¿Qué debe llevar una especificación y qué no?
Qué hay que construir y por qué, con criterios de aceptación que se puedan comprobar. El cómo (diseño, tareas, detalles de implementación) mejor en un documento aparte. En el estudio, el 77,6 % de los archivos de especificación lleva detalles de implementación, y los autores señalan que eso puede ayudar al agente pero hace que la especificación caduque antes.
¿Por qué caduca una especificación?
Porque el código cambia y la especificación no. Los autores lo llaman spec decay: la especificación se queda vieja a medida que cambia el código. Ocurre sobre todo cuando un cambio altera un comportamiento que describen otras especificaciones. En la muestra, el 81,5 % de los archivos de especificación tiene un solo commit registrado.
¿Cuándo hay que comprobar que la especificación y el código coinciden?
En cada cambio, no al final. Los participantes del estudio comprobaban especificación y código sobre todo al terminar el cambio, no con el tiempo, y quienes querían detectar la deriva después tuvieron que montarse sus propias comprobaciones. Si los criterios de aceptación se convierten en tests que corren en cada integración, la comprobación se hace sola.
¿Es el SDD burocracia?
Lo es si se aplica a todo y nadie mantiene lo escrito. El estudio encuentra que el comportamiento del agente es más fiable a cambio de más esfuerzo de planificación y de revisión. Ese coste compensa donde el cambio lo justifica y deja de compensar cuando se especifica un cambio trivial o cuando la especificación no se vuelve a mirar.
Fuentes
- Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu y Travis Breaux (Carnegie Mellon University y Google), «Spec-Driven Development as Prescribed and as Practiced», arXiv:2608.25202, versión 4 del 15 de octubre de 2026 (preprint).
- Jessica Díaz, Joaquín Gayoso, Andrea Cimminio y Jorge Pérez, «Spec-Driven Development for Agentic Software Engineering: Harnessing Human-Agent Teamwork», arXiv:2609.00252, 31 de agosto de 2026 (preprint).
- Kevin M. Storer y Derek DeBellis, «Introducing DORA's inaugural AI Capabilities Model», Google Cloud Blog, 23 de septiembre de 2025.
- Las cifras y citas de fuentes en inglés están traducidas por onext. La tabla de dónde compensa, la separación entre qué y cómo y la lectura de los hallazgos son elaboración propia de onext.
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 →