Template de Avaliação de IAs de Coding

#ai #coding #softwaredevelopment #testing

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:

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.
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

Capacidade avaliada	Codex	Devin	Claude	Outra
Corrigir um bug simples em um único arquivo
Corrigir um bug que envolve múltiplos serviços simultaneamente
Alterar a assinatura de uma função e ajustar todos os pontos que a utilizam
Criar um novo endpoint seguindo o padrão já existente no projeto
Reter contexto de uma decisão do projeto após reabertura de sessão
Responder "se eu alterar isso, o que mais é impactado?" apenas com análise, sem executar mudanças
Escrever testes que cobrem cenários relevantes, não apenas o caminho principal
Compreender uma dependência de um projeto que não está aberto no contexto atual
Seguir os padrões de arquitetura do time sem instrução repetida
Reconhecer limitação de conhecimento e solicitar mais contexto, em vez de gerar resposta incorreta com aparência de correta

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:

Tarefa de 1 arquivo, equivalente a menos de 30 min de trabalho humano
Tarefa de 2 a 3 arquivos, equivalente a 1-2h de trabalho humano
Tarefa que atravessa múltiplos serviços/repositórios, equivalente a meio dia de trabalho humano
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

Dimensão	Critério de avaliação	Codex	Devin	Claude
Consistência	O resultado varia significativamente entre execuções para o mesmo pedido?
Rastreabilidade	É possível identificar posteriormente qual ferramenta/versão gerou cada alteração?
Retenção de contexto	A ferramenta compreende o projeto como um todo ou apenas o que está aberto no momento?
Reversibilidade	Em caso de erro, é possível reverter apenas a alteração específica, ou o impacto se espalha por múltiplos arquivos?
Segurança da informação	Onde o código é processado/armazenado? Há uso do código para treinamento de modelo?
Custo real	Qual o tempo de revisão humana efetivamente economizado, descontado o tempo gasto em correções?

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