La forma mas rapida de desperdiciar tokens es empezar a codear sin un plan. Lo aprendi por las malas.
Una tarde le pedi a Claude Code que construyera un sistema de cache para mi API de Spotify. Sin spec, sin requisitos claros, solo "hazlo". El agente empezo rapido — creo archivos, modifico rutas, agrego variables de entorno. Cuarenta minutos despues tenia un sistema que no manejaba fallbacks, usaba keys inconsistentes y habia roto la ruta existente. Descarte todo y empece de cero.
El problema no era el agente. El problema era yo. Le di velocidad sin direccion.
El problema de "simplemente hazlo"
Los agentes de IA son rapidos. Demasiado rapidos para trabajar sin rumbo. Cuando les dices "construye X" sin definir que significa X exactamente, el agente toma decisiones por ti. Algunas acertadas, muchas no.
El resultado tipico:
- Reescrituras en bucle — El agente construye algo, le dices que no era eso, construye otra version, le dices que casi, construye otra. Tres iteraciones despues has consumido mas tokens que si lo hubieras planificado.
- Perdida de contexto — A los 30 minutos la ventana se compacta. Sin artefactos escritos, el agente olvida las decisiones que tomaron juntos. Empiezas de nuevo.
- Decisiones de arquitectura implicitas — El agente elige patrones, nombra archivos, estructura modulos. Si no definiste eso antes, ahora tienes deuda tecnica generada por IA.
No es un problema de capacidad del agente. Es un problema de input. Basura entra, basura sale — aplica igual a prompts que a archivos de Figma.
Que es SDD en un parrafo
Spec-Driven Development es un pipeline practico: antes de escribir codigo, creas artefactos que definen que vas a construir y como. No es una metodologia religiosa ni un framework pesado. Son fases concretas — Explorar, Proponer, Spec, Disenar, Tareas — que puedes recorrer en 10 minutos o en una hora dependiendo de la complejidad. El punto es que cuando el agente empieza a ejecutar, sabe exactamente que hacer.
Las fases que importan
Cada fase produce un artefacto concreto. No documentacion por documentar — informacion que el agente necesita para trabajar bien.
Pipeline SDD — Haz clic en cada fase
Mapa del codebase: dependencias, patrones existentes, limitaciones
"El proyecto usa Zustand para estado global, Tailwind v4 con tokens OKLCh, y no tiene tests configurados."
El agente investiga. Tu validas que entendio bien.
Exploracion — Entender antes de decidir
El agente investiga tu codebase primero. Lee tus archivos de configuracion, analiza dependencias, identifica patrones existentes. No asume — pregunta al codigo.
Esto evita el error clasico: construir algo que ya existe, o usar un patron incompatible con el resto del proyecto. Cinco minutos de exploracion ahorran treinta de reescritura.
Propuesta — Un parrafo de intencion
Antes de tocar codigo, articulas en un parrafo que vas a hacer, por que y como. Parece trivial, pero te obliga a pensar. Si no puedes explicar el cambio en tres oraciones, probablemente no lo entiendes lo suficiente para delegarlo.
La propuesta es tu contrato con el agente. "Vamos a hacer esto, de esta forma, por esta razon." Todo lo que venga despues se evalua contra ese parrafo.
Spec — Que significa "terminado"
Requisitos concretos, escenarios edge, criterios de aceptacion. No prosa — items verificables. "Si Redis no responde, la API devuelve datos directamente." "El TTL es configurable via variable de entorno."
La spec es lo que sobrevive cuando el contexto se compacta. El agente puede perder la conversacion entera, pero si tiene la spec, puede retomar desde donde lo dejo.
Tareas — Pasos que el agente ejecuta
La spec dice que construir. Las tareas dicen como, paso a paso. "1. Crear modulo. 2. Refactorizar ruta. 3. Agregar variable de entorno. 4. Verificar fallback."
Cada tarea es atomica — el agente puede ejecutarla sin contexto adicional. Si una falla, las demas no se contaminan.
Cuando usarlo vs cuando saltarlo
SDD no es para todo. Tiene un coste de setup — minimo, pero real.
Usalo cuando:
- El cambio toca multiples archivos
- Hay decisiones de arquitectura que tomar
- Es funcionalidad nueva, no un ajuste a algo existente
- Necesitas que otro agente pueda retomar el trabajo
Saltalo cuando:
- Es un fix de una linea
- Estas corrigiendo un typo o ajustando estilos
- El cambio es tan pequeno que la spec tardaria mas que el codigo
- Ya tienes claro al 100% que hacer y como
La regla practica: si puedes describir el cambio en un tweet, hazlo directo. Si necesitas mas de un parrafo, planifica primero.
El beneficio real: artefactos que sobreviven
El valor de SDD no esta en el proceso — esta en los artefactos que genera. Cuando la ventana de contexto se compacta (y se va a compactar), la conversacion desaparece. Las decisiones informales se pierden. El "quedamos en que..." ya no existe.
Pero la spec sigue ahi. La lista de tareas sigue ahi. El agente puede leer esos artefactos y retomar exactamente donde lo dejo, sin que le repitas el contexto entero.
Es la diferencia entre perder una hora de conversacion y perder cinco segundos mientras el agente relee la spec.
Planificar no es overhead cuando la IA ejecuta
En desarrollo tradicional, planificar tiene un coste de oportunidad: cada minuto planificando es un minuto que no estas codeando. Cuando eres tu quien ejecuta, esa tension es real.
Con agentes de IA, la ecuacion cambia. Tu no ejecutas — el agente ejecuta. Tu trabajo mas valioso no es escribir codigo, es definir que codigo escribir. La planificacion pasa de ser overhead a ser la actividad de mayor apalancamiento.
Diez minutos definiendo una spec pueden ahorrar una hora de iteraciones sin rumbo. Y los artefactos que produces no solo guian la sesion actual — sobreviven para la siguiente.
La proxima vez que estes a punto de decirle al agente "simplemente hazlo", para un momento. Escribe un parrafo de lo que quieres. Define que significa "terminado". Luego deja que ejecute. La diferencia te va a sorprender.
Este es el octavo articulo de la serie. El primero fue sobre las herramientas que uso. El segundo sobre por que fallan y cómo arreglarlo. Si quieres ver el puente entre diseno y codigo, lee el articulo sobre el workflow Figma-to-Code.