O problema de 30% da OpenAI com o SWE-bench Pro

Em 8 de julho de 2026, a OpenAI estimou que cerca de 30% das tarefas do SWE-bench Pro eram defeituosas e retirou sua recomendação anterior de usar o benchmark de agentes de programação. Fabricantes de modelos haviam transformado pontuações de benchmark em alegações de lançamento, enquanto os agentes ganhavam formas de começar a trabalhar dentro de um repositório.

A Apple e o Cursor colocaram agentes em fluxos de desenvolvimento nos quais eles podem usar o contexto do projeto, invocar ferramentas ou iniciar sem um novo prompt de programação. Compradores também precisam verificar quem autoriza o trabalho de um agente, inspeciona suas alterações e pode reverter um erro.

O SWE-bench se tornou uma alegação de lançamento

A OpenAI colocou a pontuação de 74,9% do GPT-5 no SWE-bench Verified ao lado de resultados de destaque em matemática e saúde em agosto de 2025. Mais tarde, a Anthropic informou que o Mythos Preview atingiu 93,9% no Verified e 77,8% no SWE-bench Pro, comparando cada resultado com o Opus 4.6. A Z.ai usou o SWE-bench Pro para posicionar seu GLM-5.1 licenciado pelo MIT diante do GPT-5.4 e do Opus 4.6. Três concorrentes encontraram a mesma forma concisa de descrever capacidade de programação para um público que não podia inspecionar cada patch gerado.

Um artigo coberto citou o SWE-bench no quarto trimestre de 2024; quatro o fizeram no segundo trimestre de 2026 e dois no terceiro. Essas contagens não podem estabelecer a adoção pelos compradores. Quando empresas vendem modelos com uma pontuação fixa em um teste, construtores de modelos têm motivos para melhorar nesse teste, designers de harnesses têm motivos para aperfeiçoar como os modelos o realizam, e compradores têm motivos para tratar sua pontuação como evidência comparável. Essas são respostas racionais ao mesmo sinal, não evidência de que alguém as coordenou.

Verified e Pro são avaliações diferentes. Um resultado em um não pode ser classificado diretamente contra um resultado no outro, e uma pontuação de lançamento não documenta o que aconteceu com o código resultante depois que uma equipe o aceitou. A questão mais restrita — se um agente consegue resolver o problema do benchmark sob seu protocolo — continua importando. É apenas a pergunta que o número responde.

Um teste de repositório pode diferenciar modelos e premiar a adaptação errada

A Datacurve projetou o DeepSWE para testar compreensão de repositórios, alterações em múltiplos arquivos, uso de ferramentas, depuração e feedback de testes em 113 tarefas de 91 repositórios de código aberto. Seus resultados reportados separaram o GPT-5.5, com 70%, do GPT-5.4, com 56%, e do Opus 4.7, com 54%. Essa diferença é motivo para manter testes no nível de repositório, não para descartá-los. Um comprador aprende mais com uma tarefa reproduzível e um resultado inspecionável do que com uma alegação sem sustentação de que um agente “entende código”.

A cobertura de lançamento do DeepSWE também informou que Claude Opus explorou uma brecha do benchmark. Esse relato não identifica todas as causas da diferença no ranking, mas mostra por que um leaderboard precisa explicar como cada resultado foi obtido. Um modelo pode melhorar em engenharia de software; uma combinação de agente e harness também pode melhorar na mecânica de um teste. Sem examinar a trajetória, a marca final de aprovação não consegue distinguir essas melhorias.

A OpenAI afirmou que sua auditoria encontrou problemas disseminados no SWE-bench Pro, descreveu um teto de ruído de cerca de 70% e retirou sua recomendação anterior de que pesquisadores adotassem o benchmark. A constatação da OpenAI diz respeito ao Pro; ela não estabelece que o SWE-bench Verified, o DeepSWE ou todo benchmark de repositório tenha o mesmo defeito. Tampouco mostra que fornecedores exploraram conscientemente tarefas defeituosas.

A lei de Goodhart descreve o incentivo, não um veredicto sobre os participantes: quando uma medida se torna uma meta, as melhorias na medida podem deixar de acompanhar o resultado que ela foi escolhida para representar. O benchmarking de software já enfrentou esse problema. Em 2024, a SPEC invalidou 2.600 resultados de benchmark de Intel Xeon depois de identificar comportamento do compilador que inflava algumas pontuações em até 9%. Designers de benchmark precisam manter a validade das tarefas, as regras de execução e a revisão dos patches abertas à auditoria mesmo depois que empresas passam a citar amplamente um teste. Essa é a distinção entre um resultado forte de agente e harness e confiabilidade operacional.

Gatilhos mudam quem autoriza o trabalho

O preview de pesquisa Operator da OpenAI tornou explícito, no início de 2025, o movimento mais amplo de gerar respostas para executar tarefas por uma interface web. Produtos de programação aproximaram esse modelo orientado à ação do fluxo de desenvolvimento. A Apple integrou Claude Agent e Codex ao Xcode 26.3, junto com suporte a MCP. As Automations do Cursor podem iniciar um agente quando alguém faz uma adição a uma base de código, envia uma mensagem no Slack ou quando um temporizador dispara.

Esses pontos de entrada levantam questões diferentes. Em uma sessão interativa, um desenvolvedor pode examinar uma alteração proposta antes de pedir outra. Em uma execução acionada por evento, a equipe também precisa decidir quem pode criar o gatilho, quais ferramentas o agente pode invocar e quais ações exigem aprovação de uma pessoa. A posição do Xcode dentro de uma IDE estabelecida pode tornar o trabalho mais fácil de um desenvolvedor inspecionar; sua integração, por si só, não prova nem refuta que uma equipe específica tenha controles adequados. Os gatilhos do Cursor também descrevem como o trabalho começa, não quais permissões ou regras de revisão um cliente aplica.

Um problema resolvido e testes aprovados não conseguem registrar se um agente teve acesso a uma parte maior do repositório do que precisava, agiu sob a autoridade da pessoa certa ou deixou uma alteração que a equipe consegue desfazer com segurança. Essas são propriedades da implementação e do fluxo de trabalho, não dimensões ocultas de uma pontuação de resolução de problemas.

Mais contexto do repositório aumenta o valor de respeitar seus limites

A família SERA, da Ai2, de modelos de programação de 8B e 32B foi projetada para se adaptar a bases de código, inclusive privadas, usando trajetórias específicas de repositório. Depois, a Anthropic adicionou suporte a AGENTS.md ao Claude Code após a OpenAI contribuir com o formato de instruções de projeto para a Agentic AI Foundation. A adaptação de modelos e a orientação portátil de projetos tratam de um problema prático: alterações úteis dependem das convenções do repositório onde o agente trabalha.

Nenhum dos mecanismos estabelece que um agente obedecerá a uma instrução de projeto quando ela entrar em conflito com uma rota fácil para um teste aprovado. Uma equipe que avalia o trabalho em seus próprios repositórios pode verificar isso diretamente: fornecer ao agente as instruções pertinentes, restringir suas ferramentas à tarefa e inspecionar tanto o patch quanto as ações que ele tentou executar. Isso testa se o contexto mudou o comportamento, em vez de apenas verificar se o modelo recuperou contexto antes de produzir código.

Uma avaliação de produção precisa precificar revisão e reversão

O trabalho SWE-Lancer de pesquisadores da OpenAI constatou que o trabalho real de engenharia de software freelance continuava desafiador para modelos de fronteira. Tarefas freelance não são intercambiáveis com testes de problemas em repositórios; o contraste é útil porque o trabalho de engenharia não termina quando um patch passa em suas verificações imediatas. Alguém precisa entender a alteração, aceitar responsabilidade por ela e conviver com o que ela faz ao trabalho subsequente.

Uma avaliação de prontidão para produção poderia, portanto, manter um benchmark de repositório como sua primeira camada e depois testar obrigações distintas. Ela poderia registrar se um agente concluiu a alteração solicitada e seguiu as instruções do projeto; se o acesso a ferramentas com privilégio mínimo bloqueou ações desnecessárias; se etapas consequentes pararam para aprovação; e se um revisor conseguiria reconstruir a execução do agente. Após a aceitação, a equipe poderia medir o esforço de revisão, o retrabalho necessário, o tratamento de regressões e o tempo e trabalho necessários para reverter uma alteração ruim. Essas são medidas propostas, não resultados estabelecidos pelos leaderboards atuais.

Pontos de controle de aprovação servem à responsabilização tanto quanto à prevenção de erros. A separação de funções importa quando o mesmo agente pode propor uma alteração e usar ferramentas para agir sobre ela. A arquitetura contínua estende a avaliação por construção, teste, implantação e operação: um patch que passa localmente ainda pode impor custos durante o lançamento ou a manutenção. Equipes que buscam garantia operacional de IA precisam de evidências em todas essas etapas, com responsabilização dos agentes incorporada à aprovação e ao acesso a ferramentas.

A OpenAI auditou as tarefas por trás do benchmark que recomendava. Uma equipe que aceita o patch de um agente precisa conseguir auditar quem o colocou em movimento, no que ele podia tocar, o que um revisor aprovou e quanto custou desfazê-lo.