Spec Driven Development: qué es y qué propone

El contexto: del vibe coding al caos productivo

Para entender Spec-Driven Developmen (SDD) o, hablando en nuestro idioma: desarrollo guiado por especificaciones, es bueno empezar conociendo el problema que intenta solucionar. En febrero de 2025, Andrej Karpathy (cofundador de OpenAI y exdirector de IA en Tesla) acuñó el término vibe coding en un tweet que se hizo viral:[1]

"Hay un nuevo tipo de programación que llamo 'vibe coding', donde te dejas llevar completamente por las vibraciones, abrazas los exponenciales, y olvidas que el código siquiera existe. [...] Acepto todo siempre, ya no leo los diffs. Cuando recibo mensajes de error, simplemente los copio y pego sin comentarios, y normalmente eso lo arregla."

Para proyectos de fin de semana y prototipos rápidos, dejarse llevar por la IA puede funcionar, pero tiene limitaciones: código aparentemente correcto, pero con bugs sutiles, arquitecturas inconsistentes, vulnerabilidades de seguridad, y la incomodidad de no conocer la lógica que implementa el código generado.

Los datos son reveladores: según Y Combinator, el 25% de las startups de su cohorte de invierno 2025 tenían bases de código generadas en un 95% por IA.[2] Eso suena impresionante si no te preguntas: ¿quién entiende y mantiene ese código?

Qué es Spec Driven Development

Spec Driven Development propone, en esencia que la especificación preceda y guíe al código. No es un marco de trabajo ni una metodología prescriptiva como scrum. Es más bien un enfoque de trabajo que propone:

1. Escribir primero una especificación clara de lo que se quiere construir: objetivos, reglas de negocio, criterios de aceptación, restricciones técnicas.

2. Usar esa especificación como fuente tanto para humanos como para agentes de IA.

3. Generar código a partir de la spec, no de prompts improvisados.

Como lo resume GitHub en su documentación de Spec Kit: "En este nuevo mundo, mantener software significa evolucionar especificaciones. [...] El código es el enfoque de última milla."[3]

Los tres niveles de SDD

Birgitta Böckeler, de Thoughtworks, propone una taxonomía útil para entender las diferentes implementaciones:[4]

• Spec-first: Escribes la spec antes de codificar, la usas para la tarea en curso, y luego la descartas. Es el nivel más básico.

• Spec-anchored: La spec se mantiene después de completar la tarea y se usa para evolución y mantenimiento del feature.

• Spec-as-source: La spec es el artefacto principal. Solo editas la spec, nunca tocas el código directamente. El código se regenera desde la especificación.

La mayoría de herramientas actuales operan en el nivel spec-first, algunas aspiran a spec-anchored, y solo unas pocas experimentan con spec-as-source (como Tessl Framework).

La relación con IA: el catalizador del resurgimiento

Aunque la idea de "especificar antes de codificar" está en el origen de la ingeniería de software, SDD resurge porque los LLMs necesitan contexto estructurado para generar código coherente.

Cuando se le da a un agente de código un prompt vago como "hazme un login", está adivinando arquitectura, patrones, validaciones y flujos de error. Cuando se le facilita una especificación detallada que define exactamente qué debe pasar, el código resultante tiene muchas más probabilidades de hacer lo que necesitas.

La spec funciona como un "super-prompt" persistente y versionable. Como describe el equipo de Kiro (AWS): "Una especificación es una especie de super-prompt (versionado, legible por humanos)."[5]

Herramientas del ecosistema

El ecosistema de herramientas SDD está creciendo rápidamente:[6]

• GitHub Spec Kit: Toolkit open source que proporciona un flujo estructurado: Constitution → Specify → Plan → Tasks → Implement. Funciona con Copilot, Claude Code y otros.

• Kiro (AWS): IDE basado en VS Code con flujo integrado de Requirements → Design → Tasks.

• Tessl Framework: Explora el nivel spec-as-source con mapeo 1:1 entre specs y archivos de código.

• BMAD Method: Usa agentes virtuales (Analyst, Product Manager, Architect) para generar PRDs y specs de arquitectura.

SDD, TDD y BDD: primos cercanos, no competidores

Si trabajas con metodologías ágiles, probablemente te preguntes cómo encaja SDD con prácticas que ya conoces. La buena noticia: no son excluyentes, son complementarias.[7]

• TDD (Test Driven Development): Tests primero. Escribes un test que falla, luego el código para pasarlo. Excelente para calidad a nivel de unidad, pero no captura el intent de producto completo.

• BDD (Behavior Driven Development): Comportamiento primero. Escenarios en formato Given-When-Then que describen cómo se comporta el sistema. Fuerte para alineación con stakeholders, pero deja decisiones técnicas abiertas.

• SDD (Spec Driven Development): Especificación primero. Define el qué y el por qué, añade un plan técnico, y descompone en tareas. La spec es el ancla que mantiene a todos (humanos y agentes) alineados.

En la práctica, puedes usar SDD para definir el feature completo, TDD para cada tarea individual, y BDD para validaciones end-to-end. Como dice Beam.ai: "SDD te dice qué y por qué. BDD verifica comportamiento en todo el sistema. TDD asegura corrección a nivel de código. Estas prácticas funcionan bien juntas."

La tensión con Agile (y cómo resolverla)

Aquí viene la pregunta incómoda: el Manifiesto Ágil dice "software funcionando sobre documentación extensiva". ¿No contradice SDD ese principio al pedir especificaciones detalladas upfront?

La respuesta corta: depende de cómo lo implementes.

La respuesta larga: SDD no propone documentación extensiva estilo waterfall. Propone especificaciones vivas, ejecutables y versionadas que evolucionan con el código. Como GitHub lo describe: "Spec-Driven Development no se trata de escribir documentos de requisitos exhaustivos que nadie lee. Tampoco se trata de planificación waterfall."[3]

En la práctica, SDD funciona bien a nivel de feature o sprint. No estás especificando todo el producto de antemano; estás especificando la siguiente funcionalidad con suficiente detalle para que un agente de IA pueda implementarla correctamente.

Consideraciones críticas y limitaciones

Ningún enfoque es perfecto. Estas son las consideraciones más relevantes en el ámbito de las discusiones profesionales:

El problema humano

Como señala Daniel Sogl en DEV Community: "El problema principal no es la IA, es el factor humano. SDD requiere que los desarrolladores especifiquen sus intenciones con precisión. [...] Después de más de 10 años en desarrollo de software, rara vez he experimentado proyectos donde los requisitos estuvieran completamente formulados antes de la implementación."[8]

Escribir buenas specs es difícil. Requiere claridad de pensamiento, conocimiento del dominio, y la disciplina de pensar antes de actuar.

Overhead vs. beneficio

Birgitta Böckeler de Thoughtworks probó varias herramientas SDD y encontró que para tareas pequeñas, el proceso era desproporcionado: "Cuando pedí a Kiro que arreglara un pequeño bug, el documento de requisitos lo convirtió en 4 'user stories' con 16 criterios de aceptación [...] Era como usar un mazo para romper una nuez."[4]

SDD tiene más sentido para features medianos a grandes donde la inversión upfront se amortiza en menos correcciones posteriores.

Falsa sensación de control

Las ventanas de contexto son más grandes, pero eso no significa que la IA siga todas las instrucciones. Böckeler observó: "Frecuentemente vi al agente no seguir todas las instrucciones. [...] También vi al agente excederse porque seguía instrucciones demasiado ávidamente."[4]

Las specs ayudan, pero no eliminan el no-determinismo de los LLMs. Todavía necesitas revisar y validar.

¿Revisar markdown o código?

Algunas herramientas generan cantidades masivas de archivos markdown. Como comenta Böckeler: "Honestamente, preferiría revisar código que todos estos archivos markdown. [...] Eran repetitivos y tediosos de revisar."[4]

Una buena herramienta SDD debería proporcionar una experiencia de revisión de specs genuinamente mejor que revisar código, no peor.

Entonces, ¿merece la pena?

Como con cualquier práctica emergente, la respuesta honesta es: depende.

SDD probablemente te beneficie si:

• Trabajas regularmente con agentes de código IA
• Tus proyectos tienen complejidad media-alta
• Valoras la trazabilidad y la documentación viva
• Tu equipo puede invertir tiempo en aprender un nuevo flujo de trabajo

Probablemente no lo necesites si:

• Solo haces prototipos rápidos o proyectos personales
• Tu trabajo consiste principalmente en fixes pequeños y mantenimiento
• Prefieres un control directo y granular sobre cada línea de código

Si decides probarlo, el consejo del equipo de AI Native Dev es pragmático: "Empieza con un feature. No especifiques toda tu aplicación. Elige una funcionalidad bien entendida y escribe una spec detallada. Ve cómo rinde tu agente de IA."[9]

Conclusión

Spec Driven Development representa un intento serio de traer estructura al caos productivo del desarrollo asistido por IA. No es un framework formal, sino una filosofía que propone: define primero lo que quieres construir, con suficiente detalle para que tanto humanos como agentes puedan trabajar alineados.

El término todavía está en evolución (algunos ya hablan de "difusión semántica"[4]), las herramientas son experimentales, y hay debates legítimos sobre su aplicabilidad. Pero el principio subyacente —pensar antes de generar, especificar antes de implementar— es tan válido hoy como lo era antes de que existieran los LLMs.

Como resume el equipo de AI Native Dev: "Estamos todos descubriendo esto juntos, y los patrones que emerjan vendrán de experiencias compartidas entre cientos de equipos."[9]

Si trabajas con IA para generar código, vale la pena experimentar con SDD, aunque sea informalmente. Al menos, te obligará a pensar con más claridad sobre lo que realmente quieres construir. Y eso, con o sin IA, siempre es una buena práctica.

Fuentes citadas

[1]: Andrej Karpathy en X (Twitter), 2 de febrero de 2025: x.com/karpathy/status/1886192184808149383 [2]: "Vibe coding" - Wikipedia. Datos de Y Combinator: es.wikipedia.org/wiki/Vibe_coding [3]: GitHub Blog - Spec-driven development with AI: github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai [4]: Birgitta Böckeler, Thoughtworks - Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl: martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html [5]: Kiro - The future of AI spec-driven software development: kiro.dev/blog/kiro-and-the-future-of-software-development [6]: Microsoft for Developers - Diving Into Spec-Driven Development With GitHub Spec Kit: developer.microsoft.com/blog/spec-driven-development-spec-kit [7]: Beam.ai - Spec Driven Development: The Future of Building with AI: beam.ai/agentic-insights/spec-driven-development [8]: Daniel Sogl - Spec Driven Development: A initial review, DEV Community: dev.to/danielsogl/spec-driven-development-sdd-a-initial-review-2llp [9]: AI Native Dev - Spec-Driven Development: 10 things you need to know about specs: ainativedev.io/news/spec-driven-development-10-things-you-need-to-know-about-specs