Por que o SWE-bench Verified não consegue mais medir a capacidade de programação de ponta

• SWE-bench Verified, que era o principal indicador para tarefas autônomas de engenharia de software, perdeu grande parte da adequação para medir a capacidade de modelos de fronteira
• Com o ganho recente de desempenho máximo limitado de 74,9% para 80,9%, ficou difícil distinguir se as falhas restantes vêm de limites do modelo ou de defeitos do conjunto de dados
• Em uma auditoria de 138 problemas, foram encontrados defeitos graves no desenho dos testes ou na descrição do problema em 59,4% dos casos, e testes restritivos ou excessivamente amplos fazem até soluções funcionalmente corretas serem reprovadas
• Como a avaliação se baseia em dados públicos e codebases públicos, é difícil evitar contaminação dos dados de treino, e alguns modelos quase reproduzem o gold patch apenas com a descrição da tarefa ou o ID
• Por isso, os relatórios de pontuação do SWE-bench Verified foram interrompidos, e o foco da avaliação está migrando para o SWE-bench Pro e para benchmarks privados menos afetados por contaminação

---

Por que o benchmark não mede mais o que deveria

• O SWE-bench Verified foi amplamente usado como métrica padrão para medir o desempenho de modelos em tarefas autônomas de engenharia de software, mas hoje está bem menos adequado para medir a capacidade atual de modelos de fronteira
• Como o ganho recente de desempenho máximo ficou limitado de 74,9% para 80,9% nos últimos 6 meses, ficou difícil separar o que é falha do modelo e o que é defeito do dataset
• A nova análise mostrou que testes defeituosos e contaminação dos dados de treino são os principais problemas, fazendo com que a pontuação reflita mais o grau de exposição ao benchmark do que a habilidade real de programação
• Por isso, a OpenAI parou de reportar pontuações do SWE-bench Verified e recomenda que outros desenvolvedores de modelos façam o mesmo
• Como alternativa, recomenda o uso do SWE-bench Pro, menos contaminado, e também está construindo novas métricas de avaliação sem contaminação

Contexto

• O SWE-bench original foi lançado em 2023 e foi montado pareando issues resolvidas do GitHub com seus respectivos PRs em 12 repositórios Python de código aberto
• Em cada problema, o modelo precisa gerar alterações no código tendo apenas a codebase anterior à correção e o texto da issue, e o critério de aprovação é passar em todos os testes após aplicar a mudança
  • Isso inclui testes que falham antes da correção e passam depois da correção correta
  • Também inclui testes de regressão para verificar se funcionalidades existentes não foram quebradas
• A avaliação original tinha problemas como testes excessivamente específicos que rejeitavam até correções corretas, especificações insuficientes que permitiam várias interpretações e testes que falhavam dependendo do ambiente
• Para reduzir isso, em 2024 foi criado o SWE-bench Verified, filtrando 1.699 problemas por revisão de especialistas para formar um conjunto de 500 problemas
  • Cada problema foi revisado de forma independente por 3 especialistas

Defeitos no desenho dos testes

• A auditoria se concentrou em 138 problemas que o OpenAI o3 não conseguiu resolver de forma consistente mesmo após 64 execuções independentes, e cada caso foi revisado de forma independente por pelo menos 6 engenheiros de software experientes
• O resultado foi que, em 59,4% dos 138 casos, havia falhas graves no desenho dos testes ou na descrição do problema, a ponto de até modelos excelentes ou pessoas terem enorme dificuldade ou impossibilidade de resolver
• 35,5% das tarefas auditadas incluíam testes restritivos que impunham detalhes específicos de implementação
  • Isso pode invalidar várias soluções funcionalmente corretas
• 18,8% das tarefas auditadas incluíam testes amplos que exigiam funcionalidades extras não mencionadas na descrição do problema
• Os 5,1% restantes tinham outros problemas que não se encaixavam claramente nessas duas categorias

• Casos de teste restritivos

  • Em pylint-dev__pylint-4551, o teste do PR importa diretamente a função get_annotation, mas esse nome de função não aparece na especificação do problema
  • Assim, mesmo resolvendo o problema de forma funcionalmente correta, o teste pode falhar por erro de importação se esse nome específico de função não for implementado

• Casos de teste amplos

  • sympy__sympy-18199 foi extraído de um PR que, na prática, corrigia três issues ao mesmo tempo: #17373, #17377 e #18212
  • Porém, a descrição da tarefa no SWE-bench Verified cobre apenas a #18212, então mesmo que a implementação siga a descrição corretamente, ela ainda pode falhar nos testes que verificam as outras duas issues

Problema de contaminação

• O SWE-bench Verified, as codebases desses repositórios e as release notes são todos públicos e amplamente usados e discutidos, então é difícil evitar contaminação de dados
• A OpenAI identificou sinais de contaminação até em seus próprios modelos, incluindo casos em que o GPT‑5.2 resolveu 31 tarefas que ela considerava praticamente impossíveis de resolver
• Em django__django-14725, os testes exigem o parâmetro edit_only, que não aparece na especificação do problema, e o GPT‑5.2 chegou a apontar corretamente em seu raciocínio que esse parâmetro foi introduzido no Django 4.1
• Para avaliar a gravidade da contaminação, a OpenAI construiu um ambiente automatizado de testes de red team
  • Para cada problema do SWE-bench Verified, o GPT‑5 investigou se GPT‑5.2‑Chat, Claude Opus 4.5 e Gemini 3 Flash Preview estavam contaminados
  • Ao GPT‑5 foram fornecidos o ID da tarefa, a descrição, o gold patch e os testes do PR, com liberdade para mudar prompts e estratégias de indução ao longo de 15 turnos
  • Após cada turno, um modelo avaliador classificava a gravidade da contaminação de nenhuma a forte com base na quantidade de informação específica da tarefa que havia sido revelada
  • Casos de contaminação forte foram verificados por um modelo avaliador adicional para confirmar excesso de vazamento de informação e depois revisados manualmente

Casos graves de contaminação por modelo

• GPT‑5.2

  • Em django__django-11451, apenas um pequeno trecho da descrição da tarefa já bastou para produzir o gold patch exato
  • O modelo reproduziu a condição de retorno antecipado username is None or password is None em ModelBackend.authenticate(), além do caminho do arquivo e do nome do método

• Claude Opus 4.5

  • Em astropy__astropy-13236, ele citou literalmente o caminho do arquivo a ser corrigido, astropy/table/table.py, o método _convert_data_to_col e até comentários inline dentro do diff
  • Também reconstruiu com precisão as 4 linhas de código que convertiam automaticamente ndarray estruturado em NdarrayMixin

• Gemini 3 Flash

  • Em django__django-11099, mesmo quase sem nenhuma informação além do ID da tarefa, ele reproduziu literalmente a descrição da tarefa e todo o gold patch
  • O conteúdo da mudança, em que a regex de validação de nome de usuário passa de r'^[\w.@+-]+$' para r'^[\w.@+-]+\Z', e o diff linha a linha também foram reproduzidos

Lições principais

• Benchmarks extraídos de materiais disponíveis publicamente carregam risco de contaminação, e a exposição aos dados de treino pode inflar a pontuação sem deixar isso evidente
• Ao construir benchmarks com dados públicos coletados por crawling, desenvolvedores de modelos precisam executar testes adicionais para verificar contaminação
• Como benchmarks e respostas públicas acabam entrando nos dados de treino, é preciso ter cuidado especial tanto com a forma de distribuição do dataset quanto com a filtragem dos dados de treino
  • Foram mencionados mecanismos de controle de distribuição, como proteção por senha
  • Também foram mencionados métodos de filtragem, como a observância rigorosa de strings canário
• A correção automática precisa ser robusta o bastante para não oscilar por diferenças de implementação sem importância, mas também para impedir soluções por atalhos, e satisfazer essas duas condições ao mesmo tempo é muito difícil
• Encontrar esses defeitos exigiu várias rodadas de rotulagem manual em larga escala

Direção futura da avaliação

• Nos últimos meses, a OpenAI decidiu passar a reportar resultados no conjunto público de avaliação do SWE-bench Pro e recomenda que outros desenvolvedores de modelos façam o mesmo
• O SWE-bench Pro também não é perfeito, mas empiricamente sofre menos impacto de contaminação do que o SWE-bench Verified
  • Alguns casos de contaminação foram encontrados no pipeline interno de verificação
  • Ainda assim, eles foram muito mais raros e menos graves do que no SWE-bench Verified
  • Nenhum modelo conseguiu gerar um gold patch completamente idêntico, letra por letra
• Daqui para frente, o plano é continuar investindo em benchmarks originais e redigidos de forma privada
• No GDPVal, especialistas de domínio escrevem tarefas de forma privada, e avaliadores treinados atribuem notas às soluções de maneira abrangente
• Esse modelo consome muitos recursos, mas está se tornando cada vez mais essencial para medir ganhos reais de capacidade

[GN⁺]

Comentários do Hacker News

• Como coautor do SWE-bench, resumindo: o SWE-bench Verified agora está praticamente saturado em 93,9%, e a Anthropic merece parabéns
  Ainda assim, equipes que ainda não chegaram nesse nível ainda têm espaço para melhorar
  SWE-bench Multilingual e SWE-bench Multimodal ainda não estão saturados, e o Multimodal deve ser aberto como open source no próximo mês
  Todo benchmark acaba saturando no fim, então continuamos criando benchmarks da próxima etapa, e já existem coisas como https://codeclash.ai/ e https://algotune.io/

  • Saturar não significa que devemos parar de usar o SWE-bench Verified
    O ponto central é que uma parte considerável dos testes é imprecisa, então até soluções realmente corretas acabam sendo avaliadas como erradas
    Além disso, há uma grande chance de os modelos de ponta já terem lido e memorizado os PRs que serviram de base para os problemas
    Alguns problemas são praticamente impossíveis de acertar sem memorizar a solução; por exemplo, há casos em que só se passa nos testes se expuser exatamente o nome de uma função helper específica que nem aparece no enunciado
    E o fato de os modelos de ponta passarem nesses casos parece vir justamente de lembrarem que aquele nome era necessário
    Se a próxima geração de benchmarks não resolver isso, o mesmo problema vai continuar existindo independentemente de saturação ou não
  • Pelo que o artigo diz, foi auditado um subconjunto de 27,6%, e dentro dele 59,4% tinham testes defeituosos que rejeitavam submissões funcionalmente corretas
    Fazendo as contas, 0.191 * 0.594 > 1 - 0.936, então fico me perguntando se o subconjunto auditado não era representativo, ou se a Anthropic conseguiu a pontuação alta de um jeito meio suspeito
  • SPECint e SPECfp passaram exatamente pelo mesmo ciclo
    Criaram o benchmark, ele saturou, foi abandonado, substituído, e depois tudo se repetiu
    No fim, essa própria treadmill parece operar como um produto, e não sei qual é a solução, mas parece história se repetindo
  • Enquanto isso, também parece existir o https://SWE-rebench.com como alternativa
    Pelo que entendi, parece uma variação interessante em cima do SWE-bench
  • Acho o SWE-bench em si excelente
    O fato de ele estar sendo tão fortemente examinado agora parece ser justamente uma reação ao quanto foi amplamente adotado e bem-sucedido

• Parece óbvio demais que qualquer benchmark novo vai rapidamente parar nos dados de treino e logo envelhecer
  Sempre existe incentivo para otimizar para um benchmark específico, nem que seja por marketing, e mesmo quando há cutoff de treino, normalmente a diferença para a data de publicação é de só 3 a 6 meses
  Então a verdadeira dificuldade dos benchmarks de código está em criar problemas totalmente novos, sem reaproveitar benchmarks existentes, com garantia de que nunca estiveram nos dados de treino
  Por essa ótica, benchmarks criados antes do lançamento de um modelo dificilmente representam bem o desempenho dele, e o incentivo financeiro para enfiar dados só para divulgar melhorias marginais é grande demais
  Sinceramente, o certo seria tirar benchmarks do material de marketing, deixar o modelo falar por si e a comunidade julgar, mas empresas com dinheiro em jogo nunca vão fazer isso

  • Foi por isso que criei o Zork bench
    O jogo de aventura em texto Zork está nos dados de treino de LLMs e é determinístico, então em tese deveria ser fácil de jogar e zerar
    Mas na prática não é, e entender por quê é justamente o objetivo do Zork bench
    https://github.com/mnky9800n/zork-bench
  • Quando se fala em deixar a comunidade julgar, nem está claro de qual comunidade estamos falando
    Vai de especialistas que usam LLMs há mais de 10 anos até vibe coders que nunca escreveram código, e online há gente que vê o GPT 5.5 como salvador e gente que acha ele mais burro que o 5.4
    Eu também não tenho tempo de montar benchmarks privados para cada novo modelo, então acabo dependendo de benchmarks private ou semi-private para estimar o tamanho da melhora, depois assino e testo por conta própria
    Pelo menos confio um pouco mais nisso do que no clima gerado por usuário aleatório ou bot no Reddit
  • Uma forma fácil de tornar benchmarks de código relevantes de novo seria preencher antes o contexto do modelo com 200 mil tokens de ruído ou conteúdo irrelevante
    Ou então rodar testes em sequência no mesmo contexto para ver até onde o modelo aguenta antes de perder o fio da meada
    Os benchmarks atuais são sempre problemas greenfield, mas no mundo real queremos modelos que lidem com contexto podre
  • Ainda parece que estamos olhando uma camada abaixo da essência
    O gargalo atual não é a capacidade em si, mas o que o modelo consegue ver em produção
    Estrutura de contexto, qualidade de retrieval, tool use e a capacidade de combinar estado ao longo de vários turnos são importantes, e o SWE-bench quase não tem nada disso
    O SWE-bench parece uma lista de exercícios one-shot, mas o trabalho de programação de ponta já não tem mais essa forma
    Mesmo que se criasse um benchmark perfeito, sem nenhuma contaminação de dados, ele provavelmente ainda mediria o eixo errado na maior parte dos casos
    Em problemas isolados, já chegamos ao nível de um pós-graduando humano; o ganho agora está em como isso funciona dentro de sistemas maiores
    Só que isso beira gosto ou preferência, então é extremamente difícil medir de forma objetiva
  • A própria comunidade online está astroturfed demais
    A Anthropic paga influenciadores para promover o Claude Code, e parece rodar bots em grande escala também, então fica difícil confiar em consenso online
    Mesmo quando todos agem de boa-fé, a percepção pode variar muito por diferença de domínio
    Por exemplo, IA pode ir muito melhor em frontend ou em bibliotecas amplamente usadas
    No fim, não tem jeito além de testar o modelo você mesmo, mas repetir isso a cada lançamento cansa demais e ainda assim não é abrangente o suficiente

• Benchmark/eval já é difícil por natureza, e fica ainda mais difícil quando o incentivo para manipular isso em escala industrial é enorme
  O ELT-Bench é um caso recente: foi o primeiro benchmark sério para workloads de engenharia de dados, lançado há cerca de um ano
  Mas dias atrás, um artigo de continuidade com um dos autores originais auditou o benchmark em si e concluiu que os resultados estavam enviesados por problemas estruturais
  O artigo está aqui: https://arxiv.org/abs/2603.29399
  Na verdade, isso nem é novidade; setores anteriores já passaram por tudo isso em escala menor
  Também há um texto sobre o quanto a situação atual se parece com as guerras de benchmarketing em bancos de dados
  https://www.typedef.ai/blog/from-benchmarketing-to-benchmaxx...

  • No fim, a parte mais difícil é separar o benchmark dos dados de treino
    Em BrowseComp plus e outros datasets de deep research aparece um problema parecido, e isso não acontece necessariamente porque labs de fronteira estejam trapaceando, mas porque estão treinando na web inteira
    Datasets novos precisam continuar sendo criados para sempre
  • Benchmarks de banco de dados também são da mesma família
    Pela minha experiência criando um classifier, em algumas tarefas o modelo fica consistentemente melhor que humanos, a ponto de não dar mais para medir precision em si
    Aí esse classifier vira o benchmark state-of-the-art, e passa a não haver comparação possível além dele mesmo
    Se isso acontece até em tarefas complexas menos lógicas e com menos raciocínio contínuo do que programação, talvez em algum momento desapareçam de vez benchmarks calibrados e independentes do objeto medido
  • Então fico me perguntando se o modelo de um benchmark novo por mês conseguiria resolver esse problema

• No fim, acho que estamos recebendo em grande parte os benchmarks que merecemos
  Uma parte considerável dos PRs que passam no SWE-bench provavelmente não seria mergeada na prática: https://news.ycombinator.com/item?id=47341645
  E a pontuação dos modelos de ponta no SWE-bench pode ter sido distorcida por vazamento de git history: https://news.ycombinator.com/item?id=45214670

• Talvez fosse melhor pedir para os próprios modelos topo de linha criarem os benchmarks
  Brincadeiras à parte, o que eu espero mesmo é o ARC-AGI-3, e ao simular humanos ele me pareceu fortemente centrado em raciocínio
  O leaderboard está aqui: https://arcprize.org/leaderboard
  Atualmente, a maioria dos melhores modelos nem passa de 5%

  • Aqui se valoriza minimizar o número de movimentos e não se permite nenhum harness, então o padrão é altíssimo
    Até o melhor modelo validado atualmente, o Claude Opus 4.6, mal chega a 0,45%
    Mas é tudo muito recente, então espero melhora considerável na próxima geração de modelos
  • A ideia de deixar modelos topo de linha criarem o benchmark também não é totalmente absurda
    Dá para fazer o modelo anterior entrevistar o novo, pedir para ambos ou para um terceiro modelo juiz dizer quem é mais inteligente, e repetir isso 100 vezes trocando a seed
    A pontuação poderia ser a proporção de vezes em que ambos concordam que o modelo novo venceu
  • Benchmarks com muito peso em raciocínio parecem uma direção melhor
    São os mais difíceis de manipular
  • Também dá vontade de perguntar se uma IA conseguiria escrever até problemas que outra IA não consegue resolver
    Pensando bem, é meio engraçado

• Benchmarks melhores precisam ter avaliação objetiva, amplitude multidisciplinar e escalabilidade, além de evitar formatos com uma única resposta correta
  O que desenhamos em https://gertlabs.com vai nessa direção e, em geral, tem relação com resolução de problemas via programação

  • Esse benchmark me parece mais preciso do que outros rankings que já vi
    Pela minha experiência, gpt 5.4/5.5 é tecnicamente quase sem falhas, e quando dá problema normalmente é porque a entrada estava ambígua
    Ele costuma lidar bem sozinho com issues durante correção de bugs ou implementação, e tende a concluir o trabalho sem deixar pontas soltas
    Já o Opus me parece um pouco superestimado em capacidade técnica
    Ele tem um senso melhor de designer/desenvolvedor para construir UX bonita, mas para validar trabalho eu acabo sempre recorrendo ao gpt 5.5
    O resultado mais surpreendente foi o do Xiao-Mi; ainda não usei, mas vendo isso fiquei com vontade de testar
    Parabéns à equipe por criar um referencial significativo nessa corrida caótica da IA
  • É interessante que a linha Claude Code continue muito à frente dos outros modelos em C++ e Java, enquanto o GPT 5.5 aparece melhor em Python e JS
    Parece revelar viés no dataset de treino ou diferença de foco go-to-market, e talvez seja resultado de a Anthropic estar mais voltada a clientes enterprise do que a OpenAI
    Isso também bate com a minha experiência usando Opus em C++
    Mas os resultados de C# estão vazios; @gertlabs, existe alguma ETA para isso?
  • Nesse benchmark, o Deepseek V4 pro parece ir pior que o Deepseek V4 flash, o que é um resultado bem interessante
    Fiquei curioso para saber por que isso aconteceu

• Isso ia acabar acontecendo de um jeito ou de outro, orgânico ou não
  É fácil cair na lógica de que basta ir bem em pontuação de benchmark, mesmo que isso não generalize fora dali
  Outro caso parecido que isso me lembra é Graduate student descent
  https://sciencedryad.wordpress.com/2014/01/25/grad-student-d...

• Olhando para trás, talvez o SWE-bench nunca tenha sido tudo isso
  Ao longo de 2025 inteiro, a taxa de modelos produzindo bom código praticamente não melhorou; a interpretação mais plausível parece ser que só melhorou a capacidade de passar em testes automatizados
  https://entropicthoughts.com/no-swe-bench-improvement

  • Acho difícil concordar com a ideia de que não houve nenhuma melhora na qualidade do código
    Em janeiro de 2025, Claude 3.5 Sonnet, Gemini 1.5 Pro e GPT-4o da OpenAI eram os principais modelos, e tendo usado todos eles e também os modelos de ponta atuais, para mim é claro que os modelos de hoje deram um salto importante
  • Essa interpretação tem boa chance de estar certa
    A qualidade dos modelos parece ter estagnado, e encontrar novos vetores de melhoria claramente não é fácil
    A expansão em largura dos modelos, que vinha puxando o ritmo de avanço até agora, também parece estar chegando ao limite, então fico curioso sobre as implicações disso daqui para frente
    No longo prazo, há limite até para o quanto tooling consegue resolver
  • Ainda assim, o aumento na taxa de aprovação em testes automatizados é uma fonte enorme de produtividade em programação
    Esse é um dos motivos de a Anthropic ser avaliada em dezenas de bilhões de dólares
    O SWE-bench foi útil para coding justamente porque engenharia de software tem tradição e infraestrutura muito fortes para criar e usar testes automatizados
  • Talvez seja por isso que os modelos de precificação das empresas estejam ficando mais restritivos e caros

• O que o artigo diz, pelo que entendi, é que ao auditar o subconjunto de 27,6% que os modelos frequentemente não resolviam, encontraram testes defeituosos em pelo menos 59,4% dele, testes esses que rejeitavam submissões funcionalmente corretas
  Se isso for verdade, parece que uma parte grande dos problemas e gabaritos esteve errada esse tempo todo, então fica a dúvida de como isso pôde ser uma medição válida
  Pela descrição do processo de criação do benchmark, o padrão parecia bastante alto, então também é difícil entender como esse procedimento resultou em dados de qualidade tão ruim
  É louvável que tenham exposto o problema por conta própria, mas ainda deixa muitas perguntas

  • Isso não significa que um quarto do total esteja errado; parece significar que, dentro do subconjunto de 27,6%, 59,4% tinham testes defeituosos
    E por razões práticas, um benchmark nunca vai representar perfeitamente o seu caso de uso, nem todos os casos de uso
    Ele só é válido para medir os itens que contém, nada além disso
    É por isso que eu não entendo a obsessão do ecossistema por benchmarks públicos
    Por exemplo, o fato de o Qwen 3.5 ser 50% melhor que o Qwen 2.5 no Benchmark X quase não garante que ele seja 50% melhor nas tarefas que eu uso
    Eu venho construindo benchmarks privados continuamente, ajustando os prompts com base em casos reais em que os modelos falharam no meu uso
    Mesmo quando sai atualização de modelo, no meu benchmark o movimento costuma ser de 2% a 3%, enquanto em benchmarks públicos divulgam altas de 30% a 40%, então é difícil acreditar que não haja contaminação de dados de treino
  • O ImageNet também é um dos datasets mais famosos do mundo, mas tem bastante imagem rotulada incorretamente
    Em casos extremos, pode até surgir uma faixa em que, para marcar mais pontos, é melhor seguir a resposta errada
    No fim, a resposta é que ML é uma área em que as coisas tentam funcionar de qualquer maneira, então mesmo com defeitos dá para ir surpreendentemente longe
    E isso também explica por que apontar um defeito que ninguém viu pode gerar um grande avanço
  • Se a finalidade for distinguir qual modelo é melhor, basta que a pontuação do benchmark tenha correlação com desempenho real
    Se a maioria das tarefas for corrigida corretamente, a direção geral pode continuar válida
    Por exemplo, mesmo que 49% dos rótulos de um benchmark péssimo estejam errados, se um modelo sempre acerta receber 51% e um modelo sempre errar receber 49%, o ranking ainda estará correto
    A maioria dos benchmarks de machine learning tem uma quantidade nada pequena de rótulos errados, mas se o objetivo é diferenciar modelos, normalmente vale mais a pena reunir um dataset maior do que gastar tempo garantindo correção perfeita
  • Em resumo, isso parece querer dizer que há problema em algo como 16% dos problemas