Why I have spent eight months mapping my code for AI agents, and why it has only just become a game changer.

On 1 June 2026, GitHub quietly flipped a switch that a lot of developers had been dreading. Copilot moved off its flat monthly rate and onto token based billing. Within days the forums filled with screenshots of monthly bills jumping from thirty dollars to seven hundred and fifty, and in a few cases from fifty dollars to three thousand. The reaction was equal parts shock and betrayal.

I understand the frustration, but I cannot say I was surprised. If anything, I had been preparing for this exact moment for the better part of a year.

The honeymoon was never going to last

Cast your mind back to the early days of GitHub Codespaces and Copilot. You spun up a cloud development environment in the browser, Copilot finished your lines before you had thought of them, and the whole thing cost about ten dollars a month. It felt like magic, and it felt free.

It was not free. It was subsidised. The Wall Street Journal reported back in 2023 that Microsoft was losing roughly twenty dollars per user per month on Copilot, and that heavier users were costing the company as much as eighty dollars a month each. The maths never worked. Running large language models across millions of developers is extraordinarily expensive, and a ten dollar flat fee was only ever a customer acquisition play. The point of the exercise was to get an entire profession hooked before anyone had to think hard about the bill.

Once you understand that the unit economics were upside down from day one, the move to usage based pricing stops looking like a betrayal and starts looking like the inevitable correction. The free ride was always going to end. The only real question was when, and whether you had built your workflow to survive it.

Why I started mapping my projects eight months ago

I run a large production platform. Not a weekend script and not a tidy little repository, but a real monorepo with many moving parts, multiple workers, a stack of databases, and the kind of architecture where a single change can ripple into corners you had forgotten existed. When AI coding agents became genuinely useful, I started leaning on them heavily, and I noticed something straight away.

The biggest hidden cost of working with an AI agent on a large codebase is not the cleverness of the model. It is context. Every time an agent has to work out how your project fits together, it reads files, it searches, it reads more files, and it burns tokens doing it. Feeding raw source code into a model is like handing a new contractor the entire filing cabinet and asking them to find the one invoice that matters. They will get there eventually, but they will waste an enormous amount of effort along the way, and the answer they hand back is often shallow, because they never really saw the relationships, only the fragments.

So about eight months ago I started doing something that, at the time, looked a little like over engineering. I began building visual maps of my projects. Structured representations of every file, function and module, and, crucially, the connections between them. Not for the AI to begin with, but for my own clarity. I wanted to see my architecture as a system rather than a list of folders.

What I did not fully appreciate then is that I was solving tomorrow's problem. The map I built for clarity turned out to be the single most effective way to control cost.

What GraphRAG actually does

The technique underneath all of this has a name. It is called GraphRAG, short for Graph Retrieval Augmented Generation, and it came out of Microsoft Research.

Ordinary retrieval augmented generation works by chopping your documents into chunks, turning each chunk into a vector, and retrieving the chunks that look most similar to your question. It is fine for simple lookups, but it has a blind spot. It treats your information as a loose pile of fragments and has no real grasp of how those fragments relate to one another. Ask it a broad, join the dots question and it struggles, because the answer is not sitting inside any single chunk.

GraphRAG fixes this by building a knowledge graph first. It uses a language model to read the source material, pull out the entities, and map the relationships between them. Entities become nodes, relationships become edges. It then clusters those nodes into communities of closely related ideas and writes a short summary of each community. The result is a structured layer that understands not just what your data says, but how every piece connects to every other piece.

That structure unlocks two kinds of search. Local search answers precise questions about a particular entity. Global search answers the broad, thematic questions that ordinary retrieval falls over on, the “catch me up on everything” style of query, because those community summaries give the model a holistic view of the whole dataset. And because every answer can be traced back to its origin in the graph, you get provenance. You can see why the model said what it said, which on a real project matters a great deal.

For a codebase, this is the difference between an assistant that can quote a file back to you and one that genuinely understands the system you have built.

What Graphify does for a real codebase

GraphRAG is the idea. Graphify is the tool that brings it to a codebase without a research budget.

Graphify is an open source tool that takes everything inside a project folder, the code, the documentation, the SQL schemas, the scripts, even diagrams and PDFs, and turns the whole lot into a queryable knowledge graph. The first pass parses your code locally using tree sitter, across dozens of programming languages, with no API calls and nothing leaving your machine. It then clusters the result and writes out three files: a machine readable graph your agent can query, a written report, and an interactive visual map you can open in a browser and click through.

A few things about it stand out to me as someone who maintains a large system. It tags every relationship by confidence, so you can tell which connections were extracted directly from the code and which were inferred by the model. It identifies what it calls god nodes, the most heavily connected components in your project, so before you touch one you can see the blast radius of a change. And it persists between sessions, so your agent is not starting from a blank slate every single time you sit down.

The headline benefit, though, is cost. By mapping the project up front and letting the agent consult the relevant corner of the map rather than rereading the entire codebase for every question, the saving on large projects is reported to be in the order of seventy times fewer tokens per query. There is a pleasing detail here too. The approach is built very much in the spirit of Andrej Karpathy's thinking on keeping AI work simple and grounded, which happens to be the same philosophy I apply to everything we build.

Why it is only now a game changer

Here is the part that matters. For most of the last eighteen months, mapping your code for an AI agent was a quality decision. It made the answers better and the work calmer, but if you skipped it, the platform quietly absorbed the waste on your behalf. Efficiency was a nicety.

That has now changed. The moment the meter started running on 1 June, context efficiency stopped being a nicety and became the line item that decides whether your monthly bill reads thirty dollars or seven hundred. The thing I had been doing for clarity turned out to be the thing that governs the budget. Same technique, completely different stakes.

There is a second reason the timing is right. The agents themselves have finally caught up. Eighteen months ago a model could not reliably make use of a structured map even if you handed it one. Today's coding agents can query a knowledge graph, follow the edges, and reason across a whole system in a way that simply was not possible back when Copilot was finishing your loops. The map, and the tools that can read it, have arrived at the same moment the economics started demanding them.

What this means if you are building with AI

The lesson I take from all of this is straightforward. The teams that treated context as architecture, rather than as something the platform would silently pay for, are the ones who will not be opening a frightening invoice this month. Mapping your project is no longer an optimisation you get to ignore. On a serious codebase it is the foundation that makes working with AI agents both sane and affordable.

That is the work we do at Digital Discovery Group. We help businesses build on AI in a way that still holds up when the bill arrives, because we have been building it that way ourselves for longer than the rest of the market has had to care.

If you are staring down a Copilot invoice that no longer makes any sense, the answer is not to abandon the agents. It is to give them a map.

Nigel Price is the founder of Digital Discovery Group, specialising in ecommerce strategy, digital transformation, AI-powered platforms, and managed cybersecurity services for small and medium businesses.