¿Qué es Spec-Driven Development (SDD)?

¿Qué es?

Spec-Driven Development (SDD) es una disciplina de trabajo con agentes de IA donde cada fase del ciclo de desarrollo deja un artefacto formal y verificable antes de avanzar a la siguiente: una propuesta, una especificación, un diseño técnico, una lista de tareas. No es una herramienta ni un framework puntual — es un principio de organización que cualquier harness puede implementar a su manera.

La alternativa habitual (pedirle a un agente "implementá X" en un solo prompt) funciona para cambios chicos, pero se rompe rápido en proyectos reales: el agente toma decisiones de alcance, arquitectura y edge cases sin que nadie las revise, y esas decisiones quedan enterradas en una conversación que nadie vuelve a leer.

SDD ataca ese problema separando el ciclo en fases explícitas — típicamente propuesta, especificación, diseño, tareas, implementación, verificación y archivo — cada una con su propio artefacto revisable antes de seguir.

Modelo mental

Piénsalo como la diferencia entre pedirle a un contratista "hazme una casa" y pedirle "hazme una casa, pero primero muéstrame los planos, después el presupuesto por partida, y recién después empiezas a construir". En el segundo caso, cada entrega es un punto de control donde puedes decir "esto no", antes de que el error cueste una pared entera.

Estas fases son genéricas — cualquier implementación de SDD las nombra a su manera. Los comandos concretos que ves más abajo (/sdd-new, /sdd-spec...) son los de gentle-ai, una suite entre varias que aplican el mismo principio en la industria — por ejemplo, GitHub Spec Kit usa su propia sintaxis de slash commands.

Cada flecha es un punto donde un humano puede aprobar, pedir cambios o frenar — antes de que el agente siga a la fase siguiente con una base equivocada.

¿Cómo se usa?

En la práctica, SDD se implementa con skills o comandos que materializan cada fase como un artefacto en disco, no solo como texto en el chat:

/sdd-new nombre-del-cambio      # propuesta: qué y por qué
/sdd-spec                        # especificación: requisitos, criterios de aceptación
/sdd-design                      # diseño técnico: cómo, con qué decisiones
/sdd-tasks                       # lista de tareas ordenadas y acotadas
/sdd-apply                       # implementación tarea por tarea
/sdd-verify                      # validación contra el spec original

Cada fase lee el artefacto de la anterior — el diseño no se inventa solo, responde a la spec; las tareas no se inventan solas, responden al diseño. Eso es lo que evita que el agente "improvise" arquitectura a mitad de la implementación.

¿Cuándo usarlo / cuándo no?

Conviene cuando:

• El cambio toca varios archivos o componentes y las decisiones de diseño importan.
• Vas a necesitar trazabilidad — poder responder "por qué se hizo así" meses después.
• Trabajas en equipo y el spec o el diseño necesitan revisión antes de implementar.
• El feature es lo bastante grande como para que "una sola conversación" pierda el hilo.

Es exceso cuando:

• El cambio es de una línea o un fix trivial — el overhead de cinco fases no se justifica.
• Estás explorando o prototipando y todavía no sabes qué quieres construir.
• La tarea es puramente mecánica y no hay decisión de diseño real que documentar.