Um engenheiro sênior gasta 4 a 6 horas por semana em code review. No time da Verboo, esse número virava gargalo direto: PR aberto sexta, feedback chegava na segunda, deploy saía na terça. Três dias de latência por causa de revisão.
A gente não terceirizou para ferramenta de review de mercado. Usamos o mesmo agente de programação que vendemos. Hoje, 40% dos PRs do nosso repositório principal passam por review automático, sem nenhuma interação humana de revisão antes do merge.
Aqui está o setup, o que não funcionou nas primeiras semanas e os números depois de 6 semanas de operação.
Por que code review ainda consome horas mesmo com time pequeno?
O problema não é quantidade de PRs, é custo por PR. Revisar código bem exige reconstruir o contexto de quem escreveu. Para uma PR de 200 linhas em 8 arquivos, isso leva 45 a 90 minutos de atenção real.
Segundo análise da Witek, o tempo médio até o primeiro feedback de review é de 4 a 24 horas. Em times com fusos horários diferentes ou agendas pesadas de reunião, esse gap sobe para dois dias.
No nosso caso, o custo era diferente. Com time pequeno, cada hora em review é hora fora de produto. O gargalo não estava na qualidade do review, estava no tempo que ele tirava de quem poderia estar resolvendo o próximo problema.
A solução que testamos antes de chegar ao setup atual: dividir o review em duas etapas. Agente faz o primeiro passe. Humano revisa apenas o que o agente não resolveu ou marcou como incerto.
Por que não usamos uma ferramenta dedicada de code review?
O ângulo contrário que mais ouvimos: "mas existem ferramentas específicas pra isso."
Existem. CodeRabbit, PR-Agent, Copilot Review. Cada um tem sua proposta e funciona razoavelmente bem. O problema é duplo.
Primeiro, custo. A maioria cobra por usuário, por PR ou por token de API externo. Para um time pequeno, o ROI não fecha imediatamente. Segundo, e mais importante, contexto. Ferramentas de review externas não conhecem o repositório com a profundidade de quem trabalha diariamente no produto. Elas leem o diff em isolamento.
O Verboo Code já rodava no nosso ambiente com CLAUDE.md específico do repositório, convenções documentadas e contexto acumulado de semanas de uso. A skill /code-review estava disponível nativamente. Fazer ele revisar PRs era a extensão mais natural possível.
Como funciona o /code-review no Verboo Code?
O Verboo Code tem uma skill nativa chamada /code-review. Ela analisa o diff atual e retorna findings de bugs, simplificações possíveis e issues de eficiência. Por padrão, opera sobre o diff staged e unstaged no working tree.
Três parâmetros mudam o comportamento:
- Nível de esforço:
low,medium,highoumax. Emmedium, o agente retorna poucos findings com alta confiança. Emhighemax, vai mais fundo e pode incluir itens menos certos. --comment: Em vez de retornar o resultado no terminal, posta os findings como comentários inline diretamente no PR do GitHub. O dev não precisa olhar o terminal, o feedback aparece no contexto do código.--fix: Aplica as correções automaticamente na working tree. Útil para issues de estilo e formatação com alta confiança do agente.
Para automação de PRs em CI, usamos sempre --comment. O agente posta, o dev lê e decide o que aceitar. Nunca --fix no CI, porque aplicar mudanças automáticas sem revisão humana no loop é pedir problema.
O modelo ativo no momento do review também importa. O comando /model no Verboo Code troca o modelo em tempo real. Configuramos o CI para passar o modelo como variável de ambiente, baseado no tamanho do diff.
O que o agente encontra melhor que o olho humano?
A resposta curta: o agente é consistente onde o humano é cansável.
Code review humano tem variância. Sexta às 18h o revisor pega 60% dos issues. Segunda às 10h pega 90%. O agente pega o mesmo percentual independente do horário, sem a degradação de atenção que acompanha a fadiga.
| Tipo de issue | Agente (Verboo Code) | Revisor humano |
|---|---|---|
| Estilo e formatação | 95%+ | 60 a 70% (cansaço, pressa) |
| Bugs de lógica isolada | 70 a 80% | 80 a 90% (com contexto) |
| Vulnerabilidades óbvias | ~75% | ~65% (revisores não são auditores) |
| Decisões de arquitetura | 25 a 40% | 85 a 95% |
| Contexto de produto | 10 a 20% | 90%+ |
O agente performa bem em tudo que é verificável contra regras, padrões e boas práticas de código. Perde onde o contexto histórico do produto importa mais que a lógica do diff isolado. Essa tabela não é uma crítica ao agente, é a definição de onde ele vai e onde não vai.
Como configuramos o fluxo em 3 semanas
Levou 3 semanas de ajustes até o processo estabilizar. As primeiras implementações tinham muitos falsos positivos e o time começou a ignorar os comentários do agente. Esse é o risco real: um agente que comenta demais perde credibilidade e vira ruído.
Semana 1: escolha do modelo
Testamos 3 modelos disponíveis no Verboo Code antes de fixar a configuração. O mimo-v2.5 ganhou para PRs grandes, acima de 500 linhas, pela janela de contexto de 1M de tokens: ele analisa o diff inteiro sem truncar. Para PRs menores, o deepseek-v4-flash é mais rápido e resolve bem os casos simples.
Semana 2: nível de esforço por tipo de PR
- PRs de bugfix e documentação:
medium(rápido, findings óbvios) - PRs de feature nova:
high(cobre mais edge cases) - PRs de refactor:
max(análise mais profunda, mais findings incertos também)
Semana 3: CLAUDE.md específico para review
Essa foi a virada. Sem instruções claras no CLAUDE.md do repositório sobre o que checar e o que ignorar, os falsos positivos ficaram em 45%. Com instruções específicas (contexto do produto, padrões aceitáveis, áreas de atenção, o que não comentar), a taxa caiu para 28% e ficou estável.
O trigger no CI dispara nos eventos pull_request.opened e pull_request.synchronize. O agente roda o /code-review --comment e o resultado aparece no PR em 30 a 90 segundos.
Quais PRs ainda precisam de revisor humano?
Não tentamos automatizar tudo. Três categorias ficaram fora do fluxo automático:
- Mudanças em autenticação e segurança: risco alto demais para confiar só no agente sem revisão humana paralela.
- Decisões de arquitetura que afetam roadmap: o agente não tem contexto do planejamento de produto.
- PRs de infra e CI/CD: impacto sistêmico que exige julgamento humano sobre consequências além do código.
Não tentamos automatizar tudo. Delimitar o escopo foi tão importante quanto configurar o agente. Um agente que tenta revisar tudo perde a precisão onde ela mais importa.
Quais resultados conseguimos depois de 6 semanas?
Aviso antes dos dados: somos um time pequeno, com repositório de produto específico. Os números refletem nossa realidade, não uma pesquisa de mercado.
40% dos PRs do repositório principal passaram por review automático completo, sem nenhuma interação humana de revisão antes do merge.
- Tempo médio até primeiro feedback: de 6 horas para 90 segundos
- PRs sem feedback humano de conteúdo (só aprovação final): 40%
- Bugs encontrados pelo agente que o dev não havia percebido: 12 nos primeiros 30 dias
- Taxa de falsos positivos descartados: 28% dos comentários (caiu de 45% após ajuste do CLAUDE.md)
- Redução estimada no tempo de cycle do PR: 2 a 3 horas por dev por semana
- Custo incremental do setup: zero, está dentro do plano do Verboo Code
A AI/R documentou redução de até 78% no tempo de review com automação por IA em times maiores. Nosso número foi menor porque automatizamos seletivamente. Não tentamos substituir todo o processo, só o primeiro passe nos PRs que não precisavam de contexto humano profundo.
O mesmo agente que revisa os PRs da Verboo é o que está disponível para os 128 assinantes do Verboo Code hoje, com MRR crescendo 8% ao mês.
Se você quer ver outros usos do mesmo agente na operação, vale ler como operamos 9 posts por semana de marketing sem redator com Verboo Code.
Quer rodar isso sem cap de tokens? Conheça o Verboo Code, agente de programação com tokens ilimitados.
