A-CODE-LLM Bench: Benchmark de Codificação Agêntica
Comparamos os principais Grandes Modelos de Linguagem (LLMs) em 10 tarefas de desenvolvimento de software usando uma ferramenta CLI agêntica. Executamos ~3,500 etapas de validação automatizadas por modelo, tanto na camada de API quanto na de UI.
Resultados do A-CODE-LLM Bench
Cada alias executou 3 vezes em 10 tarefas (30 amostras por alias, 300 células por iteração). Veja mais detalhes na metodologia.
- Sonnet pontua mais alto que Opus em codificação agêntica. O Sonnet 5 (0.772) e o Sonnet 4.6 (0.748) superam todas as variantes do Opus, incluindo Opus 4.8 (0.702). O melhor modelo de codificação da Anthropic é o Sonnet de nível médio, não o carro-chefe Opus.
- A vantagem do Sonnet 5 cresce com a duração da tarefa. Ele lidera o benchmark de build de 10 tarefas com o maior backend de qualquer modelo (0.701) e 125 chamadas de ferramenta, mas na linha de base trivial usa apenas 9 chamadas. A vantagem aparece em builds longos e autônomos, não em tarefas curtas.
- As pontuações de frontend se agrupam altas, então o backend define a classificação. Os oito primeiros pontuam de 0.79 a 0.96 no frontend. O Claude Haiku 4.5 tem um frontend funcional (0.731) mas um backend de 0.277, limitando-o a 0.413; o GPT 5.5 thinking tem um backend forte (0.620) mas um frontend de 0.542.
- O nível do modelo não prevê a habilidade de codificação. O Sonnet de nível médio pontua mais que o Opus carro-chefe em todas as variantes, portanto, ajustar um modelo para trabalho agêntico importa mais do que seu tamanho ou faixa de preço.
- A lógica de backend é a parte difícil para os LLMs atuais, não a UI. Entre os líderes, o frontend está quase resolvido (os oito primeiros entre 0.79 e 0.96) e a classificação é decidida quase inteiramente pelo backend, onde as pontuações variam de 0.70 até 0.23.
Comparação de custo e sucesso
- Custo e pontuação não estão relacionados. O modelo mais caro, Opus 4.7 a $3.08 por célula, pontua 0.610, abaixo do Sonnet 4.6 a $1.33. Gastar mais não aumenta a pontuação.
- O Sonnet 4.6 custa menos que o Sonnet 5 para quase a mesma pontuação: 0.748 a $1.33 versus 0.772 a $2.23. Os 0.024 extras custam $0.90 a mais por célula.
- Cada variante do Opus custa mais que o Sonnet para uma pontuação menor ou igual.
- Melhor custo-benefício: Kimi K2.7 Code é o modelo mais barato acima de 0.60 a $0.70. Gemini 3.5 Flash thinking pontua 0.625 a $1.30, igualando o preço do Sonnet e superando todos os Opus.
- Preço não é um sinal de qualidade para codificação agêntica. O custo reflete o posicionamento do fornecedor, não a pontuação que um modelo apresenta neste benchmark, portanto um preço mais alto não indica um modelo agêntico melhor.
Comparação de tempo de conclusão de tarefa e sucesso
- Tempo de conclusão e pontuação não estão relacionados. O modelo mais rápido, Grok 4.3 a 142 segundos, pontua 0.431; o mais lento, Qwen 3.6 Plus a 1,948 segundos, pontua 0.333.
- O Sonnet 5 é o mais lento dos seis primeiros. A 1,763 segundos, leva cerca de 3x mais tempo que o Sonnet 4.6 (612 segundos) para 0.024 a mais.
- O Sonnet 4.6 é o mais rápido entre os pontuadores altos, alcançando 0.748 em um terço do tempo do Sonnet 5.
- Execuções acima de 1,600 segundos vieram de iteração excessiva, não de tarefas mais difíceis: MiniMax M3, ambas as variantes do Qwen, GLM 5.1 base e Deepseek V4 Pro pontuaram abaixo de 0.55.
- Duas causas não relacionadas impulsionam o tempo de execução. Dentro de um modelo, execuções mais longas podem significar iteração mais profunda que eleva a pontuação (Sonnet 5). Entre modelos, as execuções mais longas vêm de iteração excessiva improdutiva (todos os modelos acima de 1,600 segundos pontuaram abaixo de 0.55). O tempo sozinho não pode distinguir os dois.
Chamadas de ferramenta por tarefa
- O número de chamadas de ferramenta é uma impressão digital comportamental, não uma medida de capacidade, e não é comparável entre harnesses. O OpenAI’s
apply_patchcondensa uma edição de arquivo completo em uma chamada, portanto suas contagens baixas refletem o design da ferramenta, não menos trabalho. - O número de chamadas de ferramenta não prevê a pontuação. As contagens variam de 18 (Grok 4.3) a 125 (Sonnet 5), sem padrão entre contagem e pontuação.
- O Sonnet 5 faz o maior número de chamadas de qualquer modelo (125) e pontua mais alto; o Sonnet 4.6 alcança quase a mesma pontuação com cerca de 50. Ambos funcionam, em extremos opostos da faixa.
- MiniMax M3 fez 108 chamadas para um 0.583 no meio da tabela, portanto, uma contagem alta por si só não ajuda.
Desempenho dos LLMs em uma única tarefa bem-sucedida
Nenhum modelo passou todas as etapas do benchmark completo acima. Para comparar custo e velocidade em condições iguais, executamos uma tarefa de linha de base simples que todo modelo consegue completar: quatro endpoints CRUD, validação básica, sem autenticação e sem banco de dados.
Comparação de custo e linhas de código
- Tarefas triviais não separam os modelos, que é a principal razão pela qual o benchmark completo existe. Na linha de base, custo, comprimento de código e taxa de aprovação convergem: todos os modelos completam, as linhas se agrupam entre 40 e 64, e o custo cai para centavos. As diferenças do modelo aparecem apenas em trabalhos agênticos longos e com vários arquivos.
- O comprimento do código não é uma característica do modelo em tarefas simples (40 a 64 linhas), exceto por um supergerador, Gemini 3.5 Flash base, que produziu 131 linhas e se tornou a linha de base mais cara.
- O Sonnet 5 ajusta o esforço à tarefa: 9 chamadas, 46 linhas, $0.09 na linha de base versus 125 chamadas no benchmark completo. O Sonnet 4.6 executou a linha de base a cerca de 15% do seu custo por célula do benchmark completo ($0.20 base, $0.15 thinking). O Opus 4.8 também reduziu para $0.16 e 6 chamadas. Consulte o artigo LLM Pricing para taxas por token.
Tempo de conclusão e uso de tokens
- Os modelos se dividem em dois tipos de ritmo. Modelos adaptativos escalam o esforço com a dificuldade (Opus 4.8: 34 segundos na linha de base, 1,072 no benchmark); modelos de ritmo fixo executam devagar independentemente (MiniMax M3: 475 versus 1,684).
- A saída para a mesma tarefa varia 8x, de 787 tokens (Qwen 3.6 Plus thinking) a 6,643 (GPT 5.4 Mini), portanto, a verbosidade é uma disposição estável do modelo, não um efeito da tarefa.
O que são sistemas LLM agênticos?
Construir software é iterativo: escrever código, executá-lo, ler erros, corrigi-los, repetir. Os sistemas de IA Agêntica permitem que os LLMs sigam esse mesmo ciclo. O modelo opera dentro de um ambiente de desenvolvimento onde pode escrever arquivos, executar comandos, ler saídas e fazer alterações com base no que vê, continuando até que a tarefa seja concluída.
Isso importa porque aplicações reais não são arquivos únicos. Elas têm backends com rotas e modelos de banco de dados, frontends com componentes e chamadas de API, arquivos de configuração, dependências e testes. Fazer tudo isso funcionar junto requer testes e refinamento iterativos, que é exatamente o que a arquitetura agêntica permite.
Adicionar como fonte preferencialComo funciona
O modelo fica dentro de um harness com acesso a um shell, sistema de arquivos e saída de execução. Quando solicitado a construir uma aplicação, ele escreve arquivos incrementalmente. Após cada etapa, o harness mostra ao modelo o que aconteceu: o servidor iniciou, os testes passaram, o linter sinalizou erros? Com base nesse feedback, o modelo decide o que escrever ou corrigir a seguir.
Isso difere fundamentalmente da geração de uma só vez. Em configurações de geração única, o modelo gera toda a base de código às cegas, sem como verificar se funciona. Nos sistemas LLM agênticos, o modelo vê as consequências de cada ação e corrige o rumo. No entanto, essa capacidade por si só não é suficiente. O modelo ainda precisa de raciocínio forte para implementar a lógica de negócio corretamente, que é onde as diferenças de desempenho realmente aparecem.
Metodologia do benchmark de LLM agêntico
Usamos o Opencode como o harness agente para todos os modelos e os conectamos através do OpenRouter, com uma exceção: Claude Fable 5 executou no Claude Code CLI na assinatura do Claude. Cada célula foi executada 3 vezes para medir a variância por célula e estabilizar a tabela de classificação. Avaliamos sua capacidade de trabalhar autonomamente em 10 tarefas de desenvolvimento de software (T-1 a T-10), variando de sistemas de reserva a painéis interativos. Essas tarefas exigem que os agentes gerenciem projetos com vários arquivos e entreguem produtos funcionais.
Execução e orquestração
Cada agente e tarefa começa em um ambiente limpo. As instruções são fornecidas como um arquivo TASK.md, e usamos um watchdog de heartbeat de 20 minutos para os scripts de lançamento. Durante esta fase, registramos códigos de saída, tempo de execução e se os arquivos de backend e frontend foram criados. Também rastreamos o uso de tokens em tempo real nas categorias de entrada, saída e cache.
Validação de backend: Implantamos os projetos gerados em ambientes isolados para testá-los contra um contrato YAML canônico. A validação cobre cenários de caminho feliz, tratamento de erros (400/403/409) e consistência de dados.
Testamos os resultados em dois modos:
O modo Adaptativo valida a funcionalidade mesmo com nomes de rota diferentes, enquanto o modo Estrito exige aderência exata ao contrato.
A pontuação geral do backend é calculada por célula como:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
onde has_backend é 1 se a célula produziu um projeto de backend, 0 caso contrário. O Adaptativo tem peso maior porque mede a correção comportamental; o estrito adiciona uma penalidade por desvio do contrato (rotas renomeadas, códigos de status substituídos, campos de resposta reestruturados).
Testes de cenário de UI e usuário
Usamos automação de navegador para simular fluxos reais de usuário, incluindo preflights, renderização e autenticação. Verificamos etapas funcionais como envio de login e comportamento pós-login para garantir que a aplicação execute sem travar.
A pontuação da UI divide oito etapas em dois grupos. Etapas de infraestrutura (preflight de backend, renderização de frontend, formulário de login visível, envio de login, login 2xx, sem travamento em tempo de execução) medem se a aplicação funciona. Etapas de comportamento (sinal de autenticação pós-login, sinal de comportamento pós-login) avaliam se a aplicação executa sua função pretendida uma vez em execução.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Etapas de comportamento bloqueadas são excluídas do denominador de comportamento, portanto, uma célula não é penalizada duplamente quando a aplicação falha ao carregar.
Cálculo de tokens
As contagens de tokens são extraídas da resposta da API do LLM. Subtraímos os tokens de entrada em cache do total de tokens de entrada para obter a entrada efetiva, que reflete apenas os tokens processados recentemente. Os tokens de saída nunca são armazenados em cache, portanto permanecem inalterados.
Agregação final
A pontuação final do benchmark é calculada combinando os resultados das fases anteriores: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Atribuímos um peso maior ao backend porque falhas de lógica no nível da API muitas vezes invalidam qualquer sucesso no frontend.
Exemplo de tarefa
Tarefa 6: Sistema de helpdesk de chamados
A Tarefa 6 foca no desenvolvimento de um ecossistema complexo de suporte ao cliente. O objetivo principal é construir uma plataforma que medeie a comunicação entre clientes e agentes de suporte, impondo estritamente regras de negócio e limites de segurança. Esta tarefa avalia a capacidade de um agente de lidar com máquinas de estado multiusuário, isolamento de dados e comunicação encadeada dentro de um ambiente full-stack.
A tarefa exigiu construir um sistema de helpdesk de chamados com:
- Permissões distintas para Clientes (emitir/responder) e Agentes (gerenciar/resolver).
- Um fluxo de status rígido que impede transições ilegais e impõe ações específicas de função.
- Isolamento avançado de dados onde solicitações de recursos não autorizadas retornam 404 em vez de 403 para proteger a integridade do sistema.
- Um sistema de resposta cronológica para interação contínua entre agente e cliente.
- Um backend FastAPI combinado com um frontend responsivo alimentado por Vite (React/Vue/Svelte).
- Configuração reproduzível via comandos de shell específicos para ativação imediata do sistema.
Você pode ver a documentação da Tarefa 6 no GitHub.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{kaleliolu2026,
author = {Kalelioğlu, Berk and Dilmegani, Cem},
title = {{A-CODE-LLM Bench: Benchmark de Codificação Agêntica}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Acessado em 2 Julho 2026}
}Resultados e carimbos de data/hora de 341 pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo 2 arquivos CSV e um README.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.