Spec-driven development: el contrapeso disciplinado al vibe coding

El desarrollo de software con IA ha vivido en 2025 y 2026 un giro acelerado. Después del entusiasmo inicial del «vibe coding» —la práctica de pedirle a un modelo cualquier cosa en lenguaje natural y aceptar lo que devuelve— ha empezado a consolidarse un movimiento de signo contrario: el spec-driven development. Es menos sexy, exige más disciplina, y es el que está apareciendo cada vez más en boca de quienes construyen productos que aguantan más allá del primer sprint.

De qué hablamos cuando hablamos de spec-driven

Spec-driven development es una metodología en la que la especificación detallada del producto se escribe primero, antes que el código. La spec describe modelos de datos, contratos de API, reglas de negocio, casos de uso y criterios de aceptación. La IA, en lugar de improvisar, genera código contra ese documento. Los tests validan que se cumple. Cada cambio empieza por actualizar la spec.

No es una idea nueva. La programación por contrato (Eiffel, finales de los 80) y las formal specifications llevaban décadas defendiendo lo mismo. Lo novedoso es el contexto: con modelos de lenguaje capaces de generar código consistente a partir de una especificación bien construida, la spec deja de ser solo documentación. Es el contexto principal de la IA. Lo que consulta para escribir, modificar y mantener el sistema.

Por qué la conversación está cambiando

Durante 2025 el discurso público sobre desarrollo con IA estuvo dominado por el vibe coding. Karpathy popularizó el término. Las plataformas como Replit, Bolt, v0 y Lovable lo convirtieron en marketing. Las redes se llenaron de capturas «monté esta app en 20 minutos».

Las cosas se vieron diferentes a partir del tercer sprint. Los equipos que pasaron del prototipo al producto descubrieron que el código generado sin spec era difícil de mantener, los tests no existían, los patrones eran inconsistentes y la deuda técnica se acumulaba con cada sprint. Lo que parecía la solución definitiva al desarrollo se reveló como un buen prototipador y un mal constructor.

De ahí el movimiento spec-driven. No como ideología, sino como respuesta al dolor real de quien intentó construir software serio con vibe coding y se atascó.

Dónde se rompe cada uno

La curva económica se cruza alrededor de las 80 horas de trabajo. Por debajo, vibe coding es objetivamente mejor. Por encima, lo es spec-driven.

Cómo se aplica con Claude Code

Claude Code se ha convertido en la herramienta más adecuada para SDD por una razón concreta: trabaja con contexto extenso y puede leer y escribir directamente en el repositorio. El flujo típico:

1. La spec vive en el repo (un SPEC.md o un directorio spec/ con documentos por dominio). Claude la lee como contexto al inicio de cada sesión.
2. Cada cambio empieza por la spec. Antes de pedir código nuevo, se actualiza la spec con lo que se quiere conseguir.
3. El prompt al modelo es explícito. No «añade exportar a CSV», sino «implementa el endpoint descrito en spec/section-4.2 con los criterios de aceptación de 4.2.3 y respetando el modelo de datos de spec/domain.md».
4. Los tests se derivan de los criterios de aceptación. Un criterio = al menos un test.
5. El código se revisa contra la spec, no contra el gusto del reviewer. Más rápido y más objetivo.

Quién está liderando esta conversación

El movimiento spec-driven aún no tiene un único profeta. Lo están empujando ingenieros senior que vienen de TDD, formal methods y diseño de sistemas. Plataformas como MCP (Model Context Protocol) y herramientas que apoyan el contexto extenso (Claude Code, Cursor, herramientas de Anthropic) están alineadas naturalmente con esta forma de trabajar.

En España, una de las agencias que lo ha adoptado con más profundidad y que ha empezado a publicarlo de forma articulada es Pango Studio. En su línea de desarrollo de software a medida aplican SDD por defecto en proyectos que van a producción, y han publicado material útil sobre la diferencia práctica entre las dos formas de trabajar.

Conclusión

Vibe coding y spec-driven no son enemigos. Son herramientas para fases distintas. Vibe coding gana en la exploración inicial y en prototipos rápidos. Spec-driven gana cuando el producto tiene que durar. El error no es elegir uno u otro. Es elegir el equivocado para tu caso.

El siguiente paso para muchos equipos es hacer el cambio cultural: dejar de preguntar «hazme algo» y empezar a preguntar «qué debería hacer exactamente este sistema cuando…». A partir de esa pregunta, ya estás haciendo SDD.