Spec-Driven Development: origen, metodología, herramientas y lo que el hype no cuenta

tl;dr — SDD es una respuesta legítima a un problema real con agentes de IA. El concepto tiene sentido, las herramientas son inmaduras, el costo es alto y la evidencia de ROI es todavía casi toda anecdótica. Vale entenderlo. Vale desconfiar.

El problema que originó todo esto

Para entender por qué surgió Spec-Driven Development, hay que dar un paso atrás.

En 2025, agentes de IA como Claude Code, Cursor y Codex dejaron de ser un autocomplete glorificado y pasaron a ejecutar tareas complejas de forma autónoma. Con ello emergió el fenómeno del vibe coding: describes lo que quieres en lenguaje natural, el agente genera cientos de líneas de código y tú apruebas sin entender del todo lo que se hizo.

¿El resultado? Código que funciona hasta el momento en que hay que mantenerlo. Decisiones arquitectónicas invisibles. Deuda técnica acumulada a ritmo industrial.

El estudio más riguroso sobre el tema —realizado por METR en 2025 con desarrolladores experimentados en proyectos open source reales— concluyó que los desarrolladores que usaban herramientas de IA fueron, en promedio, 19% más lentos que sin ellas. No más rápidos. El motivo: los prompts no estructurados creaban bucles de debugging que consumían todo el tiempo ahorrado en la generación inicial de código.

Spec-Driven Development es el intento de la industria de resolver ese problema de raíz.

De dónde viene la idea

La idea de escribir especificaciones antes de escribir código no es nueva. Es tan antigua como la propia ingeniería de software.

1963: Margaret Hamilton, al gestionar el software de las misiones Apollo de la NASA, acuñó el término “ingeniería de software” porque los programas habían crecido más allá de la capacidad de cualquier persona para comprenderlos en su totalidad. Ella lo vio con claridad: esto es ingeniería, necesita proceso.

1968: La OTAN organizó una conferencia en Berlín que identificó formalmente la Software Crisis: los ordenadores ya permitían programas tan complejos que no podían gestionarse adecuadamente. El volumen de código había superado la capacidad humana de razonar sobre él.

1972: Dijkstra, en su discurso del Premio Turing, lo resumió así: “Mientras no había máquinas, programar no era ningún problema. Cuando teníamos pocos ordenadores débiles, programar se convirtió en un problema menor. Ahora tenemos ordenadores gigantescos, y programar se ha convertido en un problema igualmente gigantesco.”

La respuesta de aquella época fue el proceso: Waterfall como estándar del DoD, luego Agile en 2001, luego CI/CD en la nube haciendo viable el Agile a escala.

Ahora estamos en el siguiente ciclo. Drew Breunig, investigador que popularizó el término SDD en 2026, lo describió con precisión: “Nuestra crisis de software actual es nuestra incapacidad de gestionar bases de código complejas que los nuevos modelos permiten crear. Antes, el problema era que no conseguíamos mantener todo el código en la cabeza. Ahora ni siquiera conseguimos leer todo nuestro código.”

Los agentes de IA habilitan volumen waterfall al ritmo del agile. Ese es el problema que SDD intenta abordar.

Qué es Spec-Driven Development

SDD es una metodología de desarrollo que trata la especificación como el artefacto primario —no el código.

En lugar del ciclo tradicional de prompt → código → iteración, el flujo se convierte en:

Spec → Plan → Tareas → Código

La spec define la intención, las restricciones, los criterios de aceptación y la arquitectura antes de cualquier implementación. El agente de IA ejecuta entonces a partir de esa entrada estructurada, en lugar de interpretar una descripción vaga.

Una distinción importante: con herramientas como Spec Kit, Kiro y Tessl, la propia spec es generada por la IA. Describes el objetivo en lenguaje natural y el agente produce los archivos de especificación —típicamente requirements.md, design.md y tasks.md— que él mismo utilizará como contexto durante la implementación. La spec no es un documento escrito manualmente de antemano por analistas; emerge de la conversación entre el desarrollador y el agente, antes incluso del código.

Esto cambia el diagnóstico de los problemas clásicos con las especificaciones: la distancia entre spec y código ya no es de semanas ni de equipos distintos. Spec y código se generan en el mismo ciclo, con la misma herramienta, con apenas minutos de diferencia. El problema que persiste no es la separación temporal —es el trabajo previo, el costo en tokens, la degradación del contexto a lo largo de las iteraciones, y lo que ocurre tras el deploy cuando la realidad diverge de lo que estaba especificado.

Existen distintos niveles de adopción de SDD:

Spec-first: la spec se genera antes de la implementación y se usa como guía para esa tarea. Una vez completada, se descarta.

Spec-anchored: la spec se conserva tras la tarea para guiar la evolución y el mantenimiento futuro del sistema. Es un artefacto vivo que acompaña al código.

Spec-as-source: el nivel más ambicioso. La spec es el código fuente. El código generado es tan solo un artefacto compilado a partir de la spec, marcado con // GENERATED FROM SPEC - DO NOT EDIT. Tessl está intentando hacer esto viable.

El Triángulo SDD — y por qué el ciclo es más difícil de lo que parece

La aportación más honesta al debate vino de Breunig en marzo de 2026, tras construir el proyecto whenwords (una biblioteca open source con cero código —solo spec y 750 tests de conformidad—) y observar cómo evolucionaron otros proyectos similares.

Su aprendizaje central: SDD no es una ecuación lineal. Es un ciclo de feedback.

Propone el SDD Triangle: spec, tests y código son tres nodos que deben estar sincronizados en todo momento. Cuando el código avanza, la spec debe actualizarse. Cuando la spec cambia, hay que escribir nuevos tests. Cuando los tests fallan, el código debe cambiar —y a veces la spec también estaba equivocada.

El problema es que mantener estos tres nodos sincronizados es difícil:

• Escribir specs es difícil. Nunca son exhaustivas y se escriben antes de que el software encuentre el mundo real.
• Escribir tests es difícil. Incluso antes de los agentes, nadie disfrutaba escribiendo tests.
• Actualizar specs y tests tras la implementación parece overhead, especialmente cuando estás usando agentes precisamente para moverte rápido.
• Los LLMs toman decisiones silenciosas durante la implementación. Esas decisiones raramente regresan a la spec.

El resultado práctico: se escribe la spec, se genera el código, se lanza el producto. La spec queda desactualizada en cuestión de días. Nadie vuelve a actualizarla. El problema original —la intención perdida, las decisiones invisibles— simplemente migra de nivel.

El ecosistema de herramientas

El espacio de herramientas SDD explotó entre finales de 2024 y principios de 2026. Conviene entender las capas:

Capa 1 — Frameworks de spec: definen y gestionan los artefactos de especificación → Spec Kit, Tessl, Kiro, BMAD, OpenSpec, cc-sdd

Capa 2 — Sistemas de planificación y tareas: convierten specs en grafos de tareas ejecutables → Taskmaster, Agent OS, Beads, Feature-Driven-Flow

Capa 3 — Agentes de ejecución: escriben y modifican código → Claude Code, Cursor Agent, Codex, Devika, OpenDevin, CrewAI

Capa 4 — IDEs con IA: integran todas las capas en un único workflow → Kiro, Windsurf, Cursor, Claude Code, Copilot

La mayoría de los desarrolladores hoy solo usa la Capa 3 —que es exactamente donde vive el problema del vibe coding.

Tabla de herramientas relevantes

Cómo usarlo en la práctica: Kiro como ejemplo

Kiro es el punto de entrada más accesible para desarrolladores que ya usan VS Code. Es un fork de Code OSS (el núcleo open source de VS Code) construido por un equipo pequeño dentro de AWS, posicionado deliberadamente fuera del ecosistema AWS —no necesitas cuenta de AWS para usarlo.

Instalación

Accede a kiro.dev y descarga el instalador para tu sistema operativo. Inicia sesión con GitHub o Google.

El workflow en tres pasos

Paso 1 — Requisitos

Describes lo que quieres construir en lenguaje natural. Kiro lo traduce a notación EARS (Easy Approach to Requirements Syntax):

WHEN usuário submete formulário de login
  AND credenciais são válidas
THEN sistema deve autenticar o usuário
  AND redirecionar para o dashboard
  AND registrar o evento de login com timestamp

Esta notación impone restricciones explícitas y legibles por máquina. Revisas y ajustas el requirements.md generado antes de continuar.

Paso 2 — Diseño

Kiro analiza tu base de código existente y genera un design.md con decisiones arquitectónicas, elecciones de stack y estructura de componentes. Para un proyecto React + Node.js, verás algo como:

## Architecture

Frontend: React 18 com React Router v6
Backend: Express 4.x com middleware JWT
Database: PostgreSQL via Prisma ORM
Auth: bcrypt (salt rounds: 12) + JWT (access: 15min, refresh: 7d)
Testing: Jest + Supertest para integração

Revisas este documento antes de que se escriba una sola línea de código. Las discrepancias con la arquitectura real del proyecto se detectan aquí —no después de 400 líneas generadas.

Paso 3 — Tareas

Kiro genera un tasks.md con pasos de implementación discretos, secuenciados por dependencia:

- [ ] Task 1: Setup de banco de dados e schema de usuários
- [ ] Task 2: Endpoint POST /auth/register com validação Joi
- [ ] Task 3: Endpoint POST /auth/login com geração de tokens
- [ ] Task 4: Middleware de autenticação JWT
- [ ] Task 5: Endpoint POST /auth/refresh
- [ ] Task 6: Testes de integração para todos os endpoints

Tú controlas qué tareas ejecutar y cuándo. El agente implementa una tarea a la vez, con puntos de revisión entre ellas.

Steering files

Además de los tres documentos de spec, Kiro soporta steering files —archivos de configuración persistentes que definen estándares para toda la base de código:

# .kiro/steering/code-style.md
- Use TypeScript estrito, sem `any` implícito
- Prefira `async/await` sobre callbacks
- Nomes de variáveis em camelCase, constantes em SCREAMING_SNAKE_CASE
- Funções públicas devem ter JSDoc

Hooks

Kiro soporta hooks basados en eventos —agentes que se disparan automáticamente en respuesta a desencadenadores definidos:

{
  "hooks": [
    {
      "name": "security-audit",
      "trigger": "on-save",
      "agent": "Verifique vulnerabilidades de segurança no arquivo salvo"
    },
    {
      "name": "test-generator",
      "trigger": "on-file-create",
      "pattern": "src/**/*.ts",
      "agent": "Gere testes unitários para o novo arquivo"
    }
  ]
}

Lo que funciona bien

• Revisar un documento de diseño antes de la implementación es fundamentalmente distinto a revisar 500 líneas de código generado después. Los problemas emergen en el nivel adecuado.
• Los steering files eliminan un volumen enorme de prompts repetitivos sobre estilo y convenciones.
• El flujo de tareas secuenciales mantiene el contexto del agente enfocado —un problema a la vez, no un sistema entero.

Lo que no funciona bien

• Kiro generó 16 criterios de aceptación para un bug fix sencillo en pruebas independientes. Para cambios pequeños, el overhead es real.
• La generación de spec para features de complejidad moderada tarda entre 30 y 45 segundos. Eso duele en un flujo de desarrollo ágil.
• La notación EARS tiene curva de aprendizaje. No es intuitiva para quien nunca ha trabajado con especificaciones formales.
• Kiro usa el registro Open VSX de extensiones (no el de Microsoft), lo que implica la ausencia de soporte oficial para C# —una limitación seria para equipos .NET.
• El modo Autopilot (ejecución de múltiples tareas sin supervisión) produce resultados menos predecibles. La lógica de aprobación tarea por tarea es donde reside el valor real.

Precios

Durante el preview público: gratuito (con límites de interacciones). GA: Free (50 interacciones/mes) · Pro $19/mes (1.000 interacciones) · Pro+ $39/mes (3.000 interacciones)

Los problemas reales

1. Trabajo previo que va contra el instinto del desarrollador

La promesa de SDD con IA es que la spec se genera rápidamente —y de hecho así es. Pero “rápido” no significa “gratis”. Antes de cualquier línea de código útil, pasas por múltiples ciclos de revisión: revisas la spec generada, corriges intenciones mal interpretadas, ajustas el plan arquitectónico, apruebas o rechazas tareas. Cada ciclo exige atención humana real.

Para una feature de complejidad media, ese overhead puede ser menor que el costo de depurar código vibe-coded más adelante. Para un bug fix puntual, el costo supera el beneficio con amplio margen —Kiro generó 16 criterios de aceptación para una corrección sencilla en pruebas independientes. El trabajo previo no desaparece porque la IA genere la spec; cambia de naturaleza. En lugar de escribir, revisas y decides. Es menos costoso, pero no es cero.

2. Costo en tokens multiplicado en todas las fases

Cada fase de SDD (spec → plan → tareas → implementación) consume tokens antes de que se escriba una sola línea de código de producción. Con modelos de razonamiento, el uso agéntico puede ser 100 veces mayor que el uso estándar.

Las sesiones intensas de SDD con Claude Code alcanzan el límite de contexto con regularidad. El proceso de compactación automática lleva entre 3 y 12 minutos. El costo no es solo financiero —también es de tiempo e interrupción del flujo. Ningún benchmark público compara el costo total (tokens + tiempo de revisión humana) de SDD frente al desarrollo directo.

3. Degradación del contexto a lo largo de las iteraciones

Este es el problema menos discutido y quizás el más grave. Las specs generadas por IA se reinyectan en la IA durante la fase de implementación. Cada ciclo de compactación o reinicio de sesión pierde matices. El agente que implementa el código no tiene acceso pleno a las decisiones que el agente de especificación registró.

El resultado: el código empieza a divergir sutilmente de la spec a medida que el contexto se degrada. El bucle entre spec y código, que debería ser sincrónico, se convierte en una cadena de teléfonos descompuestos —cada fase amplifica los pequeños ruidos de la fase anterior.

4. Las specs se vuelven engañosas después del deploy

Con las herramientas modernas de SDD, la spec no está “lejos del código” —se genera en el mismo ciclo, con la misma herramienta, minutos antes de la implementación. El problema clásico de las especificaciones escritas por analistas desconectados de la realidad técnica no aplica aquí.

El problema que persiste es distinto: lo que ocurre después del deploy. Los edge cases solo aparecen en producción. El comportamiento real del usuario diverge del modelado. Los problemas de rendimiento emergen bajo carga. La spec no se actualiza. Si se usa para guiar el mantenimiento y la evolución futura (spec-anchored), una spec desactualizada se vuelve activamente engañosa: el agente confía en ella, genera código basado en una realidad que ya no existe, y el desarrollador solo lo descubre cuando el sistema falla.

La herramienta Plumb de Breunig intenta abordar esto: un CLI que se conecta al git commit, lee los traces del agente, extrae las decisiones tomadas durante la implementación y solicita la aprobación del desarrollador antes de actualizar la spec. Es un PoC, no producción —pero apunta en la dirección correcta.

5. Proliferación de artefactos sin curación real

Cada feature genera múltiples archivos markdown. La promesa implícita de que “el agente mantiene la spec actualizada” no se sostiene —alguien debe revisar cada cambio en la spec con el mismo rigor con que revisa el código. En la práctica, eso no ocurre. Las specs se acumulan, divergen del código y pasan a ser ruido en lugar de señal.

6. Las especificaciones no eliminan el no-determinismo

Una misma spec puede producir implementaciones distintas en ejecuciones diferentes. Mayor precisión reduce la variación, pero aumenta el costo de redacción. Y las specs mal escritas —el resultado más probable cuando la metodología es nueva para el equipo— producen código bien organizado que hace lo incorrecto.

7. Riesgo de waterfall con IA en el bucle

La crítica más estructural proviene de Thoughtworks y de análisis independientes: SDD tal como se practica actualmente corre el riesgo de ser waterfall con IA en el bucle. Sigues definiendo todo de antemano y esperando que la realidad coopere. Para el desarrollo exploratorio con requisitos genuinamente desconocidos, los enfoques orientados al contexto se adaptan mejor.

Cuándo tiene sentido usarlo

SDD en su formato actual tiene sentido para:

• Equipos enterprise que desarrollan sobre bases de código grandes y existentes donde el drift arquitectónico es costoso
• Entornos regulados donde los audit trails y la trazabilidad de requisitos son obligatorios (EU AI Act, sector financiero, salud)
• Dominios estables con contratos claros: APIs, esquemas de datos, reglas de conformidad
• Equipos con madurez en TDD o BDD que quieren extender esa disciplina a la capa de IA
• Emulación y portabilidad: el caso de uso donde SDD más brilla es reimplementar un sistema existente en otro lenguaje, usando los tests del sistema original como especificación

SDD probablemente es excesivo para:

• Proyectos en solitario y prototipos rápidos
• Desarrollo exploratorio donde los requisitos son genuinamente desconocidos
• Correcciones pequeñas o bugs aislados
• Equipos sin la disciplina de mantener las specs actualizadas tras la implementación

El diagnóstico honesto

SDD es una respuesta legítima a un problema real. El vibe coding genera código más rápido de lo que los equipos pueden gobernar. Las especificaciones son una herramienta para restaurar esa gobernanza.

Pero el paralelismo con TDD es instructivo. TDD tiene 25 años, cuenta con evidencia empírica extensa, y la adopción real en el mercado ronda el 8% en sentido estricto (escribir tests antes del código, de forma consistente). SDD está generando hype porque resuelve un problema visible de la era de los agentes, pero hereda el mismo desafío fundamental: los desarrolladores prefieren entregar. Cualquier metodología que añada trabajo previo luchará contra ese instinto.

La ausencia de crítica pública fácil de encontrar es en sí misma una señal. Cuando los beneficios son triviales de hallar y los tradeoffs no lo son, una metodología sigue en fase de marketing, no de madurez. Spec-Driven Development todavía no ha pagado ese precio de entrada.

Las herramientas que vale la pena seguir: Spec Kit por su flexibilidad open source e independencia de IDE, Kiro por sus workflows estructurados en IDE, Tessl por la visión más ambiciosa de spec-as-source (aún no comprobada), y Plumb como referencia del problema más difícil y no resuelto —mantener las specs vivas después de la implementación inicial.

Referencias

• The Rise of Spec Driven Development — Drew Breunig
• The Spec-Driven Development Triangle — Drew Breunig
• Spec-Driven Development Is Eating Software Engineering — Vishal Mysore
• Spec-Driven Development: Unpacking 2025’s key new practice — Thoughtworks
• Spec-Driven Development: When Architecture Becomes Executable — InfoQ
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl — Martin Fowler’s blog
• The Limits of Spec-Driven Development — Isoform
• GitHub Spec Kit
• Kiro IDE
• Tessl
• Measuring AI Impact on Experienced Developer Productivity — METR, 2025