Vibe coding está bien — hasta que deja de estarlo
La técnica que Karpathy popularizó funciona para prototipos. Para producción es un Ferrari sin frenos. Cuándo aplicarla y cuándo no.
Andrej Karpathy le puso nombre a algo que mucha gente ya estaba haciendo en silencio: “vibe coding”. Le dices al agente “haz esto”, ves qué sale, le dices “ahora ajusta esto”, iteras sin leer el código a fondo. Vibes. Resultado funcional, proceso opaco.
Funciona increíble — en ciertos contextos. Funciona horrible — en otros. La diferencia es lo que casi nadie está hablando.
Cuándo vibe coding sí funciona
Prototipos throw-away. Quieres validar una idea en 30 minutos. El código va a la basura el lunes. No importa que esté “bien escrito” — importa que valide o invalide rápido. Vibe.
Exploratory data analysis. Notebook, Python, un dataset desconocido. La pregunta cambia cada 5 minutos. Optimizar para velocidad de pensamiento. Vibe.
Scripts personales. Tu propio dotfiles, automatizaciones que solo tú vas a usar, hacks de productividad. Si se rompe, lo arreglas. Vibe.
Demos para stakeholders. El demo es la mitad de la conversación. El código nunca va a producción — sale a Vercel preview, se borra. Vibe.
En todos estos: el código no es asset. Es disposable. Vibe coding es exactamente la herramienta correcta.
Cuándo vibe coding te va a quemar
Producción con usuarios reales. El bug que no leíste va a aparecer a las 2 AM y ningún humano en el equipo entiende el código lo suficiente para arreglarlo rápido. Vibe.
Compliance / regulado. El auditor pregunta “¿por qué este endpoint guarda esto?”. La respuesta “el agente lo escribió y yo lo aprobé” no califica como justificación. Vibe → multa.
Sistemas que otros van a mantener. Tu equipo va a heredar este código. Si tú no lo entendiste, ellos tampoco. Vibe → bus factor de cero.
Cuando hay invariantes no triviales. Banca, seguridad, transacciones financieras, datos médicos. El error invisible cuesta real money o vidas. Vibe → desastre.
La trampa peor: vibe coding sin diferenciar
Lo más peligroso que vemos: developers que descubren vibe coding en su prototipo del fin de semana, ven que funciona, y aplican el mismo proceso al sistema de pagos del lunes. La técnica es buena — el contexto donde la aplicaron, no.
No hay regla general “vibe coding malo” ni “vibe coding bueno”. La regla es: el método debe matchear la consecuencia del error.
- Error tolerable, código throw-away → vibe.
- Error caro, código permanente → review crítico, ADRs, comprensión completa.
Por qué Karpathy lo nombró
Vale aclarar: Karpathy no estaba recomendando vibe coding como metodología general. Estaba describiendo lo que pasa cuando trabajas con un agente bueno en contextos donde el output rápido importa más que la rigurosidad. Es observación, no prescripción.
El malentendido fue que la comunidad lo agarró como permiso genérico. “Si Karpathy hace vibe coding, yo también”. Sin diferenciar el contexto.
El test rápido
Antes de empezar una sesión de vibe coding, pregúntate:
- ¿Este código va a producción?
- ¿Alguien más va a tener que mantenerlo?
- ¿El bug invisible cuesta más de $1000?
Si la respuesta a cualquiera es sí, vibe coding es la herramienta equivocada. Apaga el vibe, prende el rigor: lee diffs, escribe ADRs, pide review crítico.
El truco honesto
Lo que vemos en equipos productivos: mezclan. Vibe coding en sprint chico de exploración los primeros 2 días. Rigor con review en los días 3-5 cuando consolidan. No es una vs la otra — es saber cuándo cambiar.
Quien aplica vibe siempre, quema producción. Quien aplica rigor siempre, no descubre nunca.
La pregunta para tu próxima sesión
¿Estás vibe coding porque es la técnica correcta para esto, o porque estás cansado y leer diffs cuesta?
Si la respuesta es la segunda, no estás haciendo vibe coding. Estás haciendo aprobando-sin-leer — y eso siempre fue mala idea, sin importar qué herramienta uses.
Si tu equipo necesita marcar la línea entre dónde vibe coding ayuda y dónde lastima, conversemos — el chat está abierto.