O passo mais valioso da revisão de código por IA não usa IA nenhuma

Por anos eu achei que revisão de código por IA era basicamente um ritual: jogar o repositório inteiro no modelo e rezar pra ele achar o bug. Quanto mais arquivo eu empurrava “por garantia”, mais seguro eu me sentia. A conta de API dizia outra coisa, mas eu ignorava.

Aí eu descobri uma coisa que me incomodou. O passo que mais melhorou a qualidade da minha revisão por IA é justamente o passo que não chama IA nenhuma.

Vou explicar, porque a parte interessante não é “use a ferramenta X”. É que a engenharia de verdade estava acontecendo antes da IA entrar, num lugar que eu nem olhava.

O que eu fazia antes (e por que doía no bolso)

O fluxo antigo era esse: abria o PR, pegava o diff, e pra “ter contexto” jogava no modelo o arquivo modificado mais uns 50 arquivos do entorno. Tudo que parecia relacionado ia junto. O modelo lia tudo, gastava um caminhão de token, e devolvia uma revisão mais ou menos.

O problema é que jogar mais arquivo não deixa a revisão melhor. Deixa pior. O modelo se distrai com código que não tem nada a ver com a mudança, e o ponto crítico se dilui no meio do barulho. Eu estava pagando, em dólar, pra piorar minha própria revisão.

A base de código já é um grafo

A virada veio quando parei de tratar o código como um monte de texto e comecei a tratar como o que ele de fato é: um grafo.

Uma função chama outra. Uma classe herda de outra. Um módulo faz import de outro. Isso não é metáfora, é a estrutura real do seu repositório. E se você torna esse grafo explícito, a pergunta que todo revisor faz na cabeça (“se eu mexer aqui, o que mais quebra?”) passa a ter resposta em segundos, não em meia hora de garimpo.

Quem monta esse grafo é o Tree-sitter: a biblioteca que faz parsing do código pra árvore sintática (AST). Ela roda 100% local, é determinística e (o ponto inteiro deste texto) não usa LLM. O ecossistema saiu das 19 linguagens iniciais pra mais de 40 com parser oficial, e os pacotes da comunidade já empacotam mais de 300 gramáticas. Dá saudade da época do grep no nome da função, adivinhando “deve ser por aqui que chamam”. O Tree-sitter troca o “deve ser” por “é”.

O passo sem IA: blast radius

Com o grafo montado, a operação que faz a mágica chama blast radius: o escopo de impacto de uma mudança.

Você aponta pro arquivo que mudou (Hop 0), e o grafo colore o que é afetado pela distância em saltos: dependência direta (Hop 1), indireta (Hop 2), e por aí. O resultado é a lista enxuta dos arquivos que a sua mudança realmente toca: sete, em vez dos cinquenta que eu empurrava por medo.

Mudança: auth.py

Hop 0: auth.py
Hop 1: middleware.py, api/login.py, api/register.py
Hop 2: tests/test_auth.py, tests/test_login.py
Hop 3: conftest.py

Arquivos afetados: 7

Nada disso passou por um modelo. É AST determinístico rodando na sua máquina, de graça. A primeira vez que liguei isso, perguntei o escopo de impacto de um arquivo e em dois segundos voltaram 7 arquivos, praticamente o mesmo resultado que eu tinha levado 30 minutos pra montar no grep. Fiquei grato pela resposta e levemente ofendido pelos meus 30 minutos.

O número que muda a conta

Aí sim a IA entra, mas só nos 7 arquivos que importam, e não nos 50 do começo.

Antes: arquivo modificado + 50 do entorno = 150.000 tokens
Com o grafo: arquivo modificado + 7 do blast radius = 18.000 tokens

Redução: 8,3x

Pra quem paga API em dólar e fatura em real, essa diferença não é detalhe. Num PR grande, revisado várias vezes ao dia, a distância entre 150k e 18k por revisão é a distância entre alguns reais e alguns centavos por PR. E o trabalho pesado (montar o grafo, achar o escopo) sai zero, rodando offline. O caro virou barato porque a parte cara deixou de usar o recurso caro.

Vale separar uma coisa, porque já troquei RAG por grep numa busca de código antes e não é a mesma história. Lá o assunto era achar o código certo. Aqui é entender o impacto de uma mudança que você já fez. Camadas diferentes do mesmo problema: deixar a IA focar no que importa em vez de ler tudo.

Por que isso é meio contraintuitivo

A intuição diz que a inteligência da revisão mora no modelo. Quanto mais esperto o LLM, melhor a revisão. Faz sentido, e está errado.

O que mais melhorou a minha revisão não foi um modelo melhor. Foi um passo determinístico, gratuito e local, que decide o que o modelo vê. O LLM que eu achava ser o cérebro da operação é, na prática, o estagiário: bom no julgamento final, mas perdido se você entope a mesa dele de papel. Quem faz o trabalho braçal (separar os 7 arquivos certos dos 50) é o Tree-sitter, que trabalha de graça e não reclama.

A IA não vira dispensável. O ponto é que o passo mais valioso vem antes dela, e custa zero.

Fechando

Eu passei anos achando que revisão por IA era sobre ter o modelo mais inteligente possível. Era sobre não fazer o modelo inteligente ler lixo.

O grafo de código resolve isso com um passo que não chama IA: Tree-sitter monta a estrutura, o blast radius acha os arquivos que a mudança toca, e só então a IA revisa esses. 150k vira 18k, 8,3x, offline e de graça. Da próxima vez que sua conta de API doer numa revisão de PR, lembra: a parte que mais pesa na qualidade é a parte que você pode rodar sem gastar um centavo de token.

---

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