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

Pablo Silva — Thu, 29 Oct 2026 14:25:38 +0000

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.

El problema: el agente es rápido, pero no lee la mente

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á».

La idea: primero se acuerda, después se programa

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.

Las palabras que vas a oír

Requisito. Lo que tiene que poder hacer alguien cuando esté hecho, en palabras normales. «Quien gestiona descarga las facturas del mes en un fichero.»
Propuesta. El plan del agente: qué va a cambiar, por qué y qué queda fuera.
Criterio de aceptación. Cómo sabréis que está bien. «El fichero se abre en Excel con sus tildes.» Cada requisito tiene al menos uno.
Especificación. Cómo debe comportarse el sistema, escrito para que quede. El siguiente cambio parte de ahí.
Tareas. Los pasos del agente para hacerlo.
Aprobación. El sí de una persona. Sin él, el agente no programa.

Un ejemplo de principio a fin

Marta pide algo: «Exportar las facturas del mes en CSV». Escribe tres requisitos: que quien gestiona pueda descargarlas, que se abran bien en Excel y que solo salgan las de su empresa.
El agente escribe la propuesta. Lee la tarea y escribe qué va a cambiar, qué queda fuera y cómo se comprobará cada requisito.
Alguien la aprueba o pide cambios. Hasta entonces, el agente no programa.
El agente programa y prueba, y al terminar comprueba cada criterio de aceptación contra lo acordado.
Marta lo ve llegar: cada requisito pasa de «sin empezar» a «en desarrollo», «probado» y «en producción».

¿No es más lento?

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.

Cómo probarlo esta tarde (sin herramientas de pago)

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

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.

Lo que me faltaba (y por qué acabé construyendo algo)

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.

DEV Community: Pablo Silva