Navigation is the real cost of AI coding agents

Twenty minutes into a token-burning grep across 20,000 files, my AI agent still hadn’t found where retry handling lives.

I work on the Fintech platform at Mews, where our core product is a C# monolith that size, and if you have ever used AI coding agents inside something that big you know the wall I hit. The tools are genuinely impressive once they know where to look. The problem is getting them there.

On a small project they feel almost magical. On a big one, they start behaving like someone who just joined the team on day one, doing repo-wide searches, reading the wrong files, and burning through tokens before they arrive at anything useful.
So I built a tool to fix that. It is called Context King.

The problem nobody really talks about

Most of the conversation around AI coding tools and token usage is about compacting what the agent reads. Tighter prompts, summarised context, leaner encoding. All of that is useful, but it sidesteps the bigger question for anyone working in a large codebase.

The cost is not just in what the agent reads once it gets to the right place. The cost is in the navigation itself. In how many wrong files it touches on the way there.
Think of it like walking into a huge library to find one specific paragraph. If you know the section, the shelf, and the book, you are in and out in a minute. If you do not, you end up pulling down thirty books, flipping pages, putting them back, and slowly closing in on the one you actually need. Every book you open is a cost, even if you only read the cover.

That is exactly what an unguided repo-wide grep looks like on a 20,000-file codebase. By the time the agent finds the right method, the context window is full of noise and the real question has been pushed out the back.

The idea

I wanted the agent to walk through the codebase the way a human does when they actually know it. Not “search everywhere for the word reservation”. More like “okay, reservations probably live under Inventory somewhere, let me look there first, then drill down.”
That is really a four-step movement:

1. Figure out where the thing probably lives. Narrow down to a set of folders, semantically ranked, not just plain match.
2. Look at what is in those folders without opening the files. Just the shape of it, via signature extractions using AST (Abstract Syntax Tree, a hierarchical node structure representing the code, extracted by SDK or parsers).
3. Pick the one method that actually matters and read only that.
4. Edit.

Context King installs four small commands, an embedding model, and a CLI into your AI CLI, one for each step. The embedding model is bundled and runs locally, and the index is a local file on disk, so nothing about your code ever leaves the machine.

The agent never has to open a file blindly, and it never has to scan the whole repo.

What the four steps actually look like

Take the retry-handling question from the opening. Here is what the agent sees at each step when it runs against MassTransit, an open-source C# codebase of about 5,500 files.

Step 1, find the scope. The agent runs ck find-scope –query “retry failed message policy backoff incremental” and gets back a ranked list of folders:

0.85 src/MassTransit/RetryPolicies 0.75 src/MassTransit/Configuration/Configuration/Retry 0.71 src/MassTransit/SagaStateMachine/Configuration 0.69 src/MassTransit/Configuration/Configuration/Redelivery 0.68 src/MassTransit/RetryPolicies/ExceptionFilters ...

No files opened yet. The top two hits are obviously the right places to look.

Step 2, inspect the shape. The agent runs ck signatures on those folders and gets a flat list of every method and property signature underneath, with file paths and line numbers, but no method bodies. It can see:

IncrementalRetryPolicy, ExponentialRetryPolicy, IntervalRetryPolicy, GetRetryInterval,
 CalculateIntervals, CanRetry, and so on.

Still no file reads by the Agent, method signatures extracted by AST.

Step 3, read the one method that matters. Now the agent picks specific methods and pulls just those, one at a time: 

ck-get-method-source ExponentialRetryPolicy.cs GetRetryInterval.

It returns the body of that single method with its exact line range. No file is ever opened whole.

Step 4, answer or edit. With the relevant method bodies in context, the agent answers the original question or makes the edit. For the retry question, that was enough to describe all four policy types, the exception filters, and how redelivery differs, without having read a single full file.

The whole trace is three targeted shell commands and a handful of method lookups. The agent never loaded a full file, never ran a repo-wide grep, and never pulled anything from a test project or a generated file.

Why folder-level indexing
Most existing tools use file-level indexing,  On a 20,000-file C# repo the initial index took several minutes to build, and incremental updates fell apart the moment I switched branches or worked across git worktrees. Keeping deltas in sync was both messy and expensive.

Folder-level indexing has an order of magnitude fewer units to track, builds in seconds, and barely notices a branch switch.