Aquele número bonito no benchmark? Esquece.

Você já viu aqueles posts no Twitter onde a empresa X anuncia orgulhosa que seu modelo resolveu 81% dos bugs no SWE-bench Verified? Pois é. A OpenAI acabou de jogar um balde de água fria em todo mundo: esses números não significam quase nada.

Em abril de 2026, a própria OpenAI — que ajudou a criar o SWE-bench Verified — publicou um estudo devastador mostrando que os modelos de IA estavam, literalmente, colando na prova. Não por malícia, claro. Mas porque os dados do benchmark vazaram para os datasets de treinamento. O resultado? Modelos que “resolvem” bugs sem realmente entender o código. Eles simplesmente lembram da resposta.

E o pior: 59,4% dos problemas mais difíceis tinham testes defeituosos que rejeitavam soluções corretas. Ou seja, o benchmark punia IAs que acertavam e premiava as que decoravam.

O que é o SWE-bench (e por que todo mundo usava)

Pra quem não acompanha a corrida dos benchmarks de IA, o SWE-bench é o teste mais popular para medir se uma IA consegue resolver problemas reais de código. Não estamos falando de exercícios de faculdade — são issues reais do GitHub, com repositórios reais, testes reais.

O SWE-bench Verified era a versão curada: 500 tarefas selecionadas manualmente, todas em Python, verificadas por humanos. A ideia era simples: um subset confiável onde dá pra medir progresso de verdade.

O Verified virou a métrica oficial. Toda empresa de IA reportava seu score nele. Claude Opus 4.5 marcou 80,9%. O GPT-5.3 Codex chegou a 85%. O Claude Mythos Preview bateu 93,9%.

Números impressionantes. Pena que estavam inflados.

A auditoria que destruiu a credibilidade

A OpenAI fez algo raro no mundo de big tech: admitiu que a métrica que ela mesma ajudou a criar estava comprometida. A equipe auditou sistematicamente o SWE-bench Verified e encontrou dois problemas fatais.

Problema 1: Contaminação de dados de treinamento

Todos os 500 problemas do Verified vêm de repositórios públicos do GitHub. Os issues, os pull requests, os patches — tudo público. E adivinhe o que os modelos de linguagem consomem durante o treinamento? Exatamente: código público do GitHub.

A auditoria da OpenAI mostrou que todo modelo frontier testado — GPT-5.2, Claude Opus 4.5, Gemini 3 Flash — conseguia reproduzir patches exatos, palavra por palavra, de tarefas do SWE-bench Verified. Não estamos falando de soluções parecidas. Estamos falando de reprodução literal do código original.

# Exemplo simplificado do que acontecia:
# A IA não "resolvia" o bug. Ela lembrava do fix.

# Patch original (que existe no GitHub desde 2023):
def fix_serializer(self):
    if self.instance is not None:
        return self.update(self.instance, self.validated_data)
    return self.create(self.validated_data)

# O que o modelo "resolvia" no benchmark:
# Exatamente o mesmo código. Caractere por caractere.

Eu já vi projetos falharem por confiar em métricas erradas, mas isso é outro nível. É como avaliar um aluno com uma prova cujas respostas estão no Google — e o aluno tem acesso ao Google.

Problema 2: Testes que rejeitam soluções corretas

O segundo achado é talvez pior. A equipe da OpenAI analisou os problemas que nenhum modelo conseguia resolver — a chamada “fronteira” — e descobriu que 59,4% deles tinham test cases defeituosos.

Isso mesmo: a IA mandava uma solução funcionalmente correta, e o teste falhava por razões que nada tinham a ver com a qualidade do código. Formatação diferente, ordem de imports, nomes de variáveis — detalhes que um humano reconheceria como irrelevantes, mas que faziam o CI rodar vermelho.

O resultado prático? O progresso de ponta parou. Nos últimos 6 meses, o state-of-the-art saiu de 74,9% para 80,9%. Parecia estagnação técnica. Na real, era o benchmark que estava errado.

SWE-bench Pro: o novo padrão (e por que 46% é melhor que 81%)

Se o Verified morreu, o que veio no lugar? O SWE-bench Pro, criado pela Scale AI, é a resposta da indústria. E os números contam uma história completamente diferente.

O mesmo Claude Opus 4.5 que marcava 80,9% no Verified? No Pro, faz 45,9%. Uma queda de 35 pontos percentuais. O GPT-5 cai de ~85% para 41,8%. Nenhum modelo escapa do massacre.

A real é que 46% no Pro diz muito mais sobre a capacidade de uma IA do que 81% no Verified. E a razão é simples: o Pro foi desenhado para ser impossível de colar.

O que muda no SWE-bench Pro

Quatro coisas tornam o Pro dramaticamente mais difícil — e mais honesto:

1. Multi-linguagem. Chega de resolver só bugs em Python. O Pro cobre Python, Go, TypeScript e JavaScript, em 41 repositórios reais. Se o modelo é bom só numa linguagem, isso aparece.

2. Tarefas complexas de verdade. No Verified, a mediana era 4 linhas alteradas em 1 arquivo. No Pro, a média é 107 linhas alteradas em 4,1 arquivos. São tarefas que um dev sênior leva horas para resolver. Tem task que exige mudanças em mais de 100 linhas, coordenando dependências entre múltiplos módulos.

3. Código privado que nenhum modelo viu. A jogada de mestre: o Pro inclui 276 tarefas de repositórios privados e proprietários de startups. Código que nunca apareceu no GitHub, nunca entrou em nenhum dataset de treinamento. Impossível decorar.

E aqui o dado mais revelador: quando testados em código privado (que nunca viram), os modelos caem ainda mais. O Claude Opus 4.1 cai de 22,7% para 17,8%. O GPT-5 despenca de 23,1% para 14,9%. Isso prova que parte significativa da performance em benchmarks públicos vem de memorização, não de raciocínio.

4. Licenciamento anti-contaminação. As tarefas públicas usam licenças copyleft (GPL), que legalmente restringem o uso em treinamento sem atribuição. É uma barreira técnica e legal contra a contaminação.

O que os modelos realmente erram (e onde travam)

A análise de falhas do SWE-bench Pro é fascinante porque mostra onde a IA de código realmente bate no teto. Três categorias dominam:

Tool-use inefficiency (42%) — Os agentes gastam tokens demais em ações desnecessárias. Leem arquivos inteiros quando precisam de 3 linhas. Abrem 20 arquivos quando o bug está em 2. É o equivalente digital de um dev junior que abre o projeto inteiro no grep antes de pensar.

Semantic understanding failures (35,9%) — O modelo entende a sintaxe mas erra a semântica. Sabe o que o código faz, mas não entende por que faz daquele jeito. Muda uma função sem perceber que ela tem side effects em outro módulo.

Context overflow (35,6%) — Projetos reais são grandes. Quando a IA precisa coordenar mudanças em 4+ arquivos, a janela de contexto vira gargalo. Informações do arquivo 1 já foram “esquecidas” quando o modelo chega no arquivo 4.

# Distribuição de falhas nos modelos frontier (SWE-bench Pro)
#
# Tool-use inefficiency:     ████████████████████░░ 42.0%
# Semantic understanding:    ███████████████████░░░ 35.9%
# Context overflow:          ██████████████████░░░░ 35.6%
# Planning errors:           █████████████░░░░░░░░ 28.3%
# Syntax/compilation:        ████░░░░░░░░░░░░░░░░░  8.1%

Repara que erros de sintaxe são raros (8,1%). As IAs escrevem código que compila. O problema é que o código faz a coisa errada — um problema que já apareceu em testes de lógica formal.

O que isso muda na prática pra quem usa IA pra codar

Se você usa Claude, GPT ou qualquer modelo como assistente de código no dia a dia, a morte do SWE-bench Verified tem implicações diretas:

Para de confiar em benchmark como argumento de venda. Quando a empresa X diz que seu modelo “resolve 85% dos bugs de software”, pergunte: qual benchmark? Se for o Verified, esse número é inflado. Se for o Pro, aí sim dá pra conversar.

Modelos são piores em código que nunca viram. Isso é óbvio quando você para pra pensar, mas os benchmarks antigos escondiam essa realidade. Se seu projeto tem uma arquitetura interna única, o modelo vai performar abaixo do benchmark. Sempre.

Tarefas simples ≠ capacidade real. Mudar 4 linhas num arquivo Python é trivial pra qualquer modelo frontier. Coordenar 107 linhas em 4 arquivos com dependências cruzadas? Aí separa quem resolve de quem decora.

Agent scaffolding importa mais que o modelo base. No SWE-bench Pro, o mesmo Opus 4.5 salta de 45,9% para 55,4% com scaffolding otimizado. O GPT-5.3-Codex chega a 57% com o setup certo. A infraestrutura ao redor do modelo — como ele navega código, como decide quais arquivos ler, como planeja a solução — é tão importante quanto o modelo em si.

A nova corrida: quem lidera no Pro?

Em abril de 2026, o leaderboard do SWE-bench Pro mostra uma competição muito mais apertada do que o Verified sugeria:

O Claude Mythos Preview lidera com folga, mas esse modelo ainda está em preview e não tem acesso público geral. Na prática, para devs usando ferramentas disponíveis hoje, a disputa é muito mais equilibrada.

Os top 6 modelos no baseline (sem scaffolding customizado) ficam dentro de 4,9 pontos percentuais — uma diferença que está dentro da margem de confiança estatística. Ou seja, no mundo real, Claude e GPT são mais parecidos do que as empresas querem que você acredite.

Benchmarks de IA sempre foram problemáticos — mas nunca assim

Quem acompanha machine learning há mais tempo sabe que gaming de benchmarks não é novidade. O ImageNet teve problemas parecidos nos anos 2010. O GLUE ficou saturado em meses. O SuperGLUE durou pouco mais. O padrão é sempre o mesmo: benchmark novo surge, modelos otimizam pra ele, benchmark perde utilidade, outro aparece.

Mas o caso do SWE-bench Verified é diferente por um motivo fundamental: não foi gaming intencional. Ninguém sentou e disse “vamos treinar no dataset do benchmark”. O problema é estrutural. Modelos de linguagem treinam em quantidades absurdas de texto da internet, e os dados do benchmark simplesmente estavam lá, misturados no meio de tudo.

Isso cria um dilema filosófico interessante: como você testa uma IA que já leu a internet inteira? Qualquer benchmark baseado em dados públicos vai eventualmente ser contaminado. O SWE-bench Pro resolveu parcialmente com código privado, mas isso não escala — quanto mais repositórios privados entram no benchmark, mais caro e limitado ele fica.

Alguns pesquisadores estão propondo abordagens alternativas. Uma delas é o “benchmark dinâmico”: gerar tarefas de código fresh a cada avaliação, usando mutações automáticas de repositórios reais. Outra é testar em projetos que foram criados depois do cutoff de treinamento do modelo. Ambas têm limitações, mas pelo menos reconhecem que o problema de contaminação não vai embora — só muda de forma.

“The benchmark treadmill will never end. The question is whether we’re honest about where we are on it.” — Percy Liang, Stanford HAI

A questão que fica é: se não podemos confiar nos benchmarks, como avaliamos progresso? A resposta pragmática é: combinando múltiplos sinais. Benchmarks como o Pro, sim, mas também avaliações humanas, deploy em produção real, e métricas de satisfação de devs que usam essas ferramentas no dia a dia. Nenhum número único vai capturar “essa IA é boa pra código”. E talvez essa seja a lição mais importante de toda essa história.

O que vem depois

A morte do SWE-bench Verified é um ponto de inflexão. Pela primeira vez, a indústria está sendo forçada a ser honesta sobre o que IAs de código realmente conseguem fazer.

O SWE-bench Pro não é perfeito — nenhum benchmark é. Mas ele corrige os pecados mais graves do antecessor: contaminação de treinamento, monocultura de linguagem e tarefas triviais demais.

A mensagem real aqui não é que IAs são ruins pra código. Elas são incrivelmente úteis. Mas existe uma diferença enorme entre “útil como assistente” e “resolve 85% dos bugs sozinha”. O primeiro é verdade. O segundo era marketing apoiado em um benchmark comprometido.

Na próxima vez que alguém te mostrar um score de benchmark, faça uma pergunta simples: os dados de teste estavam no treinamento? Se a resposta for “não sei” — e quase sempre é — aquele número não vale o pixel que ocupa na tela.

Fonte de inspiração: Why SWE-bench Verified no longer measures frontier coding capabilities — OpenAI