Análisis de las 7 Fases del Ciclo SDD para Crear Software con IA

Gerardo Cerda Neumann
hace 14 minutos
3 min de lectura

Hace unos pocos día me llegó la versión en papel del libro: "Spec Driven Dev" de Bezael Pérez. A fines de abril había comprado la versión en PDF la que presenta una forma muy ordenada de proponer el ciclo de SDD. En este comentario les comparto un análisis para entender las 7 fases que propone Bezael para aplicar este ciclo. Incluyo también una Infografía de resumen.

Imagen creada mediante el Prompt: Usando una estética de ciencia ficción de los años cincuenta crea una imagen que represente este concepto: "Análisis de las 7 Fases del Ciclo SDD para Crear Software con IA".

1. La frontera entre fases opcionales y obligatorias

Uno de los aciertos del modelo presentado es la distinción clara entre pasos exploratorios y fases que constituyen el núcleo indispensable de la ingeniería:

Fases opcionales (Investigación y Prototipo): se justifican ante tecnologías desconocidas, APIs no exploradas o la necesidad de evaluar criterios de diseño visual y de experiencia de usuario antes de formalizar el alcance. Si el dominio técnico ya es dominado por el equipo, pueden omitirse sin comprometer la estabilidad del sistema.
Fases obligatorias (PRD, Kanban, Loop de Ejecución y QA): representan la columna vertebral del método. Omitir el documento de requisitos o la descomposición en el tablero equivale a regresar a la improvisación. Prescindir de la verificación de calidad asume, erróneamente, que el agente interpretó de forma perfecta la especificación.

2. El PRD como definición del destino frente a la implementación

El Product Requirements Document (PRD) se sitúa como el artefacto primario y centro de gravedad del proceso. El texto enfatiza una directriz clave de la ingeniería de requisitos:

Especificar el qué y no el cómo: el documento debe describir con exactitud las condiciones observables de éxito, las restricciones operativas y el alcance fuera del sistema, en lugar de predeterminar librerías internas o algoritmos específicos.
Concisión y verificabilidad: el autor propone un límite cercano a las 500 palabras por requerimiento medio para evitar el ruido contextual que confunde a los modelos de lenguaje. Un PRD extenso suele esconder múltiples requerimientos sin desacoplar o intentos prematuros de prescripción arquitectónica.

3. Descomposición en unidades independientes: Vertical Slices y Tracer Bullets

La transición del PRD al tablero de trabajo (Kanban) requiere criterios específicos de modularidad para que un agente automatizado trabaje sin bloqueos:

Cortes verticales (Vertical Slices): se descarta la división clásica por capas horizontales aisladas (interfaz, capa de negocio, base de datos) porque generan tareas no comprobables de forma autónoma. Cada elemento de trabajo debe integrar el flujo completo de punta a punta para entregar una funcionalidad inmediatamente verificable.
Balas trazadoras (Tracer Bullets): la gestión de riesgos exige que las mayores incertidumbres técnicas o arquitectónicas encabecen la cola de ejecución. Si una suposición técnica resulta inviable, el impacto se detecta en la primera iteración y no al final del ciclo de entrega.
Relaciones de bloqueo explícitas: formalizar las dependencias de secuencia permite paralelizar tareas seguras y resguarda al agente de implementar código que luego deba descartarse.

4. El loop de ejecución y la supervisión humana del criterio técnico

Al delegar tareas al agente inteligente, el texto plantea un equilibrio entre la automatización y la responsabilidad profesional:

Modos de ejecución (autónomo vs. supervisado): patrones como el Ralph Loop permiten que el agente complete tareas de bajo riesgo de manera encadenada. No obstante, ante lógica de negocio sensible o reglas complejas, la revisión entre tareas intermedias previene la propagación de supuestos erróneos.
La lectura obligatoria del código: aunque las pruebas automáticas arrojen resultados conformes, la lectura del código generado sigue siendo obligatoria para el líder técnico. La verificación automatizada evalúa el cumplimiento de criterios funcionales, pero solo el criterio humano puede detectar patrones redundantes, malas prácticas de mantenibilidad o acoplamientos innecesarios.

5. Aseguramiento de calidad como criterio de salida y ciclo de retroalimentación

La etapa final redefine el papel del control de calidad en entornos asistidos por modelos generativos:

Colaboración en el plan de pruebas: el agente asume la tarea de formular la batería de pruebas y casos límite a partir del PRD, mientras que el profesional humano conserva la ejecución y auditoría de los escenarios críticos.
Circuito de retroalimentación cerrado: los hallazgos e inconsistencias detectados durante el aseguramiento de calidad no se corrigen con parches improvisados de última hora; se transforman en nuevas tareas que reingresan formalmente al ciclo de ejecución para preservar la trazabilidad y la integridad de la base de código.

En resumen, gráficamente NotebookLM lo presenta así: