Code review com IA: como saber se o achado é real ou falso positivo antes de mexer no código

Fala aí, beleza? A IA termina a revisão, cospe trinta apontamentos na tela e bate aquela vontade de sair corrigindo tudo de cima pra baixo

Aí você mexe em quatro arquivos, quebra dois testes e descobre que metade dos "bugs" nunca existiu 😅

Esse é o retrabalho mais caro do code review com IA: não é o bug que passou, é o problema fantasma que você foi consertar

A boa notícia é que dá pra separar achado real de falso positivo antes de tocar no código, e é sempre a mesma sequência: confirmar a localização, confirmar o caminho, ordenar por categoria e buscar confirmação independente

Esse post é essa triagem, na ordem, com o erro comum de cada passo

O que você precisa antes de começar a triagem

Antes de julgar qualquer apontamento, tenha essas quatro coisas em mãos

1. O relatório com localização. O <code>/code-review</code> do Claude Code exibe o resultado como lista de achados, e cada entrada vem com a localização no arquivo, um resumo de uma frase e uma etiqueta de categoria (por exemplo, <code>correctness</code>) quando o achado tem uma

Esse <code>arquivo:linha</code> é o seu ponto de partida: sem ele, não tem triagem, tem adivinhação

2. A branch no escopo certo. O <code>/code-review</code> roda no terminal, sem precisar instalar o GitHub App, e revisa os commits da branch que estão à frente do upstream mais as alterações não commitadas

Ou seja: o que está no seu working tree conta. Se você tem lixo de teste solto ali, ele entra na revisão e vira ruído

3. Um diff limpo pra comparar. Deixe o <code>git diff</code> à mão numa aba separada

A pergunta de toda triagem é "isso que a IA descreveu está mesmo no diff?", e você responde isso olhando o diff, não a lista

4. O CLAUDE.md do projeto, se houver. O CLAUDE.md funciona como arquivo de convenções compartilhadas do projeto, e o Code Review trata violações recém-introduzidas dessas convenções como achados de nível <code>nit</code>

Saber disso já muda a leitura da lista: um monte de apontamento pequeno pode ser só convenção sua sendo cobrada, não bug. Se você ainda não tem esse arquivo redondo, vale escrever um CLAUDE.md decente antes, porque ele muda o que a revisão te devolve

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

E o <code>/review</code>, mudou?

Mudou sim. O <code>/review</code> hoje é apelido (alias) do <code>/code-review</code> no Claude Code

Antes da versão 2.1.223 ele era um comando separado, que fazia uma passada única e somente leitura sobre um pull request do GitHub

Se você aprendeu o fluxo antigo, se liga: é o mesmo comando agora

Passo a passo: triagem de achados de code review com IA

1. Escolha o nível de esforço ANTES de gerar a lista

O <code>/code-review</code> aceita um nível de esforço que troca cobertura por confiança

<code>low</code> e <code>medium</code> retornam menos achados e de maior confiança

<code>high</code> e <code>max</code> ampliam a cobertura e podem incluir achados sobre os quais a própria revisão está menos segura

Os níveis são: <code>low</code>, <code>medium</code>, <code>high</code>, <code>max</code> e <code>ultra</code>

E o <code>ultra</code> não entra nessa régua de "mais cobertura, menos confiança": ele manda o repositório pra um sandbox remoto e verifica cada achado de forma independente antes de reportar. Volto nele lá na seção do sinal de confirmação

<pre><code>/code-review</code></pre>

O erro comum deste passo: mandar no nível mais alto "pra não perder nada" e depois passar a tarde filtrando ruído que você mesmo pediu. Cobertura maior significa mais achado incerto na sua mesa, e quem paga a triagem é você

2. Abra o <code>arquivo:linha</code> e confira se o código descrito é o código que está lá

Esse é o filtro que mata mais falso positivo em menos tempo

Leia o resumo de uma frase, abra a linha e pergunte: a função citada existe com esse nome? A variável tem mesmo esse tipo? A condição é essa?

<pre><code>git diff</code></pre>

A documentação oficial do GitHub é bem direta sobre isso no Copilot code review: o recurso tem risco de alucinação e pode apontar problemas que não existem ou que se baseiam em interpretação errada do código, e por isso precisa ser complementado por revisão humana cuidadosa

Não é defeito de uma ferramenta específica, é a natureza da coisa

O erro comum deste passo: confiar no resumo. O resumo é uma frase, ele é comprimido por construção, e frase comprimida esconde contexto

3. Confirme se o caminho é alcançável de verdade

Achado pode estar tecnicamente certo e ser irrelevante: aquele <code>null</code> só estoura se alguém chamar a função com um parâmetro que ninguém nunca passa

Então vá atrás de quem chama, com que entrada, e se existe validação antes

O erro comum deste passo: aceitar "pode acontecer" como "acontece". Se você não consegue descrever a entrada que dispara o problema, o achado ainda não está confirmado

4. Separe por categoria e trate nessa ordem

<code>correctness</code> primeiro, estilo depois, <code>nit</code> por último

A etiqueta de categoria vem no próprio relatório quando o achado tem uma, então esse agrupamento é praticamente de graça

O erro comum deste passo: começar pelos fáceis. Os <code>nit</code> são rapidinhos de resolver e dão sensação de progresso, aí você queima a energia boa da revisão nos itens que menos importam

5. Busque confirmação independente antes de mexer

Rode uma segunda passada, ou passe o mesmo diff por outra ferramenta, e veja o que reaparece

O que aparece duas vezes de forma independente sobe na sua fila. Mais pra frente, na seção sobre o sinal de confirmação, eu mostro os números que sustentam essa régua

O erro comum deste passo: rodar a segunda passada já com a correção aplicada. Aí não é confirmação, é só a ferramenta concordando com o que você acabou de fazer

6. Corrija um achado por vez e verifique

Um achado, uma correção, uma verificação

Batch de dez correções junto é a receita pra não saber qual delas quebrou o teste

O erro comum deste passo: tratar a lista como checklist de compras. Ela é uma lista de hipóteses, e hipótese você confirma antes de commitar. Se quiser aprofundar essa parte, tem um passo anterior que ajuda bastante: revisar o código antes de commitar

Quais categorias de achado costumam ser ruído (e quais merecem atenção)

Nem toda categoria custa o mesmo tempo de triagem

E segurança merece parágrafo separado, se liga nisso: o Claude Code tem o comando <code>/security-review</code>, que analisa o código em busca de padrões comuns de vulnerabilidade (SQL injection, XSS, falhas de autenticação e autorização e tratamento inseguro de dados)

E a própria Anthropic posiciona ele como complemento, não substituto, da revisão manual

Existe ainda uma segunda coisa, e é importante não confundir as duas: a Anthropic mantém o repositório público claude-code-security-review, que é uma GitHub Action de revisão de segurança com IA analisando mudanças de código

Uma coisa é o comando que você roda no terminal, outra é a Action que roda no seu pull request

O que vale desse repositório pra quem é curioso: dentro dele tem o arquivo <code>.claude/commands/security-review.md</code>, com o prompt à vista. Dá pra abrir e ler o que está sendo pedido pro modelo, é bem instrutivo

Por que estilo é ruído com tanta frequência?

Porque o incentivo de quem constrói essas ferramentas não pune ruído

No benchmark publicado pela própria Greptile, a pontuação considerou apenas a detecção do bug original: falsos positivos, sugestões de estilo e comentários não relacionados não afetaram a taxa de acerto divulgada

Deu pra sacar? Uma ferramenta pode gritar cinquenta coisas, acertar uma, e pontuar igual a outra que apontou só aquela uma

A CodeAnt publica como estimativa de mercado que a maioria das ferramentas de code review com IA opera numa faixa de 5% a 15% de taxa de falsos positivos, e argumenta que mesmo 10% já custa horas de engenharia por semana em triagem

Tome cuidado com esse número: é estimativa de fornecedor, não estudo primário. Serve como ordem de grandeza, não como régua

E o que a ferramenta NÃO vê?

Esse lado some da conversa e é tão importante quanto

A documentação oficial do GitHub afirma que o Copilot code review suporta apenas um conjunto específico de linguagens, foi desenhado para identificar um conjunto limitado e fixo de problemas de qualidade, e pode não identificar todos os problemas presentes, especialmente quando as mudanças são grandes ou complexas

Tradução prática: diff grande é justamente onde você mais precisa de ajuda e onde a ajuda é pior

PR menor não é só boa prática de time, é o que faz a revisão automática valer alguma coisa

O sinal de confirmação: quando várias passadas apontam o mesmo problema

Aqui está a parte mais útil da triagem, e ela vem de dentro das próprias ferramentas

A Cursor descreve que uma das melhorias de qualidade mais eficazes no Bugbot foi rodar várias passadas de busca de bugs em paralelo e combinar os resultados por votação majoritária, com oito passadas e cada uma recebendo uma ordenação diferente do diff

Quando várias passadas apontam o mesmo problema de forma independente, isso é tratado como sinal mais forte de que o bug é real

O Claude Code faz algo na mesma linha no nível mais alto: em <code>/code-review ultra</code> ele envia o repositório para um sandbox remoto onde uma frota de agentes especializados analisa o código em paralelo, e cada achado é verificado de forma independente antes de ser reportado

Se você conhece a ideia de pedir a mesma coisa duas vezes pro modelo pra ver se a resposta se sustenta, é exatamente isso, só que industrializado

A Cursor publica também que, quando o Bugbot saiu do beta em julho de 2025, 52% dos bugs apontados por ele estavam resolvidos no momento em que o PR era mergeado, e que em abril de 2026 essa taxa de resolução chegou a perto de 80%

Dado do próprio fornecedor, e taxa de resolução não é taxa de acerto, mas mostra a direção

Agora o contraponto duro

Em um experimento independente publicado em 2026, um engenheiro rodou quatro revisores de IA em paralelo (CodeRabbit, Sentry Seer, Greptile e Cursor Bugbot) por três semanas e meia sobre 146 pull requests reais, somando 679 achados

Das 617 localizações distintas apontadas, 93,4% foram sinalizadas por apenas uma das quatro ferramentas

Cerca de 6% por duas, quase nenhuma por três, e nenhuma pelas quatro 😳

Leia esse número com calma, porque ele corta dos dois lados

Concordância é sinal forte JUSTAMENTE porque é rara: se dois revisores independentes bateram no mesmo ponto, esse achado sobe pro topo da sua fila sem discussão

Mas a ausência de concordância não condena nada. Com 93,4% das localizações aparecendo em uma ferramenta só, exigir voto duplo pra levar um achado a sério significaria jogar fora quase tudo

Então a régua é: concordância promove, silêncio não rebaixa. O que rebaixa é o passo 2 e o passo 3, você olhando o código

Como foi rodar a revisão e receber zero achados

No vídeo abaixo eu mostro esse fluxo na prática, e adianto: não consegui testar a parte paga porque não tenho o plano exigido, então essa parte eu tratei de forma teórica, com a documentação e o artigo abertos na tela

Montei um infográfico próprio pra percorrer o funcionamento passo a passo antes de ir pro terminal, e mostrei no artigo um exemplo de achado já categorizado, com o impacto marcado como crítico e uma sugestão de correção junto

Na prática eu fui pela alternativa gratuita: instalei o plugin de code review e rodei dentro de um projeto de exemplo meu

Detalhe engraçado: não tinha nenhum pull request aberto no projeto de teste, então tive que criar um só pra conseguir demonstrar 😄

Durante a execução dava pra ver no terminal vários agentes rodando ao mesmo tempo na mesma análise

A revisão demorou cerca de 5 minutos, e o tempo varia conforme o tamanho da alteração enviada

E o resultado? Nenhum problema encontrado, o famoso <code>no issues found</code> aparecendo depois lá no GitHub

Atribuo isso ao fato de a mudança testada ser pequena

Lista vazia também é um resultado pra interpretar

Esse é o outro lado da moeda da triagem

Zero achado em um diff de três linhas não é atestado de qualidade, é o esperado

Zero achado em um refactor grande já merece desconfiança, principalmente lembrando do ponto do GitHub sobre mudanças grandes e complexas

E o tempo muda a decisão de quando rodar: 5 minutos é rápido demais pra você ficar olhando, e devagar demais pra rodar a cada commit. É comando de fim de branch, antes de abrir o PR

Duas ressalvas honestas da versão local que usei: ela exige ativação manual e não tem a integração automática com o GitHub, então fica fora do fluxo natural de abrir o PR

E sobre o recurso pago, minha leitura é que o preço por review pesa pra uso individual, mas faz sentido pra empresa grande que quer evitar bug em produção

Em nenhum dos casos ele mexe no código sozinho: é um passo a mais entre enviar o PR e aprovar, um relatório pro time decidir

O detalhe que eu acho que mais gente vai passar a usar é o arquivo de regras de revisão, pra guiar o que a IA deve destacar e o que deve ignorar, justamente pra reduzir falso positivo

Conclusão

A régua do post cabe em uma frase: achado sem caminho confirmado no código não vira commit

O resto é ordem. Nível de esforço baixo primeiro, <code>arquivo:linha</code> conferido, caminho alcançável comprovado, <code>correctness</code> antes de <code>nit</code>, confirmação independente promovendo o que aparece duas vezes, correção uma de cada vez

Seu próximo passo concreto: na próxima branch, rode o <code>/code-review</code> no nível baixo, trie a lista nessa ordem e cronometre quanto tempo você gastou

E quando o assunto for segurança, compare com o <code>/security-review</code>, que é o comando desenhado pra isso

Depois me conta como foi, se liga se aparece achado repetido entre as duas passadas 😀

até o próximo post!