Durante el último año una parte de la profesión se subió al vibe coding. Le pides algo a un modelo, te devuelve código y rezas para que funcione. Es rápido y a veces parece magia, pero tiene un problema de fondo. Nadie sabe del todo qué se pidió, por qué se construyó así ni cómo comprobar que lo que salió es lo que de verdad hacía falta.
El spec driven development es la respuesta a ese problema. En lugar de tratar el prompt como algo desechable, lo convierte en el centro del proceso. Primero defines qué quieres y por qué, lo escribes, lo validas, y solo entonces dejas que el agente escriba código. En este artículo te cuento qué es, cómo funciona su flujo y cuatro proyectos open source que te obligan a trabajar así.
Por qué surge este enfoque
El spec driven development surge como respuesta a un problema muy concreto, la falta de prompts claros. Cuando le pides algo a un agente con una frase vaga, el agente rellena los huecos como puede y el resultado depende de la suerte.
Este enfoque es, antes que nada, un flujo que obliga al usuario a aclarar sus propias intenciones y a comunicarlas con el resto del equipo. Tienes que pensar qué quieres de verdad antes de teclear. Y como todo queda escrito, aparece algo que el vibe coding no tiene, trazabilidad. Puedes mirar atrás y entender qué se decidió, cuándo y por qué.
No es un invento aislado. Durante 2025 se convirtió en una de las prácticas de ingeniería asistida por IA más comentadas. GitHub publicó su propio toolkit, Amazon lanzó un IDE construido alrededor de la idea y hasta Andrej Karpathy, que acuñó el término vibe coding, reconoció que esa etapa estaba dando paso a una ingeniería más disciplinada.
Las cuatro condiciones de un desarrollo spec driven
Un desarrollo es spec driven cuando cumple cuatro condiciones. No basta con escribir un documento largo al principio. El enfoque tiene una estructura concreta y se reconoce por estas cuatro señales.
El prompt se cristaliza en un artefacto durable
La primera condición es que el prompt inicial no desaparece en el chat. En el vibe coding la intención vive en un mensaje que se pierde en el scroll. Aquí esa intención se cristaliza en un artefacto durable, normalmente un archivo markdown que vive en el repositorio. El prompt deja de ser una conversación efímera y pasa a ser un documento que puedes versionar, revisar y reutilizar.
El trabajo se descompone por fases
La segunda condición es que hay una descomposición por fases en lugar de una petición monolítica. No le pides al agente todo de golpe. La forma dominante hoy encadena seis etapas, intent, requirements o spec, design o plan, tasks, implement y verify. Cada fase produce su propio artefacto y alimenta a la siguiente. El intent dice qué quieres, la spec lo concreta, el plan decide cómo, las tasks lo trocean, implement lo construye y verify lo comprueba.
La metodología codifica conocimiento reusable
La tercera condición es que la metodología codifica conocimiento reusable fuera del prompt suelto. Los principios arquitectónicos, la estructura del proyecto y las convenciones de código no se repiten en cada mensaje. Se guardan en archivos de skills, los famosos SKILL.md, que el agente carga cuando los necesita. El conocimiento del proyecto deja de vivir solo en tu cabeza y pasa a estar escrito donde el agente puede leerlo.
La validación empieza antes del código
La cuarta condición es que la validación ya no espera al final. En el modelo clásico revisas cuando el código está terminado, y para entonces corregir un malentendido sale caro. En spec driven development validas en todas las capas. Primero validas la intención, luego la spec, luego el plan y solo al final el código. Cada capa se aprueba antes de pasar a la siguiente, así que los errores se cazan cuando todavía son baratos de arreglar.
El flujo paso a paso
Juntando las cuatro condiciones, el flujo completo tiene seis pasos encadenados.
Intención. Dices qué quieres lograr. Por ejemplo, voy a añadir autenticación a la aplicación.
Spec. Concretas esa intención. La autenticación será con usuario, contraseña y un código de confirmación enviado al correo. Aquí desaparece la ambigüedad.
Plan. Decides cómo se construye, qué arquitectura, qué stack y qué archivos exactos se van a tocar.
Tasks. El plan se trocea en una lista de tareas pequeñas y verificables, una to do list que el agente puede ejecutar una a una.
Implementación. El agente aplica los cambios siguiendo esas tareas, sin improvisar.
Validación. Se comprueba el resultado con tests y revisión.
La diferencia con pedir todo de golpe es que en cada paso hay un punto de control. Tú apruebas antes de avanzar y el agente nunca se va por libre. El coste de un malentendido se mide en una frase corregida, no en una tarde de código tirada a la basura.
Cuatro proyectos que te obligan a seguir este flujo
La teoría está bien, pero lo interesante es que ya existen herramientas que implementan este flujo y, sobre todo, que te obligan a respetarlo. No te dejan saltarte pasos. Estos son cuatro proyectos open source que vale la pena conocer.
Superpowers
Superpowers es un framework de skills para agentes creado por Jesse Vincent. Se describe como una metodología de desarrollo de software que funciona, y con más de 190 mil estrellas en GitHub es de los proyectos más populares de su categoría. Trabaja con Claude Code, Cursor, Copilot, Gemini y otros agentes.
Su flujo tiene siete etapas. Empieza con un brainstorming en el que el agente no escribe código, hace preguntas y explora alternativas. Sigue con la especificación y el diseño, presentado en partes pequeñas para que un humano lo valide. Después vienen la aprobación del diseño, la creación de un worktree de git con una rama aislada, el plan de implementación troceado en tareas de pocos minutos, la ejecución con subagentes aplicando TDD en ciclo RED GREEN REFACTOR, y por último la revisión y el cierre. Lo importante es que los skills se activan solos y el flujo es obligatorio, no opcional. Tiene licencia MIT.
Spec Kit
Spec Kit es el toolkit de spec driven development publicado por GitHub. Su idea central es que las especificaciones sean ejecutables, es decir, que el documento no sea un papel muerto sino la fuente desde la que se genera el software. Está escrito en Python, tiene licencia MIT y soporta más de treinta agentes distintos.
Se usa a través de comandos. Con /speckit.constitution estableces los principios del proyecto. Con /speckit.specify describes qué quieres construir y por qué, sin entrar en tecnología. Con /speckit.plan defines el stack y la arquitectura. Con /speckit.tasks conviertes el plan en una lista ordenada de tareas. Con /speckit.implement ejecutas la construcción. Y hay comandos opcionales como /speckit.clarify, /speckit.analyze y /speckit.checklist para resolver dudas y verificar la calidad antes de implementar. Cada comando corresponde a una fase del flujo, así que usar Spec Kit es, literalmente, hacer spec driven development.
BMAD Method
BMAD Method lleva el enfoque al terreno de los agentes especializados. En lugar de un solo agente que lo hace todo, BMAD orquesta más de doce roles expertos, un project manager, un arquitecto, un desarrollador, un especialista en UX y más. Cada uno interviene en la fase que le toca.
Su flujo tiene siete etapas, iniciar, definir y entender, planificar de forma adaptativa, arquitecturar y diseñar, implementar de forma iterativa, probar y validar, y entregar y aprender. Lo característico es que la profundidad del plan se ajusta sola al tamaño del proyecto, así que no aplicas el mismo proceso pesado a un bug que a un sistema entero. Tiene un modo en el que varios agentes debaten contigo a la vez, se instala con npx bmad-method install y tiene licencia MIT.
Get Shit Done
Get Shit Done ataca un problema muy concreto del trabajo con agentes, el context rot, esa degradación de la calidad a medida que el agente llena su ventana de contexto en sesiones largas. Su solución es mantener el conocimiento del proyecto en artefactos estructurados que sobreviven a cada sesión, archivos como PROJECT.md para la visión, REQUIREMENTS.md para el alcance, ROADMAP.md para las fases y STATE.md para las decisiones.
Funciona con un bucle de seis comandos, inicializar el proyecto, discutir la fase, planificarla, ejecutarla en contextos frescos, verificar el trabajo a mano y por último crear el pull request. Está escrito en TypeScript, se instala con npx, tiene licencia MIT y lo usan ingenieros de empresas como Amazon, Google y Shopify. La filosofía de su creador resume bien todo el enfoque, la complejidad vive en el sistema, no en tu flujo de trabajo.
Conclusión
El spec driven development no es una moda más. Es el reconocimiento de que un agente de IA es tan bueno como las instrucciones que recibe, y que esas instrucciones merecen el mismo cuidado que el propio código. Escribir la intención, descomponerla en fases, guardar el conocimiento donde el agente lo lea y validar en cada capa no es burocracia. Es lo que separa un resultado fiable de uno que depende de la suerte.
Si vienes del vibe coding, el cambio cuesta al principio. Escribir una spec parece más lento que lanzar un prompt y ver qué sale. Pero ese tiempo se recupera con creces en cuanto el proyecto crece, porque dejas de reescribir lo que el agente entendió mal. Las cuatro herramientas que he repasado, Superpowers, Spec Kit, BMAD Method y Get Shit Done, son cuatro formas distintas de obligarte a trabajar así. Elige la que encaje con tu agente y tu estilo, pero elige alguna. El futuro del desarrollo asistido por IA pasa por la spec, no por la suerte.
En Levante construimos con esta misma disciplina, porque un producto de IA solo es tan sólido como el método con el que se levanta.
