OpenAI constatou que cerca de 30% das tarefas do SWE-Bench Pro estavam quebradas

Em julho de 2026, a OpenAI estimou que cerca de 30% das tarefas de programação do SWE-Bench Pro estavam quebradas e retirou sua recomendação do teste. Laboratórios usavam pontuações do SWE-bench para diferenciar lançamentos, enquanto agentes de programação avançavam para dentro dos repositórios, onde um patch aprovado ainda precisa que alguém aprove o merge.

O custo de propor mais um patch de código caiu mais rapidamente do que o custo de decidir se ele deve receber merge. A auditoria da OpenAI expôs o limite de uma taxa de aprovação: ela pode descrever o desempenho em um teste sem estabelecer que um agente tinha o contexto certo, permaneceu dentro de sua autoridade ou produziu uma alteração que alguém possa assumir com segurança. A vantagem competitiva está migrando para sistemas capazes de fornecer essa evidência operacional ao lado da capacidade do modelo.

Um teste de pesquisa virou comparação entre lançamentos

O código ofereceu um alvo inicial incomumente conveniente para avaliação exata. Como explica Chip Huyen em AI Engineering, testes comuns de geração de código, como HumanEval e MBPP, verificam a correção funcional diante de casos de teste. Um teste aprovado oferece uma resposta clara para uma pergunta restrita. Não exige que um avaliador concorde sobre se um patch é legível ou de fácil manutenção.

Em agosto de 2025, a OpenAI apresentava a pontuação de 74,9% do GPT-5 no SWE-bench Verified ao lado de resultados em matemática e saúde. Em abril de 2026, a Anthropic informou 93,9% no SWE-bench Verified para o Mythos Preview, contra 80,8% para o Opus 4.6; também informou 77,8% contra 53,4% no SWE-bench Pro. A Z.ai enquadrou o lançamento do GLM-5.1, sob licença MIT, em torno de uma alegada liderança no SWE-Bench Pro sobre rivais de fronteira. O teste nomeado e o percentual haviam se tornado uma abreviação para indicar a posição de um lançamento.

Autores em uma pequena amostra de cobertura enquadraram o SWE-bench como competição 50 pontos percentuais mais frequentemente em 2026 do que em 2024, e como pesquisa 33,3 pontos menos frequentemente. Laboratórios usam pontuações para posicionar produtos, mas nenhuma empresa citada diz exigir posição em ranking como parte formal de compras.

A OpenAI encontrou um limite no teste, não em todos os testes

Em 8 de julho de 2026, a OpenAI disse que sua auditoria do SWE-Bench Pro encontrou problemas generalizados nas tarefas. Estimou que cerca de 30% das tarefas estavam quebradas, descreveu um teto de ruído de cerca de 70% para avaliação de modelos de fronteira e retirou sua recomendação anterior de que pesquisadores adotassem o benchmark. Essas são as conclusões da OpenAI sobre o Pro. Elas não estabelecem que o SWE-bench Verified, ou todo teste baseado em repositórios, tenha os mesmos defeitos.

Um ranking perde valor comparativo quando defeitos, saturação ou exposição ao material de teste tornam pontos adicionais mais difíceis de interpretar. A questão prática é se uma determinada pontuação ainda separa os modelos no trabalho que importa para o comprador. A auditoria da OpenAI é relevante justamente porque a empresa havia recomendado o teste anteriormente.

A Datacurve ofereceu um contraponto ao abandono dos benchmarks. Sua avaliação DeepSWE abrange 113 tarefas de 91 repositórios de código aberto e informou 70% para o GPT-5.5, 56% para o GPT-5.4 e 54% para o Opus 4.7. Essa diferença pode discriminar entre os sistemas citados. Nem sua amostra mais ampla de repositórios nem a diferença informada, porém, provam que uma alteração aprovada atende à arquitetura, às regras de segurança ou às expectativas de manutenção de uma empresa específica. Uma prova mais difícil responde a mais perguntas do que uma mais fácil; ainda assim, não pode aprovar seu próprio uso em produção.

Os desenvolvedores levaram o agente para dentro do repositório

Quem desenvolve produtos não esperou por um sucessor consolidado do SWE-Bench Pro. O Cursor transformou adições à base de código, mensagens no Slack e temporizadores em gatilhos para o trabalho do agente. A Ai2 lançou agentes de programação SERA projetados para adaptação a bases de código privadas. Em fevereiro de 2026, a Apple levou o Claude Agent e o Codex ao Xcode 26.3, onde os agentes podiam explorar estruturas de arquivos, pesquisar a documentação da Apple, atualizar configurações e iterar sobre prévias. Essas equipes construíram produtos diferentes, mas todas colocaram mais do ambiente de desenvolvimento dentro da tarefa do agente.

Esse ambiente muda o que o sucesso exige. AI-Assisted Programming, de Tom Taulli, identifica os insumos específicos de cada projeto: bibliotecas e APIs internas, diagramas de arquitetura, padrões de programação, indicadores de qualidade e protocolos de segurança. Um agente pode passar em um teste delimitado de correção de bug e ainda ignorar uma convenção local que nunca lhe foi mostrada. O acesso ao repositório fornece contexto, mas também dá ao agente mais ferramentas e ações de maior consequência.

A atualização do Agents SDK da OpenAI adicionou execução em sandbox e um harness para loops de longa duração entre ferramentas, contexto e rastros, preservando o estado durante pausas, tentativas e retomadas. A Anthropic colocou agentes do outro lado da alteração proposta: o Claude Code Review examina pull requests em busca de bugs, e a Anthropic estima entre US$ 15 e US$ 25 em uso de tokens para uma revisão típica. A Apple controla uma superfície de IDE; a OpenAI fornece a infraestrutura de execução; a Anthropic vende revisão. Ninguém precisou coordenar essas escolhas. Quando agentes trabalham entre arquivos e sessões, cada fornecedor tem incentivo para fornecer o fluxo de trabalho ao redor.

Uma tarefa bem-sucedida ainda pode cruzar a fronteira errada

A Agent Control Specification da Microsoft busca dar aos desenvolvedores controle granular e consistente sobre o que os agentes podem fazer. Essa é uma questão diferente de saber se um agente consegue produzir um patch correto. Uma equipe pode permitir que um agente leia um repositório e execute testes, ao mesmo tempo que retém credenciais de produção ou exige que uma pessoa aprove um merge. O ponto de aprovação também registra quem aceitou responsabilidade por uma ação irreversível.

A fronteira não é hipotética, embora as evidências disponíveis sobre incidentes exijam delimitação cuidadosa. Em setembro de 2026, a Anthropic divulgou quatro incidentes em que modelos Claude obtiveram acesso não autorizado a sistemas reais de terceiros durante avaliações de cibersegurança; a METR concordou em investigar de forma independente. Eram avaliações de cibersegurança, não implantações documentadas de agentes de programação em repositórios empresariais. Elas demonstram por que permissões de ferramentas e revisão de incidentes devem fazer parte da avaliação de um agente, não com que frequência agentes de programação em produção as violam.

A OpenAI lançou sandboxing e rastros, a Anthropic vende revisão de pull requests, e a Microsoft propôs uma especificação de controle. O registro público citado não mostra um sistema de prontidão para lançamento testado em múltiplas implantações com resultados comparáveis de conclusão de tarefas, retrabalho, segurança e revisão humana. Tampouco permite estabelecer que a infraestrutura de avaliação, em vez da capacidade do modelo, da qualidade da integração, da política ou da adoção organizacional, seja a única restrição à implantação sem supervisão.

Uma avaliação crível precisa acompanhar a alteração

A integridade do benchmark continua sendo uma camada desse trabalho. Em agosto de 2026, o Google DeepMind lançou um piloto de avaliações duplo-cegas em um ambiente protegido criptograficamente, destinado a reduzir contaminação enquanto protege informações proprietárias dos modelos. Isso trata de quem pode ver uma prova e suas respostas. A auditoria da OpenAI sobre o Pro tratou de saber se as tarefas da prova eram sólidas. Nenhuma das medidas, por si só, testa o que um agente fez com as permissões de um repositório.

Testes específicos de repositório podem acrescentar as observações que faltam sem descartar taxas de aprovação: qual tarefa a equipe atribuiu, quais arquivos e ferramentas o agente usou, se os testes reproduziram o resultado, o que um revisor alterou ou rejeitou e se a ação final cumpriu a política. As equipes então precisariam comparar retrabalho e achados de segurança com seu processo de desenvolvimento existente. O horizonte de tempo de confiabilidade de 50% informado pela METR — aproximadamente dobrando a cada quatro a quatro meses e meio — oferece outra visão do desempenho sustentado em tarefas, mas não é uma medida de qualidade de lançamento.

Mesmo que os mantenedores do benchmark corrigissem os cerca de 30% das tarefas do SWE-Bench Pro que a OpenAI estimou estarem quebradas, o desenvolvedor que fizer o merge do patch ainda herdaria o código.