This is the first post in a series about my journey building DevIndext and exploring how coding agents can benefit from better context.
- Part 1: Why Coding Agents Need Better Context
- Part 2: The Index Before the MCP Server
- From a Working Project to a Release - WIP
I have found AI coding tools genuinely useful. I use them to get oriented in unfamiliar code, talk through design choices, explain an error that has me stuck, and get a first pass at tests or documentation. The part that interests me is not that they can type code quickly. It is that, with the right information, they can help me work through a problem.
That qualifier—with the right information—has become the hard part.
At work, I am often dealing with large, interconnected repositories. My usual approach has been to open Visual Studio Code, start with one project folder, and add the source I think matters. It works, but it is a very manual way to manage context. Sometimes I have had to keep redirecting the conversation just to assemble the pieces an agent needed in the first place.
Eventually, that made something click for me: an agent cannot be especially helpful if it has to rediscover the shape of the system every time you ask a question.
A real repository is more than source files. It has documentation, dependencies, history, specifications, and years of decisions tucked away in all of them. An agent can search through that material, of course, but broad searches are noisy and slow. More importantly, they spend the resource an agent always has to manage: context. Handing it a large pile of files is not the same as helping it understand the system.
That is why I started building DevIndext.
DevIndext is a local-first developer knowledge index for coding agents. It stores useful repository information in a local SQLite database and can answer questions about symbols, references, callers, implementations, text, relationships, and Git history. The index is the actual product. MCP is simply the adapter that lets a compatible coding agent use it.
The Problem I Wanted to Solve
When I ask an agent to change a feature, I do not want its first move to be a blind crawl through the repository. I want it to establish what it knows about the workspace, find the relevant symbol or document, and retrieve the relationships that are likely to answer the question.
That sounds straightforward, but it led to a few decisions that mattered to me.
- The information should stay local. I should not have to copy source code into a hosted search service just to make it useful to an agent.
- The index should be derived data. The repository remains the source of truth, and the index can always be rebuilt.
- It should be useful without AI. Before putting an MCP server in front of it, I wanted a command-line query layer that could stand on its own.
- Results need to be bounded and predictable. An agent needs relevant context, not every match in the repository poured into a response.
I also did not want to create another service to install, secure, host, and remember to maintain. The MCP server uses stdio only. An agent starts it for an active connection and it stops when that connection ends. There is no daemon, dashboard, or network listener waiting in the background.
The basic shape is small on purpose:
Coding agent
|
| stdio MCP
v
DevIndext query and context services
|
v
repository-local .devindext/index.db
Local Does Not Mean Limited
Keeping things local does not mean pretending every folder is an island. A developer might be working across an API, a web application, a shared library, and a few supporting tools. I added a lightweight workspace catalog so DevIndext can group those repositories while each one keeps its own self-contained .devindext index.
I like that separation. The workspace catalog can answer, “What repositories belong to this work?” without becoming a central copy of all their data. Each repository can still be indexed, queried, moved, or rebuilt on its own.
Git context belongs in the same picture. Finding where a method is defined is useful. Knowing what recent commits touched that file—and whether they reference a work item—can make the answer much more useful. DevIndext indexes that locally too.
A Better Starting Point for Exploration
The workflow is intentionally simple. Initialize a repository, index it, and then ask focused questions:
devindext init
devindext index
devindext git index
devindext find symbol CustomerService
devindext callers CustomerService.CreateCustomer
devindext context CustomerService.CreateCustomer
The last command is the part I care about most. It is more than a search result. It can assemble a bounded view of a target: its definition, direct relationships, callers, related symbols, and indexed history. That means fewer separate discovery steps before an agent—or a developer—can begin doing useful work.
It does not replace engineering judgment. It just helps get the right facts in front of that judgment sooner.
What I Am Building Toward
I am not claiming that an index gives an AI perfect understanding of a system. It does not. I am trying to make the first part of the work more deliberate: establish the relevant facts, follow the important relationships, and preserve source locations and provenance so the result can be checked.
The first release focuses on C#, local repositories, structured retrieval, Git context, a CLI, and an MCP server. There is room for more language plugins and integrations later, but I have deliberately kept the early product tied to a workflow I can use and verify now.
Conclusion
DevIndext is my attempt to make the first stage of software exploration more deliberate. It gives a developer or coding agent a local, inspectable starting point so that the work can begin with relevant facts instead of a long chain of guesses and searches.
In the next post, I will walk through the phases that took DevIndext from an idea to a working CLI and MCP application.
As always, keep learning and keep building.