Cuando los agentes de IA empezaron a escribir código de forma autónoma, algo quedó claro: la calidad del resultado dependía más de la claridad de las instrucciones que de la capacidad del modelo. Un prompt vago genera código vago. Una especificación precisa genera código que funciona.
Spec Driven Development (SDD) parte de esa observación y la convierte en metodología. No se trata de una moda más del ecosistema IA, sino de una evolución natural en la forma de concebir el software cuando quien escribe la mayor parte del código es un agente, no una persona.
Qué es Spec Driven Development
Spec Driven Development es un enfoque donde la especificación del software , el qué y el porqué, se define de forma completa y estructurada antes de escribir una sola línea de código. La spec se convierte en la fuente de verdad: el contrato entre la intención del producto y la implementación técnica.
No es lo mismo que Test Driven Development (TDD), donde escribes tests antes de código. En SDD, escribes la definición completa del comportamiento esperado: flujos de usuario, reglas de negocio, estructura de datos, criterios de aceptación y restricciones técnicas. Luego, un agente de IA (o un equipo humano) implementa siguiendo esa spec como guía.
La diferencia clave con el desarrollo tradicional es el orden:
- Desarrollo tradicional: requisitos vagos → código → tests → documentación (si sobra tiempo).
- TDD: tests → código → documentación.
- Spec Driven Development: especificación completa → implementación (por agente o persona) → verificación.
Por qué cobra sentido ahora
Este enfoque no es nuevo conceptualmente. La idea de definir bien antes de construir aparece en la ingeniería de software desde los años 70. Lo que ha cambiado es el contexto:
- Los agentes de IA codifican rápido, pero necesitan instrucciones precisas. Un agente como Claude, GPT-4 o Copilot puede generar cientos de líneas de código funcional en minutos. Pero si la instrucción es ambigua, el resultado será coherente con la ambigüedad. La spec elimina esa ambigüedad de raíz.
- El coste de iterar sobre una spec es mucho menor que iterar sobre código. Cambiar un párrafo en un documento de especificación toma minutos. Cambiar una implementación mal orientada puede costar días.
- La spec es reutilizable. Una buena especificación sirve para generar tests, documentación, diagramas y el propio código. Es un activo, no un trámite.
Beneficios concretos para equipos de desarrollo
Menos retrabajo
Cuando la implementación se guía por una spec revisada y validada, las sorpresas disminuyen. El equipo sabe qué se espera antes de escribir código, y los agentes de IA tienen un contexto suficiente para generar soluciones alineadas con la intención del producto.
Mejor comunicación entre perfiles
Las specs sirven como lenguaje común entre producto, diseño y desarrollo. Product managers describen comportamiento. Desarrolladores y agentes lo implementan. QA lo verifica. Todos leen el mismo documento.
Escalabilidad del uso de IA
Si un agente de IA recibe una spec completa, puede trabajar de forma más autónoma y consistente. Eso permite delegar más tareas de implementación sin perder control sobre la calidad del resultado.
Documentación viva
La spec no se archiva tras el sprint. Se mantiene actualizada y funciona como documentación de referencia para onboarding, auditorías y evolución del producto.
Comparativa de plataformas
varias herramientas han surgido para facilitar la creación, gestión y ejecución de specs. Cada una con un enfoque diferente:
| Plataforma | Enfoque | Formato spec | Integración con agentes | Licencia |
|---|---|---|---|---|
| Open Spec | Specs como código fuente, first-class citizens | Markdown + YAML frontmatter | Nativa: Cursor, Claude, Copilot, Windsurf, OpenCode | Open source (MIT) |
| SpecStory | Capturar prompts como specs versionables | Markdown en .specstory/ | Nativa: Cursor | Open source |
| Cursor Specs | Specs contextuales dentro del editor | Integrado en Cursor IDE | Propia: Cursor Agent | Propietaria |
| Claude Max / Specs | CLAUDE.md como spec de comportamiento | Markdown (CLAUDE.md) | Propia: Claude Code | Propietaria |
| Copilot Workspace | De issue a plan a implementación | Generado desde GitHub Issues | Propia: GitHub Copilot | Propietaria |
Análisis por plataforma
SpecStory
SpecStory toma un enfoque pragmático: captura los prompts que funcionan y los convierte en especificaciones versionables dentro de .specstory/. Es especialmente útil para equipos que ya usan Cursor y quieren ir documentando qué prompts generan mejores resultados. Su fortaleza es la fricción baja: no cambia tu workflow, lo mejora. La limitación es que está ligado al ecosistema Cursor y que las specs tienden a ser más prompts evolucionados que verdaderas especificaciones de producto.
Cursor Specs
Cursor ha integrado las specs como un ciudadano de primera clase dentro de su editor. Puedes definir specs contextuales que el agente de Cursor lee antes de generar código. La integración es fluida y la experiencia de uso es buena. El inconveniente principal es el lock-in: si tu equipo usa varios editores o agentes de diferentes proveedores, las specs de Cursor no son portables.
Claude Max / CLAUDE.md
Anthropic ha promovido CLAUDE.md como un archivo de contexto y comportamiento para Claude Code. No es exactamente SDD, pero cumple una función similar: definir reglas, convenciones y restricciones que el agente respeta al implementar. Es sencillo y efectivo para proyectos individuales o equipos pequeños. Para proyectos más grandes o multi-agente, se queda corto en estructura.
Copilot Workspace
GitHub Copilot Workspace automatiza el camino desde un issue hasta un plan de implementación y código. Es útil para equipos que viven en GitHub y quieren que el agente proponga su propio plan antes de codificar. La limitación es que las specs son generadas por la IA desde el issue, no escritas por el equipo. Eso reduce control sobre la definición del comportamiento.
Open Spec: nuestra opción preferida
De todas las opciones, Open Spec es la que mejor resuelve los retos reales de un equipo que quiere adoptar Spec Driven Development de forma seria y sostenible. Las razones:
Formato abierto y portable
Las specs en Open Spec se escriben en Markdown con YAML frontmatter. Nada de formatos propietarios, nada de lock-in con un editor o un proveedor de IA concreto. Si mañana cambias de agente o de IDE, tus specs siguen siendo válidas.
Agnóstica respecto al agente
Open Spec está diseñada para funcionar con cualquier agente: Cursor, Claude, Copilot, Windsurf, OpenCode y cualquier otro que respete el formato. Eso permite a cada persona del equipo usar la herramienta con la que se siente más cómoda, compartiendo las mismas specs.
Las specs son código fuente
En Open Spec, las specs se versionan en el repositorio junto al código. Se revisan en pull requests, se debaten en code review y se mantienen actualizadas como cualquier otro archivo del proyecto. Eso convierte la spec en un activo vivo, no en un documento que se escribe una vez y se olvida.
Soporte para SPEC.md
El formato SPEC.md de Open Spec incluye secciones estructuradas para objetivos, contexto técnico, restricciones, criterios de aceptación y dependencias. Esa estructura facilita que el agente tenga toda la información necesaria para implementar sin ambigüedades.
Open source
Licencia MIT. Puedes auditar el código, contribuir mejoras y adaptarlo a las necesidades de tu equipo sin depender de un proveedor comercial.
Cómo empezar con Spec Driven Development
Si quieres probar SDD en tu equipo, estos son los pasos que recomendamos:
- Elige una tarea pequeña. Un bug, una feature menor, una mejora de UX. No intentes spec-ar todo el sistema de golpe.
- Escribe la spec antes de tocar código. Describe qué quieres lograr, qué restricciones hay, qué criterios de aceptación deben cumplirse. Usa el formato SPEC.md de Open Spec.
- Deja que el agente implemente. Pasa la spec a tu agente de IA (Cursor, Claude, Copilot) y deja que genere el código.
- Revisa el resultado contra la spec. ¿Cumple los criterios de aceptación? ¿Respeta las restricciones? Si no, ajusta la spec antes de ajustar el código.
- Itera. Ajusta la granularidad de tus specs hasta encontrar el nivel que funciona para tu equipo y tus agentes.
Spec Driven Development no es una metodología más. Es una respuesta práctica a una realidad nueva: cuando quien escribe código es un agente de IA, la claridad de las instrucciones se convierte en el factor que determina la calidad del resultado.
Tu equipo necesita formacion en IA segura
El EU AI Act exige alfabetizacion IA para toda la plantilla desde agosto 2026. Nuestros cursos cubren compliance, agentes IA y gobernanza. FUNDAE puede subvencionar el 100% del coste.
