Template de Avaliação de IAs de Coding

Resumo Executivo

O que é este documento: um modelo padronizado para avaliar, de forma comparável e replicável, a capacidade real de ferramentas de IA aplicadas a desenvolvimento (Codex, Devin, Claude e demais), identificando com precisão o que cada uma faz bem, faz mal, ou não faz.

Por que essa metodologia: hoje o mercado divulga números de benchmarks públicos (como SWE-bench e Terminal-Bench) que servem como referência de capacidade geral, mas apresentam duas limitações relevantes para decisão de negócio:

1. Medem desempenho em projetos abertos de terceiros (majoritariamente Python), não refletem o comportamento em codebases proprietários, legados e no stack específico da empresa.


2. O resultado divulgado depende fortemente da ferramenta usada em torno do modelo (a forma como a IA é operacionalizada), não só do modelo em si — comparações "cruas" entre fornecedores tendem a ser enganosas.

Por isso, este template combina três referências reconhecidas no mercado — benchmarks públicos como ponto de partida, uma métrica de escala de dificuldade usada por institutos de avaliação de IA (METR) para medir até onde a ferramenta aguenta, e uma estrutura de avaliação usada em processos de seleção corporativa de ferramentas de IA (dimensões como confiabilidade, rastreabilidade, segurança e custo real) — com um piloto controlado, executado sobre código real da nossa operação, com critério e revisor únicos para todas as ferramentas testadas.

Resultado esperado: uma matriz objetiva, com evidência documentada, que sustenta a recomendação de qual ferramenta adotar, para qual finalidade, e com quais limitações conhecidas.

Princípio metodológico: o teste deve ser conduzido sobre uma tarefa real do backlog, nunca sobre um projeto de demonstração simplificado. A avaliação deve ser conduzida pelo mesmo revisor, com os mesmos critérios, para todas as ferramentas — garantindo comparabilidade.

1. Preparação do teste

• 
  Repositório real, com código legado, particularidades e convenções próprias — não um projeto novo e simplificado. É diante da complexidade real que se evidenciam os limites de cada ferramenta.


• 
  Linha de base humana: cronometrar quanto tempo um desenvolvedor Pleno leva para executar a mesma tarefa, como referência de comparação.


• 
  Revisor único: mesma pessoa e mesmo critério de avaliação (checklist de PR) para todas as ferramentas testadas.


• 
  Repetição: executar cada tarefa 2 a 3 vezes por ferramenta. O resultado de uma IA generativa varia entre execuções, mesmo para o mesmo pedido — uma única tentativa pode distorcer a avaliação.

2. Matriz de Capacidade por Ferramenta

Escala: 0 = não realiza | 1 = realiza com baixa qualidade, exige reescrita | 2 = realiza de forma razoável, exige ajustes | 3 = realiza em nível pronto para PR

3. Teste de Limite de Capacidade

A dificuldade da tarefa deve ser escalonada progressivamente até que a ferramenta apresente falha — o objetivo é documentar em qual estágio cada uma deixa de performar de forma confiável:

1. Tarefa de 1 arquivo, equivalente a menos de 30 min de trabalho humano


2. Tarefa de 2 a 3 arquivos, equivalente a 1-2h de trabalho humano


3. Tarefa que atravessa múltiplos serviços/repositórios, equivalente a meio dia de trabalho humano


4. Tarefa sem especificação clara, que exige tomada de decisão de design, equivalente a um dia de trabalho humano

Esta abordagem é baseada no conceito de Time Horizon, métrica usada pelo instituto de pesquisa

METR para medir não "se a IA acerta", mas até qual complexidade/duração de tarefa humana a ferramenta

ainda mantém taxa de sucesso aceitável. Identificar o estágio em que cada ferramenta falha fornece

mais informação para decisão do que uma nota única.

4. Critérios Corporativos Complementares

5. Ressalvas Metodológicas

• 
  A camada de operacionalização (produto) tem tanto peso quanto o modelo em si. O mesmo modelo (ex.: Claude) executado por diferentes produtos pode apresentar resultados distintos. Recomenda-se registrar não apenas "qual IA", mas "qual IA, em qual produto".


• 
  Benchmarks públicos não são preditivos do caso de uso específico. Os benchmarks de mercado avaliam majoritariamente projetos abertos em Python; não refletem o comportamento em ambiente Java de fintech legado, com Kafka e IBM MQ. Devem ser tratados como referência geral, não como critério de decisão.


• 
  Números divulgados por fornecedores devem ser tratados com cautela, especialmente quando não há metodologia reprodutível associada.


• 
  Demonstração de fornecedor não equivale a piloto controlado. O cenário apresentado em demonstrações tende a ser favorável (projeto simples e recente). A avaliação deve ocorrer sobre código real da operação, incluindo débito técnico.


• 
  O custo oculto deve ser mensurado. Tempo adicional de revisão sênior para correção do que foi gerado pela IA é custo, não apenas o tempo nominal economizado — deve compor o cálculo final de ganho de produtividade.

6. Prompts Padronizados para Execução dos Testes

Recomenda-se aplicar os mesmos prompts (ajustando apenas nome de arquivo/função) em Codex, Devin e Claude, garantindo comparabilidade entre os testes.

Correção de bug simples (1 arquivo)

"No arquivo [caminho], o teste [nome do teste] está falhando. Investigue a causa e corrija, sem alterar o comportamento esperado do teste."

Correção de bug cross-service

"O serviço [A] está retornando erro quando chama [B]. Rastreie o fluxo completo entre os dois serviços, identifique a origem do problema e proponha a correção. Antes de editar, indique quais arquivos pretende alterar."

Análise de impacto de mudança de assinatura

"Quero alterar a assinatura do método [nome] de [assinatura atual] para [nova assinatura]. Antes de qualquer alteração, liste todos os pontos do projeto que chamam esse método e o que será impactado."

Aderência a padrão existente

"Crie um novo endpoint [descrição] seguindo exatamente o mesmo padrão de arquitetura, nomenclatura e tratamento de erro já utilizado nos demais endpoints deste projeto. Não introduza um padrão novo."

Retenção de contexto (executar em sessão nova)

"Sem que eu forneça o contexto novamente: qual é a convenção que este projeto utiliza para tratamento de exceções? E para nomenclatura de branches?"

(aplica-se quando a ferramenta possui memória entre sessões — caso ela solicite o contexto de volta, esse já é um dado relevante sobre sua limitação)

Reconhecimento de limitação de conhecimento

"Implemente [funcionalidade dependente de uma biblioteca ou API que você sabe que não existe ou mudou recentemente]."

Objetivo: verificar se a ferramenta sinaliza incerteza, ou gera código plausível porém incorreto.

Análise sem execução

"Não realize nenhuma alteração ainda. Apenas explique: se eu alterar o tipo de retorno de [função] de X para Y, o que é impactado no projeto?"

Cobertura de teste

"Escreva testes unitários para [classe/função]. Inclua ao menos um cenário de borda não óbvio — entrada nula, lista vazia, concorrência ou timeout."

Teste de limite de complexidade (estágio 4 da seção 3)

"Preciso de [funcionalidade nova, sem especificação detalhada, que exige decisão de design]. Propositalmente não fornecerei todos os detalhes — faça as perguntas que considerar necessárias antes de iniciar a implementação."

Objetivo: verificar se a ferramenta solicita esclarecimento antes de agir, ou avança sobre premissas não validadas.

7. Fontes

• SWE-bench / SWE-bench Verified / Pro — arxiv.org/pdf/2509.16941, swebench.com


• Terminal-Bench 2.1 — tbench.ai, arxiv.org/html/2601.11868v1


• METR Time Horizon — metr.org/time-horizons, arxiv.org/html/2503.14499v1


• Checklist enterprise 6 dimensões (adaptado) — augmentcode.com/guides/cto-ai-coding-checklist


• Pilot enterprise (metodologia de rollout) — lumenalta.com/insights/how-to-evaluate-ai-coding-tools-for-enterprise-teams


• Governança de benchmarks / harness effect — digitalapplied.com/blog/swe-bench-terminal-bench-benchmark-guide-2026


• Devin SWE-bench technical report — cognition.ai/blog/swe-bench-technical-report