La configuración de agente del estudio que más veces produjo código que funcionaba lo hizo en el 57 % de las tareas. Solo en el 11,8 % de las tareas su código funcionó y además superó el test de seguridad. Entre sus soluciones que funcionaban, el 79,3 % seguía sin superar un test de seguridad. Cuando a los agentes no se les dieron instrucciones sobre seguridad, ninguna configuración produjo código que funcionara y superara el test de seguridad en más del 12,9 % de las tareas.
Esas son las cifras principales. Para entender qué significan, tenemos que ver cómo se construyó el banco de pruebas.
El estudio es Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks (Zhao, Wang, Zhang, Luo, Li y Li, ICML 2026, arXiv:2512.03262).
Qué hizo el banco de pruebas
Los autores construyeron 186 tareas a partir de grandes repositorios de código abierto en GitHub. Cada una partía de un caso real: una persona implementó una funcionalidad, la implementación resultó vulnerable y la vulnerabilidad se corrigió más tarde. En conjunto, las tareas abarcan 79 categorías de debilidades de la Common Weakness Enumeration de MITRE.
Para cada tarea, el agente recibe la base de código y una descripción de la funcionalidad, «sin detalles de implementación ni orientación de seguridad». Después se le pide que implemente la funcionalidad. Su parche se ejecuta contra dos conjuntos de tests escritos por personas. Uno comprueba si la funcionalidad funciona; el otro comprueba la presencia de la vulnerabilidad que eliminó la propia corrección del proyecto.
Los autores probaron tres marcos de agentes (SWE-agent, OpenHands y Claude Code) con cuatro modelos: Claude 4 Sonnet, Kimi K2, Gemini 2.5 Pro y Gemini 3 Pro. Eso dio doce configuraciones, cada una con un intento por tarea.
Qué encontró
- La configuración que más veces produjo código que funcionaba, SWE-agent con Claude 4 Sonnet, lo hizo en el 57,0 % de las tareas. En el 11,8 %, el código además superó el test de seguridad. Como lo expresan los autores, «el 79,3 % de estas soluciones funcionalmente correctas son inseguras».
- OpenHands con el mismo modelo mostró un patrón similar: el 77,8 % de sus soluciones que funcionaban eran inseguras.
- Claude Code con Claude 4 Sonnet produjo código que funcionaba en el 41,4 % de las tareas. En el 5,9 %, el código además superó el test de seguridad.
- Cuando a los agentes no se les dieron instrucciones sobre seguridad, la mayor proporción de tareas resueltas a la vez de forma correcta y segura fue del 12,9 %, y correspondió a SWE-agent con Gemini 3 Pro, que produjo código que funcionaba en el 37,1 % de las tareas.
- En las doce configuraciones, esa proporción fue de media del 8,4 % (cálculo nuestro a partir de la tabla 3); los autores describen la media como «solo alrededor del 10 %».
- En cada una de las doce configuraciones, la mayoría de las soluciones que funcionaban no superó un test de seguridad. La proporción osciló entre el 59 % y el 86 %, según nuestro cálculo a partir de la tabla 3 del artículo.
Informar al agente sobre la seguridad ayudó un poco
Los autores probaron dos instrucciones con la configuración que más veces produjo código que funcionaba. La primera da al agente la lista completa de categorías CWE que cubre el banco de pruebas, con sus descripciones. Antes de escribir código, el agente identifica qué debilidades puede implicar la tarea. La segunda instrucción nombra el tipo o los tipos de debilidad a los que apunta la tarea y pide al agente que evite implementaciones vulnerables.
Con estas instrucciones, la proporción de tareas en las que se obtuvo código que funcionaba y además superaba el test de seguridad subió del 11,8 % al 14,5 % y al 15,1 %, respectivamente. Pero la proporción en la que se obtuvo código que funcionaba bajó del 57,0 % al 50,0 % y al 55,4 %. En palabras de los autores, la mejora «no mitiga sustancialmente el problema de seguridad».
Según nuestra lectura, la segunda instrucción da al agente información que un usuario todavía no tiene. Los autores señalan que los expertos humanos pueden identificar posibles riesgos de seguridad antes de la implementación; la primera instrucción sigue ese enfoque. La segunda nombra el tipo de debilidad que la tarea se construyó para probar. Fuera de un banco de pruebas, esa información solo pasa a estar disponible una vez que se ha encontrado el fallo.
El test existía porque el fallo ya se había encontrado
Esta es la parte del diseño que subrayaríamos. Cada tarea viene con un test de seguridad que los desarrolladores del proyecto añadieron en el commit que corrigió la vulnerabilidad original. Alguien ya había encontrado el fallo, y los desarrolladores del proyecto habían escrito un test para él. Ese historial es lo que permite al banco de pruebas comprobar la presencia de la vulnerabilidad. Después, los autores comprobaron a mano cada test de seguridad y modificaron los que estaban demasiado ligados a una sola implementación.
La nueva funcionalidad de su agente no tiene un test así. Su conjunto de tests le dice lo que los tests funcionales del banco de pruebas dijeron a los autores: que la funcionalidad funciona. Sin embargo, la mayoría de las soluciones que funcionaban en el estudio seguían sin superar un test de seguridad.
Encontrar un fallo para el que nadie ha escrito todavía un test es el trabajo de una revisión adversarial. Nuestra explicación de la revisión de código adversarial expone qué abarca ese trabajo y dónde están sus límites.
Modelos distintos evitan fallos distintos
Los autores informan de que «los marcos de agentes y los LLM son buenos evitando vulnerabilidades distintas». Kimi K2 gestionó mejor los fallos criptográficos, mientras que Gemini 3 Pro fue mejor aplicando el control de acceso.
Ese resultado se refiere a escribir código. No establece si un segundo modelo detectaría fallos en el trabajo del primero. Un segundo modelo tampoco es, por defecto, una comprobación independiente: cuando dos modelos se equivocan, a menudo se equivocan de la misma manera (Kim et al., ICML 2025). Véase The attacker can run any model. How many do you run? (en inglés).
Es una de las razones por las que no tratamos la coincidencia entre modelos como prueba: la afirmación de que la coincidencia es prueba es una de las cinco afirmaciones que nos negamos a hacer (en inglés).
Una pregunta que el estudio deja abierta
Cada tarea partía de una vulnerabilidad que una persona había introducido en un proyecto real. En la mayoría de las soluciones que funcionaban, los agentes no superaron el test de seguridad para esa vulnerabilidad. Pero el estudio no pregunta si los modelos habían visto durante el entrenamiento el historial de esos proyectos, incluidas las versiones vulnerables. Véase The Illusion of the Score (en inglés).
Por tanto, no puede distinguir entre reproducir un fallo visto durante el entrenamiento y llegar de forma independiente al mismo error. Nuestro artículo de investigación, Agentic Stemmatics (en inglés), examina cómo distinguir esas posibilidades.
Lo que no muestra
- Tasas de base. Las 186 tareas se eligieron porque cada una es sensible para la seguridad y una persona se equivocó en ella en su día. Las tasas describen ese tipo de funcionalidad, no el código escrito por agentes en general.
- Modelos más recientes. El estudio probó cuatro modelos, con un intento por tarea en cada configuración. Otros modelos, y versiones posteriores, pueden puntuar de otra manera.
- Revisión. El estudio mide a un agente que escribe código sin revisión humana. No nos dice qué detectaría después un equipo, una herramienta o un revisor. Véanse A Clean Benchmark Is Not a Clean Codebase (en inglés) y La velocidad pasa. La complejidad se queda..
El resultado es limitado, pero claro. En estas tareas sensibles para la seguridad, la mayoría de las soluciones que funcionaban seguían sin superar un test de seguridad. Un conjunto de tests que comprobara solo si la funcionalidad funciona no revelaría esa distinción.
Las citas del estudio son traducción nuestra del original inglés. Esta página es una traducción del original inglés; en caso de divergencia, prevalece el original. Si algo aquí es erróneo, lo corregiremos por escrito en esta página.