Agentes de IA para código completam de verdade só 1 em cada 4 tarefas reais

Um benchmark feito com as tarefas que mais davam problema

Pesquisadores da Alibaba e de várias universidades asiáticas publicaram em novembro de 2026 um novo teste para agentes de código chamado Co-Design Bench, segundo o The Decoder. Um agente de código é um sistema de IA que não só sugere trechos de código, mas lê o pedido do usuário, mexe direto no projeto e tenta entregar a mudança pronta.

O teste pede que o agente reformule aplicações web já existentes a partir de pedidos reais, às vezes usando imagem, áudio, vídeo ou documento como entrada. Os pesquisadores escolheram de propósito casos em que o usuário precisou reformular o pedido várias vezes ou desfazer a mudança, ou seja, tarefas que já tinham histórico de dar errado na prática. Vão de ajustes pequenos, como puxar um valor de um recibo e atualizar todos os totais que dependem dele, até reformas completas de projeto.

Os números que desinflam os benchmarks antigos

De acordo com o artigo, GPT-6 Astra, o melhor entre os dez modelos avaliados, atende em média cerca de 70% dos requisitos de uma tarefa. Mas o resultado só sai totalmente correto em 26,4% dos casos. Na maioria das vezes o agente faz o grosso do trabalho e deixa pelo menos um detalhe pendente, o que significa revisão manual quase sempre.

Em benchmarks mais antigos, como o WebCompass-edit, agentes de código chegam a placares acima de 99%, quando podem rodar, checar e corrigir o próprio código. O Co-Design Bench abre uma diferença de mais de 35 pontos percentuais em relação a esses testes, o que os autores atribuem à saturação dos benchmarks anteriores: eles ficaram fáceis demais para medir diferença real entre modelos.

A correção também é mais rígida. Um juiz de IA (outro modelo usado para avaliar a resposta) testa o aplicativo pronto direto no navegador, e um segundo juiz reconfere todo veredito positivo atrás de simulações ou resultados fixados manualmente. Só pontua o que funciona de verdade dentro do aplicativo.

O ranking muda dependendo do tipo de tarefa

Atrás de GPT-6 Astra vêm Claude Opus 5 e Qwen3.8-Max, enquanto Grok 4.6 fica na última posição. Em reformas maiores de projeto, porém, o Qwen3.8-27B, um modelo bem menor, sobe para segundo lugar, resultado que os próprios autores dizem não indicar uma vantagem geral desse modelo.

O recorte por tipo de teste também expõe limite. GPT-6 Astra lidera as duas trilhas avaliadas, mas resolve por completo só 41% das tarefas multimodais (as que pedem leitura de imagem, áudio ou vídeo) e menos de 18% das tarefas em nível de repositório inteiro.

Combinar vários tipos de mudança na mesma tarefa é onde todo mundo piora

O desempenho cai em todos os dez modelos à medida que uma tarefa junta mais tipos de mudança ao mesmo tempo, como layout, design visual, interação e conteúdo. O problema é que, segundo os pesquisadores, esse acúmulo de exigências é a regra em projetos reais, não a exceção.

Isso bate de frente com a forma como muitos times avaliam ferramentas antes de adotar: testando uma mudança isolada por vez. O Co-Design Bench sugere que o teste que importa é o pedido bagunçado, com várias frentes ao mesmo tempo, porque é esse que aparece no dia a dia.

Jogar mais poder de computação não resolve

O GLM-5.2 consome quase seis vezes mais tokens (as unidades de texto que o modelo processa e que custam dinheiro) do que o GPT-6 Astra em mudanças pequenas, e ainda assim tira nota bem pior. Gastar mais processamento não compra, sozinho, mais acerto.

Para quem decide orçamento de IA em projeto de software, esse dado pesa: o custo por token mais alto de um modelo não é garantia de resultado melhor, e medir isso antes de contratar evita surpresa na fatura.

O ambiente de execução pesa tanto quanto o modelo

Os pesquisadores também rodaram os mesmos modelos em harnesses diferentes, isto é, nos programas que dão ao agente acesso para ler, escrever e rodar o código do projeto. O Qwen3.8-27B marcou 75% ou apenas 56% em reformas maiores dependendo só do harness usado, com o mesmo modelo por trás. Qual dos dois modelos ficava na frente também mudava conforme o ambiente.

Os autores recomendam que todo placar de agente de código sempre informe modelo e ambiente juntos, nunca um sem o outro. Para quem escolhe um agente de código para a empresa, a implicação prática é direta: testar o modelo isolado não basta, é preciso avaliar o par modelo mais harness que vai de fato rodar em produção.

O que muda para quem integra esses agentes no fluxo de trabalho

Um estudo da organização de pesquisa METR, citado no mesmo material, já tinha mostrado a distância entre benchmark e uso real: a taxa de aceitação de código gerado por IA, medida por líderes de projeto de verdade, ficou cerca de 24 pontos percentuais abaixo dos placares do SWE-bench Verified, um dos benchmarks mais usados do setor.

Juntando os dois estudos, o recado para quem integra agente de código no time é claro:

• não leve um placar de leaderboard como garantia de entrega pronta, especialmente em tarefa que mistura vários tipos de mudança;
• reserve tempo de revisão humana como parte do fluxo padrão, não como exceção;
• ao avaliar um agente, teste no harness que vai usar em produção, porque o resultado muda de ambiente para ambiente;
• desconfie de modelo que gasta muito mais token sem entregar ganho proporcional de acerto.

Os limites do próprio teste

O Co-Design Bench também tem restrições que vale ter em mente. Ele avalia um único pedido fixo por tarefa, sem simular as perguntas de acompanhamento ou correções no meio do caminho que acontecem numa sessão real de desenvolvimento. Os juízes de IA que fazem a correção também podem errar.

Falhas no próprio ambiente de teste podem deixar um agente passar numa tarefa sem realmente resolvê-la. E o efeito do harness não é unânime: outro estudo recente sobre agentes de código encontrou pouquíssimo ganho mensurável vindo de ambientes mais elaborados, mesmo quando eles consumiam até três vezes mais tokens.

Fonte: The Decoder