← All episodes · AI Jason
I was giving my coding agent context the wrong way...
Overview
Jason argues that most coding agents waste enormous amounts of context because they treat a codebase as flat text instead of the graph it actually is: every import and function call is an edge that gets thrown away when an agent greps and reads files one by one. He introduces Codebase Memory MCP, a tool built mostly in C/C++ that extracts functions, classes, and messages from source code and builds a relationship graph across files and even across repos, without invoking any LLM in the indexing pipeline. Because indexing is purely programmatic, it's extremely fast, indexing the Linux kernel in about 3 minutes and smaller codebases in seconds.
The tool exposes a set of graph-aware tools to the agent: get architecture (a quick overview of the codebase), search graph (to locate a specific function/class node), trace path (to map how a function connects to and is used by other code), plus the ability to run structural queries like finding which callers of a function lack test coverage, and detecting architectural impact during PR review. What makes it stand out from prior code-indexing MCP projects, in Jason's view, is its use of Cloud Code/Codex's pre-tool-use hook: even if the agent forgets to call the special graph tools and just runs a normal grep, the hook intercepts the grep call and injects the richer graph context into the grep results anyway, so the tool doesn't depend on the agent remembering to use it correctly.
Jason walks through installing the tool (with the optional --ui flag for a graph visualization web UI), indexing his own monorepo in seconds, and then a concrete demo on his Superdesign codebase: tracing a hidden dependency (a 'canvas lock' used to prevent race conditions when multiple agents create design nodes on the same canvas) that isn't visible from the function that ultimately depends on it. He then runs a side-by-side token comparison, with and without the MCP tool, showing roughly a 50% reduction in token usage for the same investigative task.
Topics
The core problem: agents read codebases as flat text
Jason opens by describing a familiar failure mode: ask a coding agent to change something in a large codebase, and it greps, gets a wall of matches, opens 20 files one at a time, and still misses places that could break. His diagnosis is that a codebase is already structured as a graph — every import and every function call is an edge — but agents discard that structure and read code as undifferentiated text.
He frames this as especially painful in production settings with more than one repo, where understanding cross-repo dependencies and getting an agent to safely modify code that spans repos has been a persistent, difficult problem. This sets up the rest of the video: a tool designed specifically to give agents a map rather than a flat text dump.
Why prior code-indexing MCP tools fell short
Jason acknowledges that viewers may be fatigued by the parade of MCP tools claiming to solve code indexing and retrieval over the past few months, but argues none of them solved the problem well. Prior approaches either used an LLM pipeline to generate a knowledge map — which goes stale quickly as code changes — or simply didn't integrate well with how coding agents actually work day to day.
By contrast, Codebase Memory MCP is mostly built in C and C++, making it (in his framing) the fastest and most efficient code intelligence engine available for coding agents, since indexing is purely programmatic with no LLM involved, avoiding both the staleness and the latency of LLM-based approaches.
How the tool builds a cross-file, cross-repo relationship graph
The tool extracts root functions, classes, and messages from source files and builds a relationship graph representing how these entities connect. This process happens per file and then gets stitched together across files — so if you have three files, it extracts each file's functions/classes/messages and builds a cross-file graph connecting them. The same process scales to build a graph across an entire codebase, and even across multiple repositories.
Because the whole extraction and graph-building process is programmatic rather than LLM-driven, it runs extremely fast: Jason cites indexing the entire Linux kernel in about 3 minutes, and smaller codebases indexing in mere seconds. This graph becomes the substrate that lets an agent understand what a code file is and how it connects to everything else without loading thousands of lines of raw code into context.
The agent-facing toolset: architecture overview, graph search, trace path, and queries
Once the graph exists, the agent gets a specific toolkit. 'Get architecture' returns a quick overview of the codebase's overall structure, so the agent can orient itself without reading everything. 'Search graph' lets the agent locate the specific node for a function it needs to change. 'Trace path' then maps out the code chain from that node — showing where a function is used and what else it touches, effectively giving a 'blast radius' view before making a change.
Beyond navigation, the agent can run structural queries against the graph that would otherwise be tedious to answer manually — for example, finding all files that call a specific function like 'handle order' and identifying which of those call sites lack test coverage. The agent can also pull the code snippet for a specific function and detect architectural change impact during PR review, so a reviewer (human or agent) can quickly see what a given change touches across the codebase.
The pre-tool-use hook: making the tool useful even when the agent forgets to call it
Jason identifies this as the single most interesting design decision in the project, and the reason he thinks it succeeds where others failed. Previous graph/memory-search MCP tools often confused agents: even when given a code-search or memory-search tool, agents frequently didn't know when to reach for it instead of the default grep tool, since every major coding agent provider (Cloud Code, Codex) has heavily optimized its own built-in grep.
Codebase Memory MCP works around this by hooking into the pre-tool-use hook. If the agent forgets to explicitly invoke a graph search and just runs a normal grep for a function name, the hook still fires: it performs the normal grep and returns those results, but simultaneously captures the relevant graph context and injects that richer information alongside the grep output. In other words, the tool doesn't depend on the agent remembering to call a special MCP tool correctly — it piggybacks on the tool the agent was already going to use. Jason explicitly recommends this hook-based pattern to anyone building their own MCP tools, calling it a better design than most existing approaches.
Installing and indexing a real monorepo
Jason walks through setup: there are two install commands, a basic version and one that adds a graphical visualization UI for the graph (installed via a --ui flag). After installing the MCP into his coding agent, he simply tells the agent 'help me use Codebase Memory MCP,' and it prompts him to set up the index.
The tool is smart about existing project conventions — in his codebase it detected folders that were already documented/organized (he mentions it identifying 'Lexi' folders) and applied filters to ignore them appropriately. Indexing his own codebase, which he describes as a large, semi-complex monorepo with multiple subfolders, took only a few seconds. Once indexed, he opens a separate terminal to run the tool with --ui=true and a defined port, launching a web UI where the graph can be visually reviewed — Jason isn't sure how practically useful the visualization is, but says it looks impressive.
Demo: tracing a hidden 'canvas lock' dependency in Superdesign
To show the tool's power concretely, Jason indexes the codebase for Superdesign, described as a vibe design platform. He highlights a backend function called 'create design draft node' — a tool the agent calls when a user gives a prompt, which adds a design node to an infinite canvas. Hidden inside this flow is a mechanism called 'canvas lock': because multiple agents might create designs on the same canvas simultaneously, the lock ensures operations flow through a queue to avoid conflicts and race conditions.
Critically, this lock is not visible in the 'create design tool' file itself — the function delegates to it indirectly through several layers, so a human or agent reading or grepping that one file would completely miss that the protection exists. Jason asks the agent to trace the 'create design draft node' and canvas lock flow using the memory graph, and within seconds it returns the full execution flow, surfacing the otherwise-invisible dependency.
He then poses a practical scenario: imagine a new engineer thinks the lock is slowing things down and wants to tweak it. Asking 'what will break if I change it?' with the graph-aware agent identifies three distinct ways the lock is used elsewhere in the code — impact that would be very easy to miss without the graph.
Token consumption comparison: with vs. without the MCP
Jason runs a direct side-by-side comparison to quantify the benefit. Using the same prompt to trace the create-design/canvas-lock flow, the session using Codebase Memory MCP consumed about 11,000 tokens for the message context, versus about 38,000 tokens for an equivalent session run without the MCP — roughly a 3.4x difference.
For a follow-up, harder question — 'trace what would break if I change the lock' — the MCP-assisted session ran for about a minute and successfully identified all 13 different call sites affected by the lock, using about 33,000 tokens total. The non-MCP session, by contrast, used about 64,000 tokens — almost double — to attempt the same investigation. Jason frames this roughly-50%-token-savings result as the headline benefit of the whole approach.
Rollout into Jason's broader agent-setup skill and open-source availability
Jason mentions he has already updated his 'set up codebase harness' skill to include Codebase Memory MCP by default, bundling it alongside other tools his team uses when spinning up a new engineering setup: end-to-end test scaffolding, a script toolkit for getting a local server running, and a 'crap box' (sandbox) setup for running parallel agent testing in a remote sandbox. He notes this is part of a broader set of skills for onboarding an AI engineer with the best practices his team has developed.
The project and his setup skill are open-source, and he points viewers to a GitHub link in the video description (searchable as 'GitHub AI Builder Club skill') for anyone who wants to copy and adapt the setup for their own codebase.
Visuals
- Index codebaseProgrammatic (C/C++) extraction of functions, classes, messages — no LLM, seconds to minutes even for huge repos
- Build relationship graphConnects entities within and across files, and across multiple repos
- Agent calls a tool (or just greps)get architecture, search graph, trace path, or a plain grep
- Pre-tool-use hook interceptsIf agent used plain grep, hook still injects graph context alongside grep results
- Agent gets blast-radius pictureSees call chains, hidden dependencies, missing test coverage, PR impact — using far fewer tokens
Takeaways
- Coding agents that rely on grep treat a codebase as flat text, discarding the import/function-call graph that's already implicit in the code — this causes both missed edge cases and blown-up context windows.
- Codebase Memory MCP builds its relationship graph programmatically (in C/C++, no LLM involved), so indexing is fast (Linux kernel in ~3 minutes) and doesn't go stale the way LLM-generated knowledge maps do.
- The tool's pre-tool-use hook design means it still enriches results even when the agent forgets to call the special graph tool and just uses ordinary grep — a more robust pattern than relying on the agent to remember the right tool.
- Tracing 'blast radius' before making a change (via trace path / graph queries) surfaces hidden dependencies — like Superdesign's canvas lock — that are invisible from reading a single file or grepping for a keyword.
- In head-to-head testing, using the graph-aware MCP cut token consumption roughly in half compared to the same investigative task without it (e.g., 33k vs 64k tokens for a 'what would break' query).
- The setup is open-source and has been folded into a broader 'codebase harness' skill alongside e2e test scaffolding and sandboxed parallel-agent testing tools.
Notable quotes
Your code base is already a map. Every import, every function call is an edge. Your agent just throw that structure away and reads it as a flat text.— Jason
This function delegated down through layers. So for any agent or even human reading this one file or grepping it for lock, this protection is real but just invisible from where the work starts.— Jason
It successfully identify all 13 different core sites. It's so far it's only taking 33,000 tokens. But for the other one without code base memory MCP, that's 64,000 tokens, doubling the other one.— Jason