⚡ AI Tools ES Formación

M4SDD en acción: de requisito a código listo para producción

Semana 2 de 4 Carga 2-3 horas Entregable Feature end-to-end con SDD documentado

4.1 El ciclo completo en la práctica

1 · Requisitopuede ser vago 2 · Spec9 bloques 3 · Revisiónchecklist 4 · Impl.la IA 5 · Validarcontra spec

Trabajas en 2 y 3. La IA hace el 4. Tú cierras el 5.

En los módulos anteriores aprendiste a escribir specs y a configurar el entorno. Ahora toca ejecutar el ciclo completo, de principio a fin, con un caso real.

El ciclo SDD completo tiene 5 fases:

FASE 1 — REQUISITO
  Recibes o defines algo que hay que construir.
  Puede ser vago. Eso es normal. Aún no es una spec.

FASE 2 — SPEC
  Conviertes el requisito en una spec de 9 bloques.
  Aquí está el trabajo de pensar. La IA no hace esto por ti.

FASE 3 — REVISIÓN DE SPEC
  Antes de implementar, validas la spec.
  Preguntas: ¿está todo cubierto? ¿hay ambigüedades? ¿los edge cases son reales?

FASE 4 — IMPLEMENTACIÓN
  Le das la spec a la IA. Ella implementa.
  Tu rol: guiar, no improvisar. Si la IA se desvía, la reconduces a la spec.

FASE 5 — VALIDACIÓN
  Verificas contra los criterios de la spec.
  Si pasa → cierre. Si no → iteras solo en lo que falla, con spec actualizada.

4.2 Fase 1: Del requisito a la spec

Los requisitos llegan de muchas formas. Algunas habituales:

Ninguno de estos es una spec. Son el input para construirla.

Cómo pasar de requisito a spec

Hazte estas preguntas y escribe las respuestas:

  1. ¿Qué sistema/módulo está implicado? → CONTEXTO
  2. ¿Por qué se hace esto? ¿Qué problema resuelve? → OBJETIVO
  3. ¿Qué tiene que pasar exactamente? ¿Qué input, qué output? → COMPORTAMIENTO
  4. ¿Qué no puede tocar o cambiar? ¿Hay restricciones técnicas? → RESTRICCIONES
  5. ¿Qué pasa si algo va mal? ¿Qué casos no obvios pueden aparecer? → EDGE CASES
  6. ¿Cómo sé que está bien hecho? → CRITERIOS DE VALIDACIÓN

Cuando puedes responder estas seis preguntas con precisión, tienes una spec.

4.3 Fase 2: La spec como contrato

Una vez escrita, la spec es el contrato entre tú y la IA.

Lo que el contrato implica:

Para que funcione como contrato, tienes que dárselo completo al inicio de la sesión. No vayas añadiendo bloques a mitad de la implementación. Eso rompe el contrato.

Cómo entregar la spec a la IA

En Claude Code o GitHub Copilot:

Lee esta spec completa antes de escribir una sola línea de código.
Cuando termines de leerla, confirma que la has entendido y describe
en un párrafo qué vas a implementar y en qué orden.
Solo cuando yo confirme, empieza.

[SPEC COMPLETA AQUÍ]

Este paso de confirmación antes de implementar es crítico. Te asegura que la IA ha procesado la spec y no ha empezado a generar desde el título.

4.4 Fase 3: Revisión de spec antes de implementar

Antes de darle la spec a la IA, párate 5 minutos y hazte esta checklist:

□ El título describe la acción, no solo el resultado
□ El contexto menciona los archivos/módulos que se van a tocar
□ El comportamiento describe TODOS los estados (success, error, loading, vacío)
□ Las restricciones son explícitas, no implícitas
□ Los edge cases cubren fallos de red, inputs inesperados y estados vacíos
□ Los criterios de validación son verificables (no "que funcione bien")
□ El fuera de alcance delimita el trabajo claramente

Si algún punto está vacío o vago, corrige antes de implementar. Cada ambigüedad no resuelta en la spec se convierte en una decisión arbitraria de la IA.

4.5 Fase 4: Implementación con la IA

El rol correcto durante la implementación

Tu rol durante la implementación NO es:

Tu rol SÍ es:

Señales de que la IA se ha desviado de la spec

Cuando detectes alguna de estas señales, para. No corrijas el código manualmente. Reconducela: "La spec dice X en el bloque de restricciones. Por favor ajusta."

Orquestación multi-paso

Para features complejas, divide la implementación en pasos explícitos:

Paso 1: Implementa solo la capa de datos (función fetchSubastas con filtro)
Paso 2: Cuando lo confirme, implementa el componente de UI
Paso 3: Cuando lo confirme, genera los tests de los criterios de validación

Esto te da puntos de control. No dejes que la IA genere todo de golpe si la feature tiene más de 3-4 archivos implicados.

4.6 Fase 5: Validación

La validación cierra el ciclo. Tiene dos niveles:

Nivel 1: Validación automática

Los tests generados desde los criterios de validación. Deben correr en CI o localmente antes de considerar la feature completa.

# Ejemplo
npm run test -- --testPathPattern=filtro-estado

Si un test falla, no arregles el test. Vuelve a la spec y verifica si el criterio era correcto. A veces el test descubre un criterio mal definido.

Nivel 2: Validación manual (si aplica)

Para criterios que no se pueden automatizar fácilmente:

Para cada criterio manual, documenta el resultado:

✅ Al recargar, el usuario sigue logueado
✅ Con 0 subastas activas → muestra mensaje vacío correcto
❌ Con ?estado=INVALIDO en URL → rompe (edge case no cubierto en spec → abrir nueva spec)

Qué hacer cuando falla algo

Si falla un criterio:

  1. Identifica si el fallo es de implementación o de spec
  2. Si es de implementación: reconduces a la IA con la spec en mano
  3. Si es de spec: actualizas la spec y documentas el cambio
  4. Nunca arregles sin saber cuál de los dos es

4.7 Ejercicio completo: ciclo SDD de principio a fin

Vas a ejecutar el ciclo completo con una feature real.

El requisito (te lo doy yo)

"Quiero que en cualquiera de mis proyectos, cuando la IA empiece una sesión de trabajo, reciba automáticamente el contexto del proyecto sin que yo tenga que pegarlo cada vez."

Este es el tipo de requisito que llega vago. Tu trabajo:

  1. Convertirlo en una spec completa de 9 bloques
  2. Revisar la spec con la checklist del 4.4
  3. Implementar con la IA siguiendo el protocolo del 4.5
  4. Validar con los criterios que tú mismo hayas definido

Entregable M4

Tres documentos:

  1. M4-Spec-Feature.md — La spec completa de la feature que implementaste
  2. M4-Implementacion-Log.md — Registro de la sesión: qué hiciste, qué desvíos detectaste, cómo los reconduces
  3. M4-Validacion.md — Resultado de la validación contra los criterios de la spec

Resumen del Módulo 4