O Benchmark Está Contaminado. E Agora?

Em 23 de fevereiro de 2026, a OpenAI publicou uma análise explicando por que não reportará mais resultados no SWE-bench Verified — o benchmark de codificação que eles mesmos criaram em agosto de 2024. As descobertas: 59,4% dos problemas auditados tinham casos de teste materialmente defeituosos, e todos os modelos de fronteira testados apresentavam evidências de contaminação por dados de treinamento.

Não é um ajuste menor. É a organização que construiu o benchmark admitindo que o benchmark não mede o que todo mundo achava que media.

O Que Quebrou

O SWE-bench Verified deveria ser a medida confiável da indústria para capacidade autônoma de engenharia de software. Quinhentos problemas, cada um revisado por três engenheiros de software especialistas. A OpenAI o criou especificamente para corrigir falhas no dataset original SWE-bench de Princeton.

Não funcionou.

A OpenAI auditou 138 problemas que seu modelo mais capaz, o3, não conseguiu resolver consistentemente em 64 execuções independentes. Desses 138 problemas, 59,4% tinham defeitos materiais — não no modelo, mas no próprio benchmark.

Os defeitos se dividem em duas categorias. 35,5% dos problemas auditados tinham testes excessivamente restritivos: exigiam detalhes específicos de implementação, rejeitando soluções funcionalmente corretas. Uma correção poderia ser inteiramente válida e ainda falhar porque não usava o nome exato da função que o teste esperava. 18,8% tinham testes excessivamente amplos: verificavam funcionalidades nunca mencionadas na descrição do problema, testando comportamentos que o modelo não tinha razão para implementar.

Isso significa que o benchmark não estava medindo capacidade de codificação. Estava medindo a capacidade de adivinhar detalhes de implementação não especificados, ou resolver problemas não descritos.

O Problema da Contaminação

A segunda descoberta é pior. A OpenAI conduziu testes automatizados de red-teaming contra GPT-5.2, Claude Opus 4.5 e Gemini 3 Flash. Em cada caso, o modelo conseguiu reproduzir informações específicas das tarefas que jamais deveria ter visto.

O GPT-5.2 reproduziu patches gold exatos — a correção de bug escrita por humanos que servia como referência. Sua cadeia de raciocínio revelou conhecimento de notas de lançamento do Django que indicavam nomes específicos de parâmetros introduzidos em versões futuras. O Claude Opus 4.5 recordou caminhos exatos de arquivos, nomes de funções e citou comentários inline de código palavra por palavra. O Gemini 3 Flash produziu descrições completas de tarefas e patches gold incluindo números exatos de linhas.

Isso não é sutil. Quando um modelo consegue reproduzir o diff exato que humanos escreveram para corrigir um bug específico, ele viu aquele diff durante o treinamento. O benchmark está medindo memória, não capacidade.

A conclusão da OpenAI: “Melhorias no SWE-bench Verified não refletem mais melhorias significativas nas habilidades reais de desenvolvimento de software dos modelos. Em vez disso, refletem cada vez mais o quanto o modelo foi exposto ao benchmark durante o treinamento.”

Os scores de ponta melhoraram de 74,9% para 80,9% em seis meses. Quanto disso foi progresso genuíno e quanto foi vazamento de dados de treinamento? Ninguém sabe. Esse é o ponto.

O Problema Estrutural

Isso não é apenas um problema do SWE-bench. É um problema de infraestrutura de medição.

Todo benchmark publicamente disponível enfrenta a mesma pressão de contaminação. Datasets de treinamento incluem porções enormes da internet pública. Benchmarks são públicos. Soluções são públicas. No momento em que você publica um teste, ele se torna dado de treinamento para o próximo modelo. Os alunos não apenas veem as respostas antes da prova — eles as memorizam sem que ninguém perceba.

A recomendação da OpenAI é usar o SWE-bench Pro e investir em benchmarks de autoria privada como seu GDPVal, onde especialistas de domínio criam tarefas e revisores treinados avaliam soluções holisticamente. Isso é direcionalmente correto e praticamente autointeressado — estão recomendando seu próprio produto substituto.

Mas a percepção subjacente é correta: você não pode medir capacidade de IA com benchmarks públicos quando os modelos são treinados em dados públicos. A infraestrutura de avaliação precisa ser pelo menos tão sofisticada quanto os sistemas sendo avaliados. Agora, ela não é.

O Que Isso Significa Para Organizações

Se você é um líder de engenharia que escolheu uma ferramenta de codificação com IA baseado em scores do SWE-bench, você tomou uma decisão de compra baseada em um sinal contaminado. Não é culpa sua — todos usavam esses scores porque eram os melhores disponíveis. Mas isso significa que você precisa de uma base diferente para avaliar o que essas ferramentas realmente entregam.

O problema vai além da seleção de ferramentas. Organizações que reportam eficácia de IA usando benchmarks sintéticos — para conselhos, investidores, stakeholders internos — estão reportando números que podem não ter relação com a capacidade real. A taxa de aprovação de 80,9% parece impressionante. Ela diz quase nada sobre se a ferramenta ajudará sua equipe a entregar software confiável.

O que funciona? Medição operacional. Rastreie o que acontece no seu codebase real, com a complexidade real do seu codebase, revisado pelos seus engenheiros reais. Meça taxas de aceitação de PRs de IA contra baselines humanos. Meça taxas de defeitos pós-merge. Meça tempo-até-produção, não tempo-até-diff.

O estudo da LinearB com 8,1 milhões de pull requests descobriu que PRs gerados por IA tinham taxa de aceitação de 32,7% versus 84,4% para escritos manualmente. A pesquisa State of Code 2026 da Sonar, com 1.149 desenvolvedores, encontrou que 96% não confiam na precisão de código de IA. Esses são sinais operacionais de workflows reais de engenharia. Eles contam uma história fundamentalmente diferente dos leaderboards de benchmarks.

A Implicação de Governança

Quando a organização que criou o benchmark admite que o benchmark está quebrado, a resposta apropriada não é encontrar um benchmark melhor. É perguntar por que você estava dependendo de uma única métrica sintética para avaliar algo tão consequente.

A resposta, para a maioria das organizações, é que não tinham nada melhor. Nenhuma infraestrutura interna de medição. Nenhum rastreamento sistemático da qualidade de código gerado por IA. Nenhum framework de comparação entre output de IA e output humano no seu contexto específico. Terceirizaram a avaliação para um número em um leaderboard porque construir sua própria capacidade de avaliação parecia desnecessário.

Não era desnecessário. Era a capacidade mais importante que não construíram.

As organizações que navegarão bem por isso são as que tratam a medição de qualidade de IA como uma disciplina operacional interna — como segurança, como compliance, como monitoramento de performance. Não um número que você lê na página de marketing de um fornecedor, mas um sistema que você constrói, opera e valida continuamente contra seus próprios padrões de qualidade.

Essa é a lacuna de governança. Não a ausência de capacidade de IA — a capacidade é real e substancial. A ausência de infraestrutura organizacional para medir, verificar e confiar nessa capacidade no seu contexto específico. Benchmarks eram um substituto conveniente para essa infraestrutura. Agora sabemos que não funcionam.

Construa a infraestrutura.

Esta análise é baseada no artigo da OpenAI “Why SWE-bench Verified no longer measures frontier coding capabilities” (23 de fevereiro de 2026), com dados de suporte dos benchmarks de engenharia 2026 da LinearB (8,1M PRs) e da pesquisa State of Code 2026 da Sonar (1.149 desenvolvedores).

Se sua organização está avaliando ferramentas de codificação com IA baseada em scores de benchmark — ou não tem framework de avaliação algum — a Victorino Group ajuda equipes de engenharia a construir a infraestrutura de medição que torna a adoção de IA confiável. Não benchmarks melhores. Governança melhor.