Cognition lança FrontierCode 2.0: o melhor resultado é de apenas 45,5%

A Cognition, empresa por trás do agente Devin, publicou o FrontierCode 2.0, a segunda geração de um benchmark que avalia não a aprovação em testes, mas a "mergeabilidade" do código: se o mantenedor de um projeto real aceitaria aquele pull request. O melhor resultado é do Claude Opus 5.5, com 45,5%. Na versão anterior, o FrontierCode 1.1, ele tinha 54,6%. A distância entre os modelos aumentou, e o teto continua longe: o benchmark não está saturado.

Por que a Cognition endureceu o critério

Pela experiência com o Devin, o desenvolvimento agêntico está longe de ser um problema resolvido. Os modelos têm dificuldade para adivinhar a intenção do usuário, violam restrições pouco óbvias e não preveem as consequências de longo prazo das alterações, então um humano precisa intervir. A maioria dos benchmarks de código não captura isso: eles fornecem uma especificação detalhada e saturam rápido. Um exemplo é a tarefa vf2-speedup-networkx, do Terminal-Bench 4.0, que descreve por completo a abordagem, o formato e as condições de verificação, incluindo uma aceleração de no mínimo 5000 vezes.

O FrontierCode funciona de outro modo. Mais de 20 mantenedores de projetos open source dedicaram 40+ horas a cada tarefa, montando-a a partir de seus próprios repositórios. Na versão 2.0, as tarefas vêm de 55% mais repositórios e incluem patches de segurança e otimizações de desempenho. Há 43% mais critérios bloqueantes. As soluções de referência alteram, em média, 67% mais arquivos e 89% mais linhas, e as bases de código são 25% maiores. A Cognition também reforçou a auditoria: em 80% das tarefas, a solução de referência difere do PR upstream (na 1.0, eram 60%). Uma das auditorias automáticas chegou a encontrar uma vulnerabilidade na implementação upstream, e os mantenedores foram avisados.

Tabela: quem perdeu quanto

Abaixo, as notas no formato "FrontierCode 1.1 → FrontierCode 2.0":

• Claude Opus 5.5 — 54,6% → 45,5%. Líder, na fronteira de Pareto, no extremo mais caro.
• GPT-6 Astra — 53,3% → 42,8%.
• Grok 4.7 — 47,6% → 28,6%.
• Gemini 4 Argon — 47,5% → 26,3%.
• Muse Wonder 1.0 — 47,0% → 24,3%.
• SWE-2 — 50,0% → 23,9%.
• DeepSeek V4.1 Flash — 43,9% → 19,3%.
• Kimi K3 — 44,2% → 17,7%.

Na fronteira de Pareto entre custo e qualidade, ao lado do Opus 5.5, estão Luna, Haiku e Sol, no extremo mais barato. A Cognition destaca separadamente o GPT-6.1 Sol pelo forte resultado em relação ao custo. A conclusão sobre os modelos abertos é dura: há muito espaço para crescer, principalmente nos modelos OSS ocidentais.

Minúcia em vez de obediência

A principal mudança é o aumento da participação dos critérios de "thoroughness": o número de bloqueadores desse tipo subiu de 168 para 501, ou seja, triplicou. Eles verificam o que o agente deveria deduzir da instrução e do código, embora não esteja dito de forma explícita. Por exemplo, corrigir o bug em todos os lugares, e não só no que foi citado, ou dar suporte a tipos de entrada vizinhos quando um código parecido já os trata. A taxa de verificações reprovadas nessa categoria subiu de 11,7% para 19,2%, a maior taxa de falhas entre todas as categorias. Para core behavior, são 14,9% contra 9,5%; para compatibilidade retroativa, 5,9% contra 2,9%.

As demais categorias de bloqueadores mudaram assim: core behavior 399 → 353, prevenção de regressões 174 → 259, qualidade dos testes 202 → 213, lint/format/typecheck 112 → 183, scope 56 → 123, compatibilidade retroativa 85 → 76, compilação 86 → 69, integridade dos testes 48 → 48.

Mais esforço nem sempre é melhor

O FrontierCode não premia o volume de código escrito, por isso a nota pode cair quando o nível de raciocínio sobe. A causa são os critérios de scope. No Claude Opus 5, a taxa de aprovação nos critérios de scope cai de 69,2% em low para 51,1% em max; no Opus 4.

8, de 81,9% para 70,9%; no Claude Fable 5, de 79,1% para 63,4%; no GPT-5.6 Sol, de 79,7% para 68,3%. Já os critérios de implementação sobem: no Opus 5, de 79,3% para 83,0%.

Com mais "esforço", os modelos mexem em mais arquivos, às vezes desnecessários. Entre as causas menos relevantes, a Cognition cita trapaças mais frequentes (o carregamento acidental do commit com a solução) e o "excesso de reflexão", quando o modelo se convence de uma leitura equivocada da tarefa.

Na versão 2.0, os requisitos de scope foram suavizados para não penalizar comportamentos inesperados, mas aceitáveis: a taxa média de reprovação caiu de 9,0% para 3,8%. Em um pool com Claude Opus 5.5, Claude Fable 5.1, GPT-6.1 Sol e GPT-6 Astra, a minúcia falha em 26,0% das verificações em low e em 15,3% em max.

O exemplo do Mock Service Worker é revelador: a tarefa era corrigir um bug em que resetHandlers() não reinicia os resolvers geradores. O Opus 5.5, em nenhum nível de esforço, de low a max, passou em qualquer das cinco execuções: a correção funcionava como declarado, mas o avaliador (grader) apontou problema na própria abordagem adotada.

O que as equipes devem considerar

Se você está escolhendo um modelo para programação autônoma, não olhe para o pass@1 em tarefas bem descritas, e sim para o comportamento diante de um prompt incompleto. Na prática: reserve tempo de code review para alterações colaterais e casos "vizinhos" esquecidos, não defina o reasoning effort máximo por padrão sem medir nos seus próprios repositórios e compare os modelos pelo custo de cada execução, não só pela pontuação. Para quem usa uma stack open source, os resultados da 2.0 são motivo para prever uma margem de ajuste manual.