El código de al lado es la plantilla
Los agentes de programación escriben una parte creciente del software en producción y se sabe que de vez en cuando producen código inseguro. Un artículo publicado en arXiv el 8 de noviembre plantea otra pregunta: qué le pasa con el tiempo a la seguridad de un repositorio cuando los agentes siguen contribuyendo a él.
Los autores hicieron dos experimentos. En el primero, los agentes recibieron 96 tareas que exigían implementar una nueva aplicación de backend en un repositorio donde ya existían otras. En el segundo, estudiaron la generación de código a escala de repositorio en 20 pares de tareas de proyectos reales en C y C++, en cada uno de los cuales el agente debía completar código crítico para la seguridad de memoria.
En ambos escenarios el resultado apuntó en la misma dirección. El código inseguro existente llevó a los agentes a escribir código vulnerable con más frecuencia. En la generación de backend el efecto fue moderado: los vecinos inseguros redujeron un 3,4% de media la proporción de implementaciones a la vez correctas y seguras. En el trabajo de repositorio en C y C++ no fue moderado en absoluto: la brecha media entre contextos seguros e inseguros llegó al 35,4%.
Podían ver lo que estaban haciendo
La cifra más incómoda del artículo no es la brecha, sino la explicación. Cuando se pidió a los agentes que justificaran sus decisiones de implementación, las atribuyeron a seguir otro punto de código del repositorio en el 76,5% de los casos. En el 69,9% de los casos reconocieron la vulnerabilidad que acababan de introducir.
Esa combinación descarta la lectura más sencilla. No es un modelo incapaz de distinguir código seguro de código inseguro; es un modelo que sí puede y que trata el precedente local como la señal más fuerte. Los autores lo dicen sin rodeos: los agentes usan las vulnerabilidades existentes como plantillas de otras nuevas de forma indiscriminada, y convierten cada contribución en una oportunidad para introducir más.
El prompt mueve la aguja sin cerrarla
El estudio probó también las dos intervenciones obvias. Pedir al agente que siguiera el estilo del código existente aumentó la fuerza con la que propagaba vulnerabilidades. Pedirle que tuviera cuidado con la seguridad la redujo. Ninguna de las dos la detuvo.
Eso importa para cómo se configuran estas herramientas en la práctica. “Sigue el estilo del entorno” es casi una instrucción por defecto en los archivos de configuración de agentes y en las guías de contribución, y este artículo dice que esa instrucción tiene un coste de seguridad. Un recordatorio de seguridad en el prompt ayuda, pero es una mitigación, no una solución.
Por qué lo importante es la dirección
Una función insegura siempre ha sido un pasivo. Lo que describe el artículo es un pasivo que se reproduce. Si un agente lee el repositorio para decidir cómo escribir, entonces una vulnerabilidad sin corregir no es solo un agujero en un sitio: es un patrón disponible para copiarse en cada nueva contribución que toque código parecido.
Los autores sacan la conclusión directamente: a medida que los agentes escriben una parte creciente del código de producción con una revisión humana decreciente, las bases de código pueden degradarse en seguridad si las vulnerabilidades no se corrigen a fondo y de forma continua. Eso convierte el parcheo, de tarea pendiente, en condición de todo lo que el agente escriba después.
Las cifras proceden de los experimentos de los propios autores y no se han reproducido de forma independiente. Lo que zanjaría el asunto es la misma medición en un repositorio real a lo largo de meses y no sobre tareas, y comprobar si la brecha del 35,4% en C y C++ críticos para memoria se estrecha cuando los agentes razonen mejor sobre el código que leen en vez de imitarlo.
