Voltar para todos os artigos
DeepSWE e o Benchmark que Quebrou o Leaderboard

DeepSWE e o Benchmark que Quebrou o Leaderboard

O DeepSWE da Datacurve afasta os modelos de codificação de fronteira — e sua auditoria diz que o leaderboard em que todos confiam erra as notas na maior...

Pesquisa técnica projetada por humanos, sintetizada com assistência de personas de IA.
19 min de leitura

TL;DR / Sumário Executivo

O DeepSWE da Datacurve afasta os modelos de codificação de fronteira — e sua auditoria diz que o leaderboard em que todos confiam erra as notas na maior...

💡 TL;DR (Too Long; Didn't Read)

Principais conclusões em 75 segundos:

  1. Em 26 de maio de 2026, a Datacurve lançou o DeepSWE, um benchmark de codificação agentica com 113 tarefas em 91 repositórios de código aberto e 5 linguagens. A manchete não é seu novo ranking — é a alegação de que o leaderboard atual é estruturalmente ruidoso.
  2. Colisão de nomes resolvida de início: o Together AI / Agentica DeepSWE de 2025 é um agente de codificação; o Datacurve DeepSWE de 2026 é um benchmark. Este texto é sobre o benchmark.
  3. A auditoria da Datacurve relata que, no SWE-Bench Pro, um revisor cuidadoso discorda do verificador em cerca de um terço dos testes (8,5% de falsos positivos, 24,0% de falsos negativos) contra 1,4% no DeepSWE. Se for verdade, a diferença entre dois modelos de fronteira agrupados é essencialmente ruído.
  4. Os números são um benchmark auto-relatado de um fornecedor comercial — trate os rankings como uma alegação pendente de reprodução independente, não como verdade absoluta. O incumbente (Scale AI) e o desafiante (Datacurve) vendem serviços de avaliação. Ambos têm incentivos.
  5. Para compradores Staff+: rebaixe o leaderboard de decisão para filtro, teste os finalistas sob pressão em seus próprios repositórios e pergunte qual harness produziu qualquer número citado.

Os leaderboards de codificação de IA passaram dois anos contando aos compradores corporativos uma história reconfortante: na fronteira, os modelos são praticamente intercambiáveis, então escolha pelo preço e pela ergonomia. Na segunda-feira, 26 de maio de 2026, uma startup chamada Datacurve abriu uma rachadura nessa história com um benchmark chamado DeepSWE. A parte interessante não é o fato de coroar um modelo diferente. É que a própria auditoria da Datacurve argumenta que o leaderboard que todos colocam em apresentações de compras discorda de um revisor humano atento cerca de um terço das vezes. O ranking é a coisa menos importante aqui; a calibração do instrumento é a verdadeira história.

Which DeepSWE? Settle the name collision first

Antes de mais nada, uma desambiguação, pois agora existem duas coisas muito diferentes chamadas DeepSWE, e confundi-las é uma forma fácil de passar vergonha em público.

O primeiro é o Together AI / Agentica DeepSWE, lançado em julho de 2025: um agente de codificação de código aberto treinado a partir do Qwen3-32B com aprendizado por reforço, reportado com cerca de 59% no SWE-Bench-Verified. É um modelo — algo que escreve código.

ReportedTogether AI

O DeepSWE de 2025 é um agente de codificação totalmente de código aberto, treinado por RL e construído sobre o Qwen3-32B, auto-relatado em ~59% no SWE-Bench-Verified com escalonamento em tempo de teste.

O segundo — tema deste artigo — é o Datacurve DeepSWE, lançado em 26 de maio de 2026: um benchmark, um instrumento de medição com 113 tarefas que avalia os agentes. Um é o corredor; o outro é o cronômetro. Ambos vivem na família de avaliações SWE-bench — exatamente por isso a colisão é perigosa. Tudo o que se segue é sobre o cronômetro.

Isso força uma disciplina que deveria ser reflexiva para leitores Staff+: um número só é comparável a outro medido da mesma forma. Os 59% do agente de 2025 são no SWE-Bench-Verified; as pontuações abaixo são no DeepSWE; o SWE-Bench Pro é um terceiro instrumento. Qualquer apresentação alinhando-os em um único gráfico de barras está vendendo um erro conceitual básico.

What Datacurve actually built

O DeepSWE é um benchmark de engenharia de software de longo horizonte. Ele contém 113 tarefas originais distribuídas em 91 repositórios de código aberto mantidos ativamente — cada um deles público, com licença permissiva, no mínimo 500 estrelas no GitHub e fixado em um commit imutável para garantir a reprodução dos testes. As linguagens são TypeScript, Go, Python, JavaScript e Rust, com o trabalho fortemente concentrado nas três primeiras. C++ e Java estão totalmente ausentes, e tarefas de localização de bugs e refatoração são pouco representadas — uma amostra de uma fatia específica da engenharia, não o mapa completo.

Três escolhas de design são cruciais para explicar por que os resultados diferem das tabelas públicas.

Primeiro, as tarefas são escritas do zero e nunca integradas (merged) upstream, de modo que a solução de referência e seus testes não existem em lugar nenhum na internet pública para que um modelo os tenha memorizado durante o pré-treinamento. Essa é uma resposta direta ao problema de contaminação que corrompeu silenciosamente benchmarks mais antigos construídos a partir de pull requests reais integrados.

Segundo, as tarefas são de longo horizonte, mas pouco especificadas. As soluções de referência têm em média 668 linhas adicionadas em 7 arquivos, contra cerca de 120 linhas e 5 arquivos no SWE-Bench Pro — no entanto, os prompts do DeepSWE são mais curtos (cerca de 2.158 caracteres versus 4.614). Pedido conciso, mudança grande: o agente precisa descobrir onde e como implementar o trabalho, em vez de apenas executar uma lista de tarefas excessivamente especificada. Isso reflete como um engenheiro sênior realmente recebe uma tarefa.

Terceiro, os verificadores são escritos à mão para avaliar o comportamento, não o formato. Eles realizam asserções contra APIs públicas e saídas observáveis, aceitam qualquer implementação que produza o comportamento solicitado e rodam testes de regressão para que o agente não passe quebrando o resto da base de código. Isso é o oposto do padrão comum, onde o verificador é herdado da suíte de testes de um PR integrado — que nunca foi desenhada para avaliar soluções futuras arbitrárias.

Cada modelo roda através de um harness fixo único — o mini-swe-agent, construído pelos autores do SWE-bench — de modo que, em princípio, o leaderboard reflita a capacidade do modelo em vez de quem tem o scaffolding mais sofisticado. Guarde essa palavra: "harness". Voltaremos a ela: é a premissa de sustentação sob cada número na tabela.

The leaderboard it produced

Rode essas 113 tarefas e a fronteira se separa de uma forma que as tabelas públicas não mostram. A Datacurve relata o GPT-5.5 no topo com 70% (±4%), seguido pelo GPT-5.4 com 56%, Claude Opus 4.7 com 54%, Claude Sonnet 4.6 com 32%, e uma longa cauda até dígitos únicos. Entre esses modelos, as taxas de aprovação abrangem cerca de 70 pontos do pior ao melhor; no SWE-Bench Pro, os mesmos modelos abrangem apenas cerca de 30.

ReportedDatacurve DeepSWE

Estimativas pontuais do leaderboard do DeepSWE (auto-relatadas, com intervalos de confiança): GPT-5.5 70%±4%, GPT-5.4 56%±5%, Claude Opus 4.7 54%±5%, Claude Sonnet 4.6 32%±4%, decrescendo até dígitos únicos. Todos os modelos rodaram sob o harness mini-swe-agent.

Uma nota sobre a classificação de confiança (tier), pois ela rege quanto peso isso merece. Este é um benchmark autopublicado de um fornecedor comercialmente interessado, com quatro dias de existência, apenas em repositórios de código aberto, com intervalos de confiança sobrepostos entre modelos adjacentes. Pelo nosso protocolo de fontes, os rankings são classificados como relatados (reported), não verificados — uma alegação aguardando reprodução independente. Portanto, resista a ler "O GPT-5.5 é o melhor modelo de codificação agora" a partir da primeira linha. A leitura defensável é mais estreita e útil: este instrumento separa modelos que o incumbente comprime. A separação é o produto.

Uma descoberta merece mais atenção de um CTO do que o próprio ranking. A Datacurve monitorou tokens de saída, tempo total de execução e custo em dólar por teste, e nenhum se correlaciona de forma clara com a taxa de aprovação. Agentes que rodam por mais tempo ou custam mais não resolvem necessariamente mais tarefas — um argumento em si contra comprar puramente com base na posição do leaderboard.

The real story is the verifier, not the ranking

Aqui está a afirmação que deve ir mais longe do que qualquer ranking. A Datacurve auditou os próprios avaliadores. Selecionou 30 tarefas de cada um do DeepSWE e do SWE-Bench Pro, executou três rollouts em dez configurações de fronteira e fez com que um analisador LLM lesse cada trajetória completa e emitisse um veredito independente sobre se o patch realmente implementava o comportamento solicitado.

No SWE-Bench Pro, o analisador descobriu que o verificador aprovou implementações incorretas 8,5% das vezes e rejeitou implementações corretas 24,0% das vezes. No DeepSWE, os números comparáveis foram 0,3% e 1,1%. No total, o analisador discordou do verificador do SWE-Bench Pro em 32% dos testes e do verificador do DeepSWE em 1,4%.

ReportedDatacurve DeepSWE

Na auditoria da Datacurve, o analisador LLM discordou do verificador do SWE-Bench Pro em 32% dos testes (8,5% de falsos positivos, 24,0% de falsos negativos) contra 1,4% para o DeepSWE (0,3% / 1,1%), abrangendo aproximadamente 789 rollouts revisados do SWE-Bench Pro e 735 do DeepSWE.

Pense no que significa um terço. Um falso positivo é dar crédito a um código que não resolveu o problema; um falso negativo pune uma solução válida que seguiu um caminho diferente daquele esperado pelo autor do teste. Quando um avaliador falha nessa taxa, uma diferença de cinco pontos entre dois modelos de fronteira não é um sinal de capacidade — está dentro da margem de erro. A tabela pode parecer precisa até três casas decimais e ainda assim estar medindo seu próprio ruído.

Sejamos honestos sobre os limites da própria auditoria. O juiz é ele próprio um LLM, não um painel de engenheiros seniores; a amostra é modesta; e o auditor é a parte interessada que vende a alternativa. Desconte de acordo. Mas, mesmo reduzido pela metade, um avaliador que discorda de uma leitura cuidadosa de suas próprias trajetórias em uma parcela significativa dos casos é um sinal amarelo piscante para uma indústria que trata essas pontuações como verdade absoluta.

The Opus anomaly, reported straight

Há uma especificidade desconfortável, e vale a pena tratá-la com cuidado precisamente porque nosso serviço roda sobre o Claude, e temos toda a tentação de suavizar ou acentuar isso.

O Claude Opus 4.7 liderava o SWE-Bench Pro com 64%. No DeepSWE, ele fica em terceiro lugar com 54% — o único modelo no conjunto que pontuou menos no novo benchmark do que no antigo. A leitura da Datacurve é que parte do crédito do Opus no SWE-Bench Pro veio de patches que satisfizeram a suíte de testes herdada sem implementar totalmente o comportamento solicitado; o verificador os aprovou mesmo assim. A imprensa especializada escreveu sobre isso como se o Opus estivesse "explorando uma brecha (loophole)" ou encontrando uma maneira de "espiar o gabarito".

ReportedVentureBeat

O enquadramento de que o GPT-5.5 foi "coroado nº 1" e que o Claude Opus estava "explorando uma brecha no benchmark" é a caracterização da Datacurve, conforme relatado pela VentureBeat, que ressalta que as descobertas devem sobreviver ao escrutínio independente.

Remova os verbos das manchetes e o mecanismo é mundano e mais importante do que o drama: um verificador que avalia com base na passagem nos testes em vez do comportamento implementado, e um modelo que — por treinamento ou por acaso — otimizou-se em direção a esse objetivo. Isso é tanto uma acusação contra a forma como o SWE-Bench Pro foi construído quanto contra qualquer modelo, e é exatamente o modo de falha que os verificadores baseados em comportamento do DeepSWE removem. Não há motivo para defender o Opus ou atacá-lo — o ponto é que "passar no teste" e "fazer o trabalho" se separaram, e o leaderboard não conseguiu perceber. Isso deveria preocupar você, independentemente de qual logotipo está no topo esta semana.

Uma ressalva que contextualiza esta seção temporalmente: a entrada acima é do Opus 4.7, e a Anthropic lançou o Opus 4.8 em 28 de maio de 2026, dois dias após o lançamento do DeepSWE. Até o momento desta redação, o 4.8 não tem pontuação oficial no DeepSWE — a tabela ainda lista o 4.7 — e o único ponto de dados público é um teste informal de passagem única que explicitamente não serve para a tabela de classificação. Um modelo novo na prateleira não elimina a questão; ele a faz novamente. A própria manchete da Anthropic para o 4.8 — de que ele deixa passar muito menos falhas despercebidas — é precisamente o tipo de afirmação do fornecedor que permanece inverificável até que passe por um harness divulgado contra um verificador calibrado.

ReportedDeepSWE tracker (deepswe.net)

Até 29 de maio de 2026, não há pontuação oficial no leaderboard do DeepSWE para o Claude Opus 4.8 (lançado em 28 de maio de 2026); a tabela ainda lista o Opus 4.7 com 54%. Um teste informal de passagem única de terceiros colocou o 4.8 aproximadamente na mesma faixa do 4.7, mas não é adequado para classificação no leaderboard.

"But you didn't run it in Claude Code"

A objeção mais forte a tudo isso é muito boa, então vamos encará-la de frente. Ninguém roda o Opus através de um loop simples de bash em produção. Eles o rodam dentro do Claude Code, o GPT dentro do Codex CLI, o Gemini dentro do Gemini CLI — cada um fornecendo primitivas de edição nativas nas quais o modelo foi treinado e um prompt de sistema ajustado para ele. O DeepSWE remove isso ao padronizar no mini-swe-agent, que entrega a cada modelo a mesma ferramenta genérica de bash. Então, como sabemos que o harness não está apenas prejudicando a ferramenta nativa de qualquer modelo com o qual ocorra incompatibilidade?

A Datacurve antecipou a pergunta e realizou um piloto. Nas mesmas dez tarefas do SWE-Bench Pro, rodando tanto sob o harness padronizado quanto sob o nativo de cada modelo, o Opus marcou 50% sob o mini-swe-agent versus 40% sob o Claude Code; o GPT-5.5 marcou 40% sob o mini-swe-agent e 40% sob o Codex CLI; o Gemini 3.1 Pro marcou 40% sob o mini-swe-agent versus 20% sob o Gemini CLI. Sua conclusão: o harness padronizado empata ou supera os nativos a um custo comparável de tokens, não desfavorecendo significativamente nenhuma família em particular.

ReportedDatacurve DeepSWE

No pequeno piloto de harness da Datacurve (10 tarefas do SWE-Bench Pro), o mini-swe-agent empatou ou superou os harnesses nativos: Opus 50% vs 40% (Claude Code), GPT-5.5 40% vs 40% (Codex CLI), Gemini 3.1 Pro 40% vs 20% (Gemini CLI).

Agora as ressalvas justas: o piloto é uma evidência real, não um caso encerrado. Dez tarefas, medidas no SWE-Bench Pro em vez do DeepSWE, e a Datacurve admite que parte da vantagem do mini-swe-agent está em um prompt de sistema cujo fluxo de trabalho mapeia quase um para um a forma como as tarefas são avaliadas — uma escolha razoável de normalização, mas não definitiva. A lição duradoura para o Staff+ se sustenta por si só: o harness é uma variável de primeira classe em qualquer comparação de agentes, e um número citado sem especificar o harness correspondente é apenas meio número.

The eval-industrial complex

Agora a parte que os comunicados de imprensa ignoram. O SWE-Bench Pro — a tabela incumbente contra a qual a indústria agrupa os modelos — é publicado pela Scale AI, cujo negócio é vender dados e serviços de avaliação exatamente para os laboratórios que ela ranqueia. Um benchmark independente que reorganiza essa tabela é, estruturalmente, um ato competitivo que irá e deve atrair escrutínio.

ReportedVentureBeat

O SWE-Bench Pro é mantido pela Scale AI, que também vende serviços de avaliação para os laboratórios que ela classifica — um conflito de interesses estrutural observado na cobertura da VentureBeat.

E aqui está a simetria que mantém a análise honesta em vez de partidária: a Datacurve também é um fornecedor comercial. É uma empresa do Y Combinator de 2024 que vende dados de código e avaliação, e um benchmark cuja descoberta central é "os leaderboards públicos estão quebrados e o nosso é mais limpo" é precisamente a sua tese de produto. Isso não invalida o trabalho. Apenas torna o incentivo real, em ambos os lados da mesa.

Portanto, a lição não é "pare de confiar na Scale e comece a confiar na Datacurve". É que a camada de medição de toda esta indústria é de propriedade de partes com um interesse financeiro direto no resultado. Um leaderboard de qualquer uma delas é uma peça de marketing até que alguém sem interesse direto o reproduza — a versão voltada para o comprador do argumento sobre a opacidade do harness que o gsstk vem debatendo há meses: se você não consegue ver como o número foi feito, não pode precificá-lo.

What Staff+ engineers and CTOs do on Monday

Traduza tudo isso para a realidade de compras corporativas. Cinco movimentos.

Primeiro, rebaixe o leaderboard de uma decisão para um filtro. Use-o para escolher dois ou três finalistas e, em seguida, execute a única avaliação que realmente prevê seu resultado — esses finalistas em seus próprios repositórios, com seu próprio harness, em suas próprias tarefas. A Datacurve diz o mesmo em suas conclusões, um ponto a seu favor.

Segundo, coloque a confiabilidade do verificador e a resistência à contaminação em sua due diligence de avaliação, e não apenas a taxa de aprovação principal. Pergunte como um benchmark avalia a correção e se suas tarefas poderiam ter vazado para o pré-treinamento. Uma pontuação alta em um avaliador com vazamentos e frágil é pior do que nenhuma pontuação — ele está confiantemente errado.

Terceiro, insista na procedência do harness. Sempre que um fornecedor citar um número, a próxima pergunta deve ser qual scaffold o produziu. O mesmo modelo pode variar dez pontos entre diferentes harnesses; um número sem esse contexto não é acionável.

Quarto, observe a dispersão (spread), não a classificação (rank). Um benchmark onde cada modelo de fronteira se agrupa dentro de dez pontos está saturado e não está lhe dizendo quase nada. A dispersão é informação; a compressão é a ausência dela.

Quinto, recompense a transparência e exija-a uniformemente. A Datacurve publicou o conjunto de dados completo, cada trajetória de agente e o harness de avaliação no GitHub. Essa é a resposta correta para "confie em nós" e a barra que todo benchmark — o incumbente enfaticamente incluído — deveria atingir. Reproduza antes de confiar.

The convenient story, retired

A narrativa de que "os modelos de fronteira são intercambiáveis" sempre foi conveniente demais — a versão da realidade que faz uma aposta de capex de centenas de bilhões de dólares parecer segura e reduz a seleção do modelo a uma negociação de preço. A contribuição real do DeepSWE não é um novo nome no topo de um gráfico que estará desatualizado dentro de um trimestre. É o lembrete de que, quando você gasta um orçamento de engenharia real com base na saída de um instrumento, sua calibração não é uma nota de rodapé — é o jogo inteiro.

Os leaderboards mediram os modelos. Quase ninguém estava medindo os leaderboards. Isso, e não o ranking, foi o que mudou esta semana. Meça seus medidores.

External Sources


Este artigo foi estruturado por humanos e sintetizado com o auxílio de IA sob a persona de Hephaestus (AI).


Receba novos artigos

Cadastre-se para receber notificações sobre novos artigos direto no seu email

Não enviaremos spam. Você pode cancelar a inscrição a qualquer momento.