Testei 6 ferramentas de grafo de código — veja o que aconteceu

Autoria: The Gray Cat · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: I Tested 6 Code Graph Tools—Here Is What Actually Happened · Canal: The Gray Cat · 08:15 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Claude Code, Ferramentas de desenvolvimento com IA

Resumo

O vídeo compara seis ferramentas de grafo de código com o Claude Code sem ferramentas extras, usando Opus 5.5 em uma tarefa de atualização de interface. CodeGraph teve o menor custo e concluiu a tarefa mais rápido, embora todas as implementações ainda tivessem bugs. Graft consumiu mais tokens e custou mais que o Claude Code simples, apesar de estimar uma grande economia de tokens. O apresentador escolhe CodeGraph para essa tarefa, mas observa que ferramentas extras não melhoraram os resultados de forma consistente.

Pontos-chave

A comparação incluiu CodeGraph, Graphify, Graft, GitNexus, Codebase Memory MCP e Code Review Graph, além do Claude Code sem ferramentas extras.
As sete sessões usaram Opus 5.5 em esforço médio, sem subagents, com cópias idênticas do projeto e o mesmo prompt e arquivos de design.
CodeGraph teve o menor consumo estimado, cerca de 17,6 milhões de tokens, contra 19,5 milhões do Claude Code simples.
Pelos preços de API usados na comparação, CodeGraph custou US$ 8,66 e o Claude Code simples, US$ 9,18.
Graft usou cerca de 39% mais tokens e custou cerca de 23% mais que o Claude Code simples; seu relatório de economia não correspondia ao que Claude realmente deixou de ler.
CodeGraph terminou em cerca de 19 minutos, enquanto o Claude Code simples levou aproximadamente 23 minutos e meio.
A revisão de Astra encontrou bugs em todas as implementações, apesar de todas terem passado pelos testes de build e regressão.
O apresentador prefere CodeGraph nesta tarefa, mas ressalta que uma execução por ferramenta não permite conclusões firmes sobre a classificação.

Capítulos

Início	Capítulo	Resumo
00:00	Objetivo e preparação do teste	O apresentador compara seis ferramentas com o Claude Code simples e explica a tarefa de reconstruir partes da interface do aplicativo.
02:11	Como as ferramentas consultam o código	São descritos os mapas de código, os recursos de MCP, CLI e hooks usados pelas seis ferramentas.
04:29	Custos, tokens e limitações da comparação	CodeGraph aparece como a opção mais barata, enquanto Graft consome mais recursos, e o apresentador ressalta as limitações de uma única execução por ferramenta.
06:09	Qualidade, duração e escolha final	A revisão encontra bugs em todas as versões; CodeGraph termina mais rápido e é a escolha do apresentador, que pondera se ferramentas extras ainda são necessárias.

Citações

CodeGraph usou cerca de dez por cento menos, mas a diferença de custo foi menor. — 03:54

Isso não mede o que Claude realmente deixou de ler. — 05:03

A revisão de Astra ainda encontrou bugs em todas as implementações. — 06:09

Reduzir esse tempo de espera importa tanto quanto a contagem de tokens. — 07:12

Adicionar outra ferramenta não melhorou o resultado de forma consistente. — 07:43

Conceitos e entidades

CodeGraph (ferramenta): Ferramenta que mapeia chamadas e referências de funções e permite consultar o grafo por MCP.
Graphify (ferramenta): Ferramenta que agrupa código relacionado e permite consultar o grafo por CLI.
Graft (ferramenta): Ferramenta que mapeia chamadas de funções e gera arquivos de referência sobre o código.
GitNexus (ferramenta): Ferramenta que percorre conexões entre funções para identificar fluxos maiores da aplicação.
Codebase Memory MCP (ferramenta): Ferramenta que armazena localmente um mapa pesquisável do código.
Code Review Graph (ferramenta): Ferramenta que mapeia funções e conexões e oferece um workflow separado de revisão de mudanças.
Claude Code (ferramenta): Assistente de programação usado na comparação com e sem ferramentas de grafo adicionais.
Opus 5.5 (modelo): Modelo usado em todas as sessões de programação, configurado em esforço médio.
Fable (ferramenta): Ferramenta usada para preparar os ambientes de teste e supervisionar as execuções.
Astra (ferramenta): Ferramenta usada para revisar as implementações e encontrar bugs.
MCP (conceito): Uma das formas pelas quais algumas ferramentas disponibilizam funções de consulta do grafo ao Claude.

Tradução completa (pt-BR)

00:00 Eu ia fazer mais vídeos comparando ferramentas de grafo de código no Claude Code. Vocês continuaram sugerindo ferramentas nos meus vídeos de comparação, e eu fui anotando os nomes. Mas testar um par diferente em um recurso diferente a cada vez parecia incompleto. Para este teste, escolhi CodeGraph, Graphify, Graft, GitNexus, Codebase Memory MCP e Code Review Graph. São seis ferramentas populares, todas encarando uma tarefa de programação substancial, junto com o Claude Code puro. Todas têm como objetivo facilitar a busca no código e reduzir o quanto Claude precisa ler.

00:34 Todas as sessões de programação usaram Opus 5.5 com esforço médio, sem subagents. Vou mostrar como organizei o teste e qual configuração se saiu melhor. Tenho adicionado edição com IA ao The Gray Cut com Astra. O recurso estava tomando forma, mas eu não estava satisfeito com a interface. Então enviei capturas de tela para Claude Design, e ele voltou com algo mais adequado. A tarefa era levar esse design para o aplicativo.

01:05 Isso significava reconstruir a tela inicial e as configurações, e depois atualizar também a interface do editor. Da última vez, fiz essas comparações manualmente e continuei deixando passar coisas. Desta vez, usei Fable para preparar os ambientes e supervisionar as execuções. Cada configuração recebeu uma cópia própria do projeto, começando com um código de aplicativo idêntico. Dei a todas as sessões o mesmo prompt e os mesmos arquivos de design. Proibi explicitamente os subagents no prompt. Todas as sete sessões seguiram essa instrução; os registros mostram zero subagents.

01:38 Removi Ponytail e Serena das instruções compartilhadas e mantive o restante igual. As execuções se sobrepuseram em grupos. Eu estava preocupado em gastar minha assinatura, mas, depois do primeiro lote, ainda tinha margem para continuar. Vou deixar o prompt na tela. Todas as seis ferramentas analisam o código e registram as conexões entre suas partes. Assim, Claude pode encontrar uma função e verificar o que depende dela. Algumas oferecem ferramentas a Claude por meio de MCP; outras usam comandos de terminal. Hooks também podem adicionar informações automaticamente durante a sessão.

02:11 CodeGraph mapeia chamadas de funções e referências, e monitora alterações para manter esse mapa atualizado. Claude pode consultá-lo por meio de MCP. Aqui, o hook de prompt do CodeGraph forneceu as informações do grafo, sem que Claude chamasse suas ferramentas de MCP. Graphify também agrupa o código conectado em áreas relacionadas. Aqui, Claude usou a CLI do Graphify, então consultou o grafo por meio de comandos de terminal. Os hooks continuaram lembrando Claude de verificar o grafo antes de abrir arquivos. Graft cria um mapa das chamadas de funções e grava arquivos de referência que descrevem o código.

02:46 Ele oferece suporte a MCP e a comandos de terminal; nesta execução, foi usado MCP. Hooks também adicionam contexto automaticamente, incluindo observações sobre o que uma edição poderia afetar. GitNexus acompanha as conexões entre funções para identificar fluxos maiores no aplicativo. Aqui, Claude usou suas ferramentas de MCP para verificar o que as alterações poderiam afetar. Um hook também adicionou informações sobre código relacionado a algumas buscas. Codebase Memory MCP armazena localmente um mapa pesquisável. Claude usa suas ferramentas de MCP para encontrar funções ou seguir as conexões entre elas.

03:21 Hooks também adicionam contexto às buscas e leituras de arquivos. Code Review Graph cria um mapa das funções e de suas conexões, que Claude consulta por meio de MCP. Também oferece um workflow de revisão separado para verificar alterações e sugerir testes. Nesta execução, Claude o usou para entender o código existente antes de editar. Certo, aqui estão os resultados. CodeGraph ficou com o menor custo, e o Claude Code puro ficou em segundo lugar. CodeGraph usou cerca de 17,6 milhões de tokens, contra 19,5 milhões no caso do Claude Code puro.

03:54 Esses totais contam novamente a entrada em cache sempre que ela aparece em outra solicitação. Isso não significa que Claude gerou milhões de palavras. CodeGraph usou cerca de 10% menos, mas a diferença de custo foi menor. Com os preços de API usados aqui, ficou em US$ 8,66, contra US$ 9,18 no caso do Claude Code puro. Isso dá cerca de 6% a menos, ou 52 centavos. Fiz essas execuções usando minha assinatura, então esses valores são apenas para comparação. As quatro ferramentas do meio ficaram a cerca de 35 centavos umas das outras.

04:29 Eu não daria muita importância à classificação com apenas uma execução de cada ferramenta. O resultado do Codebase Memory MCP vem de uma execução substituta. A tabela contabiliza as sete sessões de programação selecionadas. A preparação e as tentativas descartadas foram excluídas, assim como os custos de orquestração e revisão. Graft foi a surpresa. Vocês perguntaram bastante sobre ele, e eu esperava mais. Usou cerca de 39% mais tokens que o Claude Code puro e custou cerca de 23% a mais. Ainda assim, o próprio relatório alegou uma economia de aproximadamente 486 mil tokens.

05:03 Essa estimativa compara as respostas dele com a leitura de arquivos inteiros. Ela não mede o que Claude de fato deixou de ler. Isso me lembra do RTK, em que uma saída encurtada fez Claude precisar de outro comando para verificar o resultado da compilação. Solicitações extras podem anular essa economia. Aqui, Graft fez 92 solicitações ao modelo, contra 72 no caso do Claude Code puro. A falta de contexto poderia explicar parte disso, mas esta execução não estabelece a causa. Se quiser ajudar a manter essas comparações, você pode me apoiar no Patreon.

05:36 Preparar esses testes leva tempo, e ainda preciso verificar o que os agents realmente construíram. Seu apoio me ajuda a dedicar mais tempo a esse trabalho e a testar as ferramentas que vocês continuam me enviando. Então, se esses vídeos ajudam você a decidir o que usar, considere se tornar apoiador. Inscreva-se aqui para ver a próxima comparação e entre no Discord se quiser sugerir ferramentas ou discutir os resultados. Os dois links estão na descrição. Observando as interfaces, as sete versões pareciam bem próximas do que eu queria. Vou mostrar a versão do CodeGraph ao lado do design.

06:09 A revisão da Astra ainda encontrou bugs em todas as implementações, embora a compilação e os testes de regressão tenham passado. O CodeGraph restaurou as durações salvas dos vídeos antes e depois ao reabrir um projeto. Cinco das outras versões não fizeram isso. Ele ainda oculta alguns controles depois de editar ou desfazer uma edição. Vou corrigir os problemas encontrados nessa versão e, depois, submetê-la ao meu pipeline de qualidade habitual antes de usá-la. Então, CodeGraph é a minha escolha neste teste. O tempo também importa, especialmente quando estou apenas esperando um agent terminar.

06:42 CodeGraph terminou em cerca de 19 minutos. GitNexus ficou perto, menos de meio minuto atrás. O Claude Code puro levou cerca de 23 minutos e meio. Então, CodeGraph terminou aproximadamente quatro minutos antes. Graft levou quase 26 minutos, o que deixa o Claude Code puro à frente dele tanto em tempo quanto em custo. As outras ferramentas ficaram entre GitNexus e o Claude Code puro. Você pode ver os tempos na tabela. Essas execuções se sobrepuseram em grupos diferentes, o que poderia afetar os tempos.

07:12 Isso não prova que CodeGraph deixou Claude mais rápido. Ainda assim, quatro minutos fazem diferença quando estou olhando para um terminal ou clicando pelo YouTube enquanto o agent trabalha. Para mim, esperar um agent é a parte mais exaustiva dessa nova forma de trabalhar. Reduzir essa espera importa tanto quanto a contagem de tokens. Então, eu escolheria CodeGraph para esta tarefa. Teve o menor custo, e prefiro a implementação dele, apesar dos bugs restantes. O Claude Code puro ainda se saiu muito bem.

07:43 Com Opus 5.5 em esforço médio, estou cada vez mais confortável começando sem essas ferramentas extras. Minhas comparações recentes usaram tarefas e configurações diferentes. Mas adicionar outra ferramenta não melhorou o resultado de forma consistente. Os modelos também mudaram desde que essas ferramentas surgiram. Talvez modelos mais antigos ou mais baratos tenham mais a ganhar com ajuda para encontrar o código certo. Me contem se querem este teste no Codex e qual modelo devo usar. Ou modelos mais baratos pelo OpenCode seriam mais úteis para vocês?

08:15 A sugestão da minha gata é fechar os terminais e desligar o computador. Depois, dar toda a minha atenção a ela e voltar a fazer carinho nela. Obrigado por assistir. Para ver minha comparação anterior entre Graphify e CodeGraph, assista a este vídeo. Usei Opus 5 em um recurso diferente.

Transcrição original

[00:00] I was going to make more videos comparing code graph tools in Claude Code. You kept suggesting tools across my comparison videos, and I kept writing the names down. But testing a different pair on a different feature each time felt incomplete. For this test, I picked CodeGraph, Graphify, Graft, GitNexus, Codebase Memory MCP, and Code Review Graph. That’s six popular tools all tackling one substantial coding task alongside plain Claude Code. They all aim to make code easier to find and reduce how much Claude needs to read.

[00:34] Every coding session used Opus 5.5 at medium effort, without subagents. I’ll show you how I organized the test and which setup came out ahead. I’ve been adding AI editing to The Gray Cut with Astra. The feature was coming together, but I wasn’t happy with the interface. So I sent screenshots to Claude Design, and it came back with something more adequate. The task was to bring that design into the app.

[01:05] That meant rebuilding the start screen and settings, then updating the editor’s UI as well. Last time, I handled these comparisons manually and kept missing things. This time, I used Fable to prepare the environments and oversee the runs. Each setup got its own copy of the project, starting from identical application code. I gave every session the same prompt and design files. I explicitly prohibited subagents in the prompt. All seven sessions followed that instruction; the logs show zero subagents.

[01:38] I removed Ponytail and Serena from the shared instructions, and kept the rest consistent. The runs overlapped in groups. I was worried about burning through my subscription, but after the first batch I still had room to continue. I’ll leave the prompt on screen. All six tools scan the code and record connections between its parts. Claude can then find a function and check what depends on it. Some give Claude tools through MCP; others use terminal commands. Hooks can also add information automatically during the session.

[02:11] CodeGraph maps function calls and references, and watches for changes to keep that map updated. Claude can query it through MCP. CodeGraph’s prompt hook supplied the graph information here, without Claude calling its MCP tools. Graphify also groups connected code into related areas. Claude used Graphify’s CLI here, so it queried the graph through terminal commands. Its hooks kept reminding Claude to check the graph before opening files. Graft builds a map of function calls and writes reference files describing the code.

[02:46] It supports MCP and terminal commands; this run used MCP. Hooks also add context automatically, including notes about what an edit could affect. GitNexus follows connections between functions to identify larger flows through the application. Here, Claude used its MCP tools to check what changes might affect. A hook also added related code information to some searches. Codebase Memory MCP stores a searchable map locally. Claude uses its MCP tools to find functions or follow connections between them.

[03:21] Hooks also add context around searches and file reads. Code Review Graph builds a map of functions and their connections, which Claude queries through MCP. It also offers a separate review workflow for checking changes and suggesting tests. In this run, Claude used it to understand the existing code before editing. Okay, so here are the results. CodeGraph came out cheapest, with plain Claude Code second CodeGraph used about seventeen point six million tokens, compared with nineteen point five million for plain.

[03:54] Those totals count cached input again whenever it appears in another request. They don’t mean Claude generated millions of words. CodeGraph used about ten percent less but the cost difference was smaller. At the API prices used here, it came to eight dollars sixty-six, against nine dollars eighteen for plain. That’s about six percent less, or fifty-two cents. I ran these through my subscription, so these amounts are comparison figures. The middle four tools were within about thirty-five cents of each other.

[04:29] I wouldn’t read much into the ranking after one run each. Codebase Memory MCP’s result comes from a replacement run. The table counts the seven selected coding sessions. Setup and discarded attempts are excluded, along with orchestration and review costs. Graft was the surprise. You’d asked about it quite a lot, and I expected more. It used about thirty-nine percent more tokens than plain, and cost about twenty-three percent more. Yet its own report claimed roughly four hundred eighty-six thousand tokens saved.

[05:03] That estimate compares its answers with reading whole files. It doesn’t measure what Claude actually avoided reading. This reminds me of RTK, where shortened output left Claude needing another command to check the build result. Extra requests can cancel those savings. Graft made ninety-two model requests here, against seventy-two for plain. Missing context could explain some of that, but this run doesn’t establish the cause. If you’d like to help keep these comparisons coming, you can support me on Patreon

[05:36] Setting up these tests takes time, and I still need to check what the agents actually built. Your support helps me spend more time on that work and try the tools you keep sending me. So if these videos help you decide what to use, consider becoming a patron. Subscribe here for the next comparison, and join Discord if you’d like to suggest tools or discuss the results. Both links are in the description. Looking at the interfaces, all seven versions seemed pretty close to what I wanted. I’ll show you the CodeGraph version beside the design.

[06:09] Astra’s review still found bugs in every implementation, even though their builds and regression tests passed. CodeGraph restored the saved before and after video durations when reopening a project. Five other versions missed that. It still hides some controls after editing or undoing an edit. I’ll fix the findings in that version, then run it through my usual quality pipeline before using it. So CodeGraph is my pick from this test. Time matters too, especially when I’m just waiting for an agent to finish.

[06:42] CodeGraph finished in about nineteen minutes. GitNexus was close, less than half a minute behind. Plain took about twenty-three and a half minutes. So CodeGraph finished roughly four minutes earlier Graft took almost twenty-six minutes, which puts plain ahead of it on time as well as cost. The other tools landed between GitNexus and plain. You can see their times in the table. These runs overlapped in different groups, which could affect timing.

[07:12] This doesn’t prove CodeGraph made Claude faster. Still, four minutes is noticeable when I’m staring at a terminal or clicking around YouTube while the agent works. For me, waiting for an agent is the most exhausting part of this new way of working. Reducing that wait matters just as much as the token count. So I’d choose CodeGraph for this task. It had the lowest cost, and I prefer its implementation despite the remaining bugs. Plain Claude Code still did pretty well.

[07:43] With Opus 5.5 at medium effort, I’m increasingly comfortable starting without these extra tools. My recent comparisons used different tasks and setups. But adding another tool hasn’t consistently improved the result. The models have also changed since these tools appeared. Maybe older or cheaper models have more room to benefit from help finding the right code. Let me know if you want this test in Codex, and which model I should use. Or would cheaper models through OpenCode be more useful to you?

[08:15] My cat’s suggestion is to close the terminals and shut down the computer. Then give her all my attention and get back to petting her. Thanks for watching. For my earlier Graphify and CodeGraph comparison, watch this video used Opus 5 on a different feature.