Camada 1 → 2 → 3: o funil de code review com IA que corta 70% do trabalho humano
Passei três meses achando que “adicionar IA” no code review ia salvar meu time. Adicionei. Piorou. O que salvou foi ordenar as camadas.
Vou contar de trás para frente: hoje meu time revisa 30% dos PRs à mão. Os outros 70% passam por hook + CI e depois por revisão de IA, e o humano só olha se sobrar algo relevante. Testei essa configuração por 6 semanas em um repo BR real (~180k linhas, 4 devs, ~40 PRs/semana) e os números apareceram bem diferentes do que eu esperava.
O erro que fiz primeiro
Contratei CodeRabbit, plugei no repo, saí para tomar café. Voltei duas horas depois e o time estava ignorando os comentários dele. Motivo: a IA revisava o mesmo PR que o linter já tinha aprovado, o mesmo PR que o humano já tinha lido, e comentava sobre escolha de nomes em cima de código que o linter deveria ter formatado antes.
O problema foi de sequência. Sem definir quem faz o quê primeiro, cada camada duplica o trabalho da outra e no fim ninguém confia em ninguém.
A ordem que funciona
Camada 1 — Portão automático (hook + CI): o que pode ser julgado mecanicamente nunca chega ao PR. Formato, linter, tipo, testes, build. Se qualquer um falhar, o PR nem é aberto para revisão.
Camada 2 — Revisão por IA: o que sobra da camada 1 passa por um revisor de IA (CodeRabbit, Greptile ou Qodo, depende do orçamento). Ela pega N+1, SQL injection potencial, cobertura de teste fraca, nomes ambíguos, imports mortos.
Camada 3 — Revisão humana: só o que precisa de julgamento chega aqui. Decisão de design, regra de negócio, direção arquitetural. O humano não olha estilo, não olha typo, não olha se tem teste.
O princípio é chato mas funciona: cada camada só olha o que a anterior não conseguiu resolver.
Os números das 6 semanas
Depois de organizar as camadas, medi tudo. Repo BR interno, 4 devs, 240 PRs no período.
| Camada | PRs que passaram | PRs barrados | % do total |
|---|---|---|---|
| 1 (hook+CI) | 240 | 62 barrados/reabertos | 26% do trabalho |
| 2 (IA) | 178 | 91 com comentários acionáveis | 38% do trabalho |
| 3 (humano) | 87 | 74 mergeados / 13 com discussão | 36% do trabalho |
O corte de 70% do trabalho humano vem daí: dos 240 PRs, 153 (64%) foram resolvidos antes de chegar em um humano. Nos outros 87, o humano só precisou olhar o que sobrou, e 74 desses passaram na primeira leitura porque a IA já tinha limpo o resto.
Onde a IA erra (e por que a camada 1 é vital)
Rodei em paralelo o CodeRabbit e o Greptile por 2 semanas para calibrar. O que vi bate com o benchmark público:
- Greptile pegou mais bugs (~50% acima do CodeRabbit em benchmarks independentes), mas gerou 2x mais falsos positivos. O time começou a ignorar comentários dele por cansaço.
- CodeRabbit pegou menos bugs mas manteve confiança do time. Menos ruído, mais adesão.
Nenhum dos dois pega tudo. Um estudo Martian de 2026 mediu 51.2% F1 no CodeRabbit e 60.1% no Qodo: a IA acha em torno de 50-60% do que um humano acharia. Se você mandar 100% dos PRs direto pra IA sem camada 1, ela vai gastar 40% da atenção dela em coisas que um pre-commit hook resolveria em 20ms.
O custo (em R$ e em atrito)
Calculei o custo real na moeda que o time paga:
- CodeRabbit: US$ 24/dev/mês. Time de 4 = US$ 96/mês. Em BRL ~R$ 500/mês.
- Hora de dev sênior BR: R$ 300/hora (conta pessoa jurídica, cliente de fora).
- Tempo humano economizado: das 240 revisões, o time deixou de olhar 153. Estimei ~15 min por revisão humana completa. 153 × 15 min = 38 horas no bimestre.
38 horas × R$ 300/hora = R$ 11.400 economizados por bimestre. Custo da IA: R$ 1.000 no mesmo período. ROI de 10x, e isso ignora o custo emocional de revisar o 47º PR numa sexta-feira.
O número contraintuitivo aqui foi outro: o maior ganho veio da camada 1, não da IA. Os 62 PRs barrados no hook nem consumiram token de IA. Sem hook, esses 62 teriam gerado comentário de linter falando de vírgula. Com hook, eles nem apareceram no timeline.
Onde eu ainda quebro a cara
Duas coisas continuam ruins mesmo com o funil:
A IA não entende contexto de negócio. Ela vai reclamar de um if (user.plan === 'legacy_v2') como “magic string” mesmo que o time saiba que esse plano existe há 4 anos e vai continuar existindo. Só o humano resolve isso, e por isso a camada 3 nunca vai ser zero.
Refatoração larga passa despercebida. Quando o PR muda 30 arquivos, tanto o CodeRabbit quanto o Greptile diminuem a densidade de comentário e começam a olhar só as bordas. Nesses casos eu volto pra revisão humana completa, ignorando o funil. O funil serve para o fluxo constante de PRs pequenos, não para o refactor mensal.
Quando vale (e quando não vale)
Vale se:
- Time ≥ 3 pessoas com fluxo constante de PRs (>10/semana).
- Repo já tem hook + CI decente. Se a camada 1 for fraca, IA vai virar linter caro.
- Alguém tem tempo pra tunar as regras da IA nas 2 primeiras semanas.
Não vale se:
- Time solo. O ganho de ordenar 3 camadas com 1 pessoa é pequeno.
- Repo sem hook. Coloque hook primeiro, IA depois.
- PRs monstro (>500 linhas). O funil pressupõe PR pequeno; se o time tem cultura de PR grande, arrume isso antes de plugar IA.
O que eu esperava e não veio
Esperava que a IA descobrisse bugs que o humano tinha deixado passar. Não descobriu. Ela pegou basicamente as mesmas classes de coisa que o humano teria pegado, só que mais rápido e sem ficar de mau humor. O ganho aqui é outro: o humano deixa de fazer o que a máquina faz melhor, e sobra tempo pra olhar direção.
Se você quiser aprofundar o desenho das 3 camadas com exemplos de configuração real, escrevi um livro sobre isso, mas o funil que descrevi acima já resolve 80% do caso. Vale mais fazer 6 semanas de medição do que ler 200 páginas primeiro.
Ah, e um lembrete: no meu time-BR anterior tentei fazer isso ao contrário (IA primeiro, hook depois) e passei 3 meses ignorando comentários de PR. A ordem importa.
ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews
Este artigo foi útil?