Spec-driven development, explicado por alguien que no estudió informática

No estudié informática. Mi único título es de fotografía. Así que cuando oí hablar de spec-driven development pensé que sería algo para ingenieros. Resulta que es lo más sencillo del mundo: antes de construir, se escribe qué se va a construir y cómo se sabrá que está bien hecho.

Con un agente de IA esto cambia todo, porque el agente no recuerda tus conversaciones de ayer. Lo que esté escrito en el proyecto, sí.

Así lo hago yo:

1. Un documento de producto (PRD) con requisitos numerados. Cada cosa que el producto debe hacer tiene un identificador y una prioridad, siguiendo el método MoSCoW:

• M (Must): imprescindible. Sin esto no se lanza.
• S (Should): importante, pero puede esperar.
• C (Could): estaría bien.
• W (Won’t): lo que se decide no hacer, por escrito, para no volver a discutirlo.

Por eso en mis proyectos ves cosas como M-04 o S-08: el cuarto requisito imprescindible, el octavo importante.

2. Un criterio que se pueda comprobar. Cada requisito se escribe con la fórmula Dado… cuando… entonces…. Por ejemplo: “Dado un visitante en escritorio, cuando hace doble clic en el icono de un proyecto, entonces se abre su detalle.” Eso no admite interpretaciones: o pasa, o no pasa.

3. Una ficha por funcionalidad. Antes de construir algo grande, el agente escribe una ficha: qué se construye, qué queda fuera y, para cada requisito, qué prueba demostrará que funciona. Yo la leo, la corrijo y le doy el visto bueno. Solo entonces empieza el código.

4. Trazabilidad. Esa tabla que une cada requisito con su prueba se llama trazabilidad. En mi plantilla, un script comprueba en cada cambio que ningún requisito se queda sin su prueba.

Esto no es burocracia. Es lo que evita que el agente construya lo que él cree que quieres, en vez de lo que quieres de verdad.