Benchmark de código ou benchmark de agente: qual olhar antes de escolher o modelo?

Fala aí, beleza? Tem uma cena que se repete toda vez que sai modelo novo: o pessoal abre o gráfico, vê uma barrinha maior que a outra e já troca de ferramenta

Só que existe um detalhe que quase ninguém olha: qual tipo de prova aquele número está medindo

Porque tem benchmark que pede pra IA gerar uma função e conferir se ela passa nos testes, uma resposta e acabou

E tem benchmark que solta a IA dentro de um ambiente, com ferramentas na mão, e mede se ela termina uma tarefa longa, corrigindo os próprios erros no meio do caminho

São coisas MUITO diferentes

Se você usa o modelo no chat pra escrever um trecho de código, uma família de resultado te interessa. Se você usa o modelo como agente rodando no terminal do seu projeto, é a outra família que importa

Bora separar isso direito?

Benchmark de código vs benchmark de agente: as diferenças que importam

Antes de entrar em cada um, uma foto rápida do que muda de um lado pro outro:

Repara na linha mais importante da tabela: o que a nota inclui

É ali que mora quase toda a confusão de leitura que eu vejo por aí

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Benchmark de resposta única: o que o HumanEval realmente mede

O HumanEval é o clássico dessa família

Ele é composto por 164 problemas de programação escritos à mão, e cada problema vem com assinatura de função, docstring e testes unitários, com média de 7,7 testes por problema

A métrica é o pass@k: o modelo gera k amostras e você olha se alguma delas passa nos testes

E aqui vem a característica que define tudo: é avaliação single-turn

O modelo gera o código uma vez, sem loop de feedback, sem execução de ferramentas e sem oportunidade de corrigir o próprio erro

Ou seja, o que está sendo medido é a capacidade de acertar de primeira em um problema fechado

Isso já foi bem discriminante:

No paper original do Codex, um modelo de 12 bilhões de parâmetros resolvia 28,8% dos problemas do HumanEval com uma única amostra

Com 100 amostras, esse mesmo modelo chegava a 70,2%

Guarda esses dois números como referência histórica, não como estado atual: eles mostram um momento em que uma diferença de nota no HumanEval realmente separava um modelo do outro

Hoje esse tipo de prova ficou apertada demais lá em cima, e é por isso que ela sozinha não decide mais nada quando você usa IA em fluxo de trabalho de verdade

Benchmark de agente: tarefa longa, ferramentas e erro corrigido no meio

Agora o outro lado da moeda

Um benchmark de agente não pergunta "esse código passa no teste?", ele pergunta "essa tarefa foi concluída?"

Muda tudo, porque no meio do caminho a IA precisa ler arquivo, rodar comando, ver o erro que voltou e decidir o que fazer com ele

SWE-bench Verified:

O SWE-bench Verified é um subconjunto de 500 instâncias do SWE-bench, filtradas por revisores humanos a partir de 1.699 amostras anotadas, em colaboração com a OpenAI

A tarefa é resolver uma issue real de GitHub em Python

Ou seja: repositório de verdade, problema de verdade, não exercício de entrevista

Terminal-Bench:

O Terminal-Bench avalia agentes executando tarefas de ponta a ponta no terminal

Compilar repositórios, treinar modelos, configurar servidores, depurar ambientes

Não são funções isoladas, é fluxo completo, do tipo que você abre o terminal e passa a tarde nele

Ele nasceu de uma colaboração entre a Universidade de Stanford e o Laude Institute, e hoje é hospedado pelo Harbor junto com o Laude Institute

SWE-bench Pro:

O SWE-bench Pro, da Scale AI, foi desenhado pra resistir a contaminação

A sacada é usar repositórios com licenças copyleft fortes como barreira legal contra a inclusão daquele código nos dados de treino

São 1.865 instâncias no total, sendo 731 públicas, 858 retidas e 276 comerciais, distribuídas em 41 repositórios

E não é só código que virou tarefa de agente: a mesma lógica aparece quando você compara agentes de IA fora do código, onde o que conta também é terminar o trabalho, não gerar um trecho bonito

Por que os números dos benchmarks de código envelhecem tão rápido

Aqui a coisa fica interessante

A OpenAI deixou de usar o SWE-bench Verified como medida de capacidade de código de fronteira, e publicou um documento explicando o porquê: o benchmark não entrega mais sinal significativo

E tem auditoria por trás dessa decisão, não é achismo

Foram pegos 138 problemas do SWE-bench Verified que o o3 não resolveu de forma consistente em 64 execuções, e esses problemas foram revisados por engenheiros experientes

Resultado: 59,4% deles apresentavam falhas materiais no desenho dos testes ou na descrição do problema

E 35,5% tinham testes que exigem detalhes de implementação específicos, o que penaliza uma solução alternativa que funcionaria igual

Se liga no que isso significa na prática: parte do que parecia "o modelo errou" era, na real, o problema estar mal desenhado

Por isso nota velha não serve como critério de escolha. Tome cuidado com print de gráfico circulando sem data e sem versão, é o erro mais comum de todos

A nota do benchmark agêntico não é só do modelo

Essa é a parte que eu queria que todo mundo lesse duas vezes

Um agente de código, na prática, não é um modelo

É um sistema: modelo, harness, contexto, ambiente e sinais de feedback

E qualquer um desses componentes pode mover a nota do benchmark em margens comparáveis à diferença entre gerações de modelo

Pensa assim: é como comparar dois pilotos sem olhar o carro, a pista e o rádio da equipe

O piloto importa, claro, mas a volta cronometrada é do conjunto

Um position paper aponta exatamente isso: os benchmarks de código atuais foram desenhados na era pré-agente

Os sintomas que ele lista são três:

• a nota colapsa modelo e harness em um número só de ponta a ponta
• a correção contra uma única solução de referência penaliza alternativas válidas
• falta sinal por componente, então você não consegue saber o que melhorar

Ou seja, quando você lê um benchmark de agente, o que está na sua frente é a nota de um sistema inteiro

Trocar o harness pode mudar o resultado tanto quanto trocar de geração de modelo

Como ler uma nota agêntica: harness, versão e condição de execução

Beleza, e como eu leio isso sem me enganar?

A resposta é olhar o que vem GRUDADO no número

A versão do benchmark importa:

O Terminal-Bench 2.0 tem 89 tarefas

A versão 2.1 corrigiu problemas em 28 dessas 89 tarefas, ajustando instruções subespecificadas, testes que exigiam demais ou de menos e limites de memória, CPU e timeout

Depois das correções, nenhuma tarefa segue sem solução

Já a nota de versão do Terminal-Bench 4.0 calibra recursos das tarefas, aplica correções e remove tarefas saturadas, adotando timeout fixo de 8 horas por agente

E a 4.1 foi anunciada como a próxima, com verificadores resistentes a adulteração

Percebe? Comparar nota de versões diferentes do mesmo benchmark é comparar prova diferente

O harness importa:

E o que é o harness, afinal?

É a casca que roda o modelo: quem entrega as ferramentas, executa os comandos, devolve a saída e deixa o modelo decidir o próximo passo

Se você conhece a diferença entre o motor e o carro inteiro, é isso: o modelo é o motor, o harness é o resto do carro em volta

Por isso o benchmark agêntico sempre diz qual harness rodou. No Terminal-Bench 2.0, o harness oficial é o Harbor, e o benchmark é contínuo, com releases publicados no Harbor Hub

Mesmo modelo em harness diferente pode dar nota diferente, e volta o ponto do position paper ali de cima: essa diferença pode ser do tamanho de uma troca de geração de modelo

Então, quando a tabela não diz o harness, você não está comparando modelos, está comparando dois sistemas que você não conhece

A condição de execução importa:

Aqui entram os limites de quem rodou a prova: quanto tempo o agente tinha, quanta memória e CPU ele podia usar

Não é detalhe pequeno, olha a evolução do próprio Terminal-Bench: a versão 2.1 mexeu em limites de memória, CPU e timeout junto com as correções de tarefa, e a 4.0 fixou o timeout em 8 horas por agente

Ou seja, a régua de execução mudou de versão pra versão, e nota rodada em condição diferente não é a mesma prova

Leitura completa é aquela em que o número vem com endereço: versão do dataset, harness e condição de execução do lado

Quando vier só "modelo X tirou tanto", desconfia

O que dá pra medir sozinho: o teste que fizemos com duas ferramentas

Agora deixa eu aterrissar isso com material meu

Quando testei duas ferramentas de código no mesmo projeto, com os mesmos prompts e configurações pareadas sempre que dava, montei uma ficha técnica antes de abrir qualquer editor e coloquei três benchmarks lado a lado na tela

Os três não concordavam entre si

E ainda tem o detalhe de que parte desses dados é autorreportada pelas próprias empresas, o que já pede um pé atrás na leitura

Aí eu parti pro teste prático, estruturado em rounds: design, autenticação e sistema base, integração com IA e regra de negócio, e um jogo 3D em prompt único

O engraçado é que, no meio da execução, eu parei de olhar o resultado e comecei a olhar o COMPORTAMENTO de agente

Uma das ferramentas terminou a primeira etapa do projeto em 11 minutos

A outra, quando eu fui checar, já estava em 12 minutos rodando e ainda não tinha terminado

Nessa mesma etapa, a cota caiu de 100% para 83%, e eu cheguei a duvidar se conseguiria terminar o exemplo dentro do limite

E teve o momento que mais me chamou atenção: vi uma das ferramentas disparar 2 subagents em paralelo enquanto a outra ainda estava na fase de pensamento

Teve também uma delas travando na hora de executar a estrutura de pastas e errando um comando, o que atrasou aquele lado

E uma gerou imagens durante a tarefa por ter geração de imagem à disposição, enquanto a outra não faz isso por padrão, com prompt idêntico nos dois

Me incomodou ainda a falta de visibilidade de um dos lados: ele dizia o que estava fazendo, mas não mostrava a lista do que ainda faltava, e eu gosto de acompanhar o progresso

Olha só o que NADA disso aparece em nota de benchmark de código: tempo até a entrega, consumo de cota, estratégia de execução, comando errado no meio, visibilidade do que falta

E é exatamente isso que você sente no uso agêntico do dia a dia

A mesma diferença aparece quando você compara um agente de design rodando no laptop: o que decide é o comportamento durante a tarefa, não a barrinha do gráfico

No vídeo acima eu mostro esse teste rodando, com os dois lados lado a lado e os arquivos sendo gerados em tempo real, vale ver o comportamento no meio da execução 🙂

Veredito: qual benchmark olhar, dependendo do seu uso

Não existe "o benchmark certo", existe o benchmark certo PRA VOCÊ

Se você usa o modelo no chat, gerando função isolada: olhe o benchmark de código, tipo o HumanEval, com a ressalva de que ele mede resposta única, sem ferramentas e sem iteração, e já não separa muito bem os modelos de hoje

Se você usa o modelo de forma agêntica, no terminal, resolvendo issue real ou tarefa longa: olhe o benchmark de agente, e leia sempre a versão do dataset, o harness usado e a condição de execução junto do número

Sem esses três dados, o número é só um número solto

E lembra do que já discutimos aqui: parte do que a nota agêntica mede é o sistema em volta do modelo, não o modelo puro

A decisão final continua vindo do teste no seu próprio fluxo, com o seu stack e o seu tipo de tarefa

Conclusão

Recapitulando bem rápido: benchmark de código mede uma resposta gerada de uma vez, sem ferramenta e sem correção no meio

Benchmark de agente mede tarefa concluída dentro de um ambiente, e a nota é do conjunto modelo mais harness mais contexto

O próximo passo é simples e você faz hoje: pega uma tarefa real do seu projeto, roda ela nas duas ferramentas candidatas e mede três coisas, tempo até terminar, consumo de cota e quantas vezes o agente se corrigiu sozinho

Foi assim que eu fiz no teste, e foi ali que a diferença apareceu de verdade

Faça o teste e me conta o que deu…

Até o próximo post! 😀