Vuelvo a mis orígenes: por qué empiezo a programar con Spec-Driven Development

Terminé el grado de Desarrollo de Aplicaciones Multiplataforma convencido de que había aprendido a programar: clases, patrones, bases de datos, pruebas, el ciclo de vida del software. Y justo cuando acababa, el terreno se movió. Hoy un agente de IA escribe en segundos lo que a mí me costaba una tarde.

La primera reacción fue pensar que todo aquello ya no servía, y me lancé a programar mis proyectos a base de prompts. Funcionaba rápido, pero el resultado, al final, salía de peor calidad. Viendo varios vídeos sobre cómo están trabajando los equipos profesionales con IA, he llegado a la conclusión contraria: lo que aprendí sirve más que nunca, pero en otro sitio. Ya no está tanto en escribir cada línea como en decidir qué hay que construir, cómo y con qué garantías. Y para eso hay un nombre: Spec-Driven Development (SDD), o desarrollo guiado por especificaciones.

El problema: el «vibe coding»

En 2025 se popularizó el vibe coding: pedirle cosas a la IA a base de intuición, aceptar lo que devuelve y seguir pidiendo. Para un prototipo de fin de semana o un script de usar y tirar, funciona. El problema llega cuando ese código tiene que mantenerse, crecer o pasar a producción:

• Es indeterminista. Pide diez veces «hazme un login» sin más contexto y tendrás diez soluciones distintas. Ninguna es necesariamente la que tu proyecto necesita.
• Acumula deuda técnica. Sin requisitos ni diseño no hay forma de saber qué es lo «correcto». Tras unas semanas de prompts improvisados, tocar algo rompe otra cosa.
• Abre agujeros de seguridad. La IA puede proponer patrones desactualizados u olvidarse de validar una entrada. Si nadie revisa con criterio, eso llega a producción.

Y hay un efecto que me parece clave: cuanto más código escribe la IA, menos capaz es una persona de revisarlo línea a línea. Si no pones reglas antes, el control se pierde.

	Vibe coding	Spec-Driven Development
Sirve para	Prototipos y scripts personales	Software que hay que mantener
Resultado	Varía en cada intento	Acotado por la especificación
Cómo se comunica	Prompts improvisados	Documentos Markdown en el repositorio
Papel del desarrollador	Escribe prompts	Diseña, decide y valida

Qué es el Spec-Driven Development

Lo que más me llamó la atención al descubrirlo es que no es nada nuevo. Como explica muy bien Brais Moure en su vídeo El fin del Vibe Coding: Crea software robusto con este método, la IA no elimina la ingeniería de software: cambia la herramienta con la que se ejerce el control. El SDD recupera el ciclo de vida del software de siempre, el que estudié en DAM, y lo convierte en documentos que el agente de IA tiene que respetar:

• Planificación → constitución (constitution.md): las reglas innegociables del proyecto.
• Análisis de requisitos → especificación (spec.md): el qué y el por qué, sin entrar en el cómo.
• Diseño → plan técnico y tareas (plan.md, tasks.md): arquitectura, datos y trabajo dividido en piezas pequeñas.
• Implementación → código generado por la IA, una tarea cada vez y con pruebas primero.
• Pruebas → validación: comprobar requisito a requisito que se cumple lo especificado.

La idea central es que la especificación pasa a ser la fuente de verdad, no el prompt que escribiste en un chat y que nadie volverá a leer. Da igual que uses Claude Code, Cursor, GitHub Copilot u OpenCode: todos pueden leer esos ficheros.

Cómo se organiza en un repositorio

Un ejemplo para una pequeña herramienta de línea de comandos que registra hábitos de estudio:

.
├── AGENTS.md              ← instrucciones para el agente: stack, comandos, límites
├── docs/
│   └── constitution.md    ← reglas que no se negocian
└── specs/
    └── 001-habitos-mvp/
        ├── spec.md        ← qué debe hacer y por qué
        ├── plan.md        ← cómo: módulos, datos, pruebas
        └── tasks.md       ← tareas pequeñas, cada una ligada a un requisito

Para que los requisitos no dejen margen a interpretaciones, se puede usar la notación EARS (Easy Approach to Requirements Syntax), que obliga a escribirlos con patrones fijos:

• Siempre: «El sistema guardará todos los datos en un único archivo JSON».
• Cuando: «Cuando el usuario marque un hábito, el sistema registrará la fecha».
• Mientras: «Mientras no exista ningún hábito, el sistema invitará a crear el primero».
• Si… entonces: «Si el hábito ya está marcado hoy, el sistema lo avisará sin duplicar la racha».
• Donde: «Donde se indique la opción --verbose, el sistema mostrará el historial completo».

El flujo de trabajo

1. Constitución: escribir las reglas del proyecto (lenguaje, dependencias permitidas, separación de capas).
2. Especificación: con la IA en modo planificación, sin permiso para escribir código, redactar el spec.md.
3. Clarificación: hacer de QA exigente. Una técnica útil es pedirle al agente que, antes de cerrar la especificación, te haga preguntas de una en una sobre los casos límite: «¿qué pasa con la racha si un día no se marca el hábito?».
4. Plan técnico: traducir la especificación a arquitectura y datos.
5. Tareas: dividir el plan en tareas cortas, cada una ligada a un requisito.
6. Implementación con TDD: una tarea cada vez; primero la prueba que falla, luego el código que la hace pasar.
7. Validación: repasar los requisitos uno por uno contra las pruebas antes de dar nada por terminado.

Es más lento al principio. Pero es exactamente la diferencia entre algo que funciona hoy y algo que sigue funcionando dentro de seis meses.

Fundamentos antes que frameworks

Ya hay herramientas que prometen automatizar todo esto: GitHub Spec Kit, Kiro, OpenSpec, BMAD… Pueden ayudar, pero mi opinión es que en un momento de tantos cambios conviene no atarse a ninguna. Muchas de las herramientas que nacen en estas olas cambian de rumbo o desaparecen, y si el framework piensa por ti, no aprendes a hacerlo tú. Lo que permanece es el método: especificar, planificar, dividir, probar y validar. Eso se puede aplicar con cualquier agente, con skills y plantillas propias en Markdown.

Vuelvo a mis orígenes

Tengo que ser sincero: hasta ahora he programado sobre todo a base de prompts. En Finde, la app que estoy construyendo, tengo algunas piezas sueltas del método, como un spec.md con la visión del producto o ficheros CLAUDE.md y AGENTS.md con instrucciones para el agente. Pero muchas veces me he saltado el orden y he ido directo a pedir código, a base de vibe coding, y lo he pagado después con errores y con trabajo repetido.

Así que vuelvo a lo que aprendí en DAM, ahora con la IA de mi lado: a partir de ahora, cada funcionalidad nueva empezará por su especificación, no por un prompt. El primer banco de pruebas será la próxima fase de Finde, llevar su backend a Supabase, siguiendo el flujo completo: de la constitución a la validación.

Eso no significa darle la espalda a la IA: sería absurdo. Lo que cambia es cómo la uso. Para no depender de ningún framework, he montado una skill modular centrada en el repositorio: unas instrucciones reutilizables que guían al agente por los pasos del método y que trabajan directamente sobre los archivos del proyecto. La elegí por tres motivos:

• Es fiel al SDD: la especificación vive en el repositorio, junto al código (constitution.md, spec.md, plan.md, tasks.md), y la skill opera sobre esos archivos sin pasos intermedios.
• Escala: sirve igual para una herramienta de línea de comandos que para un proyecto con decenas de especificaciones.
• Es portátil: para usarla en otro proyecto basta con copiarla a su carpeta de configuración.

Los proyectos de Claude los dejo para la lluvia de ideas inicial, antes de tocar el repositorio. En cuanto hay código, manda la skill.

Conclusión

Lo que aprendí en DAM no ha caducado: ha cambiado de sitio. Saber qué es un buen diseño, por qué separar capas, cómo escribir un requisito o una prueba es justo lo que necesito para dirigir a una IA en lugar de dejar que me dirija ella. Lo aprendí, lo dejé de lado por la prisa de la IA, y ahora vuelvo a ello, con la IA trabajando a mi favor en lugar de por su cuenta.

Y una cosa no cambia: si un sistema falla en producción, la responsabilidad no es del agente, es de quien lo firmó. Por eso las malas prácticas importan hoy más que nunca, porque la IA las multiplica a la misma velocidad que multiplica el código. El SDD no es una moda: es la ingeniería de software de siempre, adaptada para que la velocidad no se coma la calidad.