Benchmark do mundo real mostra que agentes de programação ainda exigem revisão humana na maioria das tarefas

Agentes de programação com IA podem concluir grande parte de uma alteração de software e ainda assim não entregar um resultado totalmente funcional, segundo um novo benchmark baseado em solicitações reais de usuários. O teste constatou que até o sistema mais forte completou todas as partes necessárias de uma tarefa em apenas 26,4% dos casos, o que significa que a revisão humana continuou necessária em quase três de cada quatro tarefas.

O benchmark, chamado Co-Design Bench, foi desenvolvido por pesquisadores da Alibaba e de várias universidades asiáticas. Conforme relatado pelo The Decoder, ele avalia agentes em alterações de aplicativos web existentes, em vez de problemas de programação isolados. As tarefas podem incluir referências visuais, áudio, vídeo e documentos, refletindo as entradas combinadas que equipes de produto e engenharia fornecem cada vez mais às ferramentas de IA.

Um teste mais difícil para agentes de programação

O Co-Design Bench foi projetado para enfrentar o que seus pesquisadores descrevem como a saturação das avaliações de programação estabelecidas. Quando os modelos conseguem executar, inspecionar e reparar o próprio código, podem superar 99% em alguns benchmarks antigos, deixando pouco espaço para diferenciar os sistemas.

O novo teste, por sua vez, usa solicitações de sessões reais de programação. Os pesquisadores selecionaram casos em que os usuários já precisaram reformular solicitações ou reverter alterações malsucedidas. Eles variam de tarefas relativamente restritas, como extrair um valor de um recibo e atualizar os totais relacionados, a reformulações mais amplas de aplicativos.

Esse desenho torna o benchmark menos representativo de um exercício de programação limpo e autossuficiente e mais representativo do trabalho confuso envolvido na manutenção de um produto em operação. Isso também significa que os resultados não devem ser interpretados como uma medida universal de todo fluxo de trabalho de programação. Eles, porém, destacam a diferença entre produzir código plausível e concluir a solicitação completa de um usuário.

As evidências por trás do resultado de 26,4%

Segundo o artigo descrito pelo The Decoder, GPT-6 Astra foi o modelo de melhor desempenho entre os dez testados. Ele satisfez, em média, cerca de 70% dos requisitos das tarefas, mas resolveu completamente apenas 26,4% delas. Uma tarefa só era considerada concluída quando todos os recursos exigidos funcionavam no aplicativo.

Claude Opus 5 e Qwen3.8-Max vieram depois do GPT-6 Astra no ranking divulgado, enquanto Grok 4.6 ficou em último. Em grandes reformulações de aplicativos, o modelo menor Qwen3.8-27B subiu para o segundo lugar, embora os pesquisadores não tenham tratado esse resultado como evidência de uma vantagem geral do modelo.

O processo de avaliação também foi mais rigoroso do que uma simples revisão de código. Um avaliador automatizado testou o aplicativo concluído em um navegador, enquanto um segundo revisor verificou os resultados positivos e procurou mock-ups visuais, saídas codificadas manualmente ou outros atalhos que pudessem parecer satisfazer uma solicitação sem implementar o comportamento subjacente.

Essas são descobertas de pesquisa, não medições de adoção ou produtividade verificadas de forma independente. Os autores do benchmark reconhecem que seus avaliadores automatizados podem cometer erros, e as tarefas usam uma única solicitação fixa, em vez de uma conversa ao vivo na qual um usuário possa responder a perguntas ou corrigir um agente durante o trabalho. Portanto, os resultados mostram onde os agentes tiveram dificuldades sob essa configuração de teste, não a quantidade precisa de trabalho humano necessária em todos os ambientes de produção.

O modelo é apenas parte do sistema

Uma das descobertas mais importantes do benchmark diz respeito ao harness do agente: o ambiente de software que permite a um modelo ler arquivos, modificar código, executar aplicativos e inspecionar resultados. Em uma comparação separada, o Qwen3.8-27B obteve 75% em grandes reformulações com um harness, mas apenas 56% com outro. A posição relativa de dois modelos também mudou conforme o ambiente.

Esse resultado questiona a prática de comparar agentes de programação exclusivamente por meio de rankings de modelos. O desempenho de um modelo depende das ferramentas que ele pode chamar, do contexto que recebe, de como observa o comportamento do navegador e de sua capacidade de se recuperar de uma alteração incorreta. Para compradores que avaliam um assistente de programação com IA, a unidade prática de comparação é, portanto, a combinação de modelo e harness.

O estudo também constatou que computação adicional não fechou a lacuna de forma confiável. O GLM-5.2 usou quase seis vezes mais tokens que o GPT-6 Astra em alterações menores, mas alcançou uma pontuação significativamente mais fraca. Mais raciocínio ou uma execução mais longa podem ajudar em algumas tarefas, mas o resultado sugere que o uso adicional de tokens não substitui melhor decomposição de tarefas, testes e interação com o aplicativo.

O que as descobertas significam para desenvolvedores e empresas

Para as equipes de engenharia, a implicação imediata é que os agentes de programação com IA continuam sendo mais úteis como parceiros de implementação supervisionados do que como responsáveis autônomos por alterações de produtos. Um agente pode criar a maior parte de um recurso, mas as equipes ainda precisam verificar casos extremos, fidelidade visual, tratamento de dados e interações entre requisitos.

O risco é particularmente alto em tarefas que combinam alterações de layout, design, interação e conteúdo. O benchmark constatou que o desempenho caiu em todos os modelos à medida que mais tipos de alterações eram combinados, embora esses requisitos interligados sejam comuns no trabalho real de produtos. Um fluxo que trata cada solicitação como um único prompt pode, portanto, produzir uma implementação parcial convincente e deixar detalhes importantes inacabados.

As equipes que avaliam ferramentas devem testá-las em tarefas internas representativas, incluindo alterações em bases de código e aplicativos existentes, em vez de usar apenas exemplos de projetos novos. Elas devem medir a aceitação completa, as taxas de regressão, o tempo de revisão e a frequência de correções manuais. Isso complementa avaliações estabelecidas como o SWE-bench Verified, mas não deve substituir a revisão humana nem as salvaguardas de implantação.

As descobertas também são relevantes para desenvolvedores de plataformas de agentes. Melhor inspeção do navegador, rastreamento mais claro de estado, reversão confiável e validação mais forte podem melhorar os resultados tanto quanto um modelo subjacente maior. O resultado relativo ao harness indica que as equipes de produto devem avaliar todo o fluxo de trabalho, incluindo permissões, confiabilidade das ferramentas, observabilidade e recuperação de falhas.

O que observar a seguir

O próximo sinal útil será saber se o Co-Design Bench ou avaliações semelhantes se expandirão para além de solicitações fixas de uma única rodada. O trabalho real de software envolve esclarecimentos, requisitos variáveis e feedback de usuários ou líderes de projeto, portanto versões interativas do teste podem produzir uma visão diferente da utilidade dos agentes.

Pesquisadores e compradores também devem observar resultados que relatem modelo e harness em conjunto, em vez de publicar um único ranking de modelos. Uma replicação independente ajudaria a estabelecer se o ranking divulgado e os grandes efeitos do ambiente persistem em diferentes bases de código e tipos de aplicativos.

Por fim, as taxas de aceitação em equipes reais de engenharia continuarão sendo mais significativas do que a simples conclusão de benchmarks. O The Decoder citou pesquisas anteriores da METR mostrando que líderes de projeto aceitaram código gerado por IA a uma taxa cerca de 24 pontos percentuais abaixo das pontuações no SWE-bench Verified. Essa diferença é um alerta de que a aparente conclusão de uma tarefa não se traduz automaticamente em software pronto para implantação.

Perspectiva da Creati.ai

O Co-Design Bench é importante porque mede a última etapa do trabalho de agentes de programação: não se um agente consegue produzir código, mas se a alteração de produto solicitada realmente funciona em todo o aplicativo. Seu resultado de 26,4% de conclusão total lembra que a automação parcial ainda pode criar obrigações substanciais de revisão e reparo.

Para desenvolvedores de IA e compradores empresariais, a lição prática é deixar de tratar o modelo como o produto inteiro. A execução confiável dependerá da combinação de modelo, harness, testes, contexto do aplicativo e aprovação humana. Até que esses componentes sejam avaliados juntos em tarefas realistas, as alegações de desenvolvimento autônomo de software devem ser tratadas com cautela.