Apariencia
SDD No Son Tres Herramientas — Es una Pila de Ocho Fases
El artículo de Martin Fowler sobre herramientas SDD merece ser leído. Fowler tiene una rara habilidad para nombrar las cosas con precisión, y su enmarcación del desarrollo guiado por specs como respuesta al problema del "colapso de contexto" en la codificación asistida por IA es la articulación más clara del problema central que he visto publicada.
Pero el análisis se detiene en tres herramientas. Y ese punto de parada oscurece lo que hace que SDD sea difícil en la práctica.
Lo Que Fowler Acierta
Fowler identifica las tres herramientas en las que convergen la mayoría de las implementaciones SDD: un formato de spec, un mecanismo de validación y una puerta de aprobación. Tiene razón en que estas tres primitivas son necesarias. Una spec sin validación es una lista de deseos. La validación sin una puerta de aprobación genera caos — agentes implementando requisitos medio aprobados y luego dando marcha atrás.
Su observación de que el cuello de botella se ha desplazado de la generación de código a la verificación de corrección también es precisa y poco valorada. El problema no es que los agentes de IA escriban lentamente. El problema es que escriben con confianza en la dirección equivocada cuando los requisitos son ambiguos — y nadie lo nota hasta que la funcionalidad se lanza.
Donde el Marco de las Tres Herramientas se Queda Corto
Las tres herramientas que describe Fowler — spec, validar, aprobar — cubren el bucle de implementación. No cubren lo que ocurre antes, ni lo que ocurre después.
Antes de la implementación, existe un problema. Un desarrollador tiene una idea. Esa idea necesita ser externalizada (lluvia de ideas), estructurada en criterios de aceptación (spec), sometida a pruebas de estrés para verificar su completitud (desafío) y verificada para la preparación de implementación antes de que cualquier agente toque el código (verificación de preparación). Estas cuatro fases ocurren antes del paso de aprobación, y saltárselas es la razón por la que las specs llegan a la puerta de aprobación con criterios demasiado vagos para implementarse correctamente.
Después de la fusión, existe un problema diferente. El código que cumple los criterios de aceptación en el momento de la fusión puede apartarse de la spec semanas después, a medida que se acumulan cambios adyacentes. Las tres herramientas de Fowler no tienen nada que decir sobre esto. El ciclo aprobar-validar termina en la fusión.
Las Ocho Fases
Un ciclo de vida SDD completo tiene ocho fases:
1. BRAINSTORM → capturar la idea antes de que se disuelva
2. SPEC → estructurarla en criterios de aceptación verificables
3. CHALLENGE → examinar adversarialmente la spec en busca de vacíos y contradicciones
4. READINESS CHECK → verificar que la spec es implementable antes de comenzar a codificar
5. APPROVE → el humano da el visto bueno al contrato
6. IMPLEMENT → el agente ejecuta contra la spec
7. VALIDATE → verificar la implementación contra cada criterio
8. HEAL → detectar y corregir retroactivamente la deriva post-fusiónLas tres herramientas de Fowler mapean a las fases 5, 6 y 7. Eso deja cinco fases sin cubrir.
Las fases que los equipos más comúnmente omiten son la 3 (desafío) y la 8 (sanación). Omitir el desafío significa que los criterios de aceptación llegan a la aprobación con ambigüedades ocultas que solo surgen durante la implementación. Omitir la sanación significa que la deriva se acumula silenciosamente después de la fusión, y la spec se convierte en un artefacto histórico en lugar de un contrato vivo.
Por Qué Esto Importa para la Selección de Herramientas
Si evalúas las herramientas SDD preguntando "¿tiene un formato de spec, un mecanismo de validación y una puerta de aprobación?", casi todas las herramientas del panorama actual pasan. Esa es la pregunta equivocada.
La pregunta correcta es: ¿qué herramienta cubre las ocho fases, y qué fases requieren intervención manual?
Una herramienta que cubre las fases 5–7 pero no las 1–4 obliga a los desarrolladores a gestionar el flujo de trabajo pre-implementación fuera de la herramienta. Las fases de desafío y verificación de preparación — que existen precisamente para detectar lo que los humanos pasan por alto — están ausentes.
Una herramienta que cubre las fases 5–7 pero no la fase 8 trata la fusión como el final del ciclo de vida. Para bases de código de larga duración con frecuentes cambios adyacentes, esto es una brecha significativa.
El Marco de Fowler Sigue Siendo Útil
Nada de esto es una crítica al análisis de Fowler. El marco de las tres herramientas es una descripción precisa del flujo de trabajo SDD mínimo viable. Para equipos que adoptan SDD por primera vez, las fases 5, 6 y 7 son el lugar correcto para comenzar — ofrecen la mayor parte del valor con la menor sobrecarga.
El marco se convierte en un techo cuando los equipos intentan escalar. A mayor velocidad, con agentes en paralelo y specs de larga duración, las fases fuera de la ventana de las tres herramientas crean la fricción que limita el rendimiento.
La Pila Completa
Las herramientas SDD no son una lista de verificación de características. Son una tubería. La pregunta no es si una herramienta tiene soporte para specs — es si la herramienta cubre la tubería de extremo a extremo, incluyendo las fases que la mayoría de los análisis ignoran.
De la lluvia de ideas a la sanación, sin vacíos.
Lecturas adicionales: La Guía Completa del Desarrollo Guiado por Specs · Modo Autónomo: SDD extremo a extremo con /autonomous-sdd · Planu vs Herramientas SDD