M1Fundamentos: qué es SDD y por qué importa

Semana 1 de 4 Carga 2-3 horas Entregable Tu primera spec

1.1 El problema que SDD resuelve

Antes de definir qué es SDD, hay que entender qué falla sin él.

Cuando usas IA para programar sin método, ocurre esto:

Tienes una idea o un requisito vago en la cabeza.
Se lo describes a la IA más o menos como te sale.
La IA genera código. Parece que funciona.
Empiezas a probarlo. Hay cosas que no cuadran.
Corriges con otro prompt. La IA arregla unas cosas y rompe otras.
Repites hasta que "más o menos funciona" o te rindes.

Este ciclo tiene un nombre: vibe coding. No es desarrollo. Es improvisación cara.

El problema no es la IA. El problema es que tú nunca definiste con precisión qué querías. La IA no puede adivinar lo que no articulas. Cuando el input es vago, el output es aleatorio.

SDD resuelve esto en la raíz: obligarte a pensar antes de pedir.

1.2 Qué es Spec-Driven Development

Definición:
SDD es un método de desarrollo en el que cada unidad de trabajo (feature, refactor, bug fix, integración) empieza por una especificación escrita, precisa y verificable — antes de tocar código.

La spec no es un comentario. No es un ticket de Jira. No es un README. Es un documento estructurado que responde a cuatro preguntas:

¿Qué contexto existe? — Qué sabe la IA sobre el sistema, el estado actual, las restricciones.
¿Qué comportamiento se espera? — Qué tiene que hacer exactamente el código que se va a generar.
¿Qué restricciones aplican? — Qué no puede hacer, qué patrones debe seguir, qué no debe tocar.
¿Cómo se valida? — Qué tests o criterios confirman que el resultado es correcto.

Con esas cuatro respuestas escritas, le das a la IA un contrato claro. Ella ejecuta. Tú validas contra la spec. No hay ambigüedad.

1.3 El ciclo SDD

Requisito → Spec → Implementación → Validación → Cierre.

REQUISITO
    ↓
  SPEC  ← (aquí está el trabajo real)
    ↓
IMPLEMENTACIÓN (la IA)
    ↓
VALIDACIÓN (contra la spec)
    ↓
  CIERRE o ITERACIÓN

El trabajo humano de valor está en la spec. La implementación es delegable casi al 100% a la IA. La validación es rápida si la spec tiene criterios claros.

1.4 SDD vs. otras aproximaciones

Aproximación	Cómo funciona	Resultado típico
Vibe coding	Prompt vago → código → corrección → loop	Caos, deuda técnica, frustración
Prompt engineering	Prompt mejor redactado → código	Mejora marginal, sigue siendo frágil
Ticket-driven	Ticket de Jira → prompt → código	Depende de la calidad del ticket
SDD	Spec estructurada → implementación → validación automática	Predecible, mantenible, escalable

La diferencia clave: en SDD el pensamiento va delante del código, siempre.

1.5 Por qué el testing es parte de la spec (no del final)

En el desarrollo tradicional, los tests vienen al final. En SDD, los criterios de validación se escriben en la spec, antes de implementar.

¿Por qué? Porque si no sabes cómo vas a verificar que algo funciona, tampoco sabes exactamente qué quieres que haga.

Los criterios de validación te obligan a ser preciso. Y una vez escritos, la IA puede generar los tests automáticamente desde la spec.

Principio: Si no puedes escribir cómo validar algo, es que aún no has terminado de pensar qué quieres.

1.6 Cuándo usar SDD

SDD aplica a casi todo, pero especialmente cuando:

Vas a construir algo que tardará más de 30 minutos en implementar
La feature tiene dependencias con otras partes del sistema
Trabajas en un proyecto que otros (o tú mismo en el futuro) van a mantener
Quieres que la IA genere código consistente con el estilo y arquitectura existentes
Necesitas validar que el resultado cumple requisitos de negocio, no solo que "compila"

No vale la pena escribir una spec completa para un cambio de dos líneas obvio. Para todo lo demás, sí.

1.7 SDD y tu método PIE

Tu método PIE (Planificar, Implementar, Evaluar) es compatible con SDD de forma natural:

Planificar → es donde nace la spec
Implementar → la IA ejecuta desde la spec
Evaluar → validación contra los criterios de la spec

En el Módulo 6 integraremos SDD completamente en tu flujo PIE. Por ahora, quédate con que no son métodos distintos: SDD es la capa técnica de PIE.

Ejercicio M1 — Tu primera spec

Instrucciones

Elige algo real que tengas pendiente de construir o mejorar en cualquier proyecto tuyo. Puede ser pequeño. No importa el tamaño, importa que sea real.
Escríbelo siguiendo esta estructura mínima:

CONTEXTO:
(Describe brevemente el sistema o proyecto. Qué existe. Qué estado tiene.)

COMPORTAMIENTO ESPERADO:
(Qué tiene que hacer exactamente la funcionalidad que vas a construir.
Sé específico. Nada de "que funcione bien". Qué input, qué output, qué flujo.)

RESTRICCIONES:
(Qué no puede hacer. Qué patrones debe respetar. Qué no debe tocar.)

CRITERIOS DE VALIDACIÓN:
(Cómo sabrás que está bien hecho. Qué tests o comprobaciones lo confirman.)

No te preocupes por hacerlo perfecto. El objetivo es escribir tu primera spec y detectar dónde te cuesta ser preciso — eso ya es aprendizaje.

Entregable M1

Documento con tu primera spec en texto plano. Puedes guardarlo en esta carpeta como: M1-Entregable-PrimeraSpec.md

Una vez la tengas, compártela con Claude para revisión y feedback. Eso abre el Módulo 2.

Resumen del Módulo 1

SDD resuelve el problema raíz del vibe coding: la falta de precisión antes de pedir.
Una spec responde a: contexto, comportamiento, restricciones y validación.
El ciclo es: Requisito → Spec → Implementación → Validación.
Los criterios de validación van en la spec, no al final.
SDD es compatible con tu método PIE: es su capa técnica.