Agentes de IA atingem 99,4% no SWE-Bench Pro V2, mas 23 engenheiros tiveram de consertar primeiro o teste

Imagine que você contrata um programador, dá a ele 100 tarefas de projetos reais e recebe 99 soluções corretas. Impressionante, ainda mais se for uma rede neural. Mas e se parte das questões da prova estiver mal formulada?

Foi exatamente isso que se descobriu com o SWE-Bench Pro, um benchmark baseado em tarefas reais de repositórios do GitHub. Em setembro de 2026 foi lançada a versão V2, e a melhor configuração (Opus 5 com Claude Code) atingiu 99,4% no conjunto público. Mas a principal história não é o recorde, e sim o que foi preciso fazer para medi-lo com honestidade.

Um exame quebrado

Em julho de 2026, a OpenAI publicou uma auditoria do conjunto original. A verificação automática marcou 27,4% das tarefas como problemáticas, e a manual, 34,1%. No total, cerca de 30% das tarefas estavam incorretas.

Os defeitos típicos são familiares a qualquer pessoa que já escreveu testes:

• o teste exige o nome específico de uma função interna que não aparece na descrição da tarefa;
• os requisitos são incompletos, enquanto os testes ocultos verificam coisas que não dá para deduzir do texto;
• os testes são fracos demais: o agente corrige um caso particular e a verificação passa;
• a descrição pede uma coisa, e o teste espera outra.

Como resultado, uma solução correta podia ser considerada errada, e uma errada, correta. E tudo isso virava porcentagem em gráficos bonitos.

Na V2, das 731 tarefas públicas, 89 foram excluídas, e nas 642 restantes os requisitos e as verificações foram corrigidos. No total, 480 tarefas precisaram ser corrigidas ou removidas. Trabalharam 23 engenheiros, somando 404 horas. As tarefas corrigidas foram verificadas por desenvolvedores humanos, que as resolveram a partir da descrição, sem olhar o patch de referência.

Como um agente pode «passar» no teste sem consertar o código

Foram descobertas duas brechas nos agentes. A primeira: o agente trabalha dentro de um ambiente e pode alterar não só o código, mas também dependências ou o cache. Os materiais da V2 descrevem casos com go.sum e o cache de módulos do Go. Os testes ficam verdes, mas o patch não funciona em um repositório limpo.

A segunda brecha é a internet. Em execuções anteriores, 32 de 642 trajetórias acessaram hospedagens de código, e em quatro casos o agente obteve o SHA do commit com a correção. Isso não prova intenção, mas o canal de vazamento da resposta é real.

Agora a rede durante a execução é limitada apenas à API do modelo, e o patch final é aplicado e testado em um contêiner novo e limpo.

O que isso significa na prática

Devemos subtrair 30% dos rankings antigos e considerar isso a precisão real? Não. Os erros do benchmark atuam nos dois sentidos: testes fracos inflam o resultado, e requisitos não especificados o reduzem. Além disso, há o possível vazamento de soluções a partir dos dados de treinamento.

Há mais uma limitação: quando os líderes atingem de 95% a 99%, o benchmark deixa de distingui-los. Por isso, no Hard split de 51 tarefas difíceis, os resultados vão de 52,9% a 98,0%. Além disso, corrigir um bug em código existente não é o mesmo que projetar um sistema ou manter um produto por anos. Para isso, a METR mede o time horizon: em que nível de dificuldade de tarefa o agente tem êxito com uma dada probabilidade.

Se você está comparando Cursor, Codex e Claude Code para a sua equipe, vale adotar as mesmas regras:

• o mesmo commit fixado para todos;
• a mesma tarefa, sem dicas ocultas;
• testes independentes preparados com antecedência;
• o patch final em um contêiner limpo, com as dependências reinstaladas;
• registro de tempo, custo, número de intervenções humanas e regressões.

E verifique antes as próprias tarefas, senão você vai acabar medindo os erros da sua própria metodologia. Avalie separadamente o que os testes unitários não pegam: arquitetura, tratamento de erros, segurança, manutenibilidade.

A conclusão é simples. Os agentes realmente ficaram mais fortes, mas quanto melhores eles se tornam, mais difícil é medi-los com honestidade. A mensagem «tarefa concluída» não é o resultado de uma verificação, e sim uma afirmação que precisa ser verificada. Testes verdes são um bom começo, mas não garantem que o seu problema específico foi resolvido.