El código sale más rápido, y la vulnerabilidad también

Un desarrollador arma un SaaS completo en un fin de semana. No domina el framework, no tiene formación seria en seguridad y nadie revisa el código. La aplicación corre, se ve bien, responde rápido. Todo parece una pequeña hazaña de productividad. Hasta que aparece el detalle que arruina la épica: las claves de API quedaron expuestas a internet.

Ahí está el corazón del problema. En 2026, vibe coding se volvió la forma más veloz de publicar software útil. También se volvió la forma más veloz de publicar vulnerabilidades.

La IA ya compila mejor, pero sigue pensando peor en seguridad

La cifra más incómoda viene de Veracode, que probó más de 100 modelos en 80 tareas reales de programación. El hallazgo fue contundente: 45% del código generado por IA no superó pruebas de seguridad e introdujo fallas alineadas con OWASP Top 10 en sistemas listos para producción. Java fue el peor lenguaje, con una tasa de fallo superior a 70%. Python, C# y JavaScript se movieron entre 38% y 45%.

Lo inquietante es la contradicción. Los modelos mejoraron muchísimo para escribir código que sí corre. Hace dos años, menos de 20% de las muestras siquiera funcionaba. Hoy, cerca de 90% compila al primer intento. Pero la tasa de inseguridad casi no se movió. Como resumió el diagnóstico citado por Help Net Security al revisar el informe de Veracode, los modelos están mejorando para programar con precisión, no para programar con seguridad.

Tampoco sirve refugiarse en la idea de que el próximo modelo grande resolverá esto. Los modelos más recientes y más pesados no están generando código sensiblemente más seguro.

El hábito de “solo agrega esto” vuelve peor el sistema

Aquí entra la trampa cotidiana. Pides una primera versión. Luego agregas una feature. Después otra. Luego ajustes, permisos, validaciones, excepciones. Lo que parece una iteración normal de producto puede convertirse en una fábrica silenciosa de riesgo. La investigación de Kaspersky encontró que, tras solo cinco iteraciones de prompt, el código contenía 37% más vulnerabilidades críticas que en la generación original. En todo el conjunto de pruebas, los prompts orientados a nuevas funcionalidades produjeron 158 vulnerabilidades nuevas, incluidas 29 críticas.

La razón no es misteriosa. Cada revisión agrega complejidad sin rediseñar la arquitectura. El modelo optimiza para “ya funciona”, no para “sigue siendo robusto”. Así se van acumulando huecos que se parecen bastante a las vulnerabilidades de seguridad en infraestructura de agentes de IA: piezas que individualmente parecen razonables, pero juntas crean una superficie de ataque mucho mayor.

Eso deja a muchos equipos en una situación extraña. Sienten que avanzan rápido porque la aplicación hace más cosas. En realidad, están comprando deuda técnica y riesgo operativo a crédito.

El fallo más serio no siempre está en las inyecciones clásicas

Conviene hacer un matiz porque evita una lectura simplista. Un estudio de diciembre de 2025, recogido por CSO Online a partir de la investigación de Tenzai, evaluó cinco herramientas, entre ellas Claude Code, Codex, Cursor, Replit y Devin, construyendo tres aplicaciones idénticas con cada una. El resultado fue 69 vulnerabilidades en 15 aplicaciones.

Lo llamativo es que las herramientas no generaron fallas explotables de SQL injection ni de cross-site scripting en el nivel clásico que todos esperan encontrar. Esos patrones ya están demasiado documentados y, en parte, ya fueron desaprendidos por los modelos. El peligro real apareció en vulnerabilidades de lógica de negocio.

Un checkout que acepta que el usuario defina su propio precio. Un endpoint que confía en la autorización enviada desde el cliente. Un flujo que compila perfecto, pero entiende mal qué debería bloquear. Esos son los huecos que muchas compañías sin defensa frente a exploits de IA siguen dejando pasar, porque requieren entender intención, contexto y reglas del negocio.

El 81% más rápido puede terminar siendo tiempo prestado

La velocidad no es una ilusión total. El problema es que suele medirse demasiado pronto. InfoQ, al resumir el análisis de Ox Security, describió este tipo de código como altamente funcional, pero sistemáticamente pobre en criterio arquitectónico. Entre 80% y 90% de los proyectos revisados aparecieron anti patrones repetidos: comentarios excesivos, resistencia a refactorizar, sobreespecificación y errores que regresan una y otra vez.

La analista Ana Bildea lo resumió con una idea incómoda: la deuda técnica creada por IA no crece de forma lineal, sino compuesta. Durante unos meses parece que todo acelera. Más adelante, los parches, las reescrituras y el retrabajo devoran el ahorro inicial. Eso encaja con los beneficios de productividad que desaparecen en retrabajo.

El estudio de METR, citado en el artículo base, clavó bien esa brecha de percepción. Los desarrolladores sentían que iban 20% más rápido, pero la medición real en codebases existentes mostró un rendimiento 19% más lento. La sensación es inmediata. El costo llega después.

La solución funciona, pero exige pensar justo lo que se quería evitar

Aquí aparece la conclusión menos sexy. El prompting orientado a seguridad sí mejora resultados. La propia Kaspersky observó que una instrucción tan genérica como pedir buenas prácticas de código seguro reducía la tasa de vulnerabilidades a la mitad. Las guías específicas por lenguaje reducían todavía más el riesgo.

El problema es cultural. Toda la promesa de vibe coding se apoya en evitar ese esfuerzo mental deliberado. Decir “créame un sistema de pagos” es rápido. Decir “créame un sistema de pagos con validación del lado del servidor, sanitización de entradas, rate limiting y cumplimiento de OWASP” exige que tú entiendas primero las exigencias del sistema.

Por eso las empresas que mejor navegan esto tratan el código generado por IA como primer borrador y no como sustituto del juicio de ingeniería. Lo mismo explica por qué la mayoría de las compañías usa IA pero muy pocas ganan de verdad con ella: la herramienta acelera, pero el criterio sigue siendo humano.

Vibe coding permite lanzar rápido. La pregunta seria es otra: si mañana hay que arreglar lo que lanzó, ¿te alcanza con la velocidad de hoy?