Vibe coding: 9 veces más riesgo de mala calidad (GitClear)

La advertencia de un veterano: la IA no acumula intuición

En una entrada publicada el 22 de septiembre, el desarrollador Alex N. sostiene que la inteligencia artificial no acumula sabiduría técnica y que quienes delegan en ella la lectura y escritura de código terminarán sin haberla desarrollado. La pieza parte de frases que el autor asegura escuchar este mes: «no he escrito código desde 2025», «las code reviews están muertas», «ya nadie lee código».

Su argumento central es que la IA no está entrenada con señales de mantenibilidad. El aprendizaje por refuerzo necesita una recompensa medible al instante, pero la deuda de un mal diseño se nota en meses o años. Los LLM, además, se entrenan con código «del mundo real» y, «siendo honestos, la mayor parte del código en producción es bastante malo», escribe. Por eso su predicción es provocadora: en el futuro, más empresas presumirán una política NO-AI como ventaja competitiva. Y, dice, «tendrán razón».

¿Qué dice la evidencia? Números detrás del vibe coding

La intuición del autor coincide con datos publicados este año por varias firmas del sector. El informe State of Code Abundance 2026 de CloudBees, citado por TechTarget, encontró que el 81% de los líderes técnicos empresariales vio más problemas en producción vinculados a código generado por IA, aunque el 92% se sentía seguro al desplegarlo. El análisis de GitClear de enero de 2026, también recogido por TechTarget, halló que los peores resultados de calidad de código eran nueve veces más probables entre los usuarios más intensos de IA.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El AI Trust Index de Secure Code Warrior, elaborado con RMIT University en Australia, evaluó 1.760 codebases generadas por IA sobre 16 modelos y reportó una media de 15 vulnerabilidades por codebase, concentradas en fallos de logging, inyección, diseño inseguro y control de acceso roto. SD Times, por su parte, estima que el 83% de los desarrolladores ya utiliza herramientas de IA en su flujo diario.

En el terreno de los incidentes públicos, TechTarget recoge reportes internos divulgados por Business Insider sobre cambios de código asistidos por IA que contribuyeron a dos caídas del sitio retail de Amazon en una semana, en marzo de 2026: una costó unos 120.000 pedidos perdidos y 1,6 millones de errores web; la otra, aproximadamente 6,3 millones de pedidos perdidos.

Por qué el código vibra pero se rompe después

El término vibe coding describe aplicaciones enteras escritas por IA a partir de descripciones en lenguaje natural. Funcionan al inicio y, a ojos no entrenados, parecen correctas. SD Times advierte que la métrica más usada para «limpiarlas», reducir líneas de código, es engañosa: un repositorio más pequeño puede seguir ocultando lógica de negocio contradictoria, credenciales hardcodeadas, dependencias inseguras y, sobre todo, ausencia de capas de autorización.

El medio recoge el caso real de una aplicación con 13 rutas que renderizaban la página correcta en la secuencia correcta, pero sin route guards: cualquier visitante podía acceder a la página de facturación sin cuenta. Reducir el código no cierra ese agujero; borrarlo tampoco. Es un problema arquitectónico, no de sintaxis.

Alex N. lo describe desde el lado del diseño: la IA es «pésima simplificando código». Divide funciones en pedazos no reutilizables, y extraer una subfunción de otra mayor es una mala decisión si, para entender la mayor, aún hay que leer la implementación de la extra. Definir funciones aclaradoras y reutilizables, escribe, «es una forma de arte que lleva maestría».

Qué cambia cuando dejas de leer y escribir código

La advertencia más seria del texto no es sobre el código en sí, sino sobre las personas que lo producen. Los desarrolladores expertos, dice el autor, llegan a ese nivel gracias a horas depurando incidentes en producción y jurando no repetir errores. Su criterio se vuelve contextual, no replicable en reglas. La IA, en cambio, aprende de reglas hechas para principiantes.

Cuando un equipo entero delega la lectura y la escritura en la IA, las decisiones dejan de pasar por humanos que puedan aprender de ellas. El equipo nunca llega a maestría porque ya no elige, ya no se equivoca, ya no corrige. Y como la IA no aprende de los errores que comete (solo los repite), el resultado neto es que ni el software ni las personas que lo mantienen mejoran.

Sudheer Mareddi, SVP de Sutherland, lo confirma en TechTarget: «la primera habilidad que se erosiona no es la programación, es el diagnóstico«.

Qué significa esto para tu startup

La tesis del ensayo no es «deja de usar IA», sino «úsala sin dejar de ser responsable del código que entrega». Si tu equipo depende de generación automática para acelerar, hay tres decisiones que conviene tomar antes de que el problema aparezca:

Asignar un dueño humano por cada bloque que sale a producción. No basta con aceptar el diff: alguien debe poder explicar, defender, probar y mantener ese código en seis meses. Nick Shevelyov, fundador de vCSO.ai y ex CISO de Silicon Valley Bank, recomienda trackear el porcentaje de código mergeado con un humano responsable nombrado; «cuando ese número baja, la deuda se acumula en silencio».
Medir lo que la IA no puede medir. Líneas borradas, cobertura de tests y estado del linter no detectan capas de autorización ausentes ni lógica de negocio duplicada. Conviene complementar con revisión humana de diffs por seniors, métricas de complejidad ciclomática y walkthroughs donde el autor debe explicar qué hace realmente el módulo antes del merge.
Reservar tiempo de práctica sin IA. Pair programming, code walkthroughs y ejercicios AI-free, aunque sean quincenales, son la única manera de que tu equipo no pierda el olfato que el ensayo describe.

La apuesta de fondo del autor, que alguna compañía convertirá «no usamos IA para esto» en un argumento de marketing, ya tiene precedente en otros sectores (comida hecha a mano, soporte sin bots). Si tu ventaja competitiva real está en la mantenibilidad del código que entregas a clientes enterprise, declararlo puede ser más rentable que esconderlo.

Conclusión

El ensayo de Alex N. resume una preocupación que los datos de 2026 ya hacen difícil de ignorar: la IA acelera la escritura de código, pero no enseña a quien lo escribe, y el costo de esa combinación se paga en producción. Para founders hispanohablantes que escalan equipos técnicos, el mensaje práctico no es anti-IA; es que la maestría técnica sigue siendo un activo que se construye leyendo, rompiendo y arreglando código. Las herramientas cambian. Esa parte, de momento, no.