Índice
En una era en la que la IA escribe el código, la habilidad de mayor valor está pasando de "escribir código" a "escribir la especificación". La práctica que recoge este cambio es el spec-driven development (SDD). En 2026, las grandes herramientas —Claude Code, GitHub, AWS y otras— lo han adoptado, y está despertando interés como el "siguiente paso" tras el vibe coding.
Este artículo explica, para principiantes, qué es el spec-driven development, por qué hace falta ahora, los cuatro pasos básicos, las herramientas principales y cuándo usarlo frente al vibe coding.
"Specify → Plan → Tasks → Implement"
— cada paso deja un documento, así la IA nunca tiene que adivinar
Specify
Detalla con palabras qué vas a construir.
Plan
Añade el diseño, la tecnología y las restricciones.
Tasks
Divídelo en unidades pequeñas y revisables.
Implement
La IA lo construye ajustándose a la especificación.
1. ¿Qué es el Spec-Driven Development (SDD)?
El spec-driven development es un enfoque en el que la "especificación" es la protagonista del proyecto (el documento central) y la IA deriva la implementación a partir de ella. En lugar de hacer que la IA escriba código de inmediato, primero plasmas "qué construir y cómo" en un documento estructurado, y un agente de IA lee esa especificación para diseñar, desglosar e implementar.
Imagina "el plano antes de construir una casa". Si le pides a un carpintero que "haga algo bonito" sin un plano, el resultado varía y hay mucho retrabajo. Un agente de IA es igual: una instrucción vaga genera conjeturas. Fija primero el plano —la especificación— y reduces el margen para que la IA se desvíe hacia su propia implementación.
💡 En una línea: SDD = "escribe la especificación antes que el código". La especificación es la fuente de verdad, y el código es un derivado generado a partir de ella. Visto a través de la ingeniería de contexto, la especificación es además el mejor "contexto" que puedes entregarle a la IA.
2. ¿Por qué ahora? El "muro de los tres meses" del vibe coding
El vibe coding (construir conversando para ir dando forma a las ideas) puede producir prototipos a una velocidad vertiginosa, pero suele venirse abajo al escalar. Tanto medios como profesionales describen a menudo que el código construido por inercia choca contra un "muro de deuda técnica" al cabo de unos tres meses, con costes de mantenimiento que se disparan. El código generado por IA se deja tal cual, se acumula en producción y luego se vuelve imposible de arreglar.
El spec-driven development elimina esa "deriva de requisitos" en la fase de diseño. Fijar primero la especificación añade esfuerzo inicial, pero recorta drásticamente el retrabajo posterior. GitHub informa de que, usando sus propias herramientas, el número de ciclos de "regenerar desde cero" se redujo aproximadamente en un orden de magnitud (cifra reportada por el propio proveedor).
Rápido · bueno para explorar
- El prototipado y la validación son ultrarrápidos
- Exploras la dirección mientras conversas
- Pero suele venirse abajo al escalar
- Los requisitos se desvían y se acumula deuda
Mantenible · bueno para entregar
- La especificación es la fuente de verdad, así hay menos divagación
- Evita la deriva de requisitos por diseño
- Más esfuerzo inicial
- Mucho menos retrabajo, más fácil de mantener
Hay incluso quien dice que "en 2026, la ventaja del ingeniero está en saber escribir especificaciones más que en escribir código". Cuanto más delegas en la IA, más se desplaza el trabajo humano hacia "definir con precisión qué construir".
3. El flujo básico — cuatro pasos
Los nombres cambian un poco según la herramienta, pero el spec-driven development sigue, a grandes rasgos, los mismos cuatro pasos. La clave es que cada paso deja un documento (a menudo un archivo Markdown) que el paso siguiente lee. El truco está en no dejar la información solo en la cabeza de la IA.
① Specify
Describe con palabras qué construir: funciones, propósito, usuarios y criterios de aceptación.
② Plan (diseño)
Añade cómo construirlo: arquitectura, las librerías que usarás y las restricciones.
③ Tasks (desglose)
Divide el plan en unidades pequeñas y revisables que puedas confirmar de una en una.
④ Implement
La IA construye cada tarea ajustándose a la especificación. Las personas se centran en la revisión y la aprobación.
⚠️ La revisión humana es obligatoria: incluso con trabajo dirigido por especificación, nunca te saltes la comprobación del código generado por IA. El SDD no es una herramienta para "lanzar y olvidar": es un mecanismo que hace que a una persona le resulte más fácil llevar el timón.
4. Las herramientas principales (Spec Kit, Kiro y más)
A fecha de 2026, la mayoría de los grandes agentes de codificación admiten el SDD. Estos son los ejemplos más destacados.
GitHub Spec Kit
Una CLI de código abierto (más de 90.000 estrellas en GitHub). Admite Specify → Plan → Tasks → Implement y funciona con más de 30 agentes, incluidos Claude Code y GitHub Copilot.
AWS Kiro
Ejecuta Requirements → Design → Tasks antes de generar nada de código, con un router Auto que elige el mejor modelo para cada tarea, disponible tanto en CLI como en web.
Otras
BMAD, OpenSpec, Tessl, Google Antigravity y Cursor también ofrecen sus propios flujos de SDD. La mayoría de las herramientas principales lo admiten de alguna forma.
Ni siquiera necesitas una herramienta específica: puedes practicar la mentalidad simplemente "escribiendo primero la especificación en Markdown y haciendo que la IA la lea antes de implementar". Además, hace menos probable el problema de que la IA ignore tus reglas, porque le entregas la especificación como un documento claro.
5. Cuándo usarlo frente al vibe coding
Lo que importa no es "cuál es mejor", sino "cuándo usar cada uno". La respuesta práctica para 2026 es híbrida: vibe para explorar, spec-driven para entregar.
- Cuándo encaja el vibe coding: validar una idea, prototipos desechables, probar algo pequeño por tu cuenta. La etapa en la que solo quieres llegar rápido a "algo".
- Cuándo encaja el spec-driven: sistemas en producción que mantendrás a largo plazo, desarrollo en equipo, productos donde la especificación importa. Cuando miras todo el ciclo de vida del desarrollo.
Así que: empieza con vibe para encontrar rápido la dirección y luego, una vez que decides comprometerte, pásalo a una especificación y constrúyelo a fondo. Los dos no son opuestos: lo inteligente es usarlos en fases distintas.
6. Cómo probarlo hoy mismo
Puedes empezar poco a poco sin instalar ninguna herramienta específica.
- Escribe primero una especificación de una página: para la función que quieres, anota en Markdown, en viñetas, el "propósito, entradas/salidas y criterios de aceptación".
- Haz que la IA lea la especificación antes de pedirle código: dile "implementa estrictamente según esta especificación; pregúntame ante cualquier ambigüedad". No te limites a decir "constrúyelo".
- Trocea las tareas en pequeño: no todo a la vez; implementa una función, revísala y luego la siguiente. Capturar el procedimiento en Claude Skills mejora la repetibilidad.
- Mantén la especificación actualizada: cuando algo cambie, corrige la especificación antes que el código. Mantener la especificación como fuente de verdad es el corazón del SDD.
💡 También ayuda a los principiantes: cuando construyes una app con IA, el simple hecho de escribir primero la especificación eleva notablemente la calidad del resultado. Es un truco que puedes aplicar aunque no se te dé bien programar.
Resumen
Tres ideas clave sobre el spec-driven development.
- Qué es: escribir la "especificación" antes que el código y hacer que la IA implemente a partir de ella como fuente de verdad. La especificación es el documento central.
- Por qué: porque previene la "deriva de requisitos y la deuda técnica" del vibe coding en la fase de diseño y reduce el retrabajo.
- Cuándo: un híbrido —vibe para explorar, spec-driven para entregar—. La revisión humana es obligatoria.
Empieza con "escribe una especificación de una página antes de construir". En la era de la IA, quienes destacan no son los que escriben código más rápido, sino los que saben definir con precisión qué construir. Lee vibe coding e ingeniería de contexto junto a este artículo para tener la imagen completa del desarrollo con IA.
Preguntas frecuentes
P. ¿Puede un principiante en programación hacer spec-driven development?
R. Sí; podría decirse que es donde más eficaz resulta. Con solo organizar con palabras "qué construir" antes de escribir nada de código, se estabiliza la salida de la IA y sube la calidad. Puedes empezar desde notas en Markdown, sin ninguna herramienta específica.
P. ¿El vibe coding ya quedó obsoleto?
R. No. Para explorar y prototipar, el vibe coding sigue siendo lo más rápido. No es viejo frente a nuevo: usarlos según la fase es la corriente principal en 2026: vibe para explorar, spec-driven al entrar en producción.
P. ¿Cuánto detalle debe tener la especificación?
R. La guía es tener el detalle suficiente para transmitir "propósito, entradas/salidas y criterios de aceptación". Demasiado fino y se vuelve rígido; demasiado vago y la IA adivina. Igual que con las seis partes de un buen prompt, apunta al punto medio: específico pero flexible.
P. ¿El SDD hace innecesaria la revisión de código?
R. No. La revisión humana sigue siendo obligatoria con el spec-driven development. El SDD es un mecanismo para llevar a la IA en la dirección correcta, no una herramienta para saltarse las comprobaciones. Solo entregas con seguridad cuando una persona revisa tanto la especificación como la implementación.
