El SDD original operaba en cuatro fases secuenciales y lineales:
$$ specify → plan → tasks → implement. $$
Cada fase produce un artefacto que alimenta la siguiente. La especificación se escribe primero, se aprueba, y luego el equipo ejecuta contra ella. El ciclo asume que es posible — y deseable — separar el pensamiento de la ejecución.
El ciclo clásico no es insuficiente porque sea malo. Falla porque fue diseñado para un tipo de trabajo que ya no es el trabajo.
Ese modelo tuvo sentido en un mundo donde el costo de construir era alto y el costo de pensar era bajo. Si equivocarse en la implementación era caro, valía la pena invertir tiempo en especificar bien antes de tocar código.
Ese mundo ya no existe.
Hoy el costo de construir colapsó. Un agente puede generar en minutos lo que antes tomaba días. El costo de pensar no cambió — pero el costo de pensar mal se multiplicó, porque ahora los errores de diseño se materializan más rápido y a mayor escala. En ese contexto, un ciclo que separa especificación de ejecución no protege al equipo: lo expone. La spec se desactualiza antes de que termine el sprint. El agente ejecuta contra un contexto que ya no refleja la realidad. El equipo corrige output sin actualizar el entendimiento.
La diferencia no es solo de nombres. Es de naturaleza. El SDDi reemplaza la secuencia lineal por un ciclo continuo de cinco momentos:
$$ entiende → conversa → modela → actúa → itera $$
En el ciclo clásico, cada fase tiene un dueño claro y un output definido. En SDDi, cada momento es una operación del sistema completo — el equipo humano y el agente juntos. No hay un momento donde el humano termina y el agente empieza. El agente está presente desde entiende, aportando perspectiva, detectando inconsistencias, haciendo preguntas que el equipo humano no se había hecho. El humano está presente en actúa, no para aprobar lo que generó el agente, sino para ver lo que el agente no puede ver.
La pregunta es legítima. Más pasos puede significar más overhead, más fricción, más tiempo antes de tocar código.
La respuesta está en qué tipo de fricción se está instalando. Hay dos tipos
SDDi instala fricción del segundo tipo. Los cinco momentos no son cinco puertas que el equipo debe atravesar. Son cinco tipos de pensamiento que el equipo necesita hacer de todas formas — la diferencia es si los hace explícita y colectivamente, o implícita e individualmente.
<aside> 💡
En el segundo caso, el costo no desaparece: se paga después, cuando el agente ya construyó en la dirección equivocada.
</aside>
Hay tres cambios estructurales:
<aside> 1️⃣
Tres momentos distintos donde antes había uno. Esto no es expansión burocrática. Es el reconocimiento de que "especificar" esconde tres operaciones cognitivas completamente diferentes:
Colapsar las tres en una sola fase es exactamente lo que produce specs que nadie entiende y que el agente interpreta mal.
</aside>
<aside> 2️⃣
separando la ejecución de la revisión del entendimiento. En el ciclo clásico, iterar significa corregir el output. En SDDi, iterar significa actualizar la spec — el estado del entendimiento colectivo — a partir de lo que el equipo aprendió construyendo. Esa distinción es crítica: un equipo que solo corrige output mejora el código. Un equipo que actualiza su entendimiento mejora su capacidad de construir.
</aside>
<aside> 3️⃣
el ciclo SDDi incluye explícitamente al agente como participante con perspectiva propia en cada momento. Esto no estaba en el ciclo clásico porque no podía estar — no había agente. En SDDi, el agente no es el destinatario del ciclo. Es co-autor de la spec desde el inicio.
</aside>