Ejemplo real

Un ejemplo real, de principio a fin

Nada explica mejor la diferencia que un caso concreto. Tomamos una feature realista y la resolvemos de las dos formas.

El encargo: “En el login, bloquea la cuenta tras 5 intentos fallidos durante 15 minutos y avisa al equipo de seguridad.”

Cómo se hacía “a lo loco” (vibe coding)

1. Le pegas el encargo a la IA en el chat.
2. Te genera un bloque de código; lo copias en auth.ts.
3. No compila a la primera → pegas el error → otro bloque → vuelves a probar.
4. “Funciona” en una prueba manual. Lo subes.

Qué queda mal: nadie revisó el diseño; no hay tests que prueben el bloqueo ni el aviso; no queda registro de por qué 15 minutos; repetiste el contexto del proyecto varias veces (tokens quemados); y dentro de seis meses tendrás que leer el código para adivinar qué hace.

Cómo se hace con método (SDD + harness)

1. Encuadra el entorno. Si el repo aún no está configurado, dejas que la IA lo haga (/aiws-configure). Ahora la IA conoce tus reglas, convenciones y el safety gate. Trabajas sobre una base, no en el vacío.

2. Explora. Pides explorar antes de tocar nada. La IA revisa cómo está hoy el login, qué ficheros se ven afectados y qué opciones hay (p. ej. dónde guardar el contador de intentos). Resultado: un breve explore.md.

3. Propón y aclara. Se escribe una propuesta: intención, alcance (bloqueo + ventana de 15 min + aviso), riesgos y plan de rollback. En clarify se resuelven dudas antes de fijar nada: ¿el aviso es email o webhook?, ¿el contador es por IP o por cuenta?

4. Especifica y diseña. La spec define el qué con escenarios verificables:

   Dado 4 intentos fallidos, cuando falla el quinto, entonces la cuenta queda bloqueada 15 min y se envía un aviso a seguridad.

   El diseño decide el cómo (dónde vive el contador, qué servicio de aviso) y verifica versiones con context7. Como toca autenticación, aquí entra el safety gate: no se debilita la validación “para que funcione”.

5. Divide en tareas y aplica. Un checklist por fases (contador → bloqueo → ventana → aviso → tests). Implementas marcando cada tarea. El contexto se carga bajo demanda: la IA no necesita todo el repo, solo lo relevante.

6. Verifica con evidencia y archiva. Ejecutas build + tests: un test prueba el bloqueo al quinto intento y otro el aviso. No vale “parece que funciona”. Al pasar, archivas: la spec se pliega al baseline y el cambio queda en el histórico.

El resultado, lado a lado

	A lo loco	Con método
Diseño	Improvisado	Decidido y razonado
Tests	Ninguno	Cubren bloqueo y aviso
Seguridad	“Ya lo miro”	Safety gate aplicado
Tokens	Repetidos en bucle	Acotados (ingeniería de contexto)
A 6 meses	Lees el código a ciegas	El porqué está documentado

Es más pasos, sí —pero cada uno te ahorra un problema mayor después. Esa es toda la idea de SDD.