Apariencia
SDD vs TDD: Por Qué el Spec Driven Development Cambia las Reglas del Desarrollo Asistido por AI
La mayoría de los desarrolladores conocen TDD — Test Driven Development. Escribe un test que falla, hazlo pasar, refactoriza. Ha sido un pilar del buen código durante más de dos décadas. Pero con la llegada de los agentes AI, está emergiendo otro tipo de disciplina: el Spec Driven Development (SDD).
Este artículo desglosa qué hace cada enfoque, en qué se diferencian y por qué SDD se ha vuelto imprescindible para equipos que trabajan con herramientas AI como Claude, Cursor o Windsurf.
Qué es TDD
Test Driven Development es una práctica de micro-ciclos. El bucle es corto:
- Escribe un test que falla y que describe el comportamiento esperado
- Escribe el código mínimo para que el test pase
- Refactoriza sin romper el test
TDD opera a nivel de código. Su trabajo principal es mantener la implementación honesta: el test expresa qué debe hacer una función o módulo, y el código tiene que cumplir ese contrato.
Los beneficios son reales. TDD te obliga a pensar en las interfaces antes que en la implementación. Atrapa regresiones temprano. Crea documentación viva del comportamiento esperado. Los equipos que practican TDD consistentemente entregan código más mantenible.
La limitación también es real: TDD no te dice qué construir. Todavía necesitas decidir qué es la feature, qué acepta, qué devuelve, cómo maneja los casos límite y cómo interactúa con el resto del sistema. TDD asume que ya tomaste esas decisiones.
Qué es SDD
Spec Driven Development es una disciplina pre-implementación. Antes de escribir ningún código — y antes de que ningún agente AI escriba una sola línea — creas una especificación que define:
- Qué hace la feature (historia de usuario, criterios de aceptación)
- Cómo encaja en la arquitectura (archivos afectados, nuevos tipos, dependencias)
- Qué riesgos existen (casos límite, preocupaciones de rendimiento, complejidad del rollback)
- Cómo se mide el éxito (criterios concretos y verificables)
SDD opera a nivel de feature. Produce documentos — normalmente un archivo de Historia de Usuario y una Ficha Técnica — que sirven como contratos entre el desarrollador (o el agente) y el resultado esperado.
El ciclo se ve así:
- Escribe la spec (spec.md + technical.md)
- Obtén aprobación explícita del equipo o del product owner
- Implementa contra la spec
- Valida con quality gates automatizados
- Mergea solo cuando todos los criterios pasan
Las Diferencias Clave
| Dimensión | TDD | SDD |
|---|---|---|
| Alcance | Función / módulo | Feature / spec |
| Momento | Antes de escribir la función | Antes de escribir cualquier código |
| Artefacto | Archivo de test | Documento de spec + criterios de aceptación |
| Preocupación principal | "¿Este código hace lo que escribí?" | "¿Estamos construyendo lo correcto?" |
| Funciona bien para | Corrección de la implementación | Alcance de la feature, dirección del agente AI |
| Falla sin | Requisitos claros | Gate de aprobación antes de codificar |
Son complementarios, no competidores. TDD responde "¿es correcta esta implementación?" — SDD responde "¿es esta la implementación que acordamos construir?"
Por Qué los Agentes AI se Descarrilan Sin Specs
Aquí está el problema del mundo real: los agentes AI son muy capaces generando código, y prácticamente incapaces de mantener coherencia a largo plazo sin contexto estructurado.
Cuando le pides a Claude o Copilot que "añada una página de configuración de usuario", obtienes código. Pero:
- Puede contradecir una decisión tomada hace dos sprints
- Puede introducir un nuevo esquema de base de datos cuando ya tenías uno para los mismos datos
- Puede manejar los casos de error de forma diferente a tus patrones existentes
- En una sesión paralela, otro agente puede estar construyendo la misma feature desde un ángulo diferente
Sin una spec, cada sesión AI es un nuevo comienzo. El agente no tiene ningún contrato que cumplir, ningún criterio de aceptación que satisfacer y ninguna forma de saber cuándo ha terminado. El resultado es dispersión de features, inconsistencias y ese tipo de deuda técnica difícil de nombrar pero fácil de notar.
Con una spec, el agente tiene:
- Criterios de aceptación explícitos que debe satisfacer
- Las restricciones arquitectónicas que debe respetar
- Una definición de "hecho" que tanto tú como el agente pueden verificar
Cuándo Usar Cada Uno
Usa TDD cuando:
- Estás implementando un módulo bien definido con entradas y salidas claras
- Estás arreglando un bug y quieres prevenir regresiones
- Estás refactorizando y necesitas una red de seguridad
Usa SDD cuando:
- Estás empezando una nueva feature, aunque sea pequeña
- Trabajas con agentes AI (siempre)
- Varias personas o agentes pueden trabajar en la misma área
- La feature toca más de un archivo o capa
- Quieres un gate de aprobación explícito antes de escribir código
Usa los dos cuando: estás construyendo software en serio. SDD le dice a todos qué se está construyendo. TDD verifica que se construyó correctamente.
Cómo Ayuda Planu
Planu es un servidor MCP que trae la disciplina SDD directamente a tu flujo de trabajo con AI. Cuando instalas Planu, tu agente AI accede a herramientas que:
- Crean documentos de spec estructurados (
create_spec) con Historias de Usuario y Fichas Técnicas - Aplican un gate de aprobación antes de que empiece cualquier implementación
- Rastrean el estado de implementación contra los criterios de aceptación
- Validan que la spec está completa antes de marcarla como terminada
El flujo de trabajo con Planu se ve así:
Usuario: "Añadir soporte para login con OAuth"
Agente: [usa create_spec] → genera spec.md + technical.md
Usuario: revisa y aprueba la spec
Agente: [implementa contra la spec, hace seguimiento del progreso]
Agente: [usa validate_spec] → todos los criterios verificados
Merge cuando pasan los gatesEl agente no adivina el alcance. Tiene un contrato.
Primeros Pasos
SDD no requiere Planu — puedes practicarlo con cualquier formato de documento estructurado. Pero si quieres que la disciplina se aplique automáticamente dentro de tus sesiones AI, Planu se integra directamente con Claude, Cursor, Windsurf y cualquier agente compatible con MCP.
Lee la guía de primeros pasos para configurar Planu en menos de cinco minutos.
La spec es el contrato. TDD verifica el código. Juntos, cierran el bucle.