1 de cada 3 éxitos de los agentes de código en benchmarks no cumple la tarea

Cada lanzamiento de un modelo nuevo llega con su tabla: tanto por ciento en SWE-bench Verified, tanto en SWE-bench Pro. Los equipos usan esas cifras para decidir qué agente adoptar y cuánto confiar en él. El problema es que un benchmark de código no mide si el código hace lo que se pidió; mide si pasa las pruebas que alguien escribió hace tiempo. Y esas dos cosas se están separando.

El estudio

"TestJack: Should you trust the results in coding benchmarks?" fue publicado en arXiv el 7 de octubre de 2026 por Shuangjie Yao, Hao Wang, Koushik Sen, Simin Chen, Baishakhi Ray y Dawn Song (Columbia, UC Berkeley y George Mason). La idea es sencilla: si las pruebas fijas de un benchmark son incompletas, hay que generar pruebas nuevas para cada solución que se evalúa.

El método, que llaman prompt-grounded differential testing, funciona por intento: un agente auditor lee el enunciado de la tarea, escribe pruebas, las valida contra la solución de referencia y luego las corre sobre el parche del modelo. Un segundo agente revisa que las pruebas sean válidas. Si una prueba válida falla, el intento se considera refutado. Los resultados:

• 8,862 intentos de seis modelos de frontera sobre cinco benchmarks: DeepSWE, SkillsBench, SWE-Marathon, SWE-bench Verified y SWE-bench Pro.
• De esos, 4,487 pasaban el verificador del benchmark. TestJack refutó 1,545, es decir 34.4%.
• La tasa de resolución global cae de 50.6% a 33.2%.
• Una variante ligera —pruebas ampliadas por tarea más auditoría aleatoria de intentos— recupera 72.4% de las refutaciones con 15.4% del costo, en tres de los cinco benchmarks.

Los autores son claros sobre los límites: el método depende de una solución de referencia, del juicio de un LLM (sobre todo cuando el enunciado es ambiguo) y la precisión se midió contra la propia auditoría, no contra etiquetas humanas. Aun con ese margen, la conclusión es difícil de ignorar: aproximadamente uno de cada tres "éxitos" no cumple la tarea, aunque pase el verificador del benchmark.

Por qué pasa: el agente optimiza contra las pruebas que ve

No hace falta suponer mala fe. Un agente de código itera hasta que las pruebas pasan; esa es literalmente su señal de éxito. Si la suite cubre el caso feliz pero no el borde que el enunciado sí menciona —un formato de entrada, un valor nulo, un requisito de compatibilidad—, el agente entrega algo que pasa y no cumple. Cuanto más capaz es el agente, mejor encuentra el camino más corto hacia el verde.

La recomendación de fondo del paper es que los evaluadores deben evolucionar junto con las soluciones que juzgan. Una suite de pruebas fija fue diseñada para los modelos de su época; frente a agentes que exploran el repositorio y corren pruebas cientos de veces, se queda corta.

Lo que esto significa fuera del leaderboard

El mismo patrón aparece en cualquier repositorio donde un agente trabaja con la suite de pruebas como única guía. Tus pruebas también son un benchmark fijo, escrito para el código de hace seis meses. Si el criterio para aceptar el PR de un agente es "CI en verde", estás aceptando la misma métrica que este paper acaba de mostrar que sobreestima la calidad en un tercio.

Cómo lo abordamos en SmartDevs

Usamos agentes de código todos los días, en proyectos de clientes y en nuestros propios productos. Estas son las reglas que nos han funcionado, y que este paper confirma:

• Los leaderboards sirven para hacer la lista corta, no para decidir. Antes de adoptar un modelo o agente lo corremos sobre 10-20 tareas reales de nuestro propio código, con criterios de aceptación escritos antes de verlo trabajar.
• Las pruebas de aceptación salen del requisito, no del parche. Si el mismo agente escribe el código y las pruebas que lo validan, la evaluación es circular. Las pruebas que deciden si una tarea está terminada se escriben a partir del ticket, por una persona o por un agente separado que no ve la implementación —la misma lógica que TestJack aplica a escala.
• El enunciado es parte del código. Los requisitos ambiguos son donde más se cuelan los falsos éxitos. Un ticket con ejemplos concretos de entrada y salida y casos borde explícitos produce menos "pasa pero no cumple" que cualquier modelo nuevo.
• Auditoría aleatoria, no revisión heroica. El dato de la variante ligera —72.4% de los hallazgos con 15.4% del costo— nos parece el más práctico del paper. No hace falta auditar todo a fondo: una muestra aleatoria de PRs de agentes revisada contra el requisito original detecta los patrones de falla con una fracción del esfuerzo.
• Medimos el retrabajo, no solo el merge. Un PR de agente que se mergea y vuelve como bug dos semanas después no fue un éxito. Rastreamos cuántos cambios generados por agentes requieren corrección posterior; es nuestra versión interna de la tasa de resolución corregida.

Los agentes de código son la mejora de productividad más grande que hemos visto en años, y nada de esto cambia eso. Lo que cambia es dónde hay que poner la atención: si un tercio de los éxitos medidos en los benchmarks más usados no cumple la tarea, la pregunta para tu equipo esta semana es cuántos de los PRs en verde que aceptaste el mes pasado realmente hacían lo que pedía el ticket.