SWE-Duel: agentes de código criam bugs uns para os outros, e o GPT-5.5 corrige 98,3%

Benchmarks estáticos de programação envelhecem rápido: as tarefas acabam nos conjuntos de treinamento, e os agentes mais fortes esbarram no teto da avaliação. Os autores do preprint SWE-Duel (arXiv cs.CL) propõem outra abordagem: uma avaliação sem nenhum conteúdo preparado de antemão. Dois agentes se revezam criando tarefas um para o outro e verificando o trabalho do adversário. O torneio de 1500 turnos reuniu 11 combinações de «modelo + harness» em 15 repositórios e cinco linguagens. Em primeiro lugar ficou o GPT-5.5 com Codex CLI, que corrige 98,3% dos defeitos que chegam a ele para revisão.

Como funciona um turno do duelo

Em cada turno, o agente Red trabalha em um repositório real, em três sessões com contextos isolados entre si. Primeiro, ele inventa e implementa uma nova funcionalidade, junto com os testes dela. Depois, insere um bug sutil nessa funcionalidade e escreve testes lacrados que detectam esse bug. O resultado é um pull request.

A tarefa só entra no conjunto se atender a duas condições. Primeiro, o PR passa nos testes da funcionalidade e nos testes já existentes do repositório, e falha exatamente nos testes do bug. Segundo, uma sessão nova do mesmo agente precisa corrigir o bug às cegas. A segunda condição elimina tarefas sem solução: se o próprio autor não consegue corrigir a armadilha que plantou, ela não conta.

Em seguida, entra em cena o Blue. Ninguém avisa que há um bug no PR; ele simplesmente faz a revisão. A vitória só é computada se a correção dele passar nos três conjuntos de testes. Depois disso, os agentes trocam de papel. Assim, a dificuldade não fica fixada no lançamento: ela cresce junto com a força dos participantes.

Quem vence e como

Os líderes vencem de maneiras diferentes. Os autores destacam dois perfis: o melhor solucionador e o melhor criador de tarefas.

• GPT-5.5 + Codex CLI: primeiro lugar, melhor solucionador, corrige 98,3% dos defeitos verificáveis.
• Claude Opus 4.8 + mini-swe-agent: segundo lugar, melhor criador de tarefas, taxa de vitórias de Red de 27,3%.
• Escala do torneio: 11 participantes, 15 repositórios, cinco linguagens, 1500 turnos.
• Dentro de uma mesma família de modelos, as tarefas da versão mais nova vencem um solucionador de referência fixo em 42,9% dos casos, contra 4,0% das tarefas das versões antigas.

O último número talvez seja o mais interessante. Ele indica, de forma preliminar, que a dificuldade das tarefas cresce junto com a capacidade do modelo de criá-las. Para um benchmark que precisa «crescer sozinho», essa é a propriedade central. Se isso se confirmar em mais famílias, o teto de saturação deixa de ser um problema: criadores mais fortes passarão a preparar automaticamente provas mais difíceis.

Vale lembrar também que os participantes aqui são pares de «modelo + harness». O ranking mede a qualidade da combinação inteira, e não apenas dos pesos do modelo. Os próprios autores classificam como preliminar o resultado sobre o crescimento da dificuldade, uma ressalva honesta: os dados vêm de um único torneio.

O que dá para aplicar na prática

A ideia pode ser usada mesmo sem uma arena com 11 participantes. Uma equipe que está escolhendo um agente de código pode rodá-lo no próprio repositório seguindo o esquema do duelo. O agente escreve uma funcionalidade com testes e esconde um bug, e um segundo agente, ou uma sessão nova, tenta encontrá-lo e corrigi-lo. Um leaderboard público não mostra isso: nas suas tarefas, ele pode já estar «embutido» no treinamento dos modelos.

As conclusões práticas são estas. Separe as métricas: a capacidade de corrigir código alheio e a de criar tarefas difíceis medem habilidades distintas, e os líderes em cada uma não coincidem. O filtro de admissão de tarefas (passa em todos os testes, exceto o do bug, e é resolvível às cegas) merece ser adotado como um modelo próprio de controle de qualidade em qualquer avaliação sintética. E, ao comparar produtos, olhe para a combinação específica de modelo e harness, e não apenas para o nome do modelo.