Durante todo 2025, la conversación sobre programar con IA estuvo dominada por una expresión: vibe coding. Andrej Karpathy la acuñó en febrero de ese año para describir lo que ya estábamos haciendo todos — abrir un chat con un modelo, describir lo que queríamos, y dejar que la IA improvisara código sobre la marcha.

Funcionaba para prototipos. Funcionaba para explorar. Funcionaba para aprender una librería nueva en cinco minutos. Y entonces la gente empezó a meter ese código en producción. Llevamos un año viendo las consecuencias. Y la respuesta de la industria tiene nombre: Spec Driven Development.

Este artículo es la guía completa, en español, sobre qué es exactamente, por qué lo estás viendo en todas partes, cómo implementarlo paso a paso con las herramientas oficiales, y dónde encajan sus límites. Si programas con IA en serio, vas a necesitar esto.

Qué es Spec Driven Development

Spec Driven Development (SDD) es una metodología de programación asistida por inteligencia artificial donde la especificación funcional —no el prompt— es la fuente de verdad del proyecto. El desarrollador escribe una especificación ejecutable, versionada y revisable; el agente de IA genera el código a partir de ella, y cualquier cambio sustancial vuelve a la especificación antes de tocar el código.

El cambio paradigmático lo resumió GitHub en el lanzamiento de su herramienta oficial: pasamos de un mundo donde «el código es la fuente de verdad» a uno donde «la intención es la fuente de verdad». Durante cincuenta años, las especificaciones técnicas fueron un andamio que se tiraba cuando empezaba el «trabajo de verdad», que era picar código. SDD invierte la jerarquía: la especificación deja de ser un documento previo al desarrollo y se convierte en el artefacto central del proyecto. El código pasa a ser un resultado, no un activo.

Esto tiene implicaciones que van más allá de lo metodológico. Si la especificación es portable entre agentes —y lo es, en formatos como los de spec-kit—, entonces se puede regenerar el código entero del proyecto con cualquier modelo: Claude Code, GitHub Copilot, Gemini CLI, Cursor, Codex. La spec es el activo que persiste; el código es el output que se reconstruye.

Por qué vibe coding falla en producción

Para entender por qué SDD está reemplazando al vibe coding hay que mirar los datos, no las opiniones. Tres cifras conviene tener presentes:

Los agentes de IA, incluso los modelos punteros de 2026, resuelven menos del 25 % de las tareas reales de ingeniería en el benchmark SWE-Bench Pro. Es decir, en tres de cada cuatro encargos no triviales, el agente fracasa por su cuenta. El 66 % de los desarrolladores que usan IA en su trabajo declaran que pasan más tiempo arreglando código generado que el que tardarían escribiéndolo desde cero. Y los análisis de seguridad muestran que el código vibe-codeado contiene 2,74 veces más vulnerabilidades que el código escrito por humanos.

Estos números no son una crítica al modelo. Son la consecuencia inevitable de una metodología basada en ambigüedad. Cuando le pides a un agente «construye una página de login», el modelo se enfrenta a decenas de decisiones implícitas que no le has especificado: qué librería de autenticación usar, sesiones o tokens, dónde renderizar los errores, cómo validar la contraseña, cómo manejar rate limiting, qué política de cookies aplicar. El modelo rellena esos huecos por su cuenta. Y los rellena de manera distinta cada vez. Ejecuta el mismo prompt diez veces y obtendrás diez implementaciones diferentes — todas plausibles, todas distintas, ninguna determinista.

Para exploración, esto es una virtud. Para producción, es un fallo estructural. Hay cinco limitaciones concretas que el vibe coding ignora y que SDD ataca de frente:

1. Gestión del contexto. Aunque los modelos actuales soportan ventanas de 200.000 tokens o más, sufren del problema conocido como «lost in the middle»: la información crítica situada en el centro del prompt se atenúa. Sin un contrato claro entre intención y resultado, el agente olvida partes del encargo.
2. Coordinación entre archivos. Los agentes no construyen grafos de dependencias reales. Cuando un cambio afecta a cinco archivos, el modelo puede romper tres mientras arregla uno. SDD obliga a explicitar las dependencias antes de tocar código.
3. Fallos silenciosos. Para que los tests pasen, el agente puede borrar las comprobaciones de seguridad o fabricar datos plausibles. Lo hace en silencio, y solo se detecta en producción. Con SDD, cada tarea tiene criterios de aceptación verificables y se valida antes de marcarse como terminada.
4. Decisiones arquitectónicas implícitas. El agente ve la estructura del código, pero no entiende los trade-offs que llevaron a ella. No sabe por qué elegiste PostgreSQL en vez de MongoDB. Toma decisiones que rompen tu arquitectura sin enterarse. La constitución del proyecto en SDD codifica esas decisiones explícitamente.
5. Contexto empresarial. Toda la lógica de negocio implícita, las reglas no escritas, las convenciones del equipo… el agente no las ve. La spec las hace visibles y versionables.

El fondo del problema es la ambigüedad. SDD no es una herramienta — es una disciplina para eliminarla.

Cómo funciona Spec Driven Development: las cinco fases

La metodología canónica, tal como la formalizó GitHub en su toolkit oficial, sigue cinco fases consecutivas. Cada fase produce un artefacto versionable y cada transición incluye un checkpoint humano.

Fase 1: Constitution

La constitución del proyecto define los principios inviolables: estándares de calidad de código, requisitos de testing, decisiones arquitectónicas, criterios de rendimiento, restricciones tecnológicas. Es el contrato que el agente no puede romper.

Una buena constitución no es una lista de buenas intenciones. Es una serie de reglas verificables que actúan como quality gate. Si el agente intenta introducir una dependencia que viola la constitución, falla. Si genera código que no cumple la cobertura mínima de tests, falla. Si toma una decisión arquitectónica que contradice un principio, falla.

Esto es lo que en mi canal llamo soberanía arquitectónica: el desarrollador mantiene el control sobre las decisiones estructurales del proyecto, y la IA opera dentro de los límites que tú defines.

Fase 2: Specify

La fase de especificación describe qué se quiere construir, no cómo. Es un documento funcional: qué hace el sistema, qué inputs acepta, qué outputs produce, qué casos límite contempla, qué comportamiento se espera en cada situación.

La spec no contiene código ni nombres de librerías. Es la formalización de la intención. Un buen ejercicio mental: la spec debería ser legible para un desarrollador que no haya visto nunca el proyecto, sin necesidad de leer una sola línea de implementación.

Fase 3: Plan

El plan técnico responde al cómo. Aquí el agente genera, a partir de la spec, una propuesta arquitectónica: estructura de módulos, modelos de datos, librerías concretas, organización de tests, flujos de control.

El plan es el checkpoint más importante de todo el proceso. Antes de que el agente escriba una sola línea de código, ya has visto la arquitectura completa. Si la propuesta no te convence, la corriges aquí. Si hay un trade-off mal resuelto, lo discutes ahora. Cambiar un plan cuesta cinco minutos; cambiar tres mil líneas de código generadas cuesta una tarde.

Fase 4: Tasks

El plan se descompone en tareas atómicas, cada una con responsabilidad única, dependencias explícitas y criterios de aceptación verificables. Las tareas que no comparten dependencias se marcan como paralelizables.

Esta granularidad es lo que permite la verificación incremental. Cada tarea es testeable de forma independiente. El agente no avanza a la siguiente hasta que la actual cumple sus criterios. Si una tarea falla, el problema queda localizado a un fichero o un módulo, no disperso por toda la base de código.

Fase 5: Implement

La implementación es la fase ejecutable. El agente toma las tareas una a una, las desarrolla siguiendo las restricciones de la constitución, ejecuta los tests asociados, y solo cierra cada tarea cuando los criterios de aceptación pasan.

Esta fase suele ser la más rápida del proceso completo. Cuando llegas aquí, todas las decisiones difíciles ya están tomadas. El agente ejecuta; no decide.

spec-kit: la implementación oficial de GitHub

spec-kit es la herramienta open-source que GitHub lanzó para implementar SDD en cualquier agente de programación. Es agnóstica al modelo: funciona con Claude Code, GitHub Copilot, Gemini CLI, Cursor, Codex y cualquier otro agente que soporte comandos slash.

La instalación se hace a través de uv, el gestor de paquetes Python rápido de Astral. Hay un detalle importante de seguridad: el único paquete oficial es el del repositorio github/spec-kit. Cualquier paquete con nombre parecido en PyPI es ilegítimo. La instalación correcta es:

uv tool install --from git+https://github.com/github/spec-kit.git specify-cli

Una vez instalado, inicializar un proyecto con Claude Code como agente es un solo comando:

specify init mi-proyecto --ai claude
cd mi-proyecto

Esto crea la estructura de directorios de spec-kit, los templates de cada fase, y los comandos slash listos para usar en Claude Code. El flujo completo dentro del agente es:

/speckit.constitution
/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement

Cada comando produce un artefacto markdown que queda versionado en el repositorio. El proyecto entero —su intención, su arquitectura, sus tareas, sus tests— vive en archivos legibles. El código generado es la consecuencia.

Más allá de spec-kit, ha empezado a crecer un ecosistema de herramientas adyacentes: cc-spex para automatizar partes del flujo en Claude Code, claude-speckit-template como template base, OpenSpec como alternativa abierta, Kiro para gestión de contexto en proyectos grandes. La dirección de la industria es clara, aunque las herramientas concretas todavía están iterando.

Cuándo NO usar Spec Driven Development

Conviene ser honesto: SDD no es la respuesta correcta a todos los problemas. Hay tres contextos donde el coste de la metodología supera al beneficio.

• Prototipado puro y exploración. Si estás validando una idea, probando un concepto, o aprendiendo una librería nueva, la fricción de redactar una constitución y una spec mata el flujo. Aquí el vibe coding sigue siendo la herramienta correcta. SDD entra cuando decides que algo va a producción.
• Cambios triviales en codebases existentes. Para un bug fix de tres líneas o un ajuste cosmético, montar un flujo SDD es overkill. La metodología tiene sentido para features sustanciales o módulos nuevos, no para pequeñas modificaciones quirúrgicas.
• Legacy codebases sin disciplina de especificación. Esto es lo más doloroso de admitir. En proyectos grandes sin tradición de documentación, introducir SDD desde cero es un esfuerzo de meses, no de días. La spec inicial hay que extraerla del código existente, y eso es un proceso lento. Hay aproximaciones híbridas (extraer specs por módulos, ir migrando incrementalmente) pero conviene saber que el coste de adopción no es trivial.

Decir cuándo una herramienta no se debe usar es, paradójicamente, lo que la legitima. SDD no es una bala de plata. Es una metodología seria para un problema serio.

Hacia dónde va esto: el futuro de programar con IA

El cambio de paradigma que representa SDD encaja con una tendencia más amplia que define a la IA en 2026: el paso de modelos que responden a agentes que actúan.

Cuando los agentes pasan de generar respuestas conversacionales a ejecutar trabajos completos dentro de tu sistema, la fiabilidad deja de ser opcional. No puedes permitirte que un agente que escribe código en tu repositorio improvise. No puedes permitirte que un agente que toca tu base de datos rellene los huecos por su cuenta. Necesitas especificaciones contractuales, no prompts ambiguos.

SDD es la respuesta de la industria a esta exigencia. No es una moda; es una corrección estructural.

Tres direcciones interesantes a vigilar en los próximos meses:

• SDD multi-agente. Varios modelos colaborando sobre la misma spec, cada uno especializado en una fase: uno escribe la spec, otro revisa el plan, otro implementa, otro audita. Los primeros experimentos públicos muestran resultados muy prometedores en términos de calidad y robustez.
• SDD para legacy. Herramientas que extraen specs ejecutables desde codebases existentes. Es el problema más difícil del ecosistema y donde habrá más innovación.
• Constituciones compartidas. Repositorios públicos de constituciones por dominio (e-commerce, fintech, salud, gaming) que sirven como punto de partida para nuevos proyectos. Una especie de «stack overflow de principios arquitectónicos».

Si trabajas con IA y todavía no has empezado a explorar SDD, este es el momento. La curva de adopción es exponencial — en seis meses, esto será mainstream. En doce, será la línea base esperada.

Preguntas frecuentes sobre Spec Driven Development

¿Spec Driven Development reemplaza completamente al vibe coding?

No. SDD reemplaza al vibe coding en contextos de producción. Para prototipado, exploración y aprendizaje, vibe coding sigue siendo la metodología más eficiente. Son herramientas complementarias para fases distintas del ciclo de vida de un proyecto.

¿Necesito Claude Code para usar Spec Driven Development?

No. spec-kit es agnóstico al agente. Funciona con Claude Code, GitHub Copilot, Gemini CLI, Cursor, Codex y otros. La portabilidad de la spec entre agentes es, de hecho, una de las ventajas clave de la metodología.

¿Cuánto tiempo lleva aprender Spec Driven Development?

El flujo básico (las cinco fases con spec-kit) se aprende en una tarde. La parte difícil no es la herramienta — es escribir constituciones técnicas que funcionen y specs que no dejen huecos de ambigüedad. Esa habilidad se desarrolla con práctica, probablemente uno o dos meses de uso intensivo.

¿Spec Driven Development funciona para proyectos pequeños?

Funciona, pero el overhead puede no compensar para proyectos de menos de unas mil líneas de código. La metodología empieza a brillar a partir de proyectos de complejidad media donde la coordinación entre módulos importa.

¿Es Spec Driven Development lo mismo que TDD?

No. TDD (Test Driven Development) parte de los tests para guiar el código. SDD parte de la intención formalizada para guiar tanto los tests como el código. Son complementarios: una buena implementación SDD usa TDD dentro de la fase de implementación.

¿Qué pasa si la spec y el código se desincronizan?

Es uno de los problemas reales de SDD: el drift entre spec y código. La solución pasa por dos prácticas: tratar la spec como fuente de verdad (todo cambio empieza ahí), y usar herramientas de validación que detecten divergencias entre spec y código generado. spec-kit tiene mecanismos para esto, pero todavía es un área en desarrollo activo.

Recursos para empezar

Si quieres dar el siguiente paso, te recomiendo este orden:

1. Mira el video completo del canal donde construyo una aplicación funcional con spec-kit y Claude Code de principio a fin. La demo paso a paso te ahorra horas de exploración a ciegas.
2. Instala spec-kit y haz un proyecto pequeño. Algo de 200-300 líneas máximo. Un CLI, un microservicio mínimo, un script con varios módulos. La primera vez que sientas el flujo completo lo entiendes para siempre.
3. Lee la documentación oficial del repositorio github/spec-kit. Está en inglés, pero es corta y muy concreta.
4. Suscríbete al canal. La serie completa sobre Spec Driven Development en español la estoy publicando aquí. Los próximos vídeos cubren cómo escribir constituciones técnicas que de verdad funcionan, cómo aplicar SDD en codebases legacy, y experimentos multi-agente.

Si quieres profundizar en los fundamentos de la inteligencia artificial sobre los que se apoya todo esto, tengo tres libros publicados en Amazon (Kindle y tapa blanda) que cubren desde los principios técnicos hasta las metodologías prácticas de programar con IA. Los enlaces están en la cabecera del canal y en la descripción de cada vídeo.

Spec Driven Development no es una moda pasajera. Es la forma en que la industria está aprendiendo a colaborar con agentes de IA sin perder el control sobre lo que se construye. El vibe coding nos enseñó lo que la IA puede hacer cuando le dejamos improvisar. SDD nos está enseñando lo que la IA puede hacer cuando le damos un contrato claro.

Estamos en el momento exacto en que esta metodología pasa de experimental a mainstream. Los que entren ahora van a tener seis meses de ventaja sobre el resto.

Nos vemos en el próximo artículo. Que la IA te acompañe!