FrontierCode Diamond: 13,4% de patches integráveis em 50 tarefas difíceis (junho de 2026)

Pode encontrar materiais adicionais sobre a configuração de ferramentas na documentação do Ailoot.

O que é o FrontierCode e porque é que é importante?#

A Cognition é a empresa por detrás do Devin (o primeiro engenheiro de IA autónomo, lançado em março de 2024) e do Windsurf (adquirido em julho de 2025). Está também a desenvolver a sua própria linha de modelos SWE-1.x. O benchmark foi publicado no blogue público em cognition.com/blog/frontier-code.

A principal mudança não está nos novos números. Está na escala usada para medir as coisas agora.

O benchmark tem três níveis de dificuldade: Extended (150 tarefas, o conjunto completo), Main (as 100 tarefas mais difíceis, incluindo Diamond) e Diamond (50 tarefas extremamente difíceis). A Cognition deixou deliberadamente Diamond «em grande medida não saturado» — até o melhor modelo resolve menos de 15%. O objetivo é dar ao benchmark uma margem de um ano e impedir que fique saturado num mês, como aconteceu com o HumanEval.

O que mede o FrontierCode: «O maintainer aceitaria este PR?»#

As seis dimensões de avaliação (segundo o blogue oficial da Cognition):

1. Correção comportamental — o patch resolve a tarefa?
2. Segurança contra regressões — evita danificar o código existente?
3. Qualidade mecânica — passa a compilação e as verificações de lint e de estilo?
4. Correção dos testes — os testes escritos pelo agente são válidos (testes que passam com qualquer código não contam)?
5. Âmbito — o patch evita alterar ficheiros que não foram pedidos?
6. Qualidade do código — o código segue as convenções do projeto e é legível?

Para contar como pronto para integração, um patch tem de passar em todas as seis dimensões. Basta falhar numa para não ser integrado.

Essa é a principal mudança de perspetiva. «A correção é agora um requisito básico», como diz a Cognition. Antes, os benchmarks perguntavam: «O código passou nos testes?» Agora perguntam: «Um tech lead real aceitaria integrar isto no projeto?»

A Cognition introduziu três novas técnicas de classificação:

• Reverse-Classical: um teste escrito por um agente tem de falhar numa versão avariada do código. Caso contrário, o teste é uma fraude.
• Code Scope: um verificador automatizado confirma que o patch se mantém dentro dos ficheiros e do número de linhas acordados para a tarefa.
• Adaptive Classical Grading: a ferramenta LLM «mutagent» adapta testes rigorosos a variantes válidas da solução.

Porque é que os benchmarks antigos já não funcionam?#

Os agentes de IA já tinham excelentes resultados no HumanEval em 2024. O SWE-bench Verified é muito semelhante: em agosto de 2025, a OpenAI reconheceu publicamente o problema da contaminação (os modelos tinham «visto» o conjunto de dados durante o treino). Os benchmarks perderam a capacidade de distinguir os melhores modelos.

O estudo fundamental que abalou a antiga medida foi publicado em março de 2026.

O que fizeram:

• Selecionaram 4 maintainers ativos de 3 repositórios (scikit-learn, Sphinx, pytest).
• Pediram-lhes que avaliassem 296 PR gerados por IA do SWE-bench Verified — todos estes PR passaram nos testes automatizados.
• Compararam as decisões dos maintainers com as do avaliador automatizado.

Por outras palavras, o benchmark diz «passou», enquanto o maintainer diz «não vou integrar» — e isto acontece em cerca de um quarto dos casos, em média. Os 3 principais motivos de rejeição, do menos para o mais grave:

1. Qualidade do código — não corresponde ao estilo do repositório.
2. Parte outro código — danifica código adjacente.
3. Falha da funcionalidade principal — não resolve totalmente a tarefa, apesar de o teste estar verde.

O FrontierCode formaliza precisamente este problema. A Cognition pegou nesta ideia e expandiu-a para um benchmark completo, com mais de 20 maintainers em vez de 4.

Outro prego no caixão é um estudo de dezembro de 2025 sobre a segurança dos patches gerados por IA.

Nesse estudo, 61% das soluções do SWE-Agent com Claude 4 Sonnet estavam funcionalmente corretas, mas apenas 10.5% eram seguras.

O código passa no teste e, mesmo assim, um em cada dois patches introduz uma falha de segurança. Isto não é visível nos benchmarks SWE-bench — não medem segurança. O FrontierCode tenta, pelo menos, detetá-la através das dimensões «qualidade mecânica» e «qualidade do código».

Classificação dos modelos: Opus 4.8 com 13.4%, GPT-5.5 com 6.3%#

O que se destaca na tabela:

• Um líder claro. O Opus 4.8 da Anthropic está aproximadamente duas vezes à frente do concorrente mais próximo. A diferença que era difícil de notar no SWE-bench é claramente visível no FrontierCode.
• Os modelos open ainda não recuperaram o atraso. O Kimi K2.6 — o melhor modelo open-code — obtém 3.8% em Diamond. É 3–4 vezes menos do que o Opus 4.8. A Cognition não publicou uma tabela completa do Kimi K2.6 para Main e Extended, pelo que ainda não há comparação do conjunto completo.
• A Cognition colocou honestamente o seu próprio modelo na parte inferior da tabela.

O subconjunto Diamond foi deixado deliberadamente «não saturado». A Cognition criou uma margem de segurança para os próximos anos. Se os benchmarks anteriores saturaram em 12–18 meses, o FrontierCode foi concebido para ter um limite superior mais elevado.

O que significa «13% prontos para integração» para quem faz vibe coding com o Claude Code?#

Primeiro, uma reformulação importante: o conjunto Diamond do FrontierCode é deliberadamente extremamente difícil. Em tarefas comuns, num projeto novo de uma startup sem quarenta módulos dependentes, um agente de IA tem um desempenho claramente melhor. O mesmo Opus 4.8 obtém 51.8% de patches prontos para integração em Extended (150 tarefas, o conjunto completo). É um cenário completamente diferente.

O resultado de 51,8% aplica-se ao conjunto Extended de 150 tarefas do benchmark. É superior ao resultado Diamond, mas nenhum dos valores estima a integração dos patches de todos os modelos nas suas tarefas. Pontuações Main ou Extended ausentes para outros modelos não justificam inventar o seu desempenho.

O que isto significa para quem faz vibe coding e envia para produção:

• Um teste verde já não significa «pronto para integrar». Os testes escritos pela própria IA podem não valer nada — passam com qualquer código. O FrontierCode mede isto diretamente através do Reverse-Classical: se um teste não falhar numa versão avariada, não conta.
• O estilo e as convenções do repositório são importantes. Se um projeto tem um padrão estabelecido e a IA não o segue, um colaborador real não aceitará a alteração. Num projeto a solo sem regras, não é um grande problema. Numa equipa, é o problema número um.
• Os testes não resolvem a segurança. Lembre-se do número acima: apenas 10.5% dos patches são seguros, apesar de 61% estarem corretos. É preciso verificar isto separadamente, com ferramentas que detetem tokens, ficheiros .env e palavras-passe predefinidas.
• Exceder o âmbito da tarefa é um erro típico da IA. Pede-se-lhe que corrija uma função de autorização e recebe-se um patch que também reescreveu a camada interna e o registo de eventos. Esta é uma das 6 dimensões do FrontierCode.

Que 6 categorias de erros comete a IA em tarefas difíceis?#

Vamos analisar cada dimensão em linguagem simples:

1. Correção comportamental — o patch resolve a tarefa?

A dimensão mais básica. Muitas vezes, a IA escreve código que parece uma solução, mas resolve o problema errado. Peço-lhe para «adicionar uma confirmação de leitura à mensagem» e recebo uma função markAsRead, mas ela não está ligada ao próprio componente do chat. O teste da função passa. A tarefa de negócio continua por resolver.

2. Segurança contra regressões — evita danificar o código adjacente?

A IA altera um módulo e outro deixa de funcionar. O caso mais comum: um agente de IA altera a assinatura de uma função e esquece-se de que esta é chamada em mais 17 locais. Não se consegue ver isto no SWE-bench — executam testes apenas para um ficheiro. No FrontierCode, executam todo o conjunto de testes do repositório.

3. Qualidade mecânica — passa a compilação e as verificações de lint e de estilo?

A IA pode produzir código que compila localmente, mas falha no CI: falta um import, há tabulações em vez de espaços, dois espaços no fim da linha ou um erro em eslint.config.js. Num projeto ativo, o estilo não é um capricho; é uma regra da equipa.

4. Correção dos testes — os testes escritos pela IA são válidos?

A dimensão mais traiçoeira. A IA escreve um teste que passa. Mas passa com qualquer código, incluindo código avariado. Já vi isto muitas vezes: o teste verifica «o script falhou?» em vez de «devolveu o resultado correto?». O Reverse-Classical do FrontierCode deteta precisamente este caso.

5. Âmbito — o patch evita alterar ficheiros sem relação com a tarefa?

Peço-lhe para corrigir uma função e recebo um patch para 12 ficheiros, incluindo ficheiros sem relação com a tarefa. É precisamente essa «iniciativa» da IA que danifica um projeto de produção ao alterar coisas que não lhe pedi para alterar. Esta dimensão é um impedimento decisivo no FrontierCode.

6. Qualidade do código — o código segue as convenções do repositório?

A IA escreve uma função própria «de raiz» em vez de usar os auxiliares existentes em lib/. Ou dá nomes às variáveis que não correspondem ao estilo do projeto. Ou coloca a lógica na camada arquitetural errada. Do ponto de vista do teste, tudo funciona. Do ponto de vista do tech lead, o patch não será integrado.

Como verificar código de IA antes de o enviar: 5 passos#

1. Execute todo o conjunto de testes, não apenas os testes relacionados com a alteração

   A IA altera muitas vezes código fora do âmbito da tarefa. O problema vai aparecer nos testes adjacentes. Executo o conjunto de testes completo (com o único comando npm test, sem caminho), não apenas os testes de um ficheiro específico. Em projetos grandes, é prático fazê-lo em paralelo com um git worktree (consulte Git worktree no Claude Code).

2. Execute as verificações de lint, estilo e tipos

   Três comandos por ordem: eslint ., prettier --check ., tsc --noEmit. Um agente de IA pode não detetar tabulações nem um espaço extra no fim da linha. Se o projeto tiver verificações rigorosas, execute-as localmente antes do lançamento.

3. Teste o próprio teste

   A mais importante das 5 verificações. Faço uma pequena «avaria» no código (altero return true para return false). O teste deve falhar. Se não falhar, a IA escreveu-o só para inglês ver e é inútil. Apago o teste e peço à IA para o reescrever com uma condição obrigatória: o teste tem de falhar na versão avariada.

4. Verifique que ficheiros foram alterados pela IA

   O comando git diff --stat mostra que ficheiros foram alterados e quantas linhas. Se a IA alterou 12 ficheiros em resposta a «corrige o formulário de contacto», ultrapassou o âmbito da tarefa. Reverto as alterações extra com um único comando para o ficheiro.

5. Faça uma verificação de segurança com uma skill pronta a usar

   Os testes não detetam injeções SQL nem palavras-passe codificadas diretamente. Uso uma skill de segurança pronta a usar para o Claude Code (consulte 754 skills de segurança prontas a usar). No mínimo, pesquise manualmente no projeto as palavras «password», «secret» e «key» e verifique se .env.example está completo.

Os 5 passos abrangem 5 das 6 dimensões do FrontierCode (1–5). A sexta dimensão — qualidade do código — é verificada automaticamente através do lint e de uma revisão humana.

O que melhora realmente as hipóteses de obter código pronto para integrar?#

Num projeto sem preparação, um agente de IA vê apenas o ficheiro que abriu para ele. Não conhece o histórico das suas decisões, as suas convenções nem o mapa dos seus módulos. Não há problema nas alterações simples. Nas alterações difíceis, a falta de contexto do projeto é um risco a corrigir. O resultado de 13,4% do benchmark não isola a qualidade do contexto como causa.

O que tem de fazer para transformar esses 13% em algo que possa realmente colocar em produção:

1. Regras do projeto — para a IA reproduzir o seu raciocínio em vez da média da Internet.

É um conjunto das suas soluções prontas, hábitos e regras aprendidas num formato que o agente de IA lê em cada pedido. Quando há mais de 30 regras, a IA deixa de inventar a «média do setor» e começa a fazer sugestões ao seu estilo. É possível tratar as alterações fora do âmbito da tarefa com uma linha nas regras: «não alteres ficheiros que não estejam explicitamente indicados no pedido».

2. Um mapa do projeto — uma pasta que descreve o projeto.

É aqui que coloca produtos, público, economia, métricas e configurações. Antes de cada pedido, o agente de IA lê o índice e percebe em que parte do negócio está a trabalhar. Isto resolve automaticamente dois dos motivos de rejeição referidos acima: o estilo e os danos noutro código.

3. Context Engineering — gerir o que a IA vê antes do pedido.

Não se trata de «como formular um prompt», mas de «o que colocar na janela de contexto ANTES do prompt». CLAUDE.md, pré-requisitos e ligações direcionadas para ficheiros. Isto resolve as falhas de correção comportamental e qualidade do código.

Use a combinação como preparação para as verificações, não como evidência de que cinco dimensões já passaram. Verifique o comportamento, as regressões, os testes, o âmbito e a qualidade do código no patch real antes de o aceitar.

Uma camada adicional são os agentes de revisão:

• Cursor Bugbot — faz uma revisão de cada PR. Segundo a Cursor, a ferramenta processa cerca de 2 milhões de PR por mês.
• Subagentes aninhados no Claude Code v2.1.172 — um agente escreve o código, um segundo revê-o e um terceiro executa os testes. É a mesma ideia do FrontierCode: separar os papéis de «autor» e «tech lead».

Veja também: Segurança no vibe coding, Como configurar o Claude Code para não estragar o seu projeto durante a noite e o conceito de Context Engineering.

Para materiais adicionais sobre o trabalho com ferramentas, consulte a documentação do Ailoot.