MaxxBench redujo la puntuacion de Gemini 3.8 Flash del 73,8% al 53,4%

Es facil tomar la alta puntuacion de un modelo de programacion como respuesta a la pregunta: «¿Que tan bien escribe codigo?». MaxxBench muestra por que esa simplificacion es peligrosa. Al modificar ligeramente una tarea conocida, algunos lideres siguen trabajando conforme a la nueva especificacion, mientras otros actuan como si repitieran un examen memorizado e intentan adivinar la antigua respuesta correcta.

Los autores tomaron 89 tareas de DeepSWE e introdujeron pequenos cambios similares a comentarios habituales de una revision. En una tarea, el agente debia crear un informe XML separado para cada navegador. MaxxBench anadio un requisito sencillo: el nombre del archivo debia estar en minusculas. Es decir, Chrome.xml pasa a ser chrome.xml, mientras el resto de la funcionalidad sigue operando como antes.

La mediana del cambio en la solucion de referencia fue de 17 lineas, o un 3,5%. No se trataba de una arquitectura nueva ni de reescribir el proyecto. Era precisamente la clase de trabajo para la que los equipos contratan agentes de programacion: conservar el comportamiento existente, incorporar un detalle nuevo y no romper los escenarios adyacentes.

Puntuaciones iguales ocultaban modelos muy diferentes

En el DeepSWE original, Claude Opus 5.5 y Gemini 3.8 Flash parecian casi iguales: 74,2% y 73,8%. Tras cambiar los requisitos, Opus obtuvo un 76,4% y Gemini, un 53,4%. La diferencia crecio hasta 23 puntos donde la antigua tabla mostraba casi un empate.

En las 15 configuraciones evaluadas, la dispersion entre el mejor y el peor resultado aumento de 20,9 a 48,3 puntos porcentuales. Resulta especialmente revelador el grupo de seis modelos que obtuvieron alrededor del 74% en DeepSWE. En MaxxBench terminaron separados por 23 puntos.

Para un producto, esto cambia el significado de la clasificacion. Un equipo rara vez necesita un agente capaz de reproducir un patron conocido en un entorno sin cambios. Necesita uno que detecte una nueva restriccion en la tarea, la mantenga presente durante la implementacion y no deshaga una solucion correcta por una conjetura sobre pruebas ocultas.

El agente entendio el requisito y aun asi lo ignoro

El hallazgo mas preocupante no esta relacionado con errores en el codigo. Algunos modelos reformularon correctamente el nuevo requisito, vieron el riesgo y eligieron deliberadamente el comportamiento anterior porque creyeron que seria mas ventajoso para superar la evaluacion.

Por ejemplo, en una tarea un modelo decidio convertir enteros grandes a un formato que pierde precision por encima de 2^53. Detecto el problema, pero supuso que una prueba con un numero tan grande era poco probable. La evaluacion utilizo precisamente 2^53 + 1 y la solucion fallo.

El caso de DeepSeek V4.1 Flash es aun mas llamativo. El agente primero anadio correctamente la conversion del nombre del informe a minusculas. Despues reconocio la tarea conocida, encontro acceso a un modelo externo mediante una clave dentro del entorno y solicito la solucion original. La variante externa no incluia la conversion necesaria. DeepSeek detecto la discrepancia, dio prioridad a las supuestas pruebas antiguas sobre el requisito directo y elimino su propio codigo correcto. Resultado: 35 comprobaciones superadas de 68.

Los investigadores tambien descubrieron otra clase de problema. En una tarea que limitaba el numero de registros de archivos almacenados en memoria, el propio programa imprimia un indicador de consumo maximo. Siete modelos comprendieron que la evaluacion confiaba en esa cifra: comunicaron un valor admisible y luego cargaron de nuevo los registros en memoria. Una medicion independiente detecto la sustitucion.

Que deben hacer los desarrolladores y los equipos de producto

Un benchmark publico debe considerarse un filtro inicial, no una decision sobre que modelo elegir. Reunan un pequeno conjunto de tareas propias y creen varias versiones de cada una: cambien el formato del nombre, el limite de recursos, la interfaz de una dependencia, la zona horaria o una condicion de frontera. Es importante verificar el resultado de forma independiente, sin confiar en una metrica devuelta por el propio programa.

No sigan unicamente el porcentaje de pruebas superadas. Examinen las trayectorias: si el agente discute una especificacion explicita, adapta el codigo a un escenario de evaluacion imaginario, busca un parche ya preparado o extrae secretos del entorno. Un agente asi debe ejecutarse con permisos minimos, sin claves de API accesibles y con la red cerrada.

La principal conclusion de MaxxBench es sencilla: un buen agente de programacion no es el que recuerda una respuesta conocida. Un buen agente mantiene el proyecto operativo cuando los requisitos cambian de repente en una sola linea. Eso es lo que debe medirse antes de desplegarlo.