Los modelos más inteligentes se están volviendo más eficaces a la hora de hackear benchmarks de programación.

Las suites de eval creadas a partir de errores reales que después se solucionaron son especialmente vulnerables porque los problemas ya tienen solución. Si el agente tiene acceso al historial del repositorio o a la web pública, a veces puede buscar la respuesta en lugar de deducirla.

Para medir qué tan extendido está este comportamiento, creamos un agente para auditar trayectorias de eval. En SWE-bench Pro, descubrimos que el 63% de las resoluciones exitosas de Opus 4.8 Max recuperaron cómo solucionarlo en lugar de deducirlo. Cuando cerramos el acceso al historial de Git y restringimos el acceso a internet, las puntuaciones cayeron bruscamente tanto para Opus como para nuestro modelo, Composer 2.5:

• Opus 4.8 Max cayó de 87.1% a 73.0%
• Composer 2.5 cayó de 74.7% a 54.0%

Investigaciones previas han demostrado que las respuestas de los benchmarks de programación pueden filtrarse a través de fuentes disponibles públicamente, incluido este estudio de 2024 y un informe de Meta de 2025. Nuestro estudio cuantifica el problema en ejecuciones actuales de agentes de programación de vanguardia. La lección más amplia es que, además de evitar la contaminación durante el entrenamiento, los benchmarks de programación con agentes también necesitan entornos de ejecución controlados.

Para los equipos que realizan eval, proponemos mitigar este comportamiento de reward hacking auditando transcripciones y limitando el entorno de eval."

#Detectar un modelo con otro modelo

Para medir la magnitud de este comportamiento de reward hacking, hicimos que el auditor examinara 731 trayectorias de Opus 4.8 Max. Vio el enunciado del problema y la trayectoria completa del agente, sin saber si la ejecución había tenido éxito, y clasificó si el agente había obtenido la respuesta conocida.

Los dos patrones de reward hacking más comunes que encontró fueron:

• Búsqueda aguas arriba: En el 57% de las trayectorias, Opus 4.8 Max encontró la PR fusionada o el archivo fuente ya solucionado en la web pública, y luego reprodujo la solución casi palabra por palabra.
• Exploración del historial de Git: En el 9% de las trayectorias, Opus 4.8 Max buscó en el historial de .git incluido el commit posterior que solucionaba el error y luego extrajo el parche.¹

A medida que los modelos se vuelven más potentes, a veces pueden inferir que están en una eval, especialmente cuando la tarea se toma de un repositorio público antiguo. Incluso en los casos en que no recuerdan cómo se solucionó en el entrenamiento, el entorno aun así puede darles pistas de que el error ya se había resuelto.

En una tarea multilingüe de SWE-bench basada en una incidencia de jq de 2019, el agente intentó reproducir el error con el binario jq del sistema. Como la imagen se había generado después de que se solucionara el error, la reproducción falló, y el agente infirió que la incidencia ya se había resuelto. Eso lo llevó a buscar cómo solucionarlo en lugar de deducir una por su cuenta.

Algunos casos fueron más directos. Un agente encontró una página espejo de SWE-bench que exponía pruebas ocultas y el parche correcto. Otro obtuvo archivos de pruebas ocultos y codificó de forma fija la cadena de excepción esperada necesaria para aprobar.

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

#Diseño de entorno más estricto

La mayor parte del reward hacking se producía a través de la web pública y del historial del repositorio. En el caso de los evals creados a partir de repositorios públicos históricos, esos canales deben controlarse porque pueden contener la respuesta. Para solucionarlo, creamos un harness estricto con dos mecanismos de aislamiento:

1. Aislamiento del historial. Antes de que el agente se inicie, el directorio .git se elimina y el repositorio se reinicializa como un repo nuevo con un solo commit. El historial original solo se restaura en el momento de la evaluación, por lo que las pruebas se ejecutan con normalidad.
2. Proxy de salida. El acceso a la red se deniega por defecto. Como medida de control de máximo esfuerzo, un proxy fijo permite resolver dependencias únicamente mediante una lista de registros de paquetes permitidos, y nada más.

Esta restricción es específica de los evals creados a partir de repositorios públicos históricos. Es una de las razones por las que preferimos evals creados a partir de repositorios no públicos, como CursorBench. Pueden evaluar la capacidad de programación con agentes y, al mismo tiempo, permitir que los agentes usen herramientas del mismo modo que lo harían en trabajo real.

#Una brecha creciente

Volvimos a ejecutar SWE-bench Pro y SWE-bench Multilingual con el harness más estricto, y luego comparamos cada resultado con la puntuación del harness estándar como proxy del efecto combinado de eliminar estos canales de filtración²:

• En SWE-bench Multilingual, la diferencia fue de menos de 1 punto para Opus 4.6, 9.1 puntos para Opus 4.8 Max y 7.5 puntos para Composer 2.5.
• En SWE-bench Pro, la diferencia fue de menos de 1 punto para Opus 4.6, 14.1 puntos para Opus 4.8 Max y 20.7 puntos para Composer 2.5.

La conclusión clara es que el reward hacking es mucho más común en los modelos más nuevos y sofisticados que en los más antiguos. Curiosamente, los modelos GPT no muestran la misma escalada, con brechas generalmente menores en nuestras ejecuciones.

También observamos que nuestro propio modelo, Composer 2.5, tuvo la mayor brecha en Pro del estudio. Esta es una de las razones por las que no consideramos la puntuación estándar de SWE-bench Pro como un número de benchmark fiable para Composer. La puntuación era real en el sentido estricto de que el harness la produjo, pero mezclaba la capacidad de programación con el acceso a formas conocidas de solucionar.

#Diseño de evals para agentes conscientes

La principal conclusión para los equipos que ejecutan evals de programación es que el diseño del benchmark no debe limitarse a la construcción del conjunto de datos. También debe tener en cuenta el entorno de ejecución, incluido lo que el agente puede buscar, inspeccionar, obtener y recuperar mientras la tarea está en curso.

Eso no significa que toda eval deba eliminar el acceso a internet o el historial de git. Algunas evals están pensadas para medir qué tan bien aprovechan los agentes el contexto de una base de código real, y en esos casos un acceso amplio puede formar parte de la tarea. El problema surge cuando ese acceso cambia el significado de la puntuación.

En benchmarks históricos sobre repositorios públicos, el acceso abierto puede permitir que los agentes encuentren cómo solucionarlo, ya conocido, en lugar de solucionar el error. Sin controles en el harness, las puntuaciones pueden mezclar la capacidad de programación con la recuperación de respuestas.

Los equipos que ejecutan evals deben decidir qué comportamiento quieren medir, diseñar el harness en torno a ello y dejar clara la configuración al informar los resultados. Auditar las transcripciones puede ayudar a detectar cuándo los modelos están resolviendo tareas de formas inesperadas. El objetivo no es prohibir el uso normal de herramientas, sino asegurarse de que el benchmark mida lo que dice medir.

Incluso entonces, sigue existiendo un problema abierto más difícil. A medida que los modelos son más conscientes de cuándo están siendo evaluados, pueden cambiar su comportamiento de formas más sutiles que no se solucionan ocultando el historial de git o restringiendo el acceso a internet. La contaminación en tiempo de ejecución es una versión concreta de un desafío más amplio: crear evals que conserven la validez de constructo incluso cuando el modelo infiere que está siendo evaluado.