Pídele a un agente de código con IA un endpoint de subida de archivos y te lo entregará. Compila. La demo funciona. El pull request se ve impecable a las 6 de la tarde. Y en algún punto de dentro hay un fallo de path traversal que nadie notará hasta que alguien decida mirar.
Ya no es una preocupación hipotética. Es un resultado medido, y la cifra incomoda: el mejor agente de código de un benchmark recién publicado generó código que era funcional y seguro solo en el 25,1% de las tareas.
La cifra del 25% y por qué debería preocuparte
El 14 de octubre, un artículo publicado en Hugging Face presentó el Last Secure Code Benchmark (LSCB), con el subtítulo «Is the Code You Vibe Secure?». El diseño es brutalmente simple y, por una vez, realista. Los investigadores tomaron 150 vulnerabilidades reales, las expandieron en 450 tareas repartidas en tres escenarios de vibe coding y soltaron sobre ellas a seis agentes de frontera en siete lenguajes, entre ellos Java, C, C++, JavaScript, Python, PHP y Go. La cobertura de debilidades abarca 24 CWE, incluidas 21 del Top 25 de CWE de 2025 y 8 del Top 10 de debilidades explotadas activamente.
Los resultados se dividen en dos cifras que cuentan historias muy distintas:
- A nivel funcional, los agentes parecen excelentes. Entre el 73,6% y el 91,3% de las tareas pasan las pruebas funcionales ocultas. El código hace lo que se pidió.
- Funcional y seguro a la vez, el panorama se derrumba. El agente más fuerte, Claude Fable 5, se queda en el 25,1%. Los otros cinco se agrupan entre el 16,4% y el 24,7%.
Como las tasas funcionales son mucho más altas, la mayor parte de ese fallo es inseguridad y no rotura. El código corre, la función se demuestra y la vulnerabilidad se publica. Los autores añaden que incluso el mejor modelo supera solo el 12% de los escenarios de vulnerabilidad en todos los entornos de vibe coding.
Cómo se construyó el benchmark y por qué es justo
La decisión de diseño más importante es lo que los prompts omiten. Cada especificación de tarea pide solo funcionalidad y nunca menciona seguridad. Eso refleja cómo los equipos encargan realmente el trabajo a un agente: añade un endpoint de subida, no añade un endpoint de subida que resista path traversal.
Después, cada una de las 450 tareas se calificó dos veces con pruebas ocultas. Un conjunto comprueba si el código hace lo pedido. Un segundo conjunto comprueba si evita la debilidad concreta que representaba la vulnerabilidad real original. Usar vulnerabilidades reales en lugar de fallos sintéticos importa, y las pruebas ocultas reducen la posibilidad de que un modelo juegue con un verificador visible.
Vale la pena mantener honestas las salvedades, porque los investigadores fueron cuidadosos con ellas. El benchmark mide el comportamiento por defecto: los modelos no recibieron instrucciones de seguridad, ni una skill de código seguro, ni un bucle de revisión. Los agentes con un requisito explícito de seguridad y una pasada de revisión automatizada probablemente lo harán bastante mejor. Un aprobado significa que el código evitó la debilidad evaluada, no que el resto de las líneas sea seguro. Y los entornos de agentes cambian cada mes, así que esto es una foto fija, no un veredicto para siempre.
No es un resultado aislado
Si LSCB fuera el único estudio que apunta en esta dirección, sería fácil archivarlo como titular alarmante y seguir adelante. No lo es. La actualización de primavera de 2026 de Veracode sobre seguridad en código generado por IA probó más de 150 modelos con 80 tareas en cuatro lenguajes, verificadas con análisis estático, y encontró la misma forma de problema:
- Corrección sintáctica: por encima del 95%
- Tasa de aprobado en seguridad sin instrucción de seguridad: alrededor del 55%
- Cross-site scripting: alrededor del 15%
- Inyección en logs: alrededor del 13%
- Inyección SQL: 82%
- Dos años de lanzamientos de modelos: del 55% al 55%
Esa última línea es la que hay que digerir. Todos los lanzamientos de ese periodo se coronaron como un salto adelante y, en esta medición, la aguja no se movió. Los modelos centrados en razonamiento mejoraron hasta el 70-72%, una mejora real y todavía nada que se mande a producción sin revisión. En el nivel de repositorio ocurre algo parecido: el benchmark SusVibes informó de que la mayoría de las soluciones de agente que pasan lo funcional son inseguras, con el mejor resultado reportado en torno al 11,8% correcto y seguro.
El segundo modo de fallo: dependencias que no existen
Los fallos de seguridad son el riesgo obvio. El más extraño es la cadena de suministro, y se ha convertido silenciosamente en un ataque.
Un estudio que generó 576.000 muestras de código con 16 modelos encontró que el 19,7% de los paquetes recomendados no existía, con más de 205.000 nombres inventados distintos. Los modelos abiertos alucinaban el 21,7% de las veces de media; los comerciales, el 5,2%. La tasa no es lo interesante. Esto sí lo es: al repetir los mismos prompts diez veces, el 43% de los nombres de paquete alucinados aparecía en todas las ejecuciones. Las invenciones son sistemáticas, no aleatorias.
Un nombre predecible es un nombre que alguien puede registrar antes de que lo pidas. Ese ataque ya tiene nombre, slopsquatting, y un investigador lo demostró publicando un paquete vacío con un nombre alucinado plausible que después se descargó decenas de miles de veces. Ahora delega la instalación de dependencias en un agente autónomo y el único punto de control humano de esa cadena, darse cuenta del nombre del paquete y decidir instalarlo, desaparece sin hacer ruido.
Qué recomendamos a nuestros clientes
Nada de esto significa frenar ni renunciar a las ganancias de productividad. Significa cambiar dónde va la atención humana. Cinco reglas que usamos:
- Nombra el riesgo en el prompt, antes de que exista código. Este cambio toca datos de usuario y login: enumera primero los requisitos de seguridad y construiremos contra esa lista. Cuesta una frase y el benchmark sugiere que importa más que la elección de modelo.
- Verifica contra las categorías que de verdad fallan. No preguntes si es seguro. Eso te devuelve un ensayo. Pregunta en concreto por salidas que llegan a una página sin escapar, entradas de usuario que llegan a un log o a una consulta sin comprobar, y por todo lo que se construye uniendo cadenas de texto.
- Trata cada dependencia nueva como un evento de cadena de suministro. Para cada paquete: existe en el registro oficial, quién lo publica, cuándo se publicó por primera vez, cuántas versiones tiene. No estás auditando código, estás comprobando si la cosa tiene pasado.
- Mantén una puerta humana en el diff. Los agentes producen más código, no más software revisado. La revisión es ahora el cuello de botella y el control más barato que tienes.
- Asume que los valores por defecto son inseguros e instrumenta para ello. Añade SAST y escaneo de dependencias al pipeline en lugar de confiar en que el agente sea cuidadoso.
La conclusión para tu equipo
El código agéntico ya resolvió la generación. Lo que sigue sin resolverse es la corrección y la seguridad, y esa parte sin resolver era exactamente lo que se pagaba a los ingenieros. Los equipos que ganen los próximos dos años no serán los que hagan el prompt más hábil. Serán aquellos cuyos pipelines atrapan lo que el agente dejó atrás: requisitos escritos antes del prompt, escaneo automatizado después y un revisor que conoce las cuatro o cinco clases de debilidad que se repiten una y otra vez.
La velocidad ya es lo mínimo. Lo que sobrevive a una revisión, a un escáner y a un pentest es el producto.