Durante los últimos años, la inteligencia artificial en programación funcionaba como un autocompletado muy avanzado: sugería líneas y el desarrollador las revisaba una a una. Hoy el escenario es distinto. Los agentes de IA generan funcionalidades completas, abren pull requests y escriben sus propios tests. El cuello de botella ya no es escribir código, sino conseguir que lo que se escribe sea exactamente lo que el negocio necesita.
De ahí nace el Spec-Driven Development (SDD), o desarrollo dirigido por especificaciones: una forma de trabajar en la que la especificación —no el prompt— es la fuente de verdad del proyecto.
El problema del «vibe coding»
Pedirle a un asistente «añade filtros al listado de usuarios» y aceptar lo que devuelve es rápido y, a veces, suficiente. El problema aparece cuando el proyecto crece: cada petición se interpreta de una manera, cada agente toma decisiones de arquitectura por su cuenta y nadie ha escrito en ningún sitio qué se considera correcto.
El resultado son funcionalidades que «funcionan» pero no hacen lo que se esperaba, código sin tests, componentes duplicados y revisiones interminables. Un estudio de METR publicado en 2025 puso números a esta sensación: desarrolladores experimentados trabajando sin una metodología estructurada fueron alrededor de un 19% más lentos usando IA, aunque ellos creían estar yendo más rápido.
Qué es exactamente el Spec-Driven Development
SDD consiste en escribir, antes de generar código, un documento breve y versionado que describe qué se quiere construir, con qué límites y cómo se validará. Ese documento vive en el repositorio, se revisa como se revisa el código y se actualiza cuando cambian los requisitos.
No es volver al waterfall ni redactar documentación de cien páginas. Es dar contexto suficiente para que tanto una persona como un agente puedan tomar las mismas decisiones.
Dos niveles de especificación
- Especificación de sistema: arquitectura, convenciones de código, modelo de datos, librerías permitidas y prohibidas. Es estable y suele mantenerla quien lidera técnicamente el proyecto.
- Especificación de funcionalidad: el cambio concreto que se va a implementar, con sus criterios de aceptación. Es efímera y la mantiene quien desarrolla esa funcionalidad.
Cómo es una spec mínima
Una especificación útil no necesita ser larga, pero sí debe responder a estas preguntas:
- Objetivo: qué problema de negocio resuelve.
- Capacidades: qué debe poder hacer el usuario.
- Criterios de aceptación: cómo sabremos que está bien hecho.
- Restricciones: qué no se puede tocar, qué stack se usa.
- Decisiones técnicas: patrones y componentes a reutilizar.
- Casos de error: qué pasa cuando algo falla.
- Tareas: los pasos de implementación.
La diferencia es evidente en la práctica: «añadir filtros» produce código improvisado que cae en la revisión; una spec con criterios de aceptación produce lógica correcta, tests de los casos relevantes y reutilización de los componentes que ya existen.
El ciclo de trabajo
El flujo habitual tiene pocas fases y todas son revisables:
- Se parte de una historia de usuario en lenguaje de negocio.
- El agente la refina y devuelve las dudas que detecta.
- Se acuerda la spec técnica con criterios y plan de tareas.
- El agente implementa: rama, código y tests.
- La revisión se hace contra los criterios de aceptación, no línea a línea.
- Se verifica, se archiva la spec y queda registrada en el repositorio.
Herramientas para empezar
- GitHub Spec Kit: framework abierto y agnóstico, compatible con Copilot, Claude o Cursor.
- Kiro (AWS): entorno de desarrollo con un flujo integrado de requisitos, diseño y tareas.
- OpenSpec: ciclo completo desde la historia de usuario hasta el archivado de la spec.
- BMAD-Method: roles diferenciados (producto, arquitectura, desarrollo) para equipos grandes.
- Ficheros de contexto en el repositorio (tipo CLAUDE.md o .cursorrules): la vía más rápida si aún no quieres añadir herramientas nuevas.
Errores habituales
- Specs ambiguas que acaban delegando decisiones importantes al agente.
- Sobreespecificar hasta el detalle de cada línea, lo que elimina cualquier margen de mejora.
- Congelar la spec y convertir el proceso en un waterfall encubierto.
- No versionarla: si no está en el repositorio, deja de ser la fuente de verdad.
- Escribirla en solitario: una spec que no comparte el equipo es solo una opinión.
Por qué esto también es una cuestión de seguridad
Cuando nadie define las restricciones, es la IA quien decide cómo se gestionan las sesiones, qué se registra en los logs, cómo se validan las entradas o qué dependencias se instalan. Escribir esas reglas una sola vez, en la especificación de sistema, evita tener que detectarlas más tarde en una auditoría —o después de un incidente. Es la diferencia entre una web generada deprisa y un proyecto que se puede mantener durante años.
Por dónde empezar
No hace falta transformar el equipo de golpe. Un buen primer paso es escribir una especificación de sistema mínima (stack, convenciones y prohibiciones), aplicar una spec pequeña a la próxima funcionalidad antes de escribir el primer prompt y medir el resultado. Y ojo con la métrica: SDD no acelera la primera versión, reduce el número de iteraciones hasta llegar a la buena.
La IA no deja de ser impredecible porque el modelo mejore, sino porque le damos una intención clara y verificable. Eso es, en el fondo, todo el Spec-Driven Development.
Artículo elaborado a partir del análisis sobre Spec-Driven Development publicado por LIDR.