35% Less Token, 94% Drop in Tool Calls! 5 Programming Habits Changed by a Local Knowledge Graph

After building a local knowledge graph, my programming habits changed.

It all started a few days ago:

I was chatting with a developer friend, and he mentioned a project his company was optimizing:

A psychological assistant agent for teenagers, used for emotional guidance and crisis intervention.

“We’re stuck on the knowledge base design,” he said. “You know, we want to build a knowledge graph for the AI to diagnose with.” I had mistakenly thought RAG was the same as a knowledge graph, and then he gave me a lesson…

After that, he suggested I find an open-source SKILL (tool) and build my own knowledge graph for my current project.

Honestly, I’m grateful he explained things to me. After fully understanding both concepts and building a knowledge graph once, my programming habits felt completely reshaped (what a descent?). The local graph worked way better than I expected.

So today, I decided to write about my experience, focusing on three things: What exactly RAG and knowledge graphs are, what Graph RAG is, and the five programming habits that were completely transformed by my local knowledge graph in practice.

Clarify First: What’s the Difference Between RAG and Knowledge Graph?

1. What Exactly Is RAG

RAG stands for “Retrieval-Augmented Generation”. Its core idea is to combine the “memory” stored in the large model’s parameters with “non-parametric memory” retrieved from external sources, using retrieval results to assist in generating answers.

For example, you ask AI: “What cuisine does Peking duck belong to?”

Normally, the question itself is fed as context to the large model, which answers based on the memory from its training parameters.

But the problem is clear: if the model wasn’t trained with relevant information, or the information isn’t the most recent or accurate (e.g., overwritten by a recent “Peking duck leg incident”), the answer quality may be unsatisfactory.

With RAG, you stitch in additional external memory or knowledge:

1. Peking duck is a famous dish from Beijing.
2. Peking duck belongs to Beijing cuisine.
3. The main ingredient of Peking duck is duck meat.

This knowledge is combined into a complete input prompt: {Peking duck is a famous dish from Beijing. Peking duck belongs to Beijing cuisine. The main ingredient of Peking duck is duck meat.} + {What cuisine does Peking duck belong to?}

Because the context provides the model with more relevant information, the model essentially “flips to the correct page” in its reference, making the answer more reliable. It accurately finds the key information “Beijing cuisine” and answers:

Peking duck belongs to Beijing cuisine, with duck meat as the main ingredient.

Of course, this is just a simple example. Below is the complete RAG flow.

Since building RAG often involves building a vector database, many people misunderstand: vector database == RAG. I made that mistake when I was starting out. But actually, RAG is a system process; the vector database is just one commonly used component within RAG.

A typical RAG system usually includes:

1. Source material
2. Split into chunks
3. Convert to embeddings
4. Store in vector database
5. User asks a question
6. Retrieve relevant chunks
7. Feed chunks as context to the large model
8. Large model generates answer

So RAG is a pipeline:

In practice, the chunk is an important unit. For example, a 10-page PDF might be split into many chunks:

• chunk 1: Page 1, paragraph 1
• chunk 2: Page 1, paragraph 2
• chunk 3: Page 2, paragraph 1
• …

Each chunk is converted into a vector.

The user’s question is also converted into a vector.

Then the system asks: Which chunks are semantically closest to this question?

That’s vector retrieval. After retrieval, we go back to our initial step: concatenate the retrieved content back into the question – e.g., “What cuisine does Peking duck belong to?” – and let the large model answer.

2. Knowledge Graph: Complete Constraint on Reasoning Chains

The thought model of a knowledge graph is completely different. Instead of cutting documents into fragments for retrieval, it breaks knowledge into “entity + relation” triples.

Using the Peking duck example with a knowledge graph:

• (Peking duck, belongs to dish type, Beijing cuisine)
• (Beijing cuisine, is a type of, Chinese cuisine)
• (Peking duck, main ingredient, duck meat)
• (Peking duck, cooking method, roasting)
• (duck meat, comes from, duck)
• (duck, belongs to, poultry)
• (poultry, belongs to, animal)

This graph can not only answer “What cuisine does Peking duck belong to?” but also reasoning questions that RAG finds hard to answer directly:

“What kind of animal does the main ingredient of Peking duck come from?”

The reasoning path:

Peking duck → duck meat → duck → poultry → animal

That’s the core advantage of a knowledge graph: it can perform multi-hop reasoning along relationship chains, instead of just searching through semantically similar text chunks.

3. Why Are They Often Confused?

Because both are called “knowledge bases.” Because both can make large models answer more accurately.

It’s a simple trap.

To AI, both are usually treated as external knowledge bases, both aiming to improve model answer quality.

Many online tutorials say:

“Use RAG to build an enterprise knowledge base” or “Use a knowledge graph to build an enterprise knowledge base.”

But in reality: RAG enhances answers with external text evidence. Knowledge graphs constrain reasoning with structured relationships.

Same goal, different paths.

At this point, a quick-thinking audience member might ask: “Host, host, is there a way I can both use external evidence and leverage local structured relations to enhance reasoning?”

Yes, brother, yes. Enter Graph RAG.

Extra: Graph RAG – Making AI a Reliable Brain Trust

As the name suggests, this combines RAG and a knowledge graph into one.

You can think of it this way: Graph RAG uses graph structures to enhance RAG’s retrieval and reasoning.

Of course, this also introduces extra overhead. Essentially, it requires the large model to first understand the relationships between entities before answering, then combine text evidence to generate more accurate and explainable answers.

You not only need to maintain your knowledge graph, ensuring consistency and correctness of relations, but also spend time building the RAG pipeline, and finally wiring up the interface – quite troublesome. This is usually an enterprise-level engineering task. I don’t recommend it for personal local knowledge bases; it’s too much hassle.

Hands-On: How to Turn a Project into a Knowledge Graph

From my personal experience, the most comfortable approach is to convert a large local code project into a knowledge graph.

By pre-indexing your entire codebase into a local knowledge graph (building it in advance), subsequent queries go directly through the graph, eliminating the need to scan all files every time. Tool call count dropped by 94%, speed skyrocketed, and tokens were saved significantly. I’ve fallen in love with this paradigm.

It’s also surprisingly easy to set up. There’s a popular open-source project called “CodeGraph” that runs entirely locally, meeting my security and privacy needs, so I installed it directly.

Installation & Integration

In fact, the following three steps were all done by AI. I literally just said:

“Help me install: https://github.com/colbymchenry/codegraph”

Step 1: Install

npm i -g @colbymchenry/codegraph

Verify:

codegraph version
# Output: 1.0.1

Step 2: Integrate with AI Assistant

CodeGraph supports Claude Code, Cursor, Codex CLI, Hermes Agent, and 8 other mainstream AI programming assistants. I use Hermes Agent. One command automatically integrates:

codegraph install --target hermes --location global --yes

It automatically writes the MCP Server configuration into ~/.hermes/config.yaml.

Then restart Hermes. Done.

Step 3: Initialize the Project

Enter your project directory:

cd your-project
codegraph init

My project is a long-standing detection system with 92 files, mixing Python + Vue + YAML. Running it:

◆ Indexed 92 files
● 1,166 nodes, 2,141 edges in 1.3s
└ Done

1.3 seconds. 92 files, 1,166 nodes, 2,141 edges. After initialization, CodeGraph automatically starts file watching. Any code changed by you or AI will automatically sync incrementally into the graph, no need to manually rebuild indexes.

Changes in Programming Habits: Five Concrete Before & After

I know some people might think I’m clickbait because I didn’t “recycle” the title.

But this article isn’t just a simple intro. I honestly share my journey and workflow changes during this period.

No More Blind “grep” for AI

Before: Having AI understand a feature flow required 8–12 tool calls back and forth – grep this, read that, grep again, read again – burning tons of tokens. I’m looking at you, Claude, costing me real money every time.

Now: One codegraph_explore("how does video extraction work") instantly returns the relevant symbols, call chain, and source code. The AI went from “a blind person feeling an elephant” to “walking with a map.”

Needless to say, token savings are real – token costs are down 35%!

No More Fear of Taking Over New Projects

I remember: In the past, when taking over a new project, the first two days were spent understanding the code structure. If AI helped, it would burn a ton of tokens in one go – because the project was really big.

Now: With codegraph init, the graph is built in a second. After Hermes summarizes, it directly tells me where the entry point is, how data flows, and which modules are core.

From needing two days to get started, now I can write code in minutes. Efficiency improved 114514%.

Precision Test Execution

Previously, when adding “aff” to the relay station, testing was incomplete. Some steps led to bugs, causing a black screen. I didn’t catch it during local testing, spent half a day fixing it, and was exhausted.

Now, with the graph, codegraph affected runs only the tests that are actually affected. Combined with git diff --name-only HEAD | codegraph affected --stdin, one command does it all. No need to worry about test coverage.

Feedback loops went from minutes to seconds. And shorter feedback loops = higher development efficiency.

Afterword

I didn’t title this article “CodeGraph Tutorial” because the tool itself isn’t important – there are many open-source ones online. What matters is how it changes you.

If you also find your AI assistant “getting lost” in your project – repeatedly grepping, reading, misunderstanding, missing key dependencies – try giving it a map.