AIM-Code Bench: Benchmark de Programação Agêntica

Avaliar LLMs sem seus arcabouços de agente de programação não reflete plenamente como são usados na prática. O desenvolvimento real também envolve estender trabalhos existentes, assumir código desconhecido e deixar implementações que outros possam aproveitar. Apresentamos o AIM-Code Bench para avaliar models em conjunto com seus arcabouços de agente de programação em tarefas de software em evolução. Além da correção, o benchmark mede o desempenho em tempo de execução, a adaptação a requisitos em mudança e os resultados quando agentes desenvolvem a partir do código uns dos outros.

Resultados

O Fable 5.1 teve a menor latência observada nos estágios 1 e 2; o Opus 5 liderou os estágios 3 e 4.

A tabela mostra a latência p95 (o 95 percentil) em milissegundos; quanto menor, melhor. Cada valor é a mediana de dez medições de replay do programa salvo. As classificações usam precisão total dentro de cada estágio. As mesmas medições do estágio 4 servem como controles de código próprio na comparação de transferência. Classificações numéricas próximas não indicam necessariamente desempenho distinguível.

Parte 1: desenvolvimento e melhoria das próprias implementações

Cada agente manteve seu código e sua conversa ao longo dos estágios. Atualizamos a especificação da tarefa conforme novos requisitos chegavam e demos a ela até 20 minutos para cada estágio. Os prompts descreviam trabalho de desenvolvimento comum e pediam que os agentes buscassem o melhor desempenho possível, preservando o comportamento exigido.

O experimento abrangeu treze configurações de model e produto: quatro no Claude Code, três no Codex, quatro no OpenCode, uma no Grok Build e uma no Devin CLI. O esforço foi médio quando suportado, alto para Kimi K3 e GLM 5.3, e o padrão do provedor para MiniMax M3. Cada resultado, portanto, pertence ao model e ao produto de programação em conjunto.

Tentamos refletir o mais fielmente possível como as pessoas realmente usam produtos de programação de IA em cenários da vida real. Muitas pessoas usam models dentro de seus próprios arcabouços; portanto, embora tenhamos utilizado os models disponíveis dentro de seus respectivos arcabouços, usamos models de pesos abertos via opencode.

Quatro estágios do projeto

Os estágios 1–3 usaram 5.000 operações por lote. O estágio 4 usou requisições HTTP independentes com 1.000 operações cada, com uma CPU e 128 MiB de memória alocados ao serviço candidato.

A latência de lote medida do MiniMax M3 passou de 37.833 ms no estágio inicial para 12.254 ms no estágio de capacidade. Esta é uma redução observada de 67,6% conforme a implementação mudou e a evicção se tornou um requisito. Sua implementação original do HTTP no estágio 4 ficou posteriormente em 4 lugar, com 3.009 ms.

A latência de lote medida do Qwen 3.8 Max passou de 11.638 para 8.023 ms entre os dois primeiros estágios, uma redução observada de 31,1%. Seu resultado no estágio 3 ficou em 4 lugar. Essas trajetórias mostram por que um único resultado inicial perde mudanças que aparecem à medida que um agente continua desenvolvendo um projeto.

Essas porcentagens descrevem as trajetórias registradas, não ganhos de otimização controlados. Cada estágio altera o comportamento ou a carga de trabalho exigidos. Em particular, a latência do estágio 4 não pode ser subtraída latência do estágio 3: a interface e as operações por requisição diferem. Uma afirmação direta de otimização antes/depois exigiria repetir ambas as versões sob a mesma carga de trabalho aplicável.

Quanto código mudou ao longo do caminho?

Os quatro estágios abrangem 52 diffs verificados do estágio original nas treze configurações. O estágio 4 ilustra a variação no tamanho da implementação e no estilo de edição:

Essas contagens incluem testes e ferramentas de código-fonte escritos pelo agente, comentários e linhas em branco; atualizações fornecidas de tarefa/teste e diagnósticos JSON são excluídos. Elas medem a diferença final em relação ao snapshot inicial de cada estágio. Mudanças maiores podem incluir testes ou otimizações úteis; mudanças menores não são automaticamente melhores. O relatório de diff vinculado contém as mudanças de código por estágio.

Parte 2: assumindo a implementação de outro agente

Depois de medir as trajetórias originais, fizemos duas perguntas diferentes: o código de quem oferece a outros agentes um ponto de partida útil e qual agente tem melhor desempenho ao estender o código de outra pessoa?

Ramificamos a partir das implementações salvas do estágio 3 e pedimos aos destinatários que realizassem o estágio 4. Cada uma das treze configurações recebeu o código das outras doze configurações, resultando em 156 pares ordenados doador–destinatário. Não houve novas auto-transferências. Cada destinatário iniciou uma nova sessão isolada com o código do doador e os mesmos requisitos do estágio 4; não podia ver o arcabouço nem as sessões de outros agentes.

As submissões originais do estágio 4 servem como controles de código próprio, usando as mesmas medições da Parte 1. Esses controles haviam sido desenvolvidos com o histórico de conversa original, enquanto as transferências começaram do zero. A comparação, portanto, combina efeitos do código inicial e da conversa. Essa transição pede aos sucessores que estendam um cache existente para um serviço HTTP enquanto otimizam a latência das requisições.

Visão A: benefício fornecido pelo código de um doador

Para cada par, comparamos a latência HTTP do sucessor com a latência original do estágio 4 do mesmo sucessor:

successor benefit = (recipient own latency − inherited-code latency) / recipient own latency

A pontuação de um doador é a mediana desses doze benefícios percentuais. Positivo significa que seus sucessores normalmente alcançaram latência menor do que suas próprias continuações originais. Esta é uma visão baseada em desempenho de quão útil foi uma implementação inicial; ela não mede diretamente a qualidade da documentação nem a facilidade de compreensão.

O Opus 5 forneceu o maior benefício mediano ao sucessor, +17,30%, seguido pelo Opus 5.5 com +15,70% e pelo Fable 5.1 com +11,34%. Esses resultados podem refletir tanto o desempenho da implementação herdada quanto a facilidade com que os sucessores puderam estendê-la. As porcentagens normalizam a escala, mas não eliminam diferenças de qualidade inicial ou de margem para otimização.

Visão B: desempenho como sucessor

Para cada doador, calculamos a latência mediana alcançada por seus doze destinatários. Cada destinatário desse doador é então comparado com essa referência compartilhada:

successor advantage = (same-donor median latency − recipient latency) / same-donor median latency

A pontuação do destinatário é sua vantagem mediana entre doze doadores. Positivo significa que ele normalmente foi mais rápido do que o destinatário mediano do mesmo código inicial. Isso evita recompensar um destinatário simplesmente porque sua própria implementação original era lenta.

O GPT-6 Astra liderou este resumo exploratório de sucessores com +2,68%, seguido pelo Opus 5 com +2,33% e pelo Grok 4.6 com +0,88%. A vantagem do Astra sobre o Opus 5 não foi distinguível dentro da incerteza medida. Ser o doador mais forte e ser o sucessor mais forte são resultados diferentes neste experimento.

Os sucessores desenvolveram a partir do código herdado?

Relatamos a rotatividade de código-fonte separadamente do desempenho: (added lines + deleted lines) / inherited source lines. Também contamos transferências que excluíram mais de 50% do código-fonte herdado. Esta é uma taxa de exclusão grande, não uma prova de reescrita do zero: renomeações, reformatação e remoção de código auxiliar podem ultrapassar o limite.

Nenhum dos sucessores selecionados excluiu mais da metade do código-fonte total herdado de GPT-6 Astra, Claude Fable 5.1, Claude Opus 5, Claude Opus 5.5 ou Qwen 3.8 Max. Todos os doze ultrapassaram esse limite para Kimi K3, GPT-5.6 Luna, MiniMax M3 e Claude Sonnet 5. Essas são observações sobre mudanças em linhas físicas, não uma classificação de manutenibilidade. Os programas doadores continham apenas 75–668 linhas de código-fonte, incluindo código auxiliar, e a escolha de incluir testes/ferramentas afeta as porcentagens de exclusão.

Método de medição, repetições e escopo

Cada pontuação de desempenho relatada usa dez replays do mesmo programa salvo. Os estágios 1–3 usaram 40 lotes medidos por replay. O estágio 4 e a cronometragem das transferências usaram 1.200 requisições HTTP por replay a 20 requisições por segundo durante 60 segundos, com uma CPU, 128 MiB de memória e um limite de 64 processos/threads para cada candidato.

Medimos os programas serialmente em um servidor Linux dedicado Intel i7-7700. O driver e o candidato rodaram em núcleos físicos separados, com threads irmãs não utilizadas, política fixa de CPU a 2 GHz e turbo desativado.

Todas as 156 submissões de transferência selecionadas e todas as 52 builds do estágio original passaram em todos os replays. A avaliação completa contém 2.080 medições, incluindo todos os treze controles de código próprio. Verificamos as respostas brutas, recalculamos a latência p95, verificamos hashes do código-fonte e limites de recursos e mantivemos todas as medições programadas.

Calculamos intervalos de 95% a partir de 10.000 reamostragens das dez rodadas de medição, usando as mesmas rodadas amostradas em todos os programas. Uma comparação é inconclusiva quando seu intervalo de diferença inclui zero. Esses intervalos exploratórios não são ajustados para comparações múltiplas. As contagens de sucessores mais rápidos comparam pontuações medidas e não implicam diferenças estatisticamente distinguíveis.

Nas 13 builds originais do estágio 4 e nas 156 transferências, todas as 2.028.000 respostas HTTP medidas estavam corretas. O atraso máximo de despacho foi de 0.607 ms. Todos os replays atenderam aos limites do driver de atraso de despacho p95 abaixo de 0.05 ms e atraso máximo abaixo de 1 ms. O atraso permanece incluído na latência.

A seleção publicada inclui tentativas adicionais. GLM 5.3 e Qwen 3.8 Max usam suas segundas trajetórias originais completas após falhas iniciais no estágio 3. Quatro builds piloto de transferência concluídas foram reutilizadas, quinze pares Claude receberam tentativas de recuperação de infraestrutura e sete transferências com falha receberam uma nova tentativa de programação de seus doadores originais. Todas as sete repetições de programação passaram. Novas tentativas foram selecionadas independentemente do resultado; tentativas anteriores permanecem arquivadas. Esses resultados comparam builds selecionadas, não a confiabilidade da primeira tentativa.

O avaliador distingue falhas do candidato de medições inválidas por infraestrutura. A correção HTTP exige pelo menos 99% das requisições atendidas, aquecimentos corretos e nenhuma resposta incorreta. Cada build classificada deve ter dez replays válidos. Nenhum código mudou durante a avaliação de cronometragem.

Este é um projeto e uma trajetória selecionada por configuração. Os quatro estágios estão relacionados, e os 156 pares de transferência compartilham doadores e destinatários. Os intervalos descrevem a variação de replay neste host; eles não abrangem outras tarefas, máquinas ou execuções de programação independentes. Os achados descrevem esses artefatos sob essas cargas de trabalho, e não uma classificação geral de habilidade de programação, compreensão de código ou manutenibilidade em produção.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

O que vem a seguir?

Os próximos experimentos adicionarão mais projetos e trajetórias de programação independentes, aumentarão a dificuldade dos estágios que atingem o teto de carga oferecida e medirão versões aplicáveis de antes/depois sob a mesma carga de trabalho. Controles de autocontinuação em sessões novas ajudariam a separar os efeitos do histórico de conversa do fato de começar com o código de outro agente.

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{alper2026,
  author = {Alper, Şevval},
  title  = {{AIM-Code Bench: Benchmark de Programação Agêntica}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Acessado em 22 setembro 2026}
}

Registro de alterações

13 atualizações

Todas13Geral9Metodologia4

2026

1. 23 jul

   Adicionados os resultados dos modelos Kimi K3 e Inkling ao ranking do benchmark.

2. 23 jul

   Adicionados Kimi K3 e Inkling ao benchmark de codificação agêntica.

3. 10 jul

   Adicionados o Grok 4.5 e a família de modelos GPT 5.6 à comparação do benchmark de codificação.

4. 10 jul

   Adicionados sete modelos ao benchmark: Grok 4.5 e a família GPT-5.6 (Sol, Terra, Luna).

5. 2 jul

   Adicionada comparação dos modelos especializados em código GPT 5.3 Codex e Kimi K2.7 Code à seção de pontuação de backend.

6. 1 jul

   Adicionado o Claude Sonnet 5 ao ranking do benchmark com pontuação geral de 0,772.

7. 15 jun

   Adicionados Kimi K2.7 Code e Claude Fable 5 aos resultados do benchmark e às seções de comparação de custos.

8. 15 jun

   Atualizada a metodologia do harness: Claude Fable 5 rodou na assinatura Claude Code CLI em vez de Opencode via OpenRouter.

9. 3 jun

   Adicionados Claude Opus 4.8, Gemini 3.5 Flash e MiniMax M3 à classificação do benchmark e às comparações de custo.

10. 20 mai

    Substituída a lista de modelos avaliados e todos os resultados de sucesso, custo e latência por novos valores.

11. 20 mai

    Substituído o Aider pelo opencode como harness dos agentes e adicionadas três execuções por célula para medir a variância.

12. 3 abr

    Substituído Gemini 3 Pro por Gemini 3.1 Pro Preview no resumo dos resultados do benchmark.

13. 24 fev

    Adicionado Gemini 3.1 Pro Preview aos resultados do benchmark Agentic LLM.

Şevval Alper

Pesquisadora de IA

Siga-nos

Şevval é pesquisadora de IA na AIMultiple. Ela tem experiência anterior de pesquisa em geração de números pseudoaleatórios usando sistemas caóticos.
Şevval se concentra em ferramentas de codificação de IA, agentes de IA e tecnologias quânticas.

Ver perfil completo

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.

Nome

Endereço de email

Comentário

0/450

Postar comentário