Spec-Driven Development vs. vibe coding: una comparación honesta desde la práctica
El vibe coding es real y útil. También es la opción equivocada para todo lo que tiene que ser correcto. Un RCT de METR, un duelo de idempotencia en pagos y el veredicto honesto.
El vibe coding es real, funciona y lo uso. Pero tiene un modo de falla que se vuelve más caro cuanto más capaz es el modelo. Este artículo es la comparación honesta: qué es cada enfoque, dónde se rompe cada uno y la regla para decidir cuándo usar cuál.
Si recién llegas a SDD, la metodología completa está en ¿Qué es Spec-Driven Development?. Después vuelve aquí para el cara a cara.
Qué es realmente el vibe coding
Andrej Karpathy acuñó el término en un post en X el 2 de febrero de 2025. Su descripción era precisa: te entregas por completo a las vibes, abrazas los exponenciales y olvidas que el código siquiera existe. No estás escribiendo código. Estás describiendo una intención y aceptando lo que produce el modelo. El nombre es exacto. Programas a puro feeling.
Cuando lo presentó, Karpathy limitó explícitamente el vibe coding a proyectos desechables de fin de semana. Ese límite importa. Su creador nunca lo propuso como metodología para producción. En menos de un año se había convertido en otra cosa: la forma por defecto en que la mayoría de los devs usa las herramientas de AI coding. El nombre se quedó y la restricción original se cayó por el camino sin que nadie lo notara.
El workflow tiene tres pasos. Describes lo que quieres en lenguaje natural. El modelo genera el código. Lo corriges un poco cuando algo se ve mal y vuelves a generar. No lees cada línea. Llevas una conversación. El que maneja es el modelo.
Es un trabajo genuinamente útil. En un prototipo desechable, tienes algo corriendo en veinte minutos. En un script roto, tres prompts suelen arreglarlo. Para entender cómo se ve realmente un problema antes de comprometerte con una arquitectura, el vibe coding te da un ciclo de feedback rápido que nada más iguala.
La pregunta no es si el vibe coding funciona. Es dónde deja de ser seguro.
El problema estructural que el vibe coding no puede resolver
El vibe coding optimiza para el momento en que algo corre por primera vez. Terminal en verde. Una página que renderiza. Una función que devuelve un valor. Ese momento se siente como progreso. La confianza del modelo es contagiosa.
La sensación empieza a mentir en cuanto tu trabajo tiene que sobrevivir a la sesión. La IA vive en un presente eterno. Cada conversación empieza de cero: no recuerda la restricción que agregaste a las 10 de la noche, el edge case que se te ocurrió en la ducha, la regla de negocio que dejaste en un comentario y después borraste. Todo lo que no escribiste se reinventa. Y no siempre igual.
No es un problema que se arregle con más contexto. Una context window de un millón de tokens le dice al agente qué es el sistema hoy. No dice nada sobre en qué debería convertirse: tu intención, tus restricciones, los edge cases que te importan, lo que queda fuera de alcance a propósito. Una ventana más grande deja al agente mejor informado sobre el presente y ni un poco más sabio sobre el objetivo.
La formulación de Addy Osmani muestra dónde está el techo: la IA te lleva más o menos al 70% del camino, rápido. El último 30% es donde vive el código de producción: edge cases, reglas de negocio, invariantes, restricciones de seguridad, todo lo que no es obvio desde el camino feliz. El vibe coding no tiene ningún mecanismo de precisión a esa profundidad. Manda otro prompt y espera que el modelo llene el hueco correctamente.
A veces lo llena. Muchas veces, no. No sabes cuál de los dos hasta que el código se topa con algo real.
La spec es lo que aporta la dirección que el modelo no puede inventar.
Los datos son peores de lo que esperas
Lo que encontró realmente la investigación
- 19%
- más lentos con IA (resultado real)RCT de METR, 2025, devs experimentados en sus propios codebases
- ~20%
- más rápidos (lo que creyeron después)Mismos devs, mismo estudio, conclusión equivocada
- 246
- issues reales evaluados16 devs experimentados, proyectos open source grandes y maduros
- ~40%
- del código de IA sensible a seguridad tenía una vulnerabilidad conocidaPearce et al., IEEE S&P 2023
En 2025, METR hizo un ensayo controlado aleatorizado con 16 devs open source experimentados que trabajaron 246 issues reales en codebases grandes y maduros, con modelos de frontera: Cursor Pro con Claude 3.5 y 3.7 Sonnet. Los devs esperaban que la IA los hiciera un 24% más rápidos. En realidad fueron un 19% más lentos. Y después seguían creyendo que los había acelerado cerca de un 20%.
Ese último número es el incómodo. La combinación de un output seguro de sí mismo con errores invisibles hace que la pérdida de productividad sea invisible desde dentro de la sesión. Te sientes rápido. Vas más lento. La distancia entre ambas cosas es justo lo que produce código equivocado-pero-seguro que termina en producción. (METR publicó un follow-up a inicios de 2026 señalando que los modelos más nuevos muestran resultados distintos en su estudio en curso; los datos de 2025 siguen siendo la base de RCT más rigurosa para esa generación de herramientas, y el mecanismo de fondo no cambió.)
El panorama de seguridad es aparte. La investigación de Pearce et al., publicada en IEEE Security and Privacy, encontró que alrededor del 40% del código generado en contextos sensibles a la seguridad contenía una vulnerabilidad conocida. El mecanismo importa más que la cifra: en código generado por IA, un defecto es un hueco en la especificación. Ese hueco reaparece cada vez que se regenera el código, con otra forma, hasta que una spec codifica la restricción de forma explícita.
La crítica se vuelve más incómoda por una razón concreta: el problema empeora a medida que los modelos mejoran. Un modelo más débil hace algo pequeño y obviamente mal. Un modelo capaz hace algo grande, coherente, bien arquitecturado y sutilmente mal. La capacidad amplifica la dirección. No la aporta.
Por qué el mismo bug siempre vuelve
Este es el mecanismo que la mayoría de las comparaciones pasa por alto, y es el argumento central a favor de trabajar con specs.
En código generado por IA, un defecto no es un error en el código. Es un hueco en la especificación. Como la generación es no determinista, ese hueco reaparece con otra forma cada vez que se regenera el código, hasta que una spec codifica la restricción explícitamente. Parchas el output. No parchas el proceso. La siguiente regeneración trae de vuelta la misma clase de problema con otra forma.
El vibe coding no tiene manera de cerrar ese hueco en el origen. Cada corrección es un ajuste local a un output aislado. El agente empieza cada sesión nueva desde cero, deduce la misma suposición que faltaba y produce la misma clase de error.
La solución no es un mejor prompt. Es escribir la restricción en un artefacto durable desde el cual el agente pueda ejecutar. Escribir la spec es parchar el proceso en lugar del output. Cuando parchas el proceso, cada regeneración futura produce una implementación segura automáticamente. Cada sesión arranca desde la misma base.
Por eso el modo de falla es invisible desde dentro de la sesión. Mandas otro prompt, el problema desaparece, la terminal queda en verde. Parece resuelto. El hueco sigue abierto. Vuelve en la próxima regeneración, cuando cambia el contexto o cuando otro agente toca el mismo código.
Un cara a cara concreto: el cobro que cobra dos veces
Toma una tarea realista de tamaño medio: un endpoint de cobros donde un reintento del cliente nunca debe cobrarle dos veces al usuario final. Este patrón aparece en los flujos de pago que construí mientras entregaba, solo, una fintech cripto de 13 apps en 70 días. El caso de estudio tiene todos los números.
El camino del vibe: escribes “agrega un endpoint POST /v1/charges con idempotencia”. El modelo genera sesenta líneas de handler en ocho segundos. Se ve completo. No lo está. La idempotencia requiere estado: un registro de qué keys ya se procesaron. Sin una constraint explícita en la base de datos, dos reintentos concurrentes pueden entrar en race condition, ambos leen “no encontrado” y ambos insertan un cobro nuevo. Cliente cobrado dos veces.
El camino de la spec escribe esto antes de que exista una sola línea de código:
FR-1 WHEN a merchant POSTs a charge with a valid Idempotency-Key,
THE SYSTEM SHALL create at most one charge for that (merchant_id, key) pair.
FR-2 WHEN the same Idempotency-Key is replayed within 24h,
THE SYSTEM SHALL return the original charge and create no new one.
Data model:
charges(id, merchant_id, amount_cents, idempotency_key, status, created_at)
UNIQUE(merchant_id, idempotency_key) -- this enforces FR-1 at the database levelLa constraint UNIQUE es toda la diferencia. No es un chequeo en el código que una race condition pueda esquivar. Es una invariante a nivel de base de datos que el agente tiene que implementar, y sobrevive a cada regeneración. La frase EARS (WHEN/SHALL) hace el comportamiento lo bastante explícito como para que el modelo no invente un atajo. Usé exactamente este patrón en todos los endpoints de pago de esa fintech. Ninguno cobró doble en producción.
Vibe coding
- 01Prompt: agrega un endpoint de cobros con idempotencia. 60 líneas en 8 segundos.
- 02La idempotency key se guarda en una columna, pero sin constraint: los reintentos concurrentes compiten y ambos insertan.
- 03El cobro doble aparece en las pruebas de carga (en el mejor caso) o en producción (en el caso común).
- 04Otro prompt corrige el síntoma, no el hueco. Próxima regeneración: la misma clase de bug.
- 05Próxima sesión: el modelo empieza de cero. Sin memoria de la discusión sobre la restricción.
Spec-Driven
- 01Regla EARS escrita primero: WHEN se reenvía la misma key, THE SYSTEM SHALL devolver el cobro original.
- 02UNIQUE(merchant_id, idempotency_key) declarada en el modelo de datos antes de que exista código.
- 03El agente genera el handler con el caso de concurrencia cubierto en la primera pasada.
- 04La restricción vive en la spec. Cada regeneración produce una implementación segura.
- 05Próxima sesión: el agente lee la spec. La invariante ya está ahí.
El camino del vibe no solo es más lento en total. Es más lento de una forma que no ves hasta que el código falla. Y falla de una forma que vuelve cada vez que regeneras sin corregir la spec.
Cara a cara en lo que realmente importa
Vibe coding vs. Spec-Driven Development
| Criterio (peso) | Vibe coding | Spec-Driven |
|---|---|---|
| Velocidad hasta el primer output (2) | 5 | 3 |
| Corrección en features reales (3) | 2 | 5 |
| Costo de retrabajo (invertido: más alto = menos retrabajo) (3) | 2 | 5 |
| Escala más allá de una sesión (3) | 1 | 5 |
| Puntuación ponderada | 25 | 51 |
Scale 1-5 (5 = best). Highlighted column: winner by weighted score.
El vibe coding lidera en una sola dimensión de producción: velocidad hasta el primer output. Esa ventaja se achica en cuanto cuentas los ciclos de retrabajo. La velocidad hasta el output correcto cuenta otra historia.
Dónde difieren los métodos en lo que cuenta
Vibe coding frente a Spec-Driven Development, de un vistazo
| Dimensión | Vibe coding | Spec-Driven |
|---|---|---|
| Artefacto principal | El último prompt | La spec aprobada |
| Memoria entre sesiones | Ninguna. Empieza de cero cada vez. | El archivo de la spec. El agente sigue desde donde lo dejaste. |
| Garantía de corrección | Lo que el modelo dedujo del prompt | Lo que la spec dice explícitamente |
| Cuando un defecto vuelve | Otro prompt y cruzar los dedos. El hueco en la spec sigue abierto. | Actualizar la spec. La restricción queda sellada para todas las ejecuciones futuras. |
| Sirve para | Prototipos, scripts, exploración en una sola sesión | Features de producción, movimiento de dinero, compliance |
La habilidad que les falta a los devs senior
La mayoría de los devs llegó a las herramientas de IA con la intuición de que el cuello de botella era la velocidad de implementación. Si el modelo escribe código más rápido, yo voy más rápido. El resultado de METR rompe esa suposición sin rodeos. Devs experimentados en sus propios codebases fueron más lentos. El cuello de botella nunca fue la implementación. Fue la precisión de la intención.
Esto les pega más fuerte a los devs senior de lo que nadie espera, y el porqué es contraintuitivo. Experiencia significa más contexto implícito: más conocimiento de la historia del sistema, más suposiciones sobre qué significa “correcto”, más decisiones que parecen obvias y nunca se escriben. Todo ese conocimiento tácito es invisible para el modelo. Cuanto más sabes, mayor es la distancia entre lo que dijiste y lo que quisiste decir.
Un dev junior describe lo que quiere en términos más explícitos, porque está menos seguro de qué es obvio. Un dev senior le pasa al modelo un boceto y espera que complete el resto como lo haría otro ingeniero experimentado. El modelo no completa así. Hace pattern matching contra todo lo que ha visto, y el patrón más común no es tu sistema en particular.
Por eso el hallazgo de METR golpea más fuerte justo a quienes más esperaban de la IA. Los devs del estudio eran experimentados, trabajaban en sus propios codebases y usaban modelos de frontera. Aun así perdieron terreno. La causa no es la capacidad. Es la distancia entre lo que se dijo y lo que tenía que ser cierto.
La propia guía de Anthropic lo dice explícitamente: “dejar que Claude salte directo a programar puede producir código que resuelve el problema equivocado”. Años de experiencia no te ayudan a escribir prompts más rápido. Te ayudan a pensar con precisión en lo que tiene que ser cierto antes de que el código corra: las restricciones, los edge cases, las invariantes, lo que queda fuera de alcance a propósito. Esa precisión, encerrada en tu cabeza, es invisible para el modelo. Escribir una spec la externaliza en un artefacto durable desde el cual el agente sí puede ejecutar.
Profundicé en esto en Don’t Code, Specify: por qué los devs experimentados obtenían peores resultados con herramientas de IA y qué cambió cuando cambié el workflow por defecto.
El veredicto honesto: vibe cuando equivocarse es barato, spec cuando no
No estoy argumentando contra el vibe coding. Lo uso todo el tiempo, y tú también deberías. El error es aplicarlo a la clase equivocada de problema.
Anthropic traza una línea práctica en su propia guía: “si puedes describir el diff en una oración, sáltate el plan”. Uso esa prueba todo el tiempo. Una oración significa baja complejidad, bajo riesgo, probablemente poco en juego. Cuando la descripción necesita tres oraciones y una lista de edge cases, eso es la spec.
La mayoría de los proyectos reales necesita los dos modos. Haz en modo vibe el trabajo exploratorio, para entender cuál es realmente el problema. Especifica todo lo que entra a producción. El error es tratar todo el trabajo como de una sola categoría. Así terminas con vibe coders con incidentes en producción y escritores de specs sin nada entregado.
La idea del 70% señala dónde está la costura. Usa vibe coding para llegar rápido al 70% y luego pasa a SDD para cerrar el hueco correctamente. Uno después del otro, no uno contra el otro.
Preguntas frecuentes
¿El vibe coding es malo?
No. El vibe coding es genuinamente útil para trabajo de bajo riesgo y feedback rápido: prototipos, scripts, spikes exploratorios. El problema no es el enfoque. Es aplicarlo a trabajo donde la corrección, los edge cases y la continuidad entre sesiones realmente importan.
El modo de falla es tratar el vibe coding como opción por defecto para todo el desarrollo asistido por IA, incluidas las features de producción donde el último 30% de corrección es el que sostiene todo.
¿Karpathy inventó el vibe coding?
Andrej Karpathy acuñó el término el 2 de febrero de 2025, en un post en X. Lo describió como entregarse por completo a las vibes y olvidar que el código siquiera existe. El concepto en sí (aceptar el output de la IA sin leer cada línea, guiándose por feeling) ya venía apareciendo en la práctica; él le puso nombre y forma.
También lo limitó explícitamente a proyectos desechables de fin de semana. Esa restricción original se perdió a medida que el término se difundió. La mayoría de los problemas del vibe coding en producción vienen directamente de ignorar el alcance que Karpathy fijó al definirlo.
¿Puedo combinar vibe coding y SDD?
Sí, y en la mayoría de los proyectos reales deberías. El vibe coding es excelente para explorar: aprendes cuál es el problema construyendo rápido una versión tosca. La spec captura lo que descubriste y se convierte en la base del build de producción.
Vibe para descubrir. Spec para entregar. Uno después del otro, no uno contra el otro.
¿Por qué el mismo bug de IA siempre vuelve?
Porque corregiste el output, no la spec. En código generado por IA, un defecto es un hueco en la especificación. La generación es no determinista, así que ese hueco reaparece con otra forma cada vez que regeneras, hasta que una spec codifica la restricción explícitamente.
La solución es parchar la spec, no solo el código. El código es el output. La spec es la fuente. Este es el mecanismo central detrás de la recurrencia de vulnerabilidades en código de IA sensible a seguridad (Pearce et al., IEEE S&P 2023).
¿Por qué los devs senior van más lentos con IA?
Por dos razones. Primero, los devs experimentados cargan más contexto implícito, es decir, más suposiciones que el modelo puede violar en silencio. La distancia entre lo que quisiste decir y lo que dijiste es mayor cuando tu modelo mental del sistema es complejo.
Segundo, los devs experimentados suelen trabajar en sistemas de producción donde el último 30% de corrección es el que sostiene todo. Justo ahí es donde el vibe coding se estanca. El hallazgo de METR (19% más lentos en sus propios codebases, con modelos de frontera) llama la atención porque esos devs conocían bien sus codebases. El cuello de botella era la precisión de la intención, no la familiaridad con el código.
Por dónde seguir
El vibe coding y SDD responden preguntas distintas. El vibe pregunta: ¿qué tan rápido puedo tener algo corriendo? SDD pregunta: ¿cómo me aseguro de que lo que corre es lo que realmente quería construir?
Las dos preguntas importan. La habilidad está en saber cuál aplica.
La newsletter
Don’t Code, Specify. Cada semana, agentes de IA en producción de verdad. Sin hype: lo que funcionó y lo que se rompió.
Suscríbete en Substack (se abre en una pestaña nueva)