Benchmark de modelos de IA para programação no seu próprio repositório

Por que benchmark público não diz qual modelo é melhor para o seu código?

Benchmarks públicos de programação medem como um modelo se sai num conjunto fixo de tarefas dos outros, num setup dos outros. O seu trabalho é diferente em quase tudo o que decide se um diff presta.

• Outro código. Suas linguagens, frameworks, bibliotecas internas e convenções não estão no conjunto de teste.
• Outro harness. Você roda um agente de CLI com ferramentas, prompts e gestão de contexto próprios, não o modelo puro. O mesmo modelo pode se comportar diferente dentro de dois agentes.
• Outra definição de pronto. Quem define a régua são seus testes, seu linter e seus revisores, não o critério do benchmark.
• Alvo em movimento. Modelos e CLIs de agentes mudam o tempo todo; o ranking do trimestre passado pode não valer para as versões que você roda hoje.
• Diferenças difíceis de ler. Tarefas públicas populares podem vazar para os dados de treino, e as notas do topo costumam ficar coladas.

Ranking serve para montar uma lista curta. Quem bate o martelo é um teste no seu código, com os agentes que você realmente usa (veja como Claude Code, Codex e Gemini CLI se comparam).

O que é um benchmark no seu próprio repositório?

Um benchmark de repositório é um teste pequeno e repetível que dá as mesmas tarefas reais do seu código para vários agentes ou modelos de IA, roda cada tentativa isolada e pontua os resultados com uma rubrica só. Ele responde uma pergunta mais estreita que um ranking, "qual configuração eu uso para este tipo de tarefa, neste repo?", que é a pergunta que você tem de verdade.

Cada concorrente é uma entrada: um agente, um modelo e um nível de esforço. De duas a quatro entradas bastam.

Como escolher as tarefas de um benchmark de programação?

Escolha de três a cinco tarefas parecidas com o seu trabalho real, cada uma com uma definição de pronto que dá para conferir.

• Correção de bug com reprodução: um teste falhando ou passos claros.
• Uma feature pequena que mexe em dois ou três arquivos.
• Um refactor de código que já tem teste cobrindo.
• Testes para um módulo com pouca cobertura.
• O canto mais esquisito do projeto: o módulo legado, o framework interno, o script de build. É onde o treino genérico ajuda menos.
• Fora: tarefas que precisam de segredos de produção ou serviços ao vivo, ou grandes demais para duas tentativas serem comparáveis.

Como rodar a mesma tarefa com vários agentes ao mesmo tempo?

Dê a cada entrada o mesmo prompt, o mesmo commit de partida e um workspace isolado, para uma tentativa não ver nem sobrescrever a outra. No Tallos, dá para fazer na mão ou com uma squad.

O template já vem com um membro, "Resolve o objetivo inteiro de forma independente", com Quantos = 3. Para comparar agentes ou modelos diferentes, use três membros com essa função, cada um com Quantos = 1 e seu próprio agente, modelo e esforço. Veja o playbook melhor de três para uma execução completa, e como os workspaces paralelos usam git worktrees para manter as tentativas separadas.

Faça sua primeira comparação: uma tarefa, três agentes, três worktrees isolados.

Baixar o Tallos →

Como avaliar agentes de IA de programação? Uma rubrica que funciona

Pontue todas as tentativas com os mesmos critérios e anote as notas antes de olhar qual agente gerou qual diff. Se alguém do time puder renomear as branches para A, B e C, revise às cegas.

Leia cada tentativa na revisão de diff; cada comentário de linha que você devolve ao agente conta como retrabalho. Numa squad, edite as instruções do líder para o relatório final trazer esses campos por tentativa, e trate o selo Recomendado como um dado a mais, não como o veredito.

Como fazer um benchmark no meu repositório, passo a passo?

1. 1

   Monte uma lista de duas a quatro entradas

   Escolha agente, modelo e esforço de cada uma e conecte os agentes no Tallos.

2. 2

   Escolha de três a cinco tarefas

   Do backlog ou de tickets já resolvidos, cada uma com a definição de pronto escrita.

3. 3

   Congele o setup

   Mesmo commit base, prompt e modo de permissão. Escreva a rubrica e os pesos antes de rodar qualquer coisa.

4. 4

   Rode as tentativas isoladas

   Um workspace por entrada, ou uma squad "3 tentativas, escolhe a melhor" com um membro por entrada.

5. 5

   Revise e pontue

   Abra as alterações de cada tentativa, rode as checagens e preencha a rubrica. Às cegas, se der.

6. 6

   Repita os casos apertados

   Agente não gera o mesmo diff toda vez. Quando duas entradas ficarem próximas, rode a tarefa de novo.

7. 7

   Decida por tipo de tarefa

   Anote qual entrada vai para bug, feature, refactor e teste, e quando você vai rodar de novo.

Como transformar o resultado do benchmark numa decisão?

Decida por tipo de tarefa, não no geral. É normal uma entrada ganhar em correção de bug e outra em testes.

• Confie em diferença consistente, não em vitória isolada. Ganhar o mesmo tipo de tarefa duas vezes é sinal; uma tentativa brilhante, não.
• Dê peso ao esforço de revisão. Um diff que passa nos testes mas leva uma hora para ganhar sua confiança custa mais que um maior que você lê em cinco minutos.
• Coloque o uso na conta. Deu empate, fique com a entrada que gasta menos. Veja quanto custa rodar agentes em paralelo.
• Transforme em padrão. Guarde a vencedora como squad salva, ou numa tabelinha no repo: tipo de tarefa, agente, modelo, esforço.
• Rode de novo quando algo mudar: modelo novo, versão nova do CLI, refactor grande.

Faça o benchmark dos agentes que você já paga, no código que você realmente entrega.

Baixar o Tallos →