O teste que decide se confio numa ferramenta de análise de código

Mantenho um sistema que não vou reescrever. Ele é grande demais pra isso valer a pena, e reescrever traria seu próprio risco: meses com duas versões rodando ao mesmo tempo, uma delas sempre desatualizada. Então eu mexo nele aos poucos, com cuidado. E cuidado, nesse tipo de código, começa por uma pergunta simples: antes de mudar uma função, quem mais chama ela?

Num sistema de centenas de milhares de linhas, grep sozinho não responde isso direito. Ele acha o texto, mas não a relação entre as partes. Eu queria uma ferramenta de grafo de código, que lê o projeto inteiro e monta o mapa de quem chama quem, pra eu poder perguntar “se eu mudar esta função, o que mais quebra?” e confiar na resposta.

Fiz uma pesquisa e cheguei a três candidatas: CodeGraph, Graphify e Delphi-RAG-Lint. No papel, as três prometiam a mesma coisa. Como eu não tinha como escolher pela descrição, resolvi fazer um teste de desempenho e eficiência com cada uma, no meu código de verdade. A regra era rodar num arquivo real e grande do sistema e conferir o resultado contra um caso cuja resposta eu já sabia de cabeça.

CodeGraph falhou sem avisar

Comecei pelo CodeGraph. Ele indexou o projeto inteiro, mais de 9 mil arquivos, passou no teste de fumaça e achou os símbolos que eu procurava. Por um momento achei que a busca tinha acabado ali.

O problema apareceu quando cheguei no arquivo mais central do sistema, um dos maiores, com 26 mil linhas. Ele não aparecia nas buscas, como se não existisse. Fui investigar e achei o padrão: todo arquivo acima de 15 a 20 mil linhas sumia do índice. Sem erro, sem aviso, sem uma linha de log dizendo que algo tinha sido pulado. A ferramenta terminava a indexação, reportava sucesso, e a peça mais importante do sistema simplesmente não estava lá.

Graphify achou o símbolo e errou o resultado

O Graphify resolveu o problema do tamanho e achou o arquivo grande sem dificuldade. Então rodei o mesmo teste com uma função real, ValidarEMail. Eu já sabia, por grep manual, que ela tinha 5 chamadores.

A ferramenta achou a função, mas o grafo de chamadores veio com menos de 5. Não era zero, nem um “não encontrado”. Era um resultado parcial e plausível, que qualquer pessoa sem o gabarito aceitaria como completo. Confesso que essa falha me incomodou mais que a do CodeGraph, já que eu só percebi o erro porque sabia a resposta.

Delphi-RAG-Lint passou, e avisava quando cortava

A terceira candidata foi o Delphi-RAG-Lint, um CLI nativo em Object Pascal construído sobre o tree-sitter-delphi13. Ele trouxe os 5 chamadores de ValidarEMail. Repeti o teste em três escalas (uma pasta isolada, duas pastas juntas, o repositório inteiro) e o resultado bateu nas três.

O que me convenceu de vez foi o comportamento dele quando não conseguia processar algo. Ele tem um limite de tamanho explícito e avisa quando um arquivo passa dele. Prefiro uma ferramenta que diz “isso eu não li” a uma que termina como se tivesse dado conta de tudo.

Indexado, o projeto ficou com 668 MB, 8.466 arquivos e 557 mil símbolos catalogados. Numa consulta real de impacto, ele devolveu 931 chamadores exatos de uma função usada em várias partes do sistema. A mesma busca por grep, sem qualificar o termo, tinha devolvido quase 2 mil linhas brutas, que eu teria de filtrar à mão pra chegar no mesmo lugar.

Por que isso é pré-requisito pra não reescrever

Nenhuma das duas ferramentas descartadas travou ou mostrou mensagem de erro. As duas erraram caladas, e um erro calado parece sucesso.

Por isso levo esse teste tão a sério. Numa reescrita do zero, uma ferramenta de análise errada custa retrabalho: você refaz o que saiu errado. Num sistema que você decidiu manter e evoluir aos poucos, o custo é mudar uma função achando que sabe quem depende dela, com uma resposta incompleta na mão. E é justamente nessa hora, quando a ferramenta que deveria dar segurança falha sem avisar, que a vontade de jogar tudo fora e reescrever volta mais forte. Sem uma verificação que eu mesmo provei, eu não conseguiria sustentar a decisão de não reescrever.

O que aprendi com a experiência

Antes de confiar numa ferramenta, numa skill ou num servidor MCP, eu testo num universo que já conheço. Escolho um caso cuja resposta sei de antemão, como os 5 chamadores de ValidarEMail, e comparo com o que ela devolve. Sem esse gabarito, eu não teria como saber que o Graphify trouxe menos chamadores do que devia, porque o resultado parecia completo.

Nesse teste olho duas coisas: se ela acerta, e como se comporta quando não consegue. Uma skill que inventa uma resposta plausível, ou um MCP que devolve meio resultado sem avisar, faz o mesmo estrago que um grafo de código incompleto. Confio mais em quem avisa “isso eu não processei” do que em quem termina em silêncio parecendo completo.

Aprendi isso num sistema legado em Delphi, mas a regra vale pra qualquer coisa que vá responder por mim. Primeiro testo onde eu sei a resposta, e só depois confio onde não sei.