O modelo que venceu o benchmark de código real errou 6 de cada 10 tarefas

A demo não tem legado, e agora existe um número desenhado para medir exatamente essa distância: o modelo que ficou em primeiro lugar errou 6 de cada 10 tarefas. Em setembro, a Specific Labs publicou o Real-SWE, um benchmark que testa modelos de ponta em código real, licenciado, de empresas que existem — não em quebra-cabeça público escrito para parecer difícil. Organizei o que os números dizem por tipo de falha, não por modelo, porque é isso que muda o argumento de quem decide orçamento.

O que o Real-SWE testa que os outros benchmarks não testam

Cada tarefa do Real-SWE vem de um sistema privado de produção que a empresa licenciou de verdade — entre eles, um concorrente do Luma/Partiful com mais de 200 mil usuários e top 100 na App Store, uma fintech de consumo que processa mais de 100 mil extratos bancários e uma plataforma de vendas corporativa com fluxo de trabalho complexo. A instrução típica tem 1.742 caracteres — na mesma faixa dos concorrentes FrontierCode (2.056) e DeepSWE (1.975), então não é o enunciado que fica mais difícil. É o sistema por trás dele.

Isso importa porque a maioria dos benchmarks públicos usa problema sintético ou código aberto — que pode estar, sem ninguém saber, no material de treino do próprio modelo. Código privado licenciado é nativamente fora dessa distribuição: o modelo nunca viu aquela convenção de nomes, aquela regra de negócio, aquele jeito específico de calcular imposto. É a primeira vez que vejo um benchmark medir capacidade contra sistema em produção com histórico real, em vez de contra prova de vestibular de programação — a mesma distinção que separa número de marketing de resultado medido que já apareceu aqui noutro contexto.

O placar: 38,8% no topo, 16,2% no fim — e o vencedor ainda erra 6 em cada 10

A métrica é taxa de resolução — o percentual de tentativas em que o agente resolveu a tarefa corretamente, medido como pass@1 (acerto já na primeira tentativa) e calculado pela média de oito rodadas independentes por tarefa. O placar completo, cada modelo com sua ferramenta de execução (harness) nativa:

O Fable 5.1 venceu com 38,8% rodando sobre o harness Claude Code, que já analisei aqui por outro ângulo — o que quer dizer que, mesmo no topo da tabela, o modelo falhou em pouco mais de 6 de cada 10 tentativas. O Real-SWE também mede o solto na mão do juiz: a solução de referência de cada tarefa mexe numa mediana de 11 arquivos, quase o dobro dos 6 arquivos que a Cognition publicou como mediana para o FrontierCode e o DeepSWE, dois benchmarks concorrentes. Mais arquivo tocado por tarefa é o retrato de manutenção real — mexer numa função sem quebrar quem depende dela em outro lugar do sistema.

Dar mais tempo não ajuda. O gargalo não é paciência, é contexto

Se o problema fosse falta de raciocínio, rodar o agente por mais tempo deveria melhorar o resultado. Não melhora: tarefas resolvidas em menos de 10 minutos falharam em 70,4% dos casos (76 de 108); tarefas que passaram de 10 minutos falharam em 72,4% (385 de 532) — praticamente o mesmo índice, segundo os próprios dados publicados pela Specific Labs. Rodar mais tempo não empurra o placar porque o problema não é tempo de raciocínio, é conhecimento que não está em lugar nenhum acessível ao modelo: como este time nomeia coisas, onde mora a regra de negócio, o que já foi tentado e não funcionou.

A própria Specific Labs chega perto dessa conclusão: "hoje os modelos são mais fracos em entender os padrões de código da empresa e com frequência erram requisitos ou não verificam as próprias suposições". É a mesma distância que aparece toda vez que um agente escreve código correto sintaticamente e errado contra a convenção que ninguém documentou — o tipo de erro que só aparece quando alguém revisa, não quando o agente termina de rodar.

O que muda para quem decide orçamento de ferramenta de código

O próprio Real-SWE avisa que a amostra pública são 10 tarefas de um conjunto maior, ainda não divulgado — vale tratar o placar como direção, não como decimal definitivo. Ainda assim, a condição de teste está declarada com um detalhe que a maioria dos benchmarks de fornecedor omite: reasoning no nível mais alto disponível, harness nativo por modelo, oito rodadas por tarefa. É possível saber exatamente o que o número mede.

Com gente sem formação técnica publicando código gerado por IA em volume recorde, esse número importa além do time de engenharia. Para quem decide orçamento de ferramenta de código, o número que importa não é o do topo da tabela — é o complemento dele. Se o melhor modelo erra 6 em cada 10 tarefas reais mesmo com todo o tempo de execução que quiser dar, o orçamento que precisa existir não é o da licença: é o de revisão humana por trás de cada tarefa que o agente entrega como pronta. Comprar a ferramenta pelo número da demo e não orçar essa revisão é a forma mais garantida de descobrir, na prática, que o custo aparece no incidente, não na planilha de licença.

Marta respondeu a esta peça: concorda com o diagnóstico do Real-SWE, discorda de tratar revisão humana como item de orçamento — leia a réplica.