El Backlash del Vibecoding Es Real — Pero También Lo Es Estar Perdiendo el Punto
Esta semana, dos posts llegaron a Hacker News con horas de diferencia y los dos superaron los 100 puntos antes del mediodía. El primero: “The 100-Hour Gap Between a Vibecoded Prototype and a Working Product” — 315 puntos, 238 comentarios, ingenieros compartiendo historias de guerra sobre codebases generadas por IA que explotaron en producción. El segundo: “I’m 60 Years Old. Claude Code Killed a Passion” — 169 puntos, 124 comentarios, devs mayores lamentando lo que sienten como la automatización lenta del oficio de programar.
Dos posts, la misma semana, la misma comunidad. El backlash del vibecoding es oficialmente mainstream.
¿Está justificado? Sí y no. Acá está el mapa real.
Qué disparó el backlash
Cuando Andrej Karpathy acuñó “vibe coding” a principios de 2025, lo describió como entregarse al flujo del output de la IA — aceptar el código sin leerlo demasiado, iterar por intuición. Se viralizó porque era honesto y un poco rebelde. Para mediados de 2025, el interés de búsqueda en “vibe coding” había saltado un 6.700% (Exploding Topics).
Después terminó la luna de miel.
Una revisión de seguridad de 15 aplicaciones construidas con herramientas populares de vibecoding encontró 69 vulnerabilidades. Investigaciones separadas encontraron que el código generado por IA introducía factores de riesgo OWASP en el 45% de las muestras. Un análisis de CodeRabbit encontró 1.7x más bugs graves y 2.7x más vulnerabilidades de seguridad en código escrito por IA vs. código escrito por humanos.
Y quizás el dato más contraintuitivo: el estudio de METR encontró que desarrolladores experimentados trabajando en repos familiares eran en realidad un 19% más lentos usando herramientas de IA — a pesar de creer que eran más rápidos.
Mientras tanto, un artículo de Fast Company lo llamó el “vibe coding hangover”: ingenieros senior lidiando con codebases enormes generadas por IA que nadie entendía del todo.
El enojo de la comunidad tiene sentido. Mucha gente se movió rápido, despachó software malo, y ahora está lidiando con las consecuencias.
Pero los críticos también están errando el punto
Esto es lo que los posts del backlash tienden a confundir: el vibecoding como práctica y el vibecoding como filosofía.
El framing original de Karpathy — “olvidate de que el código existe” — siempre fue la parte peligrosa. Nadie serio adoptó eso al pie de la letra. Pero ¿usar IA para generar porciones significativas de tu codebase? Eso está en todos lados ahora. Google reveló que más del 25% de su código nuevo es generado por IA. Gartner proyecta que el 60% de todo el código nuevo será generado por IA en 2026. El batch de invierno 2025 de Y Combinator tuvo un 25% de founders generando el 95%+ de su código con IA.
La pregunta no es si usar IA en tu workflow. Ese barco zarpó. La pregunta es dónde lo aplicás y qué nivel de supervisión traés.
Hay una división útil: zona verde vs. zona roja.
| Zona | Qué contiene | Riesgo del vibecoding |
|---|---|---|
 Verde |
Componentes UI, prototipos, herramientas internas, scaffolding, CRUD | Bajo — iterá rápido, los errores son baratos |
 Roja |
Business logic, auth, flujos de pago, capa de datos, paths críticos de seguridad | Alto — la IA no conoce tus políticas de seguridad |
Aplicar generación por IA indiscriminadamente en ambas zonas es donde las cosas salen mal. Usarla quirúrgicamente en la zona verde, con revisión real en la zona roja, es donde vienen las ganancias de productividad del 51% de las que todos hablan.
El gap de las 100 horas es real — y predecible
El título del post de HN clava el problema real: hay una brecha genuina entre un prototipo vibecodeado que se ve bien en un demo y un producto listo para producción. No son siempre 100 horas, pero el gap es real y viene de fuentes predecibles:
1. Deuda técnica que se acumula. Los modelos de IA optimizan para “funciona ahora”, no para “mantenible en seis meses.” El resultado suele ser código acoplado y no modular que es perfecto para demos y brutal para iterar. Un analista proyecta $1.5 billones en deuda técnica generada por IA para 2027.
2. Gaps de seguridad que no sabías que existían. La IA no conoce las políticas de seguridad específicas de tu organización, tus reglas de clasificación de datos, ni esa API legacy que espera un header en formato específico. Llena los blancos de maneras que suelen introducir vulnerabilidades que solo aparecen bajo condiciones reales.
3. Pérdida de contexto a escala. Los prototipos empiezan chicos, pero los codebases crecen. Cuanto más alejado estás de la generación inicial, más difícil es guiar la IA productivamente sin un spec estructurado al que pueda referirse. Por eso existen herramientas como los workflows basados en specs y los archivos CLAUDE.md — son una respuesta directa a este problema.
La pregunta del oficio es más difícil
El post “tengo 60 años y Claude Code mató una pasión” está tocando un nervio diferente. No uno técnico — uno de identidad.
Vale la pena tomarlo en serio, aunque no tengas 60. Hay una diferencia real entre programar como oficio — la satisfacción de resolver un problema a través de tu propio entendimiento — y programar como mecanismo de entrega. La IA colapsa el segundo. No toca el primero.
Dario Amodei en Davos dijo que los ingenieros de Anthropic ya dejaron de escribir código manualmente — dirigen la IA y revisan el output. Sam Altman dijo que la IA ya escribe hasta el 50% del código en muchas organizaciones. Ambos venden herramientas de IA, así que descontá el hype. Pero la dirección es clara: el medio de expresión está cambiando.
Los devs que mejor están navegando esto no son los que “se entregan a los vibes” ni los que se niegan a usar IA. Son los que redefinieron en qué consiste su habilidad. Menos: “Escribo funciones.” Más: “Diseño sistemas, especifico el intent con precisión, y sé cómo se ve el output correcto.”
Eso sigue siendo un estándar alto. Solo es uno diferente.
Un framework práctico para decidir
Antes de agarrar una herramienta de vibecoding para cualquier tarea, preguntate:
1. ¿Esto es descartable o va a producción?
Prototipado, herramientas internas, y MVPs — generá libremente, revisá selectivamente. Sistemas de producción — generá con spec ajustado, revisá todo en la zona roja.
2. ¿Puedo debuggear lo que vuelve?
Si no podés leer y entender el código generado, no podés hacerte dueño de él. El cuello de botella pasa de generación a verificación — y si no estás equipado para verificar, estás acumulando riesgo, no velocidad.
3. ¿El repo es familiar o nuevo?
El 19% de ralentización en el estudio de METR vino de devs trabajando en codebases existentes y complejos. En código nuevo, la IA es más rápida. En sistemas legacy con mucho contexto que la IA no tiene, la matemática suele invertirse.
4. ¿Esto toca auth, pagos, o datos?
Zona roja. Aplicá criterio de ingeniería humana antes de deployar cualquier cosa generada por IA en esos paths.
La conclusión
El backlash del vibecoding es una señal de madurez, no una sentencia de muerte. Cuando una tecnología pasa de “magia” a “esto causó problemas reales y la gente está enojada”, significa que se está usando en serio — a escala, en producción, por gente que tiene algo en juego.
El camino a seguir no es abandonar el código generado por IA. Es ser explícito sobre sus modos de falla y construir workflows que los contemplen. Los devs que ganan en 2026 no son los que vibecodearon más fuerte ni los que se negaron a tocar el output de la IA. Son los que saben exactamente cuándo dejar que la IA corra y cuándo volver a tomar el volante.
¿Coincidís con que el backlash es una señal de madurez, o creés que hay algo más profundo en juego? Dejá tu opinión en los comentarios. 