Vibe coding vs spec-driven development: el debate que define cómo construyes software en 2026
Si llevas un tiempo construyendo software con IA, habrás visto dos campos. En uno están los que abren un chat con Claude, escriben «hazme una app que…» y aceptan lo que devuelve. En el otro, los que escriben una especificación detallada, dejan que la IA genere código contra ella y validan cada iteración contra criterios explícitos. El primero se llama vibe coding. El segundo, spec-driven development. Ambos funcionan. Pero no funcionan para lo mismo.
Este artículo es la comparativa honesta entre los dos enfoques. Cuándo conviene cada uno, dónde se rompe el vibe coding cuando intentas escalar, y qué cambia cuando trabajas spec-driven.
Qué es vibe coding
El término vibe coding lo popularizó Andrej Karpathy en 2025. Se refiere a construir software dejando que la IA tome las decisiones técnicas mientras tú describes la intención en lenguaje natural. «Quiero una app de listas de tareas con un toque minimalista». La IA escribe el código, tú aceptas o pides cambios, iteras hasta que te gusta.
Funciona sorprendentemente bien para prototipos. Un fin de semana, una idea, una demo que puedes mostrar. La fricción es mínima, el output es funcional, el coste es bajo.
El problema empieza después.
Qué es spec-driven development
Spec-driven development es lo contrario. Antes de escribir código, escribes una especificación detallada: modelo de datos, contratos de API, reglas de negocio, casos de uso, criterios de aceptación. Esa spec es el documento autoritativo. La IA genera código contra ella. Los tests validan que se cumple. Cada cambio empieza por actualizar la spec.
Es menos sexy. Más lento al principio. Y exactamente lo que necesitas si lo que construyes va a durar más de una semana. Lo abordamos en detalle en qué es spec-driven development y por qué importa.
La diferencia, traducida a lo que importa
| Criterio | Vibe coding | Spec-driven development |
|---|---|---|
| Tiempo a primer demo | Horas | Días |
| Tiempo a producto serio | Nunca llega | Semanas |
| Calidad estructural | Variable, suele degradarse | Consistente |
| Mantenibilidad a 6 meses | Baja | Alta |
| Coste de añadir features | Crece con cada sprint | Estable |
| Documentación | No hay | La spec es la documentación |
| Transferible a otro equipo | Casi imposible | Sin fricción |
| Resistencia a bugs en regresión | Baja | Alta (tests derivados de spec) |
| Coste inicial | Mínimo | Moderado |
| Coste a 3 meses | Empieza a explotar | Predecible |
Dónde se rompe el vibe coding
Lo que casi nunca se cuenta sobre vibe coding es lo que pasa a partir del segundo o tercer sprint. La curva es siempre la misma:
Sprint 1: gloria absoluta
Construyes en horas algo que parecía un mes de trabajo. Compartes capturas con orgullo. Crees haber encontrado la solución definitiva al desarrollo de software.
Sprint 2: empieza la fricción
Pides añadir una funcionalidad. La IA, sin recordar las decisiones implícitas del sprint 1, escribe código que rompe algo del anterior. Pasas un rato debugging. Sigues adelante.
Sprint 3: las inconsistencias
Empiezas a notar patrones contradictorios en el código. Una parte usa async/await, otra callbacks. Un endpoint devuelve { data, error }, otro lanza excepciones. No sabes por qué. Tampoco te apetece refactorizar todo.
Sprint 4: la deuda técnica visible
Un cambio que «debería ser de cinco minutos» te lleva la mañana. La IA, al no tener spec, no sabe cuál es la intención correcta. Tú, sin documentación, tampoco la recuerdas con precisión. Decides «hacerlo a mano esta vez».
Sprint 5+: el atasco
Cada nueva feature requiere arqueología en el código. Los tests, si existen, fallan de forma intermitente porque dependían de comportamientos implícitos. No puedes traer a nadie nuevo porque no tienes cómo explicarles qué hace el sistema. Lo único que te queda es reescribirlo. Y descubres que reescribir es más caro que haber especificado al principio.
Dónde se rompe el spec-driven (sí, también se rompe)
SDD no es la solución universal. Tiene sus propios riesgos:
- Spec demasiado detallada al inicio. Si pasas semanas especificando un MVP, has matado la ventaja de velocidad. La spec inicial debe ser lo suficiente, no perfecta.
- Spec que se desactualiza. Si el equipo deja de actualizarla, vuelve a ser una mentira y todo el sistema se cae.
- Discusiones bizantinas sobre nomenclatura. Si la cultura de equipo permite eternos debates sobre cómo llamar a una entidad en la spec, el método se convierte en lastre.
- Pretender especificar lo no-especificable. Hay decisiones de UX y de copy que no caben en spec técnica. Forzarlas allí es contraproducente.
SDD funciona cuando hay disciplina, no cuando hay obsesión.
Quién debería usar cada enfoque
Vibe coding tiene sentido para:
- Prototipos de fin de semana para validar una idea con tres amigos.
- Scripts internos que solo tú vas a usar una vez.
- Demos rápidas para acompañar una conversación.
- Aprender una tecnología nueva sin compromiso.
- Hackathons.
Spec-driven tiene sentido para:
- MVPs que van a producción con usuarios reales.
- SaaS multi-tenant con billing y panel admin.
- Integraciones con sistemas empresariales (ERP, CRM, PIM).
- Productos con lógica de negocio compleja (pricing, descuentos, workflows).
- Cualquier código que vaya a vivir más de tres meses.
- Equipos que rotan o crecen.
- Clientes que van a auditar el código.
El argumento económico
Vibe coding gana en coste durante las primeras 40 horas de proyecto. Spec-driven gana a partir de las 80 horas. La curva se cruza alrededor de la semana 2 o 3 de trabajo.
Por debajo de ese umbral, vibe coding es objetivamente mejor: más rápido, más barato, menos overhead. Por encima, spec-driven es objetivamente mejor: menos deuda, más mantenible, transferible.
El error no es elegir uno u otro. Es elegir el equivocado para tu caso.
Cómo combinarlos
El flujo que mejor funciona en proyectos reales es híbrido:
- Vibe coding para explorar. Cuando no sabes todavía qué quieres construir, prototipa con vibe coding. Construye 3-4 versiones distintas, valida la dirección, descarta lo que no.
- Spec a partir del prototipo elegido. Una vez sabes qué quieres, convierte el prototipo en una especificación. No es trabajo perdido: el prototipo te ha enseñado lo que necesitabas saber.
- SDD para construir la versión que va a producción. A partir de aquí, todo cambio empieza por la spec.
El error común es saltarse el paso 2. Si pasas directamente de un prototipo vibe coded a producción sin escribir spec, has firmado para el atasco del sprint 4.
El cambio cultural pesa más que el cambio técnico
Vibe coding apela al hemisferio que quiere resultados ya. Spec-driven apela al hemisferio que entiende que la velocidad del proyecto se mide en meses, no en días. Pasar de uno a otro no es enchufar una herramienta nueva. Es cambiar la conversación que el equipo tiene con la IA.
La pregunta que sustituye «hazme algo» es: «qué debería hacer exactamente este sistema cuando…». Una vez la haces, ya estás haciendo SDD.
El stack moderno de SDD
Si decides moverte a spec-driven, las herramientas que necesitas existen y son maduras:
- Claude Code o Cursor como entorno principal de generación.
- MCP para que el modelo consulte datos reales.
- Schemas declarativos (Zod, Pydantic, JSON Schema) que codifiquen restricciones de la spec.
- Tests automáticos derivados de criterios de aceptación.
- Git con commits estructurados que enlacen cada cambio de código con su justificación en spec.
No necesitas adoptar ningún framework propietario. Las prácticas funcionan con cualquier stack moderno.
Cómo lo abordamos en Pango Studio
En Pango aplicamos spec-driven development para todos los proyectos que van a producción. No porque sea ideología, sino porque después de muchos proyectos hemos visto la diferencia entre el código que aguanta seis meses y el que no.
Si quieres ver el método aplicado a un proyecto real, aquí explicamos cómo lo abordamos o hablamos directamente.