Spec-Driven Development (SDD)
Spec-Driven Development surge como respuesta a una limitación cada vez más visible del desarrollo asistido por IA: la facilidad para generar código no garantiza que ese código sea correcto, mantenible, seguro o coherente con la arquitectura del producto.
En enfoques como el vibe coding, el profesional describe lo que quiere en lenguaje natural, la IA genera una solución y el equipo prueba, corrige y vuelve a pedir cambios hasta que algo parece funcionar. Este enfoque puede ser muy útil para prototipos, exploración rápida o herramientas internas de bajo riesgo. El problema aparece cuando se usa el mismo modo de trabajo para código de producción.
SDD cambia el orden del trabajo: primero se especifica, después se implementa. La spec se convierte en el contrato operativo entre el equipo humano y el agente de IA.
La spec no es solo un documento previo: es el artefacto primario del desarrollo, el que una persona revisa y aprueba y el que el agente consume para generar código. Por eso la revisión se desplaza del código a la spec, y SDD se organiza alrededor de las puertas de aprobación entre fases.
Qué problema resuelve
La IA puede generar código con mucha rapidez, pero esa rapidez desplaza el cuello de botella hacia la revisión. El equipo ya no dedica tanto esfuerzo a escribir código desde cero, sino a entender, verificar, corregir e integrar código producido por otro sistema.
SDD ayuda a reducir esa carga porque proporciona un criterio explícito contra el que revisar el resultado. El equipo no revisa el código preguntándose “qué habrá hecho la IA”, sino comparando la implementación con una especificación previamente acordada.
En la práctica, SDD busca reducir tres problemas habituales del desarrollo asistido por IA:
- Ambigüedad: cuando el prompt es vago, el agente toma decisiones implícitas que quizá no coincidan con la intención del equipo.
- Carga de revisión: cuanto mayor es el volumen de código generado, más difícil resulta detectar errores sutiles.
- Deuda técnica: si la IA genera soluciones plausibles pero inconsistentes con la arquitectura, el coste aparece después en mantenimiento, seguridad o evolución del producto.
La evidencia sobre la productividad real de la IA está en revisión. El ensayo controlado de METR de julio de 2025 midió que desarrolladores experimentados tardaban más con IA mientras creían ir más rápido; en febrero de 2026 METR anunció que rediseñaba el experimento, y su propia autora considera probable que la aceleración real sea mayor. El dato se cita con su fecha y su matización, y el argumento se sostiene en la brecha entre percepción y medición, no en la cifra. Lo que sí se sostiene, con evidencia más reciente, es el diagnóstico del coste: el informe de DORA sobre el retorno de la IA describe el impuesto de verificación (revisar código generado consume lo que la generación ahorra) y la curva J (la productividad cae antes de subir). DORA respalda el problema; no nombra las especificaciones entre los factores de retorno, así que no se le debe atribuir un aval de SDD.
Cómo funciona
SDD no es una herramienta concreta ni un plugin. Es una metodología de trabajo que puede implementarse con distintas herramientas, agentes o flujos de desarrollo.
El método tiene una columna vertebral estable: cuatro fases con un documento por fase.
- Requisitos: qué problema se resuelve, para quién, con qué comportamiento esperado y qué queda fuera del alcance.
- Diseño: decisiones técnicas, restricciones de arquitectura, integración con lo existente, datos, APIs y criterios no funcionales.
- Tareas: la implementación dividida en unidades pequeñas, revisables y ejecutables por un agente o por una persona.
- Implementación: el agente genera el código siguiendo la spec, y el equipo revisa, prueba e integra el resultado.
Las implementaciones de referencia han asentado además dos envolturas alrededor de ese núcleo. Antes de los requisitos, la constitución del proyecto recoge lo que se decide una vez para todo el proyecto (principios, estándares, arquitectura, límites de actuación del agente) y persiste por encima de las specs individuales; GitHub Spec Kit la crea con el primer comando de su flujo y en el resto del ecosistema vive en un fichero de instrucciones para agentes en la raíz del repositorio. Después de la implementación, la revisión de convergencia comprueba que lo construido coincide con lo especificado; es la única revisión del método que mira código, y sin ella nadie ha verificado que la implementación cumple la spec, que es donde empieza la deriva entre ambas.
La clave no está en escribir documentación extensa, sino en escribir documentación operativa: lo suficiente para que humanos y agentes compartan una misma interpretación del trabajo.
Puertas de aprobación
Entre cada par de fases hay un punto donde una persona con criterio revisa y aprueba el documento producido antes de pasar a la siguiente. En la primera puerta se comprueba que se resuelve el problema correcto; en la segunda, que el diseño es viable y coherente con el código existente; en la tercera, que las tareas, en ese orden, producen el diseño. Las tres revisan texto, no código, y por eso pueden participar personas que no programan. La razón es económica: un criterio de aceptación ambiguo se corrige en requisitos reescribiendo una frase, y en implementación descartando y regenerando código. Una puerta que se cruza sin leer no detecta nada y da una garantía falsa.
Proporcionalidad
La intensidad del proceso se ajusta al tamaño del problema. Un defecto menor no necesita una spec de cuatro fases; una funcionalidad que afecta a varias partes del sistema sí. La pregunta que calibra es una sola: ¿qué ocurre si el agente toma la decisión equivocada en este punto? Si la respuesta es «lo corrijo en dos minutos», ese punto no necesita especificarse; si es «pierdo horas o introduzco un defecto sutil», sí. Mal calibrado, SDD se convierte en burocracia de especificación, y el equipo acaba evitando el flujo entero, con las puertas que sí lo protegían.
Niveles de adopción
No todos los equipos aplican SDD con la misma intensidad. Una forma útil de entenderlo es distinguir tres niveles:
| Nivel | Cómo funciona | Cuándo tiene sentido |
|---|---|---|
| Spec-first | La spec se escribe antes de codificar, se usa para la tarea actual y puede descartarse al terminar. | Es el punto de entrada más sencillo. Útil para equipos que empiezan a ordenar su trabajo con IA. |
| Spec-anchored | La spec se conserva después de la implementación y se actualiza cuando evoluciona la funcionalidad. | Útil cuando la funcionalidad será mantenida, extendida o revisada más adelante. |
| Spec-as-source | La spec se trata como artefacto principal. El código se genera o regenera a partir de ella. | Es el nivel más avanzado y todavía experimental en muchos contextos. Requiere mucha disciplina y herramientas maduras. |
La mayoría de equipos empiezan por un enfoque spec-first. Pretender saltar directamente a spec-as-source puede generar más rigidez que valor si el equipo no tiene prácticas sólidas de validación, testing y revisión.
Herramientas del ecosistema
El instrumental alrededor de SDD es la capa más volátil del método: la implementación de referencia publica versiones con frecuencia y las alternativas aparecen y desaparecen, de modo que cualquier lista con nombres y versiones caduca en semanas. Lo que sí es estable son los criterios con los que se elige una herramienta:
- Flujo ligero o completo. Algunas implementan el flujo entero (constitución, fases, puertas y convergencia); otras se limitan a organizar las specs y sus cambios. El principio de proporcionalidad se aplica también a la elección del instrumento.
- Proyecto nuevo o código existente. Hay herramientas pensadas para empezar de cero y otras que se declaran brownfield primero, con capacidad de describir lo que ya existe.
- Línea de comandos o entorno integrado. La primera se añade al flujo del equipo y funciona con el agente que ya usa; la segunda impone su propio flujo y su propio agente a cambio de una experiencia más guiada.
- Gobernanza y trazabilidad. Cuánto necesita el equipo que la herramienta registre, versione y permita auditar; pesa más cuando el producto entra en el ámbito del Reglamento europeo de IA.
GitHub Spec Kit, la implementación más adoptada, publicó su versión 1.0 en agosto de 2026, y el método tiene ya entrada propia en el Technology Radar de Thoughtworks, formación reglada y literatura académica. Ninguna herramienta es imprescindible para aplicar SDD, y dominar una herramienta no es dominar el método.
Relación con las historias de usuario
SDD no sustituye a las historias de usuario. Las complementa.
La historia de usuario ayuda a expresar intención, usuario, necesidad y valor. Es un artefacto de conversación entre personas. La spec traduce esa intención a un formato más preciso, verificable y ejecutable por un agente de IA.
Una forma simple de distinguirlas:
| Artefacto | Función principal | Pregunta que responde |
|---|---|---|
| Historia de usuario | Comunicar valor y necesidad desde la perspectiva del usuario. | ¿Para quién construimos esto y por qué importa? |
| Spec | Definir comportamiento, restricciones y criterios de verificación. | ¿Qué debe producirse exactamente y cómo sabremos que está bien? |
En equipos con IA, una historia puede seguir siendo el punto de partida del backlog, pero las tareas que vaya a ejecutar un agente necesitan una spec suficientemente clara.
Relación con TDD y BDD
SDD no compite con TDD ni con BDD. Los tres enfoques son complementarios y pueden aplicarse juntos:
| Práctica | Foco | Pregunta que responde |
|---|---|---|
| SDD | Especificación. Define el qué y el por qué antes de implementar. | ¿Qué debe construirse exactamente y bajo qué restricciones? |
| TDD | Calidad a nivel de unidad. El test precede al código. | ¿Esta unidad de código hace lo que debe hacer? |
| BDD | Comportamiento del sistema. Escenarios en formato Given-When-Then. | ¿El sistema se comporta como esperan los usuarios y stakeholders? |
En la práctica un equipo puede usar:
- SDD para definir una funcionalidad completa,
- TDD para cada tarea de implementación individual
- y BDD para las validaciones de extremo a extremo.
SDD actúa como capa de contexto compartido que mantiene alineados a humanos y agentes durante todo el proceso.
SDD en equipos Scrum con IA
En Scrum con IA, las specs funcionan como puente entre los artefactos clásicos y el trabajo ejecutado por agentes.
La spec no sustituye al backlog ni al refinamiento. En el product backlog y en el refinamiento el equipo acuerda objetivo, contexto y prioridad; el contrato detallado (requisitos, diseño y tareas) madura dentro del sprint, como parte de hacer el trabajo y con la información que solo aparece al empezarlo. El error de integración más habitual es llevar la spec completa al product backlog: lo convierte en un depósito de documentos que caducan antes de ejecutarse y devuelve al equipo la sensación de cascada. La spec aprobada es la Definition of Ready de esa funcionalidad, dicha en el lenguaje de SDD.
El sprint pasa a contener dos tipos de elementos, specs por crear y specs aprobadas listas para implementar, y la planificación del sprint decide cuántos de cada tipo entran. La estimación se desdobla: el esfuerzo de especificación es humano y consume la capacidad real del equipo; el de implementación recae sobre todo en el agente. La reunión diaria se centra en el estado de las specs y sus desviaciones, y la revisión de código se hace contra la spec, no solo contra el criterio del revisor.
También se conectan con una Definition of Done reforzada. El código generado por IA no debería considerarse terminado solo porque compila o porque el agente afirma que funciona. Debe pasar revisiones técnicas, pruebas, controles de seguridad y revisión humana.
En equipos con IA, la spec no elimina la responsabilidad humana. El agente puede generar la implementación, pero el equipo sigue siendo responsable de validar que el incremento cumple los criterios de calidad, seguridad y valor esperados.
SDD y agilidad
Una objeción habitual es que SDD “suena a cascada”: requisitos, diseño, tareas e implementación antes de tener software funcionando.
La objeción merece tomarse en serio. Si SDD se convierte en documentación pesada, aprobación burocrática y bloqueo del aprendizaje, entra en conflicto con la agilidad. Pero SDD no tiene por qué aplicarse así.
La diferencia está en el uso de la spec. En un enfoque ágil, la spec no es un contrato cerrado contra el cambio, sino un artefacto vivo para reducir ambigüedad antes de delegar trabajo a una IA. Puede iterarse, dividirse, contrastarse con usuarios y revisarse conforme aparece nueva información.
SDD comparte con la cascada la secuencialidad, pero difiere en tres ejes. El alcance: la secuencia se aplica a cada incremento, no al proyecto entero, y el ciclo completo se mide en horas o días. El feedback: llega en cada puerta de aprobación, no al final. La reversibilidad: las fases previas a la implementación son documentos de texto, y modificarlos es trivial frente a reescribir código. Además, la spec es una categoría nueva de documentación, la documentación operativa: no informa a una persona ni cumple un trámite, es el insumo que el agente consume para producir software que funciona, y por eso la preferencia del Manifiesto Ágil («software funcionando sobre documentación extensiva») no le aplica del mismo modo.
La objeción tiene defensores con nombre y conviene leerlos. François Zaninotto (Marmelab, noviembre de 2025) tituló su crítica «Spec-Driven Development: The Waterfall Strikes Back» y enumera fallos reales: documentos enormes que nadie lee, pérdida del contexto del código, revisión duplicada y falsa sensación de seguridad. Son los antipatrones del método visto desde fuera. El Technology Radar de Thoughtworks mantiene SDD en el anillo «Assess», sin promoverlo a «Trial»: recomienda evaluarlo cuando los requisitos son ambiguos, los equipos están distribuidos o hace falta trazabilidad, y advierte de que puede no compensar en problemas triviales.
El criterio práctico es sencillo: si la spec ayuda a entregar software funcionando con menos errores, mejor aprendizaje y menor deuda técnica, refuerza la agilidad. Si se convierte en un requisito documental que retrasa la validación, la debilita.
Cuándo usar SDD
SDD resulta especialmente útil cuando:
- el código generado por IA va a llegar a producción;
- la funcionalidad afecta a datos, seguridad, permisos, facturación o experiencia crítica de usuario;
- existen restricciones de arquitectura que el agente debe respetar;
- el equipo trabaja sobre un producto existente, especialmente en contextos brownfield;
- varias personas o agentes deben coordinarse sobre una misma funcionalidad;
- el coste de revisar código ambiguo es mayor que el coste de escribir una buena spec.
Puede ser excesivo cuando el objetivo es explorar una idea muy temprana, crear un prototipo desechable o validar una hipótesis en un carril rápido de aprendizaje. En esos casos, puede tener más sentido empezar con vibe coding y pasar a SDD cuando la idea merezca convertirse en producto robusto.
SDD y la IA
SDD cobra especial relevancia con la IA generativa porque los agentes de código son muy sensibles a la calidad del contexto. Cuando la instrucción es vaga, el agente completa huecos con patrones probables. A veces acierta. Otras veces introduce decisiones invisibles que el equipo descubre tarde.
Una buena spec reduce esa libertad no deseada. Define comportamiento esperado, límites, dependencias, criterios de aceptación, restricciones técnicas y casos borde. No convierte a la IA en infalible, pero mejora la calidad de la delegación.
En este sentido, SDD transforma el papel del desarrollador. El valor no desaparece: cambia de lugar. Gana peso la capacidad de escribir specs, diseñar arquitectura, revisar críticamente outputs de IA y decidir qué debe automatizarse y qué debe permanecer bajo control humano.
Limitaciones
SDD tiene limitaciones que conviene conocer antes de adoptarlo:
- Escribir buenas specs es difícil. Requiere claridad de pensamiento, conocimiento del dominio y la disciplina de pensar antes de actuar. En proyectos donde los requisitos raramente están completamente formulados antes de la implementación, la spec puede convertirse en un artefacto aspiracional más que operativo.
- El overhead puede ser desproporcionado en tareas pequeñas. Para funcionalidades simples o correcciones de bugs menores, el proceso de especificación puede generar más trabajo del que ahorra. SDD tiene más sentido cuando la complejidad de la funcionalidad justifica la inversión previa.
- Las specs no eliminan el no-determinismo de los modelos. Una especificación detallada reduce la libertad no deseada del agente, pero no la elimina. Los modelos de lenguaje pueden ignorar instrucciones, excederse en su interpretación o generar outputs que cumplen la spec literalmente pero no en espíritu. La revisión humana sigue siendo necesaria.
Error frecuente
Confundir SDD con documentación en cascada. SDD no consiste en escribir documentos extensos para congelar el plan antes de construir. Consiste en crear especificaciones operativas, revisables y suficientemente precisas para que un agente de IA pueda ejecutar trabajo sin inventar decisiones críticas. Si la spec impide aprender, iterar o responder al cambio, se está aplicando mal.
Recursos
📊 Guía didáctica SDDRecursos · Scrum Manager
🏦 SDD en equipos ágilesSkill Arena · Scrum Manager
Referencias
- AGENTS.md.
- Beck, Kent et al. (2001). “Manifesto for Agile Software Development”, AgileManifesto.org.
- Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR.
- Böckeler, Birgitta. (2025). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, MartinFowler.com.
- Díaz, Gayoso, Cimmino y Pérez (2026), “Spec-Driven Development for Agentic Software Engineering”, ArXiv.
- DORA. (2026). “ROI of AI-assisted Software Development”, DORA.
- GitClear. (2025). “AI Copilot Code Quality: 2025 Look Back at 12 Months of Data”, GitClear.
- GitHub. (2025). “Spec-driven development with AI: Get started with a new open source toolkit”, GitHub Blog.
- Mavin, Alistair. EARS.
- METR. (2026). “We are changing our developer productivity experiment design”, METR.
- OpenSpec.
- Scrum Manager. (2026). SDD – Spec Driven Development en equipos ágiles. Scrum Manager.
- Scrum Manager. (2026). Scrum en equipos con IA. Scrum Manager.
- Thoughtworks. Technology Radar, “Spec-driven development”, Thoughtworks.
- Wessling, Jens. (2025). “We Asked 100+ AI Models to Write Code. Here’s How Many Failed Security Tests”, Veracode.
- Yeret, Yuval. “Is Spec-Driven Development a step forward or back for product development?”, YuvalYeret.
- Zaninotto, François. (2025). “Spec-Driven Development: The Waterfall Strikes Back”, Marmelab.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.