SDD (Spec-Driven Development): el salto que exige desarrollar con IA sin perder el control

Desde que la IA entró en el desarrollo, hemos visto dos extremos:

• Vibe coding: iteración rápida, mucha intuición, buenísimo para prototipos y pruebas de concepto.

• Ingeniería “clásica”: procesos y controles pensados para un mundo donde el cuello de botella era escribir código.

El problema es que ahora el cuello de botella ya no es teclear. Con IA, el riesgo real es otro: construir rápido algo mal definido, difícil de validar y aún más difícil de mantener.

Aquí es donde encaja SDD, Spec-Driven Development.

Qué es SDD (de verdad)

SDD es un enfoque en el que la especificación se convierte en el artefacto central del desarrollo. No “documentación bonita” a posteriori. No “un par de bullets en un ticket”.

Una spec en SDD es:

• Versionable (vive en el repo).

• Revisable (se hace review como el código).

• Verificable (incluye criterios de aceptación y plan de validación).

• Ejecutable en la práctica (sirve para descomponer tareas, generar tests y guiar la implementación).

El código deja de ser la única “fuente de verdad”. Pasa a ser la materialización de lo que la spec define.

Por qué vibe coding se queda corto

Vibe coding no es “malo”. Es fantástico para:

• explorar,

• aprender,

• validar ideas,

• prototipar interfaces,

• llegar rápido a una demo.

Pero a medida que suben las apuestas (producción, usuarios, auditoría, compliance, rendimiento, seguridad), empieza a fallar por un motivo simple:

la IA es literalista. Si la intención está borrosa, el resultado también. Y la deuda técnica se acumula desde el minuto uno.

SDD no pretende quitar agilidad. Pretende cambiar dónde pones el rigor: antes, no después.

“Scrum ya no es suficiente” (matizado)

Aquí conviene ser preciso para no sonar a eslogan.

Scrum es un marco para gestionar trabajo. No define por sí solo:

• contratos,

• modelos de datos,

• reglas de negocio,

• criterios de aceptación fuertes,

• trazabilidad,

• validación automatizada.

Con IA, el equipo puede “producir” mucho más por sprint, sí. Pero si no tienes una capa fuerte de especificación y validación, lo único que escalas es el caos.

Así que no: no es que Scrum “no valga”. Es que necesitas una capa adicional. SDD suele ser esa capa.

Qué tiene una buena spec (y qué NO tiene)

Una spec buena no es un documento eterno. Es lo mínimo necesario para que un equipo pueda construir sin adivinar.

Debe incluir

1. Objetivo y contexto

• Qué problema resuelve y por qué importa.

• Qué éxito significa (métrica o criterio).

2. Alcance y no-alcance

• Qué entra.

• Qué queda fuera (para evitar el “ya que estamos”).

3. Requisitos funcionales

• Casos de uso.

• Reglas de negocio.

• Flujos principales.

4. Casos límite y errores

• Qué pasa si falta un dato.

• Qué pasa si el sistema externo falla.

• Qué pasa si hay concurrencia.

5. Contratos

• API (request/response), eventos, esquemas.

• Versionado, compatibilidad, códigos de error.

6. No funcionales

• Seguridad, auditoría, rendimiento, disponibilidad, trazabilidad, RGPD si aplica.

7. Criterios de aceptación

• Checklist verificable o Given/When/Then.

8. Plan de validación

• Qué tests deben existir.

• Qué métricas o logs se miran.

No debe convertirse en

• Un “waterfall” de 40 páginas.

• Una excusa para bloquear el avance.

• Un documento que nadie actualiza.

SDD solo funciona si la spec está viva y se trata como código: si cambia el comportamiento, cambia la spec.

Un ejemplo de plantilla mínima (copiable)

Título + versión
Objetivo
Alcance / No alcance
Actores
Flujo principal (pasos)
Reglas de negocio (invariantes)
API/Contratos (inputs, outputs, errores)
Datos (modelo mínimo)
No funcionales (seguridad, auditoría, rendimiento)
Criterios de aceptación (lista verificable)
Tests esperados (smoke + edge cases)
Riesgos / supuestos

En muchos casos, con 1-2 páginas bien hechas basta.

Cómo se trabaja en SDD (flujo práctico)

1. Spec v1
   Se escribe rápida pero completa en lo esencial.

2. Review de spec
   Negocio valida objetivo y alcance. Técnica valida contratos, casos límite, no funcionales.

3. Descomposición en tareas
   Tickets pequeños, ordenados, cada uno con su parte de spec o su referencia clara.

4. Implementación incremental
   Un ticket, un PR. Idealmente, cada PR actualiza spec si ha cambiado algo real.

5. Validación contra la spec
   Tests automatizados, contract tests si hay integraciones, y checklist de aceptación.

6. Mantenimiento
   La spec se versiona y se mantiene, igual que el código.

El impacto real cuando lo aplicas con IA

Con IA, la velocidad de implementación sube. Entonces, el valor diferencial pasa a ser:

• definir bien,

• validar bien,

• mantener bien.

SDD te da un marco para que la IA te multiplique sin destrozar consistencia, seguridad o mantenibilidad.

En otras palabras: el diferencial no será “usar IA”. Será tener un sistema de especificación y validación que permita escalarla sin perder el control.

Trampas habituales (para no vender humo)

1. Specs demasiado vagas
   Si parece “obvio”, no lo es. La IA rellena huecos con suposiciones.

2. Specs demasiado grandes
   Si tarda semanas en aprobarse, te has pasado. Divide por incrementos.

3. No actualizar la spec
   Si se queda desfasada, se convierte en ruido y el equipo la ignora.

4. No funcionales ignorados
   Seguridad, auditoría, rendimiento y trazabilidad deben estar en la spec, aunque sea de forma mínima.

Conclusión

SDD no es una moda más. Es una respuesta natural a un cambio de realidad: cuando generar código es barato, lo caro es definir con precisión y validar con rigor.

Mi apuesta para 2026: los equipos que lo hagan bien no serán “los que más IA usan”, sino los que mejor especifican y mejor validan.

Si quieres debatirlo: ¿en tu equipo estáis más en vibe coding, TDD/BDD clásico, o ya tratáis la spec como fuente de verdad?