Automação de Code Review: como as redes neurais estão assumindo a rotina dos desenvolvedores

Por que a automação é necessária

A Avito gera mil pull requests por semana — até 300 simultâneos nos horários de pico. Isso cria uma carga enorme sobre os desenvolvedores, que são tirados do trabalho principal para fazer code review. O resultado: PRs podem ficar dias na fila de revisão, o time-to-market de novas funcionalidades aumenta, a equipe se cansa e pode deixar passar bugs críticos.

O time de engenheiros de LLM definiu três objetivos para a automação:

• Acelerar o desenvolvimento — eliminar as filas de revisão • Reduzir a influência do fator humano — a troca constante de contexto faz os desenvolvedores perderem o foco • Unificar o processo — revisores diferentes fazem observações diferentes, e muitas vezes surge subjetividade

Arquitetura do sistema

O sistema é composto por três componentes conectados em um fluxo de trabalho claro:

1. Stash — a interface onde o desenvolvedor deixa o comentário ai_review no PR 2. Serviço em Go — recebe o evento do Data Bus, analisa o comando, pega o diff e os metadados do repositório, grava a revisão no banco de dados com status STATE_REQUESTED e envia um RPC para o serviço de ML 3. Serviço Python ML Pipeline — processa o contexto e retorna os comentários gerados

O serviço de ML responde com 200 OK imediatamente para não bloquear o serviço em Go, já que a geração pode demorar.

Pipeline de ML: três etapas

RuleChecker (geração). O modelo identifica todos os problemas potenciais, com base em uma taxonomia de erros extraída de PRs reais do time. É otimizado para alto recall, mesmo que isso gere falsos positivos. A saída é um JSON com números de linha e recomendações.

ReviewFilter (validação). Uma segunda passagem melhora a precisão. O modelo opera no padrão Conclusion First — recebe o mesmo contexto mais um comentário específico e responde se aquela observação é importante ou não. Elimina 90% das alucinações e falsos positivos.

CommentAggregator (deduplicação). O sistema constrói embeddings dos comentários com o BAAI/bge-m3 e calcula a similaridade de cosseno. Se a similaridade for maior que 0,85, os comentários são agrupados. De cada grupo, sobra apenas o mais substancial. A saída é uma lista final de observações únicas.

Escolha do modelo e desempenho

No benchmark MERA-RuCodeReviewer (689 exemplos em Java, Python, Scala e Go), o Gemini 2.5 Flash lidera, mas o time escolheu o Qwen3-Coder-30B-Instruct-FP8 (segundo lugar) porque é open-source e pode ser hospedado na própria infraestrutura. Isso é crucial: o código não sai para APIs externas, e o self-hosting fica mais barato em grande escala (os PRs exigem de 2.000 a 10.000 tokens).

Desempenho: • PRs pequenos (até 3 arquivos): 10–20 segundos • PRs grandes (10+ arquivos): ~60 segundos • Máximo de 650 revisões em paralelo

As métricas de qualidade são coletadas a partir dos likes dos desenvolvedores: • Precisão: 85% dos comentários são classificados como bons • Taxa de obsolescência: 32% (comentários que o desenvolvedor encerrou ao corrigir o problema). Para Infra e DevOps, chega a 60%.

Principais conclusões

A ideia central: separar Recall e Precision funciona melhor do que uma única requisição. Mesmo com um contexto longo, o modelo se perde, por isso é necessário um sistema de múltiplas etapas. A validação que elimina alucinações é crítica — é a base da confiança dos usuários.

O modelo precisa ver o código completo dos arquivos e a estrutura do repositório — o diff por si só não é suficiente para uma análise de qualidade. A IA assume a rotina, mas as pessoas devem continuar controlando o processo.