SDD desde cero: cómo dejé de tirar código de Claude Code a la basura

Posted on Oct 29 • Originally published at atalayahq.io

Hace unos meses tiré a la basura dos días de trabajo de Claude Code.

No estaba mal hecho. Estaba muy bien hecho. El problema es que no era lo que hacía falta: le había pedido algo en una frase, se puso a programar y, cuando lo vi, ya era tarde.

Desde entonces trabajo con SDD ( Spec-Driven Development, desarrollo guiado por especificaciones). Este artículo es lo que me habría gustado leer al empezar: qué es, por qué cambia tanto con agentes de código y cómo probarlo en una tarde.

Un agente de código hace en minutos lo que antes llevaba días. Pero trabaja con lo que entiende de un mensaje. Si el encargo era ambiguo, construye otra cosa, y te das cuenta al revisar el código, cuando ya hay mil líneas.

Y hay un segundo problema que se ve menos: quien pidió el cambio (alguien de negocio, de soporte, un cliente) no tiene forma de saber cómo va. Pregunta en el chat, alguien mira el código, contesta «casi está».

SDD es una regla sencilla: antes de tocar código, se escribe qué se va a construir y una persona lo aprueba.

Con agentes, ese papel lo escribe el propio agente. Tú solo lo lees y dices sí o no. El malentendido sale antes de programar, cuando arreglarlo cuesta una frase, y no después.

Añade una parada: aprobar. En mi caso son cinco minutos leyendo mientras tomo mate. A cambio, se programa una vez lo acordado y no varias veces lo malentendido.

No todo necesita SDD: un bug o una incidencia se arreglan y ya. SDD es para lo que cambia el comportamiento.

La pieza base es OpenSpec, un formato abierto para que el agente escriba propuestas y especificaciones dentro de tu repositorio, en ficheros de texto.

npm install -g @fission-ai/openspec@latest cd tu-proyecto openspec init Enter fullscreen mode Exit fullscreen mode A partir de ahí, en Claude Code le pides que proponga el cambio antes de implementarlo. Te deja en openspec/changes/ la propuesta, las especificaciones y las tareas. Lo lees, corriges lo que no cuadre y le dices que adelante.

Con esto ya tienes el 80 %: el agente piensa antes de programar y tú decides con el plan delante.

OpenSpec resolvía mi parte. Pero la propuesta vivía en el repositorio, y quien pedía el cambio no la veía nunca. La aprobación era «lo leí y dije OK en el chat», y nadie fuera del terminal sabía en qué punto estaba cada requisito.

Por eso hice Atalaya, un gestor de trabajo (tareas, sprints, Kanban) con SDD dentro: los requisitos se escriben en la tarea, el agente informa su propuesta por MCP, una persona aprueba en la tarea (el agente no puede aprobarse solo) y cada requisito enseña su estado hasta producción. Las especificaciones siguen siendo ficheros de OpenSpec en tu repo: si un día lo dejas, se quedan contigo.

Está en acceso anticipado y es gratis. Pero lo importante del artículo no es la herramienta, es la regla: que el agente proponga y una persona decida antes de que se programe. Empieza con OpenSpec a pelo y verás la diferencia.

¿Cómo lo hacéis vosotros? ¿Revisáis lo que va a hacer el agente antes, o el código después? Me interesa mucho saber qué os funciona.