Carregando
Code review manual não escala quando o time cresce. Veja como configurar reviews automáticos com IA que encontram bugs reais, não só erros de formatação.
Como Automatizar Code Reviews com IA (Setup. Code review manual não escala quando o time cresce. Veja como configurar reviews automáticos com IA que encontram bugs reais, não só erros de formatação.
Num time de 3 devs, code review manual funciona. Todo mundo conhece o código, o contexto está fresco na cabeça, os PRs são pequenos e frequentes. Quando o time cresce para 8, 10, 15 pessoas, a conta muda. Os PRs ficam maiores porque as pessoas esperam ter 'tempo' para revisar. O tempo de cycle time — do PR aberto ao merge — estica de horas para dias. A qualidade das reviews cai porque todo mundo está correndo.
O problema mais insidioso: reviews superficiais dão falsa segurança. Um LGTM de 30 segundos não é review — é permissão sem responsabilidade. E o dev que abriu o PR assume que alguém verificou quando na verdade ninguém verificou direito. Bugs de lógica sutil, problemas de segurança, regressões de performance passam não porque o time não sabe encontrá-los, mas porque ninguém teve energia ou tempo pra olhar com atenção.
IA não cansa. Não tem dias ruins. Não vai fazer review superficial porque está com a cabeça em outra coisa. Pra cada PR, ela vai olhar o código com a mesma atenção — seja o primeiro do dia ou o décimo. Isso não substitui o julgamento humano sobre decisões de produto e arquitetura, mas garante uma camada de qualidade consistente que humanos cansados não conseguem manter.
O mercado de ferramentas de AI code review cresceu rápido em 2025 e 2026. As principais opções são: CodeRabbit, Qodo (antigo CodiumAI), Graphite Review e a abordagem DIY com Claude API via GitHub Actions. Cada uma tem seu perfil de uso.
A abordagem DIY com Claude API via GitHub Actions é a mais flexível e a mais poderosa para times com necessidades específicas. Você controla exatamente o prompt, as regras de review, o formato dos comentários e o que aciona o review. O custo é direto — você paga por tokens da Anthropic — e fica mais barato quanto mais você otimiza os prompts. A desvantagem é o trabalho de setup e manutenção.
Por que Claude especificamente? Porque o modelo tem janela de contexto grande o suficiente para processar PRs médios inteiros, tem capacidade de raciocínio que encontra bugs de lógica (não só de sintaxe) e escreve comentários em português de forma natural. GPT-4o também funciona bem, mas para code review com contexto maior, Claude 3.7 Sonnet costuma ter vantagem.
CodeRabbit é a ferramenta pronta mais popular. Você instala como GitHub App, configura um arquivo .coderabbit.yml no repositório e ele começa a revisar PRs automaticamente. O plano gratuito cobre repositórios públicos e oferece reviews básicos. O Pro custa a partir de $12/usuário/mês e adiciona reviews mais profundos, contexto de codebase e integração com Jira e Linear.
Qodo foca em geração de testes além de review. Para cada mudança de código, ele sugere testes que deveriam cobrir o novo comportamento. É mais opinionado que o CodeRabbit sobre o que deve existir no seu projeto, o que pode ser vantagem ou incômodo dependendo do seu estilo de trabalho. Graphite combina review de IA com stacked PRs — mais interessante para times que trabalham com muitos PRs pequenos em série.
Vou mostrar como montar um review automático com Claude API e GitHub Actions. O objetivo: toda vez que um PR é aberto ou recebe novos commits, o workflow roda, manda o diff para o Claude e posta os comentários de review diretamente no PR.
Cria o arquivo .github/workflows/ai-review.yml. O trigger é pull_request com tipos opened, synchronize e reopened. Você vai precisar de dois secrets no repositório: ANTHROPIC_API_KEY com sua chave da API da Anthropic e GITHUB_TOKEN que já vem automático nas Actions. O job precisa de permissão de leitura no pull-requests e escrita para comentar.
O passo principal do workflow: usa a GitHub CLI para pegar o diff do PR com `gh pr diff $PR_NUMBER`, manda esse diff para a Claude API via curl com o prompt de review, e posta o resultado como comentário no PR com `gh pr comment`. A lógica toda pode ser um script Python ou Node.js — fica mais fácil de manter do que tudo inline no YAML.
O prompt é onde a maioria das implementações peca. Prompts vagos geram reviews genéricos que não agregam nada. O prompt deve especificar: foco em bugs de lógica e edge cases não tratados, problemas de segurança como SQL injection e exposição de dados, problemas de performance óbvios, e violações das convenções do projeto que você listou no prompt de sistema.
Um prompt que funciona: 'Você é um revisor de código sênior especializado em [stack do projeto]. Analise o diff abaixo e identifique: 1) Bugs de lógica ou edge cases não tratados, 2) Problemas de segurança, 3) Problemas de performance com impacto real, 4) Violações das convenções do projeto. Para cada problema encontrado, explique por que é um problema e sugira a correção. Não comente sobre estilo ou formatação — esses são cobertos pelo linter. Se o código estiver correto e sem problemas óbvios, diga isso claramente.' Específico, orientado a problemas reais, com instrução clara de quando dizer que está ok.
PRs grandes — mais de 500 linhas de diff — consomem muitos tokens e podem exceder o limite da API. A estratégia: divide o diff por arquivo antes de mandar para o Claude. Para cada arquivo modificado, faz uma chamada separada e consolida os resultados. Isso também ajuda a focar o review nos arquivos mais críticos primeiro — arquivos de autenticação, billing e dados sensíveis devem ter prioridade sobre mudanças de UI ou configuração.
Outra abordagem: filtra arquivos que não precisam de review de IA. Mudanças em package-lock.json, arquivos gerados automaticamente, assets de imagem e documentação não precisam passar pela API. Um filtro simples no script que descarta esses arquivos antes de montar o prompt pode reduzir o custo em 30-40%.
O poder real do setup DIY está na customização. Você pode criar regras específicas para o seu projeto que uma ferramenta genérica nunca vai ter. Exemplos: 'todo endpoint que acessa dados de usuário deve verificar se o userId no token JWT bate com o userId na query', 'mutations no banco de dados devem sempre estar dentro de uma transaction', 'logs nunca devem conter dados de PII como email ou CPF'.
Essas regras ficam num arquivo de configuração — pode ser um .ai-review-rules.md ou um JSON — e são injetadas no prompt de sistema de cada review. Quando a IA revisa um PR, ela está ciente das regras específicas do SEU projeto, não de princípios genéricos de boas práticas. Isso transforma o review de genérico para específico e relevante.
Você também pode customizar por diretório. Code de autenticação recebe um prompt de review focado em segurança. Code de queries de banco recebe um prompt focado em performance e N+1. Code de UI recebe um prompt focado em acessibilidade e comportamento de estados de loading. Essa granularidade é impossível em ferramentas prontas — é o diferencial de construir o seu próprio setup.
Implementei esse setup em um projeto de SaaS com time de 6 devs. Antes: cycle time médio de PR era 28 horas. 3 a 4 bugs chegavam em produção por sprint que tinham passado em review manual. Depois de 3 meses com AI review automático: cycle time caiu para 18 horas (reviews humanos mais rápidos porque o review de IA já filtrou o óbvio), bugs em produção caíram para 1 a 2 por sprint.
O ganho mais inesperado: devs júniors aprenderam mais rápido. Os comentários da IA explicam por que algo é um problema — não só aponta. Um dev junior que recebia 'isso pode causar SQL injection' sem explicação agora recebe 'essa query concatena strings diretamente com input do usuário. Um atacante pode enviar uma string como X OR 1=1 que vai retornar todos os registros. Use prepared statements assim: ...' A explicação cabe no review e o aprendizado acontece no contexto do trabalho real.
Com Claude 3.7 Sonnet via API, o custo por review varia conforme o tamanho do PR. Para um PR médio de 200 linhas de diff, o custo fica entre $0.05 e $0.15. Para um PR grande de 800 linhas, pode chegar a $0.50. Para um time com 50 PRs por semana de tamanho médio, o custo mensal fica em torno de $30 a $60. Isso é literalmente menos que o café do time em uma manhã.
Para otimizar custo: use Claude Haiku para um primeiro filtro rápido — ele é 10 vezes mais barato — e só chama o Sonnet quando o Haiku encontra algo suspeito ou para arquivos críticos. Esse modelo em cascata pode reduzir o custo total em 60% sem perder cobertura nos pontos que importam.
CodeRabbit Pro a $12/usuário/mês com time de 6 devs sai $72/mês — mais caro que o DIY mas com zero setup. Para times que não querem manter o workflow, faz sentido. Para times que querem controle total sobre as regras e o comportamento do review, o setup DIY com Claude API é mais poderoso e frequentemente mais barato.
Se você está construindo uma base técnica sólida para trabalhar com IA, veja também o roadmap completo em /2026/roadmap-ai-coding-30-dias. Para o contexto maior do que está acontecendo com o movimento de AI coding, o artigo em /2025/agile-coding-is-here-90-ai-cod cobre o panorama completo — code review automático é só uma das automações que esse movimento está tornando acessível para qualquer time.
Plano prático de 30 dias para dominar AI coding do zero.