Nos últimos meses, a adoção de IDEs com IA explodiu – de repente, todo dev tem um “assistente” de IA no editor.
Só que, convenhamos, escrever código é a parte divertida.
Revisar código, nem tanto.
Aí bateu a dúvida: será que os grandes modelos de linguagem (LLMs) conseguem dar conta de revisar PRs sozinhos?
Testamos os clássicos (GPT-4o e Claude Sonnet 3.7) contra nosso pipeline, Kody, e este benchmark mostra o que rolou.
A Realidade de Revisões de Código Feitas por LLM
Deixar um LLM revisar seu código parece incrível… até perceber que eles podem ser bem “prolixos”.
Soltam um monte de informação extra – às vezes irrelevante ou até errada. Em resumo:
- Treino em Código Imperfeito: LLMs aprendem de tudo: tanto código top quanto uns péssimos. Isso significa que podem absorver umas práticas questionáveis.
- Ruído ao Invés de Sinal: Mesmo quando encontram um bug de verdade, te afogam em um mar de sugestões “mais ou menos”.
- Lógica vs. Sintaxe: Mandam bem no syntax check, mas não entendem muito a lógica profunda do seu código. O ruído só piora as coisas, misturando um monte de comentário desnecessário.
TL;DR: Contar só com um LLM “puro” pode deixar seu code review bagunçado. Entra em cena o pipeline agente da Kody, que filtra esse barulho todo e entrega insights mais objetivos.
Como Montamos o Benchmark
Dataset
Pegamos 10 pull requests (PRs) de um repositório—(trabalho em andamento, viu?)—e rodamos três revisões diferentes em cada um:
- Kody
- Claude Sonnet 3.7
- OpenAI GPT-4o
Métricas
Analisamos:
- True Positives (TP): Problemas reais que foram pegos.
- False Positives (FP): Alertas que não eram problemas de verdade.
- False Negatives (FN): Bugs que passaram batido.
Com isso, calculamos:
- Precisão (Precision): Quão confiáveis são os alertas.
- Cobertura (Recall): Quantos problemas reais foram detectados.
- F1 Score: Combinação balanceada de precisão e cobertura (tudo em um número só).
Também checamos desvio padrão e coeficiente de variação (CV) pra ver se o modelo mantém consistência ou joga dados na hora de revisar.
O Que É o Coeficiente de Variação (CV)?
O CV basicamente mostra o quanto os resultados estão espalhados em relação à média, calculado assim:
CV = (Standard Deviation / Mean) × 100%
- Sem Unidade: Dá pra comparar coisas de diferentes escalas sem bagunça.
- CV Alto: Significa que seu modelo é mais inconstante que uma bolsa de criptomoedas.
- Normalização: Coloca a variabilidade em perspectiva com a média.
Nossos Resultados (CV)
- Kody (0,402): Bem consistente.
- Claude (0,774): Meio indeciso.
- GPT (1,651): Totalmente inconstante.
Guia Rápido:
-
- CV < 0,15 → estável demais
- 0,15–0,30 → variação moderada
- 0,30 → segura na cadeira que vai balançar
Adicionando um Fator de Consistência
Pra ficar justo, mas sem perdoar tudo, aplicamos uma penalização de consistência (peso = 0,2) que reduz a pontuação se o modelo variar demais:
- Kody: Score ajustado ~0,581 (redução de 8%)
- Claude: ~0,283 (caiu uns 15,5%)
- GPT: ~0,072 (levou uma surra de 33%)
Se quiser ser mais “bonzinho”, baixa o peso pra 0,1. Se quiser punir pesado, sobe pra 0,5. Escolhemos 0,2 porque equilibra penalizar a galera inconsistente sem anular o resto do desempenho.
Resultados
Bora ver o placar final:
-
F1 Original
- Kody: ~0,65
- Claude: ~0,48
- GPT: ~0,18
- Kody é ~1,35× melhor que Claude e ~3,6× melhor que GPT.
-
F1 Ajustado (DP)
- Kody: ~0,60
- Claude: ~0,40
- GPT: ~0,15
- Kody ~1,5× maior que Claude e ~4× maior que GPT.
-
F1 Ajustado (CV)
- Kody: ~0,58
- Claude: ~0,28
- GPT: ~0,07
- Kody ~2,1× maior que Claude e ~8,3× maior que GPT.
Em resumo: Kody lidera no quesito consistência e performance. Claude fica no meio do caminho. GPT-4o, usado cru, oscila bastante e desce lá pra baixo.
Próximos Passos
Esse estudo tá só começando. A gente vai continuar avaliando mais PRs, mais linguagens, e talvez alguns modelos adicionais só pra ver se sobrou alguém que aguente o tranco. A ideia é evoluir sempre e trazer um panorama cada vez mais completo de como essas ferramentas se saem em cenários reais de code review.
—
