Filtro duplo de IA no PR: CodeRabbit + Claude Code Action cortaram 47% dos comentários humanos (ch10)

Rodei CodeRabbit sozinho por 3 meses num monorepo com equipe de 4 pessoas. Ele já cortava bastante comentário chato no PR — style, nomes de variável, TypeScript any implícito. A fila que sobrava para o revisor humano tinha caído uns 20% desde o mês zero.

Aí, nos últimos 30 dias, empilhei o Claude Code Action em cima do CodeRabbit. Mesmo repo, mesmo pipeline, mesma equipe. Contei os comentários humanos por PR antes e depois.

Média por PR de comentário humano: caiu de 5,8 para 3,1 — ou seja, 47% a menos.

Só que em 2 categorias o filtro duplo piorou. Este post é sobre onde a camada 2 vira dupla checagem de verdade, e onde ela vira só ruído em dobro.

O que eu contei, para você poder me chamar de mentiroso

109 PRs no total, divididos em dois blocos:

• Bloco A (3 meses, só CodeRabbit): 62 PRs, 359 comentários humanos → média 5,8/PR
• Bloco B (últimos 30 dias, CodeRabbit + Claude Code Action): 47 PRs, 146 comentários humanos → média 3,1/PR

“Comentário humano” aqui é qualquer coisa que um dos 4 humanos da equipe escreveu na aba de review — issue, suggestion, praise, nitpick. Não conto emoji de aprovação nem “LGTM”. Também não conto o próprio comentário da IA, senão o número teria ido pro teto.

A equipe é a mesma. O critério de merge é o mesmo (2 aprovações). O revisor de plantão em 60% dos PRs sou eu, então tem viés. Mas o padrão vale para os outros 3 revisores humanos também, dentro do erro de amostra.

Onde a queda de 47% veio, categoria por categoria:

Categoria	Bloco A (só CodeRabbit)	Bloco B (+ Claude Code Action)	Delta
N+1 em query Prisma	1,2 comentários/PR	0,3	-75%
Server / Client Component boundary	0,9	0,2	-78%
Tratamento de erro (Result type)	0,7	0,3	-57%
Segurança (validação de entrada, auth)	0,6	0,4	-33%
Style / naming	1,4	0,9	-36%
Refactor de arquitetura	0,4	0,7	+75%
Nomeação de módulo/arquivo	0,3	0,5	+67%
Outros	0,3	0,3	0%

As 5 primeiras linhas explicam de onde vieram os 47%. As 2 linhas em negrito são onde o filtro duplo me deu mais trabalho, não menos. Vou por partes.

Onde o filtro duplo funcionou

Query Prisma com N+1. Isso caiu de 1,2 comentário/PR para 0,3. CodeRabbit já pegava alguns casos óbvios via análise estática. O Claude Code Action pega os casos onde o N+1 está escondido atrás de uma abstração — um useQueryX que dentro faz map + await. Quando os dois concordam, o desenvolvedor já vem para o PR humano com o include corrigido.

Isso é exatamente o argumento de “camada dupla” que virou padrão em aviação (ver o primeiro post desta veia sobre revisão sem IA na camada 1 com tree-sitter): um problema que passou pelos dois filtros pede julgamento humano de verdade.

Server / Client Component boundary no Next.js. CodeRabbit avisa quando você importa uma função server-only num arquivo "use client". Claude Code Action lê o CLAUDE.md (com --mcp-config ligado no MCP interno de docs) e cita o padrão da equipe. Duas vozes dizendo a mesma coisa: raro alguém subir esse tipo de PR sem já ter corrigido.

Tratamento de erro com tipo Result. Este é do CLAUDE.md também. O CodeRabbit não sabia do padrão interno. O Claude Code Action sabe, porque o CLAUDE.md está no repo. Aqui a camada 2 fez o trabalho que a camada 1 não conseguia fazer por design.

Segurança. Caiu 33%, menos que os outros. Suspeito que seja porque o Claude Code Action estava com permissions: {contents: read, pull-requests: write} e não tinha acesso a rodar nada — segurança precisa de contexto de execução para ver certos padrões. Vou testar rodar em modo additional_permissions: actions: read no próximo mês.

Onde o filtro duplo piorou

Refactor de arquitetura. Aqui o número subiu de 0,4 para 0,7 comentário humano por PR.

O motivo é que o Claude Code Action, ao ler todo o PR com contexto grande, começa a sugerir refatorações que ninguém pediu. “Este service poderia virar dois.” “Este hook mistura preocupações.” Os humanos leem e ficam com aquela dúvida legítima: “espera, ele tem razão? preciso refatorar antes de mergear?” — e escrevem comentário para discutir.

A conta ficou pior porque a IA levantou uma discussão que ninguém queria ter naquela PR. Adicionei ao CLAUDE.md:

## Regras de revisão

Não sugira refactor de arquitetura em PRs de bug fix ou feature de escopo pequeno.
Refactor só quando explicitamente pedido no título ou corpo do PR.

Depois disso, a linha começou a cair. Mas isso é uma regra escrita à mão para desligar um comportamento — não é o filtro duplo funcionando. É o filtro sendo domado.

Nomeação de módulo / arquivo. Mesma raiz. O Claude Code Action sugere nomes “mais claros” para arquivos que a equipe nomeou consciente. parseUserInput vira sugestão para sanitizeAndParseUserInput. Humano lê, discorda, escreve comentário para defender o nome atual.

Aqui a solução foi colocar no CLAUDE.md a regra de nomeação da equipe explicitamente, com exemplos. Depois disso a IA parou de sugerir renomeações. Mas de novo — não foi o filtro duplo agindo, foi eu descrevendo a política para a segunda camada não brigar com ela.

O que o capítulo 10 do meu book dizia (e o que eu mudei de opinião)

No capítulo 10 do meu livro sobre revisão de código com IA, eu escrevi que a camada 2 (Copilot ou Claude Code Action em cima do CodeRabbit) serve como seguro contra omissão. Escrevi também que na aviação a dupla checagem é procedimento padrão e que um problema que passa pelos dois filtros pede julgamento humano.

Isso continua verdade, e os dados dos últimos 30 dias confirmam. Mas eu subestimei uma coisa: a camada 2, com contexto maior, é mais opinativa. CodeRabbit é uma faca de análise estática — corta o que corta e cala. Claude Code Action é um par de olhos com opinião. Se você não escreve a política, ele inventa uma.

O copilot-instructions.md do Copilot funciona da mesma forma, mas o Copilot é mais tímido para sugerir refactor não pedido. Claude Code Action, sendo mais capaz, também é mais aventureiro.

Então o meu ajuste ao ch10: camada 2 corta 47% do trabalho humano, mas só depois de você escrever no CLAUDE.md o que ela não deve sugerir. Antes do CLAUDE.md estar polido, é 30% de corte com 15% de barulho a mais. Depois de 2 semanas ajustando o CLAUDE.md, você chega nos 47% líquidos.

Se a sua equipe já usa o Claude Code para desenvolvimento, o mesmo CLAUDE.md que governa o desenvolvimento passa a governar a revisão — sem gestão duplicada. Esse é o argumento central de Practical Claude Code, que cobre justamente os padrões de CLAUDE.md, Plan Mode e workflows de equipe.

Se você vai copiar isso amanhã

Três passos, na ordem:

1. CodeRabbit ligado sozinho por pelo menos 4 semanas. Você precisa saber o que ele já pega para não contar duas vezes.
2. Claude Code Action com permissions: pull-requests: write e CLAUDE.md no repo, começando com trigger só em PRs com label deep-review. Não ative em todos os PRs no primeiro dia. Deixe o time se acostumar.
3. Anote os comentários que o Claude Code Action gerou mas ninguém quis discutir. Cada um desses vira uma regra no CLAUDE.md: “não sugira X quando o PR for Y”. Em 2 semanas você chega no regime dos 47%.

O trabalho não é ligar o filtro duplo. O trabalho é ensinar o filtro duplo o que a sua equipe não quer discutir num PR de 15 linhas.

Um problema que passou por CodeRabbit e Claude Code Action e o CLAUDE.md da equipe é um problema onde o revisor humano vai realmente aprender algo. Isso é a versão calibrada da “dupla checagem” que o ch10 propunha.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews