Em 23 de fevereiro, a equipe Frontier Evals da OpenAI publicou um post explicando por que parou de reportar pontuações de SWE-bench Verified. A auditoria descobriu que 59,4% dos casos de teste mais difíceis do benchmark têm falhas fundamentais — testes que exigem nomes de função exatos não mencionados nos enunciados do problema, ou verificam comportamento não relacionado. Mais condenatório: cada modelo de fronteira principal testado — GPT-5.2, Claude Opus 4.5, Gemini 3 Flash — podia reproduzir as soluções gold-patch verbatim de memória usando apenas o task ID. A conclusão da OpenAI foi direta: "Melhorias no SWE-bench Verified não refletem mais melhorias significativas nas capacidades de desenvolvimento de software dos modelos no mundo real". Eles recomendam SWE-bench Pro em vez disso. Três meses depois, o resto da indústria de agentes de coding ainda está se classificando no bench contaminado.
Os números atuais do topo da tabela sendo publicados são: Claude Code no Opus 4.7 a 87,6%, OpenAI Codex no GPT-5.5 a aproximadamente 88,7% (rastreador de terceiros; a própria OpenAI não se auto-reporta), Gemini CLI a 80,6%, OpenHands a 72%, Augment Code a 70,6% auto-reportado em seu próprio harness, Cursor em torno de 51,7% em defaults, GitHub Copilot em torno de 56%. No SWE-bench Pro — a alternativa que a OpenAI agora recomenda — os mesmos modelos ficam muito mais baixos: Claude Opus 4.7 a 64,3%, GPT-5.5 a 58,6%. Terminal-Bench 2.0 é o outro benchmark que se manteve crível: Codex a 82,7%, Claude Code a 69,4%, Gemini CLI a 68,5%. A lacuna entre as duas famílias de benchmarks é em si o sinal: quando as pontuações de um eval comprimem os modelos contra o teto e as pontuações de outro eval os espalham, o segundo está fazendo o trabalho de discriminação.
O problema mais profundo é a lacuna entre maximizar-benchmark e maximizar-produtividade. O scaffolding de agente sozinho produz aproximadamente ±17 problemas de variância em modelos idênticos, o que significa que as escolhas de harness podem dominar a escolha de modelo em qualquer corrida dada. Nenhuma das classificações públicas vem com uma especificação de harness publicada, então comparações apples-to-apples entre vendors não estão realmente sendo executadas — apenas apples-vs-os-números-próprios-de-cada-vendor. A implicação prática para builders é que a comparação correta não é "qual agente lidera SWE-bench Verified" mas "qual agente resolve minhas tarefas na minha codebase com meu CI e minhas convenções de estilo". O método empírico que funciona é rodar 50 a 100 tarefas do seu backlog real contra dois ou três candidatos e medir resultados em vez de pontuações.
O padrão de recomendação que realmente se ajusta aos dados é um stack em camadas em vez de uma aposta em uma única ferramenta. Agentes de terminal — Claude Code ou Codex — ganham seu custo em refactors multi-arquivo, mudanças arquiteturais, e o tipo de debugging que de outra forma queimaria a tarde de um engenheiro sênior. Extensões IDE — Cursor ou GitHub Copilot — ganham os seus em completações inline, edições rápidas, e assistência ambiental durante trabalho de rotina. Agentes open-source — Aider, Cline, OpenHands — ganham os seus quando você quer trocar modelos, evitar markup de plataforma, ou auditar o comportamento do agente de ponta a ponta. Usar mais de um não é indecisão; é a resposta honesta à especialização. Lado benchmark: SWE-bench Verified não é mais seu amigo. SWE-bench Pro, Terminal-Bench 2.0, e sua própria codebase, são.