SWE-bench: o teste que mede se a IA consegue corrigir issues reais de projetos no GitHub

O SWE-bench entrega a um modelo de IA um repositório Python de verdade e a descrição de um bug relatado no GitHub, e verifica se a correção proposta passa nos testes do próprio projeto. Virou o número-padrão dos anúncios de modelos de programação porque se parece com o trabalho de um desenvolvedor. Ao fim deste texto, você vai saber como uma tarefa é montada e corrigida, por que duas notas do mesmo modelo divergem e por que a OpenAI, parceira na criação do Verified, deixou de reportá-lo.

Por que o SWE-bench existe

O SWE-bench parte da pergunta que dá título ao artigo: um modelo de linguagem consegue resolver issues reais do GitHub? Em vez de um enunciado curto e isolado, o modelo recebe uma base de código inteira que não conhece. O problema a resolver foi relatado por usuários reais do projeto.

O artigo saiu no arXiv em 10 de outubro de 2023 e foi aceito no ICLR 2024. Os autores são Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press e Karthik Narasimhan. Eles assinam pela Princeton Language and Intelligence, pela Universidade de Princeton e pela Universidade de Chicago.

O conjunto original tem 2.294 tarefas tiradas de 12 repositórios Python populares. A escala do problema explica a dificuldade. Em média, cada repositório tem cerca de 3.010 arquivos que não são de teste e 438 mil linhas. A descrição do problema tem 195,1 palavras, e a correção oficial muda 32,8 linhas em 1,7 arquivo.

Hoje o site swebench.com reúne uma família de projetos dos mesmos mantenedores. Há placares para as versões Verified, Multimodal, Multilingual, Lite e a completa. Há também ferramentas como o SWE-agent, o mini-SWE-agent e o SWE-smith. Em setembro de 2025 saiu o SWE-bench Pro, um benchmark à parte cujo placar público é mantido pela Scale AI, que herda a ideia e tenta corrigir os defeitos dela.

Como é uma tarefa

Cada tarefa nasce de um par real: uma issue do GitHub e o pull request que a resolveu. Para chegar às 2.294 tarefas, os autores coletaram cerca de 90 mil pull requests. Depois ficaram só com os que foram aceitos, resolviam uma issue e mexiam em arquivos de teste. Por fim, executaram tudo e descartaram os casos com erro de instalação ou sem nenhum teste que mudasse de resultado com a correção.

O próprio artigo usa como exemplo a tarefa sphinx-doc__sphinx-8713, do gerador de documentação Sphinx. A issue diz que a extensão napoleon formata errado a seção "Other Parameters" das docstrings. O erro acontece quando a opção napoleon_use_param está ligada, porque essa seção ignora a configuração que as outras respeitam.

O modelo recebe o texto da issue e o código do repositório no estado anterior à correção. Ele precisa achar o arquivo e a função responsáveis, entender a regra de configuração e escrever a mudança. O que ele entrega é um patch, ou seja, um diff que o avaliador aplica sobre o código. Ninguém lê o patch para dar a nota: quem decide são os testes que os mantenedores do Sphinx escreveram no pull request original.

Nesse exemplo, o modelo errou de um jeito instrutivo. Ele editou a função certa, mas a fez se comportar como se a opção estivesse sempre ligada, sem consultar a configuração antes. O teste test_parameters_with_class_reference pegou a falha. Achar o lugar certo do código não basta: a correção tem de respeitar o comportamento esperado em todos os casos.

Como a nota é calculada

A métrica se chama % resolved: a porcentagem de tarefas resolvidas. Cada tarefa vale 1 ou 0, sem crédito parcial. A escala vai de 0% a 100%, e a nota de um placar é a média simples sobre o conjunto avaliado.

Para contar como resolvida, a tarefa passa por dois grupos de testes. Os FAIL_TO_PASS falhavam no código original e passam com a correção oficial, e por isso provam que o bug foi resolvido. Os PASS_TO_PASS já passavam antes e precisam continuar passando, para provar que nada quebrou. O patch do modelo só ganha o ponto se todos os testes dos dois grupos passarem.

A referência é a própria correção do mantenedor, que por construção passa nos dois grupos de testes. No conjunto original, cada tarefa tem em média 9,1 testes FAIL_TO_PASS e 120,8 testes no total. Isso dá a medida do que o patch precisa acertar e do muito que ele não pode quebrar.

No Verified, as 500 tarefas vêm com uma estimativa do tempo que um engenheiro levaria. Segundo a Vals.ai, 194 levariam menos de 15 minutos, 261 entre 15 minutos e 1 hora, 42 entre 1 e 4 horas e só 3 mais de 4 horas. Ou seja, 455 tarefas, 91% do conjunto, são consertos de até uma hora.

Como o teste é rodado

O modelo não roda sozinho. Ele trabalha dentro de um harness, o programa que monta o ambiente, entrega a tarefa, executa os testes e registra o resultado. Muitas vezes há também um scaffold, a camada de agente que decide quais ferramentas o modelo pode usar e em quantos passos. Em 2023, o artigo usou um formato sem agente: um sistema de busca escolhia arquivos para colocar no prompt, e o modelo gerava um único patch com decodificação gulosa, sempre a opção mais provável.

Havia duas formas de escolher esses arquivos. Na BM25, uma busca por palavras-chave enchia o contexto com os trechos que pareciam relevantes. Na oracle, o modelo recebia exatamente os arquivos que a correção oficial alterou, o que os autores consideram pouco realista. O Claude 2 resolveu cerca de 1,96% das tarefas na primeira forma e 4,8% na segunda.

As avaliações atuais usam agentes. Na Epoch AI, o modelo trabalha num container Docker Linux sem acesso à rede, num laço simples que o lembra do orçamento restante a cada turno. As ferramentas são bash, um editor de texto e um comando para aplicar patches. O orçamento é de 2 milhões de tokens não cacheados por tarefa, incluindo o raciocínio, e o histórico do git posterior à issue é apagado para o modelo não encontrar a resposta ali.

O placar oficial tem uma visão chamada bash-only. Nela, todos os modelos rodam no mesmo mini-SWE-agent, um agente mínimo que só tem o terminal. Serve para comparar modelos sem a interferência de agentes diferentes. Quando cada equipe usa o próprio agente, o que se compara é o sistema inteiro, não só o modelo.

Por isso duas notas do mesmo modelo raramente batem. Na Vals.ai, o Claude Opus 4.8 fez 85,80% com o Claude Code e 88,60% com o mini-SWE-agent. Também pesam a versão do conjunto, as tarefas excluídas e os limites de passos e tokens. A Epoch roda 484 das 500 tarefas, porque exclui 16 que não rodam de forma confiável na sua infraestrutura. Em 12 de fevereiro de 2026, a versão 2.0.0 da avaliação da Epoch mudou scaffold, ambientes e limites de tokens, o que pede cautela ao comparar notas de antes e depois.

O placar hoje e como chegou aqui

O ponto de partida foi baixo. Em outubro de 2023, o melhor resultado do artigo era o do Claude 2, com cerca de 1,96% no conjunto completo. O GPT-4 resolveu cerca de 1,3% com busca oracle, numa amostra de 25% das tarefas, e o SWE-Llama, ajustado pelos autores, ficou em 0,70%.

Lido em 10/11/2026 pelo agregador BenchLeader, o placar oficial bash-only do Verified mostra o Claude Opus 4.5 (high) em primeiro, com 76,8%, publicado em 17/02/2026. Depois vêm Gemini 3 Flash (high) e MiniMax M2.5 (high), ambos com 75,8%, e Claude Opus 4.6, com 75,6%. São medições dos mantenedores do SWE-bench, não dos laboratórios. Nenhuma entrada é posterior a fevereiro de 2026.

A Vals.ai, uma medição independente, chegou mais longe e depois parou. Em 1º de setembro de 2026, o Claude Opus 5 liderava com 97,00%, seguido do DeepSeek V4 Pro 0813, com 96,40%, e do GPT-5.6 Sol, com 96,20%. A Vals.ai arquivou o teste: segundo ela, o desempenho saturou, e por isso deixou de avaliar novos modelos nele.

A atenção passou para o SWE-bench Pro. No placar público mantido pela Scale AI, lido em 10/11/2026, lideram o Muse Spark 1.1, com 61,50 ± 3,10, o gpt-5.4 (xHigh), com 59,10 ± 3,56, e o Muse Spark, com 55,00 ± 3,60. O claude-opus-4-6 (thinking) vem em quarto, com 51,90 ± 3,61. Essas entradas rodaram com o harness mini-swe-agent, e quase todo o placar usa um limite de 250 turnos.

A trajetória resume a mudança. O melhor resultado publicado saiu de 1,96% no conjunto completo, em 2023, para 97% no Verified, em 2026, segundo a Vals.ai. Num conjunto mais difícil, o Pro público, o líder fica em 61,5%.

O que a nota não diz

A crítica mais documentada é que os testes deixam passar patches errados. Em outubro de 2024, Reem Aleithan e coautores publicaram o estudo SWE-Bench+ sobre as correções que o SWE-Agent com GPT-4 tinha acertado. Em 32,67% delas, a solução já estava escrita na issue ou nos comentários. Em 31,08%, os testes eram fracos demais para confirmar que a correção estava certa.

Quando os autores tiraram essas tarefas, a taxa desse sistema caiu de 12,47% para 3,97%. Eles também apontaram que mais de 94% das issues são anteriores à data de corte do treino dos modelos. Ou seja, o modelo pode ter visto a issue e a correção durante o treinamento.

O Verified nasceu para corrigir parte disso. Revisores humanos checaram se cada descrição era clara, se os testes estavam corretos e se a tarefa tinha solução. Mesmo assim, a Epoch AI classifica o conjunto como "Flawed", defeituoso, e já estimou que de 5% a 10% das tarefas tenham erro.

No início de 2026, a OpenAI, parceira na criação do Verified, anunciou que deixaria de reportá-lo. Segundo o relato do blog Prompt20, a empresa auditou 138 tarefas que o o3 não resolvia de forma consistente. Em 59,4% delas, encontrou problemas sérios no teste ou na descrição.

Pelo mesmo relato, cerca de 35,5% das tarefas auditadas tinham testes que exigiam detalhes de uma implementação específica. Outros 18,8% cobravam um comportamento que a issue nem pedia. A OpenAI também argumentou que as notas passaram a refletir quanto o modelo viu do teste no treino, e recomendou o SWE-bench Pro. O Pro tenta resistir a isso pela escolha dos repositórios: o conjunto público, de 731 tarefas, vem de projetos com licença copyleft. Há ainda um conjunto held-out de 12 repositórios e um comercial com 18 bases fechadas de startups parceiras.

Como ler esse número num anúncio

A primeira pergunta é qual conjunto foi usado. "SWE-bench" num slide pode ser o completo, o Lite, o Verified ou o Pro, e os números não se comparam entre si. O Claude Opus 4.6, por exemplo, tem 75,6% no placar bash-only do Verified e 51,90 no Pro público.

A segunda pergunta é quem mediu e com que harness. O número do laboratório costuma vir do agente que ele escolheu e configurou. O placar bash-only e a Vals.ai usam o mesmo mini-SWE-agent para todos. A diferença de 2,8 pontos do Claude Opus 4.8 entre dois harnesses já é maior do que a distância entre os três líderes da Vals.ai.

A terceira pergunta é sobre o orçamento. Vale saber quantos turnos e tokens o modelo teve, se houve uma ou várias tentativas e se todas as 500 tarefas entraram. O placar do Pro marca em cinza as entradas com custo limitado e teto de 50 turnos, porque elas não se comparam às de 250.

Por fim, olhe o intervalo de confiança. No Pro público, a margem chega a cerca de ±3,6 pontos. Dois modelos a três pontos de distância estão, na prática, empatados. Perto do teto do Verified, diferenças de um ponto dizem mais sobre ruído e gabarito do que sobre capacidade.

Para quem importa

Para quem escolhe um modelo para um agente de código, a nota funciona como filtro grosso. Um modelo muito abaixo do pelotão num teste com harness padronizado dificilmente vai bem num repositório real. O Pro, com tarefas que segundo os autores podem tomar de horas a dias de um engenheiro, separa melhor os modelos de ponta.

A nota não diz como o modelo se sai na sua base de código. O conjunto original é só Python, de 12 projetos abertos, e 91% do Verified são consertos de até uma hora. Ele também não mede revisão de código, desenho de arquitetura, conversa com o time ou qualidade da solução além do que os testes verificam.

Para um gestor, a decisão útil é outra: montar uma avaliação própria no formato do SWE-bench. Pegue issues já resolvidas no seu repositório, volte o código ao estado anterior e veja se o agente faz os testes passarem. Assim a lógica de FAIL_TO_PASS e PASS_TO_PASS passa a medir o trabalho que importa para o seu time.

Glossário

Issue: relato de bug ou pedido de mudança aberto num repositório do GitHub. No SWE-bench, é o enunciado da tarefa.

Patch: arquivo de diferenças (diff) com as linhas a adicionar e remover. É o que o modelo entrega e o avaliador aplica sobre o código.

Harness: o programa que monta o ambiente, roda o modelo na tarefa, executa os testes e registra a nota.

Scaffold: a estrutura de agente em volta do modelo. Ela define as ferramentas disponíveis, o formato dos passos e os limites de turnos.

mini-SWE-agent: agente mínimo dos mantenedores do SWE-bench, que só dá ao modelo um terminal bash. Serve de base comum para comparar modelos.

FAIL_TO_PASS e PASS_TO_PASS: testes que falhavam antes da correção e devem passar depois, e testes que já passavam e devem continuar passando.

Em resumo

• Cada ponto exige que os testes escritos pelos mantenedores do projeto passem com o patch do modelo, sem crédito parcial.
• O melhor resultado subiu de 1,96% no conjunto completo, em 2023, para 97% no Verified em setembro de 2026, segundo a Vals.ai.
• Um estudo de 2024 mostrou que um terço dos acertos de um agente vinha de soluções já escritas na própria issue.
• A OpenAI deixou de reportar o Verified em 2026, citando testes defeituosos e contaminação, e passou a recomendar o SWE-bench Pro.
• No SWE-bench Pro público, o líder fica em 61,5%, com margem de cerca de 3 pontos.
• O harness muda a nota: o mesmo modelo variou 2,8 pontos entre dois agentes.

Explicação escrita por um agente de IA a partir das páginas listadas abaixo e conferida contra elas por uma segunda checagem automática. Placares mudam: veja a data de cada número. Atualizado em 10/11/2026 às 00:30 (Brasília).