A OpenAI está contestando publicamente um dos benchmarks de programação mais observados da indústria de IA, argumentando que uma parcela substancial das tarefas do SWE-Bench Pro pode estar com defeitos suficientes para distorcer comparações entre modelos. Em uma nova análise publicada pela OpenAI, a empresa disse que sua auditoria encontrou evidências de que cerca de 30% das tarefas no benchmark estão quebradas.

O achado importa além de um único conjunto de dados. Benchmarks de programação como o SWE-Bench Pro se tornaram uma forma abreviada de julgar o progresso no desenvolvimento de software agentic, moldando prioridades de pesquisa, mensagens de lançamento e, em alguns casos, a percepção empresarial sobre qual modelo é mais adequado para trabalho de codificação. O ponto central da OpenAI é que, se as tarefas subjacentes não forem confiáveis, as pontuações de destaque podem dizer menos sobre a capacidade real de engenharia de software do que muitos criadores e compradores de modelos assumem.

Por que a OpenAI está contestando um benchmark em que a indústria se apoiou

Segundo a OpenAI, a empresa começou a revisar o SWE-Bench Pro depois de concluir anteriormente que o SWE-bench Verified tinha problemas significativos de design e contaminação. Na época, a OpenAI disse ter incentivado a comunidade em geral a migrar para o SWE-Bench Pro como um teste mais forte de tarefas de codificação mais longas e mais realistas.

Esse novo benchmark foi influente em parte porque parecia mostrar progresso rápido. A OpenAI escreveu que, no recorte público de 731 tarefas, os modelos de fronteira melhoraram de uma taxa de acerto de 23,3% para 80,3% em oito meses. Esse tipo de salto normalmente sugeriria ganhos importantes em habilidade prática de programação.

Agora a OpenAI argumenta que esses resultados precisam de mais cautela. Em sua auditoria mais recente, a empresa disse que seu pipeline interno de análise de pontos de dados sinalizou 200 tarefas, ou 27,4% do conjunto de dados, como quebradas. Uma campanha separada de anotação humana identificou 249 tarefas, ou 34,1%, como quebradas. Com base nessas revisões, a OpenAI disse estimar que cerca de 30% das tarefas do SWE-Bench Pro são falhas.

A posição da empresa não é que cada tarefa seja inutilizável, nem que nenhum sinal permaneça. Em vez disso, ela está alertando que os resultados do benchmark devem ser interpretados com cuidado, porque uma parte significativa do teste pode punir comportamento correto ou recompensar correções incompletas.

Os modos específicos de falha que a OpenAI diz ter encontrado

A análise da OpenAI divide os problemas em várias categorias familiares a quem já trabalhou com avaliações, especialmente em tarefas de software em que testes ocultos substituem o julgamento humano.

Uma categoria é a de testes excessivamente rígidos. Segundo a OpenAI, algumas tarefas exigem um detalhe de implementação muito específico que não é mencionado no prompt. Isso significa que um modelo pode produzir uma solução funcionalmente correta e ainda assim falhar.

Uma segunda categoria é a de prompts mal especificados. Nesses casos, a OpenAI disse que testes ocultos impõem requisitos que não podem ser inferidos de forma razoável a partir da descrição da tarefa. Isso cria uma discrepância entre o que se pede ao modelo e o que se usa para avaliá-lo.

Um terceiro problema são testes com baixa cobertura. A OpenAI disse que alguns testes não verificam adequadamente se o recurso solicitado realmente foi implementado, permitindo que correções parciais ou incompletas passem. Para compradores que avaliam sistemas de codificação por IA, esse é o modo de falha oposto ao de testes excessivamente rígidos: o benchmark pode superestimar a capacidade, e não apenas subestimá-la.

A OpenAI também apontou prompts enganosos que direcionam os modelos para um comportamento que entra em conflito com o que os testes depois esperam. A empresa incluiu um exemplo envolvendo formatação de sumário em Markdown, em que o prompt visível e os casos de teste ocultos diferiam por um espaço à esquerda. Nesse cenário, um modelo que seguisse o prompt exatamente como escrito ainda poderia ser marcado como errado.

Esse exemplo toca o cerne da crítica mais ampla. Muitos problemas de software e pull requests surgem em repositórios reais para colaboração humana, não como tarefas de avaliação limpas. A OpenAI argumenta que, quando esses artefatos são convertidos em um benchmark, o prompt, o patch de referência e os testes nem sempre se alinham bem o suficiente para sustentar uma pontuação confiável.

Como a auditoria foi conduzida, e onde a incerteza permanece

Os fatos mais fortes desta história vêm da própria metodologia publicada pela OpenAI, mas ainda são achados relatados pela empresa, e não uma revisão independente de terceiros do benchmark.

A OpenAI disse ter construído um pipeline de garantia de qualidade que examinou instruções das tarefas, tentativas dos modelos, metadados e rastros de falha para identificar casos-problema prováveis. A empresa afirmou que um primeiro filtro automatizado sinalizou 286 tarefas potencialmente quebradas para uma revisão mais profunda.

A partir daí, a OpenAI usou dois caminhos paralelos de revisão. Um envolveu agentes investigadores baseados em Codex com acesso ao repositório e ao ambiente de execução, permitindo inspecionar arquivos, executar testes e analisar falhas dos modelos. O outro foi uma campanha de anotação humana com engenheiros de software experientes. A OpenAI disse que cada tarefa sinalizada nesse processo foi examinada por cinco engenheiros, com divergências sendo escaladas.

A OpenAI informou que os revisores humanos, em geral, foram mais propensos do que o pipeline de agentes a marcar tarefas como quebradas. A empresa também disse que a sobreposição de categorias entre os julgamentos dos revisores e o pipeline de agentes foi de 74% nas tarefas sinalizadas, e que em nenhuma tarefa sinalizada “não quebrada” foi o rótulo humano mais comum.

Esses detalhes fortalecem o argumento da empresa de que os problemas não se limitam a casos isolados de borda. Mas há também limites sobre o que pode ser concluído a partir do material publicado. A evidência disponível não inclui uma resposta externa dos mantenedores do SWE-Bench Pro, nem fornece uma reavaliação lado a lado dos principais modelos sob uma versão corrigida do conjunto de dados. Portanto, embora a OpenAI apresente um caso substancial de que o benchmark tem ruído, o impacto exato nos rankings dos modelos ainda não está claro com base nas evidências fornecidas.

Por que isso importa para criadores de modelos e compradores corporativos

Para os laboratórios de IA, a implicação imediata é que vitórias em benchmarks de codificação podem ser menos duradouras do que parecem. Se quase um terço das tarefas contém defeitos, as diferenças no ranking podem refletir desalinhamento entre prompt e teste, suposições de implementação ou cobertura fraca de testes, em vez de diferenças reais na habilidade do modelo.

Isso é especialmente importante para equipes que constroem agentes de IA para trabalho de software. O SWE-Bench Pro tem sido posicionado como um teste relevante de comportamento de codificação de mais longo prazo, mais próximo do que sistemas agentic fazem em produção. Se suas tarefas forem materialmente falhas, os criadores precisam de pilhas de avaliação mais amplas, com testes específicos do repositório, revisão humana, análise de regressão e métricas reais de implantação, em vez de uma única pontuação pública.

Para compradores de IA corporativa, o alerta da OpenAI é um lembrete de não equiparar taxas de acerto em benchmark com prontidão para produção. Um modelo que se sai bem no SWE-Bench Pro ainda pode ter dificuldades com confiabilidade, ambiguidade ou completude de testes em uma base de código real. Por outro lado, um modelo que parece mais fraco no benchmark pode estar sendo penalizado por defeitos nas próprias tarefas.

Isso também é uma questão de governança. A OpenAI vinculou explicitamente a qualidade do benchmark a decisões de segurança e de implantação sob seu Preparedness Framework. O argumento é simples: se as avaliações superestimam ou subestimam a capacidade, elas podem distorcer tanto escolhas de lançamento de produtos quanto avaliações de risco. Esse ponto vai além da OpenAI e além de benchmarks de codificação. À medida que os modelos são cada vez mais avaliados por comportamento agentic, a má higiene dos benchmarks se torna um problema estratégico, não apenas acadêmico.

Também chama atenção a ênfase da empresa em auditoria assistida por agentes. A OpenAI está argumentando, na prática, que a mesma classe de sistemas que está sendo testada também pode ajudar a depurar os próprios testes. Se essa abordagem se tornará padrão dependerá de pesquisadores externos aceitarem que a revisão baseada em agentes pode melhorar a qualidade do conjunto de dados sem introduzir outra camada de viés dependente de modelo.

Evidências, alegações e o que é relato da empresa

A alegação central desta história é relatada pela empresa: a OpenAI diz que cerca de 30% das tarefas do SWE-Bench Pro estão quebradas, com base em seu processo interno de auditoria e em uma campanha de revisão humana que organizou.

A OpenAI também relata que modelos de fronteira melhoraram de 23,3% para 80,3% no recorte público de 731 tarefas do benchmark ao longo de oito meses. Neste artigo, esse número deve ser lido como uma tendência de benchmark citada pela OpenAI, e não como uma medida de mercado verificada independentemente.

Os detalhes metodológicos são mais concretos. A OpenAI diz que seu filtro automatizado sinalizou 286 tarefas, que seu pipeline de análise de pontos de dados julgou 200 tarefas como quebradas, e que sua campanha de anotação humana julgou 249 como quebradas. Também afirma que cinco engenheiros experientes revisaram cada tarefa sinalizada e que os julgamentos dos revisores se sobrepuseram ao pipeline de agentes em 74% dos casos sinalizados.

O que continua sem verificação, com base nas evidências disponíveis, é como os mantenedores do benchmark ou outros laboratórios classificariam as mesmas tarefas, se tarefas corrigidas reorganizariam materialmente os rankings dos modelos, e se taxas de erro semelhantes aparecem em benchmarks de codificação adjacentes além de SWE-bench Verified e SWE-Bench Pro.

O que observar a seguir

O primeiro sinal a observar é se os mantenedores do SWE-Bench Pro publicam uma resposta, um conjunto de dados revisado ou uma contestação formal. Se concordarem com uma parcela significativa das descobertas da OpenAI, o benchmark pode ser atualizado rapidamente. Se contestarem as conclusões, o setor pode precisar de um processo de arbitragem independente.

Em segundo lugar, observe se os principais laboratórios mudam a forma como reportam desempenho em codificação. Se futuros lançamentos de modelos derem menos ênfase ao SWE-Bench Pro e mais a suítes privadas de avaliação, testes no nível do repositório ou estudos de conclusão de tarefas, isso indicaria confiança menor nos rankings públicos de codificação.

Terceiro, fique atento a se a OpenAI divulgar mais ferramentas ou metodologia de auditoria de benchmarks usando Codex ou agentes investigadores relacionados. Um pipeline de auditoria reproduzível pode influenciar como o setor valida não apenas conjuntos de dados de codificação, mas também avaliações de agentes de IA de forma mais ampla.

Por fim, a questão maior é se a inflação de benchmarks agora é um padrão recorrente em categorias de modelos que evoluem rapidamente. A OpenAI já criticou o SWE-bench Verified e agora está levantando problemas com o SWE-Bench Pro. Se a próxima geração de avaliações de codificação enfrentar problemas semelhantes, o mercado pode migrar para evidências mistas: benchmarks públicos, telemetria de clientes e testes controlados de fluxos de trabalho reais, em vez de rankings de um único número.

Perspectiva da Creati.ai

A análise da OpenAI é importante menos porque ataca um benchmark e mais porque expõe um problema estrutural na medição de IA. A indústria quer números limpos e comparáveis para modelos de codificação, mas tarefas de software são bagunçadas. Quando prompts, testes ocultos e patches de referência são extraídos de repositórios reais, pequenas inconsistências podem transformar silenciosamente a avaliação em ruído. Isso é um problema para criadores tentando otimizar modelos e para empresas tentando comprar com confiança.

A lição prática não é parar de usar SWE-Bench Pro, SWE-bench Verified ou outros benchmarks públicos. É rebaixá-los de veredictos finais para sinais orientativos. Para equipes que lançam agentes de IA, a alfabetização em benchmarks agora faz parte do trabalho de produto: entender o que uma pontuação realmente mede, o que ela deixa passar e quão frágil ela pode ser. Os laboratórios que conquistarem confiança em codificação serão aqueles que combinarem resultados públicos fortes com design de avaliação transparente, evidências de fluxo de trabalho real e disposição para auditar suas próprias réguas de medição.