DEV Community: Tim Wheeler

Supercharge your AI Coder with a code-graph

Tim Wheeler — Wed, 24 Jun 2026 03:19:06 +0000

One of the most powerful upgrades you can give any AI developer

Introduction

AI coding assistants are dazzling on a single file and surprisingly lost on a large one. Point a capable agent at a mature, multi-package codebase and you watch the same pattern every session: it greps for a symbol, opens a dozen files to work out how they fit together, and burns a large slice of its context window simply rediscovering the shape of the system before it can do any actual work.

That orientation phase — the crawling, the grepping, the file-by-file reconstruction of structure the codebase already encodes — is the single biggest waste of tokens in most AI-assisted workflows. And it repeats every session, because nothing persists.

The fix is straightforward: give the agent a map. Model your codebase as a knowledge graph and let the agent query the map instead of crawling the territory. This article explains what that looks like, why it works, and what it actually finds when you run it on a real system.

TL;DR

A code-graph should map your architecture not just your code.

Converting grep to graph minimises token usage and saves you time.

Find bugs, security mistakes, and omissions in your codebase in seconds.

Plan upgrades quickly and with far more accuracy.

Using deep-memory's vocabulary simplifies usage for your AI.

Use deep-memory free.

Check out the full example code-graph-guide.md

What is a code-graph

A code-graph is a graph database representation of your system. I use the word system and not code deliberately — the real power comes from driving architectural insights, not just building a faster file search.

Code graphs are becoming popular. There are some impressive repositories where the author has scripted a process to mirror a codebase into a graph DB, capturing files, imports, and call relationships. That approach is useful for dependency visualisation. But mirroring syntax only scratches the surface.

What separates a useful code-graph from an elaborate directory listing is intentional modelling. You decide what entities matter to your architecture — commands, services, API routes, database tables, tests, authorisation checks, validation rules — and you define the relationships that carry meaning: implements, depends-on, guards, covers, throws. The graph is built against your conventions, not a generic notion of "code." That specificity is what makes absence detectable, and absence is where the real value hides.

The Power of Insights in a code-graph

The real value isn't the graph itself — it's the questions it answers in one query that would otherwise require a mass of grepping. And often the most important answer is the relationship that isn't there.

Security holes show up as missing edges. You can see which routes run an authorisation check — and, more importantly, which don't. The absence of a "checks access" edge on a route that reaches real business logic is a hole you'd never spot by reading files one at a time.
Defence-in-depth gaps become obvious. When a guard lives only at the route and not on the command beneath it, the graph shows it — so you know before you add a second caller that bypasses the check.
Dead and dangerous code surfaces instantly. Permission targets nothing enforces, validators no scenario uses, database tables no code reads — all are just nodes with no incoming edges.
Untested risk is ranked, not guessed. You can list destructive operations with no test covering them, turning "we should test more" into a concrete, prioritised backlog.
Blast radius is one traversal away. Before changing anything you can see everything that depends on it — callers, routes, docs, tests — so planning is faster and regressions are rarer.
Hot spots and choke points are visible. The most-depended-on services and most-accessed tables tell you where a change ripples widest and where to focus review and hardening.
Architecture rules become checkable. Intended conventions (e.g. "only the data layer touches SQL") turn into queries, so violations are caught in CI instead of code review.
New developers ramp up faster. A newcomer can ask "what calls this, what guards it, what tests it?" and get an answer in seconds instead of reverse-engineering it from source.
It scales where people don't. These insights hold across thousands of files and hundreds of routes — exactly the scale at which manual review quietly misses things.

We dogfood this on our own codebase

The best way to understand what a code-graph actually does is to see it working on a real system.

At Utaba we use Deep Memory — our own open-source library — to build a live code-graph of the UCM platform itself. UCM is the product we ship; the code-graph is how our team and our AI coding agents navigate it. We build UCM with the very capability we offer to customers.

Here is what it has found and done.

Blast-radius analysis — in one query. Before modifying a core UCM service, the graph returned the full dependency picture: 35 commands rely on that service. One query, no file reads. That list became the review checklist before the change landed.

Security audit — zero false alarms. We asked: which public API endpoints reach a command with no permission check? The graph returned exactly four — all legitimate sign-in and service-discovery routes. No surprises buried in the list, no manual triage needed. That kind of signal, at that precision, from a text search is not realistic.

Dead code caught automatically. The graph recently flagged 24 validation rules that were defined but never used — the kind of quiet accumulation that is invisible in day-to-day work and would only surface in a dedicated audit, if at all. It also caught a documentation example that had silently gone stale.

Planning a new feature from graph queries, not file reads. When planning a new capability, our AI agents check the graph first: Does this already exist? What will it affect? Are we duplicating something? These are graph queries, not guesswork. They consistently stop wasted effort and accidental duplication before a line is written.

Token efficiency — the quiet win. Instead of an AI agent reading dozens of files to understand a dependency chain, one near-instant query returns the precise answer. Less reading means fewer tokens, lower cost, and faster, more accurate responses. On a large codebase the saving is not marginal — the orientation phase is often the single largest consumer of context, and the graph collapses it.

One detail worth highlighting: roughly 80% of the graph builds itself with no AI involved. Most relationships are already declared in the code — imports, interface implementations, route registrations — so they are mined deterministically. Fast, exact, and free. The AI handles the edges that require interpretation; the extractor scripts handle everything mechanical.

Building a code-graph with deep-memory

The implementation is a set of small, independent extractor scripts feeding a single reconciling orchestrator. Each extractor owns one layer of the model (packages, providers, tools, docs, tests, modules, errors) and is a pure function: it reads source with a real parser — never regex — and returns plain node and edge descriptors with no knowledge of the graph store.

The script runs automatically on each build, or on-demand. It should take just a few seconds because it reconciles delta changes, not a full rebuild.

There is a full example you can point your AI at to build its own specialised code-graph for your codebase. The guide walks through the vocabulary, the extractor pattern, and how to wire the orchestrator — an afternoon's work to have it running on your own system.

Conclusion

AI coding agents do not struggle with large codebases because they cannot read. They struggle because they have no map. Every session, they reconstruct the same structural knowledge from scratch — at your cost in tokens, latency, and their finite attention.

Build the map once, and every session after pays it back. Navigation becomes one query instead of twenty file reads. Security gaps surface as missing edges, not missed audits. Architecture rules move from wiki pages nobody re-reads to queries any agent can run on demand.

The practical starting point: clone the deep-memory repo, read the code-graph guide, and point an AI agent at the example scripts. It is open source and designed to be adapted to your codebase in a single session.

If you are working on a larger system and want to talk through what this would look like applied to your architecture, get in touch.

How I Solved AI's Inconsistent Code Problem

Tim Wheeler — Fri, 29 Aug 2025 03:39:46 +0000

After 30 years of development, AI coding tools promised to revolutionize my workflow. After much learning, I found a solution.

In the Beginning

Do you find yourself restraining from scolding your AI developer? Well, if yes, you are not alone.

When I started working with Claude Desktop, then Claude Code, I said, "This is so cool!".

Reality Hits Hard

"This is so cool!" quickly turned into "What a pile of @#$%#!"

The problems were everywhere:

Inconsistent patterns across different sessions
Hardcoded configuration scattered throughout the codebase
Missing security validations that any junior dev would catch
Architectural decisions that changed randomly between conversations
Reinventing the wheel instead of using established libraries

Claude has epic amounts of Intelligence, and teenie tiny amounts of wisdom.

Giving Claude Wisdom

After much frustration, I had a realization: the fault wasn't Claude's—it was mine.

AI systems are basically a pattern matching behemoth. Without proper guidance to narrow down those patterns, they'll match against everything they've ever learned. That's a recipe for inconsistent, buggy, insecure code.

The solution? Persistent guidance, and the term in the industry right now is Context Engineering.

My Failed First Attempts

I started simple: markdown files with coding standards, architecture decisions, and examples stored in Git repositories.

This worked... sort of. But it quickly became cumbersome:

AI couldn't easily discover relevant guidance
No way to ensure AI actually read the documentation
No continuity in our conversations
Guidance scattered across different repos and folders
Lack of governance
Compacted conversations lost a lot of the initial reading

I needed something better.

The Real Solution: Context Management

I built what I call the Universal Context Manager (UCM) - essentially "GitHub for AI-consumable artifacts."

Here's what it does:

Structured storage for guidance, templates, and examples
AI-friendly tools through MCP (Model Context Protocol) servers
Discovery-first workflow so AI finds relevant patterns automatically
Version control for guidance and templates

When I first started using the UCM for my own work, it felt like I was 7 years old again and got my first bike. Wow, this is really cool. Let's make it better.

The aim was to minimize friction between the AI and the system.
So, after much trial and error, working with Claude, testing, reviewing and improving the workflow, the UCM was ready.

Instead of inconsistent code, I got:

Quickly get up to speed with the 'Recent Artifacts Tool'
Find code, patterns and guidance through the 'Search' and 'List Artifacts' tool
Consistent architectural patterns
Proper configuration management
Security validations by default
Reusable, tested components

What was so powerful about the UCM:

The MCP Server tools forced Claude to do a few key things:

Get initial guidance from the 'UCM Quickstart' tool which explained important concepts and rules
Forced Claude to assign Categories and Subcategories to the artifacts, creating a natural structure and coherent filing system
Gave Claude valuable metadata to fill out, such as a 'Description', allowing for search and quick retrieval of relevant details.

And all this I get now for almost no effort. Claude just knows how to deal with things.

This is the closest to 'J.A.R.V.I.S.' I've been able to get, one of my goals :)

A Real Example: The MCP Server Saga

Let me share a concrete example that shows the before and after.

The Task: Build a Remote MCP Server compatible with Anthropic's specifications.

Without UCM (Days of pain):

Day 1: Claude builds NodeJS server → Incompatible with NextJS
Day 2: Rebuild for NextJS → Doesn't follow MCP protocol standards  
Day 3: Add Anthropic MCP SDK → SDK incompatible with NextJS
Day 4: Build custom adapter → Partial success, still buggy
Day 5: Discover 'mcp-handler' package → Finally works!

Many days of trial and error, wrong turns, and... let's say "colorful" feedback to Claude.

Next time, With my published guidance in the UCM (30 minutes):

Me: "Hi Claude, build a Remote MCP Server. Check UCM for implementation guidance."
Claude: *Reads stored guidance, finds mcp-handler solution, generates working code*
Result: Working server in first attempt

Check it out here: nextjs-remote-mcp-server.md and here route.ts

Claude remembers your history

I got a little frustrated with having to repeat myself, you know even a Junior Dev get's it after some practice, but not Claude. That's solved now.

The Game Changer: Shared Knowledge

Here's the powerful part - I documented that entire MCP server solution in UCM's public repository.

This means other developers can:

Get a free UCM account
Add the Remote MCP Connector: https://ucm.utaba.ai/api/mcp
Ask their AI to check the Utaba repository for MCP guidance
Build a working Remote MCP Server immediately

No more three-day debugging sessions. No more reinventing solutions.

Building a Community

The vision extends beyond personal productivity. Imagine a community where developers share battle-tested guidance:

Security patterns that prevent common vulnerabilities
Architecture decisions that scale properly
Integration solutions for complex scenarios
Best practices that actually work in production

Currently, UCM accounts are private (you access your guidance plus public Utaba patterns). But I'm exploring public repositories - carefully, because we all know the security implications.

What's Next?

I'm looking for developers who want to try this approach. There's a free tier that will always exist, plus I'm offering free paid subscriptions for anyone willing to test the system and provide feedback.

The goal isn't to replace your development skills - it's to amplify them. When your AI has consistent, tested guidance, you spend time solving business problems instead of debugging inconsistent generated code.

More importantly, you get a code base built on standards, that is cohesive and consistent.

Connect to the UCM and become a true orchestrator of AI Development.

Want to try it?

Grab a free UCM account
Add the Remote MCP Connector: https://ucm.utaba.ai/api/mcp
Join our Discord for feedback and discussion or to request a free upgrade subscription: https://discord.gg/ZkVEJvBt
Send feedback directly through your AI (yes, really - we built tools for that)

After 30 years of development, I thought I'd seen every productivity tool. Turns out, the missing piece wasn't better AI - it was better context management.

By Tim Wheeler, Code Monkey, Solution Architect - Passionate about Tech, Founder of Utaba.

Tags: #ai #claude #development #aigovernance #productivity #mcp #coding #contextengineering #anthropic