The More I Learn About AI, the Less I Put the Model Everywhere.

I built a knowledge graph for my codebase without a single model call — and refusing to use one taught me more about where AI actually belongs in a system than reaching for it would have.

That sounds like a contradiction.

It actually became one of the most useful things I’ve built while learning AI.

For the last few months, I’ve been deliberately working my way into AI from the fundamentals.

Not just learning how to call an LLM.

I’m trying to understand what happens around the model:

tokens → context → tools → retrieval → agents → protocols → code intelligence.

And then build those pieces myself.

This time, I started with a tool called graphify.

The idea is simple:

Give an agent a persistent knowledge graph of a codebase so it doesn’t have to rediscover the repository every time.

The interesting part was how that graph was built.

For every batch of files, an LLM was used to read the code and infer relationships.

That made sense for things that actually require interpretation.

But then I thought about code.

If I have:

import foo
save() → persist_batch()
test_x() → save()

those relationships aren’t really something the model needs to reason about.

They’re already present in the structure of the code.

That’s when Tree-sitter clicked for me.

Instead of asking an LLM to understand something a parser can determine exactly, why not let the parser do it?

So I built my own version:

[**claude-graph](https://github.com/mohansagark/claude-graph)** — pip install claude-graph

A local knowledge graph for a codebase that Claude Code can access through MCP.

The pipeline is surprisingly simple:

Tree-sitter → parses the repository

SQLite → stores the graph

Graph traversal → answers structural questions

MCP → exposes those capabilities to the agent

And the LLM?

It doesn’t build the graph.

It reads the results and reasons over them.

That distinction taught me something important about AI engineering.

MCP became much less mysterious.

Before building an MCP server, “Model Context Protocol” sounded like another big AI abstraction.

After building one, I realized the important part isn’t the protocol itself.

It’s the interface you expose to the model.

The model sees your tool description, understands what the tool can do, decides when to use it, and generates the arguments.

That means something I previously thought of as ordinary documentation suddenly becomes part of the model interface.

A vague description can produce a bad tool call.

A precise description can make the tool much more useful.

That’s a different way of thinking about API design.

I also started seeing tokens differently.

Previously, tokens were mostly something I associated with model pricing and context windows.

Building this made them feel much more like an engineering resource.

Every unnecessary model call has a cost:

tokens + latency + context + network dependency.

If a deterministic parser can answer the question, sending the problem to an LLM isn’t “AI-powered.”

It’s just expensive.

I checked what that’s actually worth instead of guessing. On claude-graph’s own repo, right now, asking “who calls get_node?” the honest way — opening the five files that call it and reading them in full — costs about 6,700 tokens. Asking claude-graph the same question costs about 600. Same answer, roughly a tenth of the tokens, and that’s before graphify’s per-file model call to build the graph is even in the picture.

That changed another instinct I had.

I initially considered embeddings for semantic search.

But then I realized something obvious:

Claude Code is already the language model.

My tool doesn’t need to become a second, smaller language model.

It needs to provide good information to the model that is already doing the reasoning.

So I kept the tool deliberately simple:

Tree-sitter + SQLite + graph traversal + MCP.

No embeddings.

No model calls.

No network calls.

There’s even a test that runs the entire build, query, impact, search, visualization, and MCP workflow with outbound sockets disabled.

The constraint is enforced, not just documented.

And that was probably the biggest lesson.

I’m beginning to understand that building AI systems isn’t necessarily about putting an LLM everywhere.

It’s about understanding:

What should the model reason about?

What should be deterministic?

What information should enter the context?

How much context is enough?

What should a tool expose to an agent?

Where are tokens actually buying intelligence, and where are they just paying for work a parser or database can already do?

That’s the part of AI engineering I’m finding increasingly interesting.

Not just prompting models.

Not just using agent frameworks.

But understanding the machinery around the model well enough to build my own.

A few months ago, I was learning the vocabulary.

Now I’m starting to build the components.

And that’s probably the most meaningful progress I’ve made in my AI journey so far.

The goal isn’t to say “I know AI.”

It’s to get to the point where I can look at an AI system and understand why every piece is there — and build the pieces myself when I need to.

This is one more step in that direction.

The code’s on GitHub, and it’s on PyPI if you want to point it at your own repo: pip install claude-graph.

I’m learning AI in public, one fundamental at a time. What AI concept did you understand only after you actually built it? 👇