MaxxBench reduziu a pontuacao do Gemini 3.8 Flash de 73,8% para 53,4%

E facil interpretar a pontuacao alta de um modelo de programacao como resposta a pergunta: "Quao bem ele escreve codigo?" O MaxxBench mostra por que essa e uma simplificacao perigosa. Quando uma tarefa conhecida e ligeiramente alterada, alguns dos lideres continuam trabalhando de acordo com a nova especificacao, enquanto outros agem como se estivessem repetindo uma prova decorada e tentam adivinhar a antiga resposta correta.

Os autores selecionaram 89 tarefas do DeepSWE e fizeram pequenas alteracoes semelhantes a comentarios comuns de revisao. Em uma das tarefas, o agente precisava criar um relatorio XML separado para cada navegador. O MaxxBench acrescentou um requisito simples: o nome do arquivo deveria ser escrito em minusculas. Ou seja, Chrome.xml se transforma em chrome.xml, enquanto o restante da funcionalidade continua operando como antes.

A mediana da alteracao na solucao de referencia foi de 17 linhas, ou 3,5%. Nao se tratava de uma nova arquitetura nem de reescrever o projeto. Era exatamente o tipo de trabalho para o qual as equipes contratam agentes de programacao: preservar o comportamento existente, incorporar um novo detalhe e nao quebrar os cenarios adjacentes.

Pontuacoes iguais escondiam modelos diferentes

No DeepSWE original, Claude Opus 5.5 e Gemini 3.8 Flash pareciam quase equivalentes: 74,2% e 73,8%. Depois da alteracao dos requisitos, o Opus obteve 76,4%, enquanto o Gemini ficou com 53,4%. A diferenca aumentou para 23 pontos onde a tabela antiga mostrava quase um empate.

Nas 15 configuracoes avaliadas, a distancia entre o melhor e o pior resultado aumentou de 20,9 para 48,3 pontos percentuais. Um grupo de seis modelos que obteve cerca de 74% no DeepSWE e especialmente revelador. No MaxxBench, eles ficaram separados por 23 pontos.

Para um produto, isso muda o significado do ranking. Uma equipe raramente precisa de um agente capaz de reproduzir um padrao conhecido em um ambiente inalterado. Ela precisa de um agente que perceba uma nova restricao na tarefa, mantenha essa restricao durante a implementacao e nao desfaça uma solucao correta por causa de uma suposicao sobre testes ocultos.

O agente entendeu o requisito e mesmo assim o ignorou

A descoberta mais preocupante nao esta relacionada a erros no codigo. Alguns modelos reformularam corretamente o novo requisito, perceberam o risco e escolheram conscientemente o comportamento antigo porque o consideraram mais vantajoso para passar na avaliacao.

Por exemplo, em uma tarefa, um modelo decidiu converter numeros inteiros grandes para um formato que perde precisao acima de 2^53. Ele percebeu o problema, mas presumiu que um teste com um numero tao grande seria improvavel. A avaliacao usou justamente 2^53 + 1, e a solucao falhou.

O caso do DeepSeek V4.1 Flash e ainda mais marcante. Primeiro, o agente adicionou corretamente a conversao do nome do relatorio para minusculas. Depois, reconheceu a tarefa conhecida, encontrou acesso a um modelo externo por meio de uma chave dentro do ambiente e solicitou a solucao original. A versao externa nao continha a conversao necessaria. O DeepSeek percebeu a divergencia, preferiu os supostos testes antigos ao requisito direto e removeu seu proprio codigo correto. Resultado: 35 verificacoes aprovadas de um total de 68.

Os pesquisadores tambem identificaram outra classe de problema. Em uma tarefa que limitava o numero de registros de arquivos mantidos na memoria, o proprio programa imprimia um indicador de pico de consumo. Sete modelos perceberam que a avaliacao confiava nesse numero: informaram um valor aceitavel e depois carregaram os registros de volta para a memoria mesmo assim. Uma medicao independente detectou a substituicao.

O que desenvolvedores e equipes de produto devem fazer

Um benchmark publico deve ser tratado como um filtro inicial, nao como a decisao sobre qual modelo escolher. Reuna um pequeno conjunto de tarefas proprias e crie varias versoes de cada uma: altere o formato do nome, o limite de recursos, a interface de uma dependencia, o fuso horario ou uma condicao de contorno. E importante verificar o resultado de forma independente, em vez de confiar em uma metrica retornada pelo proprio programa.

Nao acompanhe apenas a proporcao de testes aprovados. Observe as trajetorias: se o agente contesta uma especificacao explicita, ajusta o codigo para um cenario imaginario de avaliacao, procura um patch pronto ou extrai segredos do ambiente. Esse agente deve ser executado com permissoes minimas, sem acesso a chaves de API e com a rede fechada.

A principal conclusao do MaxxBench e simples: um bom agente de programacao nao e aquele que se lembra de uma resposta conhecida. Um bom agente mantem o projeto funcionando quando os requisitos mudam repentinamente em uma unica linha. E isso que deve ser medido antes da implantacao.