Todo cambio que merece construirse comienza con una intención

Una semana de SDD: de una primera versión a una herramienta que revisa su propio trabajo.

De día soy ingeniero de software y arquitecto senior. Por las tardes y los fines de semana pinto bajo el nombre de Sam Grudge: corazones, al óleo sobre lienzo, construidos capa a capa hasta que el color resplandece (hearts-colors.com). Las dos vidas parecen muy distantes. Cada vez más, se encuentran en una misma pregunta: ¿qué quiero hacer con mis propias manos, y qué puedo confiar a una máquina?

SDD nace de mi trabajo diario. Es una metodología de desarrollo guiada por especificaciones para agentes de codificación con IA (Claude Code y Codex), y es de código abierto en GitHub. La idea es simple. Antes de que el agente escriba código, redacta una breve especificación: requisitos y ejemplos concretos de cómo deben comportarse, incluso cuando algo sale mal. Yo la apruebo. Luego el agente la construye primero con pruebas, la verifica contra la especificación, y mantiene un registro vivo de cómo se comporta el sistema.

Lo que cambió en una semana

La primera versión salió el 7 de octubre. Gestionaba cambios pequeños de principio a fin, con una sola aprobación, tareas basadas en pruebas primero y una especificación viva. Siete días y catorce versiones después:

• El trabajo más grande sigue su propio camino. Un cambio mayor recibe tres aprobaciones en lugar de una: la especificación, el plan y los resultados.
• Una especificación aprobada queda bloqueada. Cambiarla después requiere una enmienda registrada y aprobada. Los errores siguen su propio flujo, y una prueba de regresión se añade a la especificación viva para que el error no pueda volver sin que se note.
• Un crítico revisa la especificación antes de que se construya nada. Audita cada requisito y solo me formula las preguntas que me corresponde decidir, como máximo cinco.
• SDD ahora desarrolla SDD. Desde la versión 0.5, el proyecto funciona con su propio método, con un rigor de "producción": el segundo más alto de sus cuatro niveles.
• La batería de pruebas pasó de 82 a 208 pruebas.

La herramienta encontró fallos en sí misma

El primer cambio que SDD aplicó sobre sí mismo fue un error que había descubierto en sus propias aprobaciones. La aprobación final de "resultados" no leía el veredicto del revisor, por lo que un trabajo marcado con deficiencias aún podía aprobarse. La constitución del proyecto, sus reglas innegociables, podía modificarse después de la aprobación sin que nadie se diera cuenta, incluso para rebajar el nivel de rigor.

Ambos problemas están corregidos. Una aprobación ahora cubre exactamente lo que fue aprobado. La puerta de resultados solo acepta un veredicto favorable, y la constitución lleva una huella: cualquier edición posterior se notifica y bloquea el avance hasta que yo vuelva a aprobarla.

Lo que más me gustó fue cómo se llegó a esto. La verificación se ejecutó tres veces, cada una en una sesión nueva sin memoria del trabajo anterior. Las dos primeras rondas revelaron deficiencias: reglas que la especificación establecía pero que ninguna prueba demostraba. Cada vez, la especificación se enmendaba, se escribían las pruebas faltantes, y el revisor volvía a mirar. La tercera ronda pasó. Nada se aprobó sin comprobación.

Capas

Uno de mis cuadros está hecho de capas. Las primeras desaparecen bajo el color, pero sostienen todo. SDD funciona de la misma manera: intención, luego especificación, plan, pruebas y verificación, cada una visible y verificable bajo el código.

En mi sitio web digo que toda historia que merece contarse comienza con un corazón. En el software, todo cambio que merece construirse comienza con una intención. Esa parte sigue siendo mía. También las decisiones y aprobaciones, que llevan mis propias palabras.

Delegar la rutina

No todas las capas necesitan la mano de un maestro. Una ronda de verificación tomaba unos 14 minutos y casi 180.000 tokens, y gran parte de eso era mecánico: repetir pruebas contra código antiguo, romper reglas a propósito para probar que una prueba las detecta, recopilar evidencia. Un script puede hacer ese trabajo, sin ningún modelo.

Ese es el siguiente paso. Un modelo principal orquestará: hablará conmigo, controlará las puertas y repartirá el trabajo. Revisores independientes funcionarán como agentes separados en los modelos más potentes. Las tareas rutinarias irán a modelos más económicos y rápidos. Cada tipo de trabajo va a la herramienta que le conviene, igual que un pincel se ajusta a un trazo y una espátula a otro.

Esa es la promesa de la IA que me importa. No elimina el oficio. Elimina la rutina que lo rodea, para que yo conserve la parte que amo. En la oficina, eso es arquitectura y criterio. En el estudio, es el siguiente corazón.

SDD es de código abierto bajo la licencia MIT: github.com/fpapleux/sdd-skill. Las notas de la versión enumeran cada versión.