OpenAI: SWE-bench Verified falha no frontier coding, use Pro

Introdução

OpenAI declarou em 23 de fevereiro de 2026 que o SWE-bench Verified deixou de medir de forma confiável capacidades de frontier coding e que a recomendação é usar o SWE-bench Pro enquanto novas avaliações sem contaminação não chegam. A decisão veio após uma auditoria técnica que identificou falhas significativas nos testes e evidência ampla de contaminação de treinamento. SWE-bench Verified é a palavra-chave central aqui, porque está no centro da mudança que afeta como a indústria mede agentes e modelos para engenharia de software autônoma.

O ponto central da análise é direto. Melhoras recentes no Verified parecem refletir exposição do modelo ao benchmark, não avanço real em habilidades de desenvolvimento. Isso levou OpenAI a parar de reportar resultados do SWE-bench Verified e a recomendar que outros desenvolvedores façam o mesmo, priorizando o SWE-bench Pro até que novas métricas limpas estejam disponíveis.

Por que o SWE-bench Verified saiu do centro das avaliações

OpenAI mapeou dois problemas estruturais. Primeiro, os testes rejeitam soluções corretas, o que distorce a leitura de capacidade. Em uma auditoria de 138 itens, 59,4% tinham issues materiais na forma como o problema foi descrito ou nasservides de teste. Em casos do tipo narrow test, os testes forçam detalhes de implementação não necessários. Em casos wide test, cobram funcionalidades não especificadas. Resultado prático, correções funcionais falham indevidamente.

Segundo, contaminação de treinamento. Como os problemas do SWE-bench vêm de repositórios open source amplamente usados em treinamento, modelos fronteira foram capazes de reproduzir patches humanos de referência, os chamados gold patches, e até trechos literais de enunciados. Isso indica que parte relevante do conjunto foi vista durante o treinamento. Em consequência, ganhos no Verified não necessariamente traduzem maior habilidade de desenvolvimento, mas sim maior exposição ao benchmark.

Há ainda um dado que liga o diagnóstico à cronologia dos avanços. O progresso reportado em state of the art no SWE-bench Verified desacelerou e passou de 74,9% para 80,9% nos últimos 6 meses antes do anúncio. Em vez de refletir salto real de capacidade, essa subida pode estar capturando a familiaridade do modelo com o conjunto e lacunas dos testes.

O que muda na prática para equipes técnicas

A consequência imediata para equipes que usavam o SWE-bench Verified como KPI é revisar governança de benchmarks e painéis de performance. Onde antes bastava citar percentuais no Verified, agora a recomendação é reportar SWE-bench Pro enquanto novas avaliações não contaminadas não chegam. OpenAI parou de publicar pontuações no Verified e recomenda que a indústria evite usá-las para comunicados de frontier launches. Isso muda como se constroem comparativos entre modelos comerciais e agentes.

Do ponto de vista operacional, times de plataforma e MLOps devem auditar dependências de benchmark em seus artefatos de go to market e relatórios internos. Também vale rever pesos usados em composições de scorecards para tomadas de decisão, por exemplo, seleção de modelo para agentes de refatoração, automação de PR e correção de bugs regressivos. Migrar para o Pro reduz o risco de sobreajuste comunicacional a um número inflado por exposição prévia ao dataset.

Background essencial, de SWE-bench a Verified

SWE-bench original foi lançado em 2023 com tarefas extraídas de issues resolvidas em 12 repositórios Python, pareadas a PRs e avaliadas por testes de regressão e testes que falham no código original e passam após um fix correto. O modelo não vê os testes, apenas o issue text e o estado do repositório pré-fix. Passa quem faz todos os testes passarem depois do patch. Esse formato ancorou a primeira geração de comparativos para agentes de software.

Para endereçar problemas da versão inicial, como testes super específicos, enunciados subespecificados e falhas espúrias de ambiente, OpenAI lançou em agosto de 2024 o SWE-bench Verified, um subconjunto curado de 500 problemas a partir de 1.699 amostras auditadas por especialistas, com anotações de qualidade e dificuldade. Esse passo melhorou robustez e tornou o Verified a referência preferida em lançamentos de frontier models.

Exemplos de falhas que distorcem a avaliação

O caso do repositório pylint ilustra o narrow test. O teste importava uma função específica, get_annotation, que não estava no enunciado. Soluções funcionais que não criavam a função com o nome imposto pelos testes eram reprovadas por erro de import, mesmo corrigindo o problema real. Isso cria falso negativo por coerção de implementação, não por falta de capacidade do modelo.

No lado wide test, um exemplo do SymPy mostra a assimetria. O PR de origem resolvia três issues distintas em nthroot_mod, enquanto o enunciado da tarefa do Verified cobria apenas um dos problemas. Modelos implementavam corretamente o conserto descrito, mas falhavam nos testes que verificavam os outros dois pontos não especificados. Isso pune a interpretação correta do enunciado e subestima a competência real.

![Tela com código CSS destacando sintaxe, metáfora visual para benchmarks de código]

A decisão da OpenAI e o que esperar das novas avaliações

OpenAI foi explícita. Melhoras no SWE-bench Verified não refletem mais progresso significativo em habilidade de desenvolvimento de software. Elas refletem cada vez mais o quanto o modelo foi exposto ao benchmark no treinamento. Por isso, a organização parou de reportar Verified e recomenda que outros também parem. Em paralelo, anunciou que está construindo novas avaliações não contaminadas para acompanhar de perto capacidades de coding, e que até lá a alternativa indicada é o SWE-bench Pro.

Essa posição sinaliza um movimento de qualidade em avaliação de agentes. Benchmarks estáticos e públicos têm ciclo de vida finito, especialmente quando usados como dados de treino em escala. O caminho provável envolve pipelines de geração contínua de tarefas e blindagens contra vazamento de soluções. O ecossistema acadêmico já investiga extensões, como versões multilíngues e pipelines automáticos de coleta e rotulagem, reforçando a hipótese de que diversidade de linguagens e rotatividade de instâncias são vitais para manter validade externa.

O que é o SWE-bench Pro e por que ele é o indicado agora

SWE-bench Pro é a evolução operacional do benchmark, mantida pela comunidade liderada por Scale AI, com foco em elevar a dificuldade, mitigar fuga de dados e refletir cenários de software mais próximos do mundo real. Embora detalhes específicos do post oficial sejam dinâmicos, sua posição pública é de que o Pro eleva a régua para agentic coding e serve como referência atual de avaliação prática.

Dados publicados por terceiros que medem agentes populares no Pro sugerem um conjunto substancial de tarefas reais, com 731 problemas em rodadas avaliadas por empresas independentes. Em 4 de fevereiro de 2026, a Augment Code relatou 51,80% para o agente Auggie, acima de Cursor e Claude Code em ambiente controlado, o que indica que o Pro já consegue diferenciar escolhas de scaffolding e orquestração mesmo quando o backbone do modelo é semelhante. Para times técnicos, isso é útil para separar arquitetura de agente de capacidade bruta do LLM.

![Editor de código com Python e saída do matplotlib, imagem didática para tarefas de bugfix]

Como ajustar estratégia de benchmark e KPIs internos

• Trocar o Verified por Pro em dashboards de engenharia e relatórios executivos. Manter uma nota metodológica explicando a decisão de 23 de fevereiro de 2026 e seus motivos. Isso evita comparações indevidas entre séries históricas.
• Rodar verificações cruzadas. Complementar Pro com tarefas internas proprietárias, rotatividade periódica e checks de contaminação. Quando possível, gerar amostras sintéticas orientadas por logs reais de falhas e PRs revertidos.
• Medir capacidade além de pass rate bruto. Incluir tempo para solução, número de tentativas, estabilidade em múltiplas seeds e custos de tool use. Esses indicadores ajudam a entender robustez e previsibilidade do agente.
• Acompanhar pesquisas emergentes de geração escalável e versões multilíngues, que reduzem o viés Python only e aproximam o benchmark de portfolios reais.

Insights de produto e risco para líderes de engenharia

• Produto. Se a oferta depende de promessas no Verified, é hora de reprecificar o valor entregue com base no Pro. Clientes enterprise vão perguntar qual métrica está sendo usada. Uma narrativa transparente aumenta confiança.
• Segurança e conformidade. Contaminação não é só um problema acadêmico. Se um agente aprendeu soluções literais do benchmark, ele também pode reproduzir padrões de patch que passam em testes mas não cobrem casos reais. Estabelecer políticas de avaliação em ambientes isolados e com testes adicionais reduz risco operacional.
• Roadmap técnico. Investir em harnesses que suportam múltiplas seeds, retries e registros detalhados de trajetória. Incorporar métricas de orquestração de agente, como uso de ferramentas, frequência de execução de testes e granularidade de commits sintéticos. Esses dados explicam por que um agente com o mesmo backbone performa melhor ou pior, como visto nos resultados diferentes de agentes rodando modelos semelhantes no Pro.

Perguntas frequentes que times estão fazendo agora

• Ainda posso publicar números no Verified em materiais públicos. A recomendação de OpenAI é não reportar Verified para frontier launches, já que não mede mais capacidade real. Adotar Pro como métrica principal evita conclusões enganosas.
• Esses achados valem para todos os modelos. A análise encontrou indícios em todos os frontier models testados de reprodução de gold patches ou de trechos literais dos enunciados, o que caracteriza contaminação.
• O que virá depois do Pro. OpenAI disse que está construindo novas avaliações não contaminadas. Enquanto elas não chegam, usar Pro e complementar com conjuntos proprietários e rotacionados é a forma pragmática de manter acurácia nas métricas internas.

Conclusão

O anúncio de 23 de fevereiro de 2026 é um divisor de águas para avaliação de agentes de software. SWE-bench Verified, que já foi um bom termômetro, hoje mistura ruído de contaminação com falhas de desenho de teste. A recomendação prática é clara, parar de reportar Verified para frontier coding e adotar SWE-bench Pro como referência transitória. Isso protege decisões de produto, MLOps e comunicação externa contra leituras enviesadas de performance.

O lado positivo é que a indústria amadurece. A próxima geração de benchmarks tende a ser dinâmica, mais diversa em linguagens e preparada para resistir à contaminação. Enquanto chegam as novas avaliações limpas, times que combinarem Pro com conjuntos internos rotativos, métricas além do pass rate e auditorias metodológicas vão medir melhor o que importa, capacidade real de engenharia de software em produção.