Como meu agente de IA mudou a forma como os times da empresa fazem code review e o que aprendemos no caminho

O contexto: code review na era da IA
Code review sempre foi um dos rituais mais importantes da engenharia. Mas seja honesto: quantas vezes um PR fica parado por dias esperando alguém olhar? Quantas vezes a revisão acontece no automático, com um "tá bom, pode subir" depois de bater o olho em 800 linhas?

Numa era em que muito código é escrito por IA, revisar virou ainda mais crítico. Código gerado por IA tende a parecer correto, e é justamente aí que mora o risco.

E quando falamos de segurança, o jogo muda completamente. SQL injection, secrets vazados, criptografia mal implementada, validação ausente. Esses são bugs que você NÃO quer descobrir em produção. Revisão de segurança exige um tipo de raciocínio diferente da revisão de engenharia: outro vocabulário, outro modelo mental, outros padrões.

A decisão: dois subagentes especializados, não um generalista
Aqui está a primeira lição que quero compartilhar: misturar code review e security review num único agente produz um resultado não tão bom nos dois lados.

Foi por isso que o projeto nasceu com dois subagentes independentes, cada um com seu foco e, importante, cada um rodando em um modelo de IA diferente. Um é responsável pela revisão de engenharia (arquitetura, performance, qualidade) e roda no Gemini 3, o modelo mais recente do Google. O outro é responsável pela revisão de segurança (OWASP, secrets, crypto) e roda no Claude Opus 4.7, o modelo mais avançado da Anthropic.

A escolha de cada modelo foi proposital. O Gemini 3 tem se mostrado excelente em raciocínio sobre código em escala, captando padrões arquiteturais e questões de performance com bastante precisão. Já o Claude Opus 4.7 brilha em tarefas que exigem raciocínio cuidadoso, output estruturado e atenção ao detalhe, exatamente o perfil que segurança demanda.

Essa estratégia de usar dois modelos diferentes traz um benefício importante: de certa forma, você recebe dois pontos de vista distintos sobre o mesmo Pull Request. Modelos diferentes foram treinados em corpora diferentes, têm vieses diferentes, e enxergam coisas diferentes. Quando dois modelos olham para o mesmo código com objetivos distintos, o resultado é uma revisão muito mais rica do que qualquer um deles entregaria sozinho.

Stack resumida: FastAPI + asyncio para o orchestrator, SQLite com WAL para estado, Gemini 3 + MCP para code review, Claude Opus 4.7 (via AWS Bedrock + tool use) para segurança, structlog para observabilidade.

Os dois rodam em paralelo sobre o mesmo PR. Um delega segurança ao outro. O outro delega arquitetura ao primeiro. Sem sobreposição, sem ruído.

Por que não usamos uma ferramenta pronta
Existem várias soluções comerciais de code review com IA no mercado. Avaliamos várias. E mesmo assim escolhemos construir. Três motivos:

1. Customização real para os padrões da empresa. Cada projeto nosso tem um arquivo de contexto que descreve os padrões daquele repositório: ADRs, idioms, decisões arquiteturais, convenções específicas. O agente carrega esse contexto antes de revisar. Isso significa que ele não fala "use prepared statements" como conselho genérico. Ele aponta o padrão exato que o time já adotou, no estilo que o time já documentou. Ferramentas externas não conseguem esse nível de contextualização personalizavel.

2. Qualidade dirigida ao nosso problema. Conseguimos calibrar a confiança mínima dos findings, escolher os modelos certos para cada tipo de análise, e forçar output estruturado onde isso importa (segurança). Conseguimos decidir o que vira comentário e o que não vira. A revisão fica focada em sinal, não em ruído.

3. Custo controlado. Soluções SaaS cobram por seat, por PR, ou por linha analisada. Com a infra própria, pagamos só o custo dos tokens. E ainda conseguimos aplicar filtros agressivos antes de gastar uma chamada de modelo (PRs muito grandes, paths ignorados, bots de dependência, etc.). Em escala, a economia é considerável.

Some isso ao fato de que nada do nosso código sai da nossa infra para um terceiro, e a equação fica clara.

O impacto nos times
O que mudou no dia a dia desde que o sistema entrou em produção, em todos os times da empresa:

Cobertura sistemática. Todo PR é revisado por IA em minutos, independente de quem está disponível. Ninguém mais espera dias por uma primeira passada.

Revisores humanos focam no que importa. Decisões de produto, contexto de negócio, trade-offs arquiteturais. Coisas que IA não captura. Os N+1, os secrets esquecidos, as queries concatenadas, os agentes pegam. Importante deixar claro: a revisão humana não deve ser descartada. O agente não substitui o olhar de outro dev sobre o código, ele potencializa esse olhar. O humano continua sendo a última palavra antes do merge.

Os devs estão aprendendo com os code reviews. Esse é, talvez, o ganho que mais me surpreendeu. Os comentários do agente de code review são pedagógicos por design. Ele não só aponta o problema, ele explica o porquê e mostra como resolver da forma correta. Devs novos absorvem padrões só de ler a revisão dos próprios PRs. Devs mais experientes redescobrem alternativas que tinham esquecido. O code review virou uma ferramenta de aprendizado contínuo, não só um portão de qualidade.

Defesa em profundidade na segurança. O agente de segurança não substitui SAST, DAST ou revisão humana de segurança. Complementa. Mais uma camada antes do código entrar em master.

Velocidade. Feedback chega enquanto o contexto ainda está fresco na cabeça de quem escreveu. Correção é rápida, custo cognitivo baixo.

A lição mais importante
Construir foi mais simples do que eu imaginava, e mais profundo do que eu esperava. A parte difícil não é integrar com um LLM. É decidir o que pedir, como pedir, e como filtrar o que volta. É decidir que segurança merece output estruturado e auditável enquanto code review pode ser texto livre conversacional. É decidir que dois subagentes especializados batem um generalista. É escolher modelos diferentes propositalmente, para ganhar a riqueza de duas perspectivas.

IA não substitui revisão. IA muda quem revisa o quê. Os humanos sobem na cadeia de abstração e ganham tempo para pensar nas coisas que realmente exigem julgamento humano. E, no caminho, todo o time aprende.

Se você está pensando em adotar revisão automatizada no seu time, meu conselho é: experimente construir. Você vai aprender mais sobre o seu próprio processo de revisão do que qualquer ferramenta pronta vai te ensinar.