SDD · Código Sin Siesta · 2026

Spec-Driven
Development

Escribir primero el contrato de comportamiento.
Menos ambigüedad, menos retrabajo, más calidad de equipo.

TDD BDD API-First OpenAPI Especificaciones
Alejandro de la Fuente

Alejandro de la Fuente

Technical Leader · NTT Data · GDNE

🌐 🐙 💼
El punto de partida

¿Qué pasa cuando programamos sin spec?

🩺

Diagnóstico

Sin un contrato previo de comportamiento, cada iteración añade incertidumbre en lugar de reducirla. El equipo decide en caliente, en cada PR, sobre qué significa "estar terminado".

~40% del esfuerzo de un sprint se va en aclarar lo que ya estaba "hecho"
3× coste de arreglar un bug funcional descubierto en QA vs en spec

Síntomas que reconocemos

🌫️ Requisitos ambiguos
Frase tipo "Que sea como el flujo de pago, pero más simple"
💥 Producto, backend y frontend interpretan tres cosas distintas. Reuniones para reabrir lo cerrado.
🔁 Retrabajo estructural
Frase tipo Sprint 3: "esto no era lo pedido"
💥 Implementamos rápido, validamos tarde y rehacemos diseño y código crítico.
🧪 Tests desconectados
Frase tipo Cobertura 90% · bugs en producción
💥 Las pruebas validan detalles técnicos, no comportamiento de negocio. Falsa sensación de seguridad.
💡

El bug funcional nace en el momento en que decidimos no escribir la spec. Todo lo demás es manifestarlo más tarde y más caro.
Definición operativa

SDD ordena el flujo, la spec es la fuente de verdad

📐

Definición

SDD no reemplaza el desarrollo: lo ordena. La especificación se escribe primero como contrato observable; el diseño técnico, la implementación y los tests se derivan de ella.

🏛️ Analogía

Como un arquitecto que firma planos antes de levantar muros: cualquier desviación se discute con el plano en la mano, no improvisando con el ladrillo ya puesto.

Bucle canónico

01
📝 Especificar

Capturar intención y comportamiento observable. La spec es contrato, no documento.

02
🗺️ Planificar

Validar escenarios y criterios con producto, backend y frontend antes de tocar código.

03
⚙️ Ejecutar

Implementar contra la spec. Tests y diseño se derivan de ella, no al revés.

04
✅ Verificar

Comprobar que comportamiento y tests cumplen la spec. Cierre explícito por feature.

💡

El bucle es el mismo en todas las herramientas SDD del ecosistema. Lo que cambia es cuánto orquestan y dónde ponen los gates.
Niveles de adopción · Böckeler 2026

Tres niveles bajo el mismo nombre "SDD"

Cada nivel hereda del anterior. Casi todas las herramientas son spec-first; pocas aspiran a anchored; solo una persigue spec-as-source en serio.

01
Spec-first La spec arranca el flujo

La spec se redacta antes de codificar. Tras cerrar la tarea, la spec se descarta o queda muerta. Cada nueva evolución empieza con spec nueva.

Herramientas Kiro · GSD · Spec Kit (en la práctica)
02
Spec-anchored La spec sigue viva

La spec se mantiene editable durante toda la vida de la feature. En cada cambio se reedita primero la spec; el código se ajusta detrás.

Herramientas OpenSpec · Spec Kit (aspiracional)
03
Spec-as-source Solo la spec se edita

El humano edita solo la spec; el código se regenera con marcadores tipo // GENERATED FROM SPEC. Hereda riesgos históricos de MDD + no-determinismo LLM.

Herramientas Tessl (private beta)
🧠

Otra distinción útil de Böckeler: spec ≠ memory bank. La spec describe una feature; el memory bank (Cline: memory-bank, Kiro: steering/, Spec Kit: constitution.md) describe el proyecto entero y vive aparte.
Por qué pagamos el coste

Cuatro retornos verificables

🎯 +alineación

Alineación técnica y funcional

Producto y desarrollo discuten sobre escenarios concretos, no sobre interpretaciones.

Aparece en Sprint 1
🧱 −deuda

Menos deuda accidental

El diseño técnico nace con restricciones explícitas y evita reescrituras tempranas.

Aparece en Sprint 2–3
🧪 +propósito

Tests con propósito

Las pruebas cubren criterios de aceptación reales, no solo detalles internos.

Aparece en Sprint 3+
🚀 −rampa

Onboarding más rápido

Nuevos miembros entienden el sistema leyendo specs vivas y ejecutables.

Aparece en Meses 3+
Los 4 retornos no son simultáneos
Alineación
Menos deuda
Tests con propósito
Onboarding
Sprint 1 Mes 3+
💡

El retorno aparece cuando la spec se mantiene viva, no cuando se escribe una vez y se archiva. SDD es una disciplina, no un entregable.
Decisión de aplicación

Cuándo SDD paga

🛡️ Crítico

Dominios con reglas complejas

Pagos, inventario, compliance. La spec captura invariantes que un test aislado no protege.

🧑‍🤝‍🧑 Equipos

Squads múltiples y handoffs frecuentes

La spec evita la "interpretación de pasillo" entre equipos que no comparten daily.

⚠️ Alto coste

Features donde un fallo cuesta caro

Compliance, dinero o reputación. El coste de la spec es siempre menor que el del fallo.

🗺️ Largo plazo

Roadmaps con trazabilidad

Productos longevos donde "por qué decidimos esto" importa tanto como "qué decidimos".

💡

La pregunta no es "¿podemos usar SDD?" sino "¿el coste de no tenerla supera el coste de mantenerla?". Si la respuesta es sí, paga.
Anti-patrones

Cuándo SDD no paga

⚡ 1 día

Prototipos de feedback inmediato

Validar visualmente con stakeholders. La spec llega cuando la idea sobrevive al primer contacto.

🛠️ Bajo riesgo

Scripts internos efímeros

Tareas de un solo uso, herramientas internas sin SLA. La spec es overhead innecesario.

🔬 Exploración

Spike técnico sin requisitos

Si aún no sabemos qué construimos, especificarlo es ficción. Primero spike, después spec.

📚 Anti-patrón

Spec como burocracia

Documento muerto que nadie consulta. Si la spec no se ejecuta ni se valida, es papel.

💡

SDD es una inversión, no un decreto. Aplicarla donde no paga la convierte en burocracia y mata la confianza del equipo en el método.
Metodologías + Ecosistema

SDD enmarca, las herramientas amplifican

📜
SDD Spec primero

Contrato de producto y diseño técnico como fuente de verdad. Tests y comportamiento se derivan.

🧪
TDD Test primero

Diseño emergente desde tests unitarios. Útil dentro del marco que define la spec.

🎭
BDD Comportamiento primero

Escenarios en lenguaje ubicuo. Traduce la spec a casos verificables con producto.

Ecosistema SDD 7 herramientas, mismo bucle: especificar → planificar → ejecutar → verificar
GSD Orquestación profunda
  • Paralelismo por oleadas
  • Subagentes aislados (~200k)
  • Verificación + UAT
Mejor para Proyectos grandes en Claude Code
Spec Kit Oficial GitHub · gates fuertes
  • Greenfield-first
  • ~800 líneas de spec
  • Multi-agente (Copilot, Claude, Cursor…)
Mejor para Greenfield medio-grande con gobierno
★ Recomendada
OpenSpec Brownfield-first · ligera
  • ~250 líneas/spec
  • 25+ asistentes soportados
  • Multi-cambio en paralelo
Mejor para Mantener código legado iterativo
Taskmaster AI PRD → tareas
  • Descompone PRDs en backlog
  • Integración MCP nativa
  • Cursor / Windsurf / Roo
Mejor para Tu entrada natural es un PRD
PAUL AC formales · cierre disciplinado
  • UNIFY obligatorio
  • In-session sin subagentes
  • Calidad sobre velocidad
Mejor para Disciplina de cierre y AC
Kiro VS Code de Amazon · ligera
  • 3 documentos por feature
  • Memory bank "steering"
  • Workflow Req → Design → Tasks
Mejor para Features con User Stories formales
spec-as-source
Tessl Private beta · regenera código
  • // GENERATED FROM SPEC
  • CLI + MCP server
  • Reverse-engineering de código
Mejor para Experimentar spec-as-source
💡

Ninguna es universalmente superior. La metodología SDD es el valor real; la herramienta sólo amplifica. Dos pueden combinarse (p. ej. OpenSpec + GSD).
De la spec al código

Caso real: alta de usuario

📜

Spec

fuente de verdad
Escenario feliz 
Dado un email válido y no registrado,
cuando se solicita alta,
entonces se crea el usuario
y se publica `user.created` exactamente una vez.
Conflicto controlado 
Dado un email ya registrado,
cuando se solicita alta,
entonces responde 409
con código semántico `EMAIL_ALREADY_REGISTERED`.
Invariante 
Para todo intento de alta,
se audita el evento
incluso si la transacción falla.
⚙️

Derivaciones

se generan, no se inventan
🧱
Modelo

Validación con Zod a partir de la spec; tipos compartidos cliente/servidor.

🧪
Tests

Test de contrato API + integración con DB y bus de eventos.

📡
Observabilidad

Métrica `user.created.count` y traza por `request_id`.

Sin SDD

Empezamos por el endpoint, descubrimos los conflictos en QA, parcheamos el evento publicado dos veces en producción.

💡

La spec no añade trabajo: cambia el momento en el que lo hacíamos, moviendo las decisiones difíciles al punto más barato para tomarlas.
Cierre

De la intuición al contrato

01 La especificación ejecutable es el contrato: todos hablan el mismo idioma.
02 SDD reduce ambigüedad antes de escribir una sola línea de código.
03 TDD, BDD y API-First son instancias del mismo principio: spec primero.
04 El retrabajo cae cuando el equipo valida comportamiento, no código.
05 Empieza pequeño: una feature crítica, dos sprints, mide el impacto.
Siguiente paso

Piloto de 2 sprints

Una feature crítica. Dos métricas: PRs reabiertos por interpretación y tiempo hasta aprobación en QA. Si ambas mejoran, se extiende. Si no, se revisa.

⭐ Herramienta sugerida: OpenSpec

Recursos

🔗 Presentación publicada🔗 Repositorio GitHub🔗 tellmealex.dev

Esta presentación fue construida con agentes de IA.

Código Sin Siesta · 2026
1 / 10
Navegación