While working on Driftya, I noticed something strange about using AI coding tools.

They were helpful, but they kept having to rediscover the same project structure again and again.

A feature in Driftya is rarely only one file. It can touch the domain model, application services, repositories, API endpoints, Razor pages, React components, localization files, background workers, and tests. When an AI assistant only sees the currently open files, it can miss the wider shape of the system.

That is not really the assistant’s fault. Large projects are not just files. They are relationships.

A service calls another service. A controller depends on a use case. A repository implements an application port. A test protects a specific behavior. A markdown document explains a rule that may or may not still match the code.

I wanted a way to make those relationships visible. That became CodeMeridian.

I have not used CodeMeridian enough yet to call it a finished answer. It is still early. But it grew from a real itch: I wanted AI tools to stop walking into the project blind every time.

This post is a look at why I built CodeMeridian, how I want to use it with Driftya, and why I think large codebases need more than search when AI assistants are involved.

The problem I was trying to solve

Driftya has grown into more than a small experiment.

It has note creation, arrivals, replies, reports, soft deletion, blocking, localization, invite links, routing rules, unread states, and shared spaces like Between Us. Many of those features are intentionally constrained because Driftya is not meant to become a noisy feed.

That means the code has rules that matter.

For example, if I change how replies work, I also need to understand how that affects:

• arrival routing

• report and hide behavior

• soft-delete rules

• unread reply state

• creator-owned note views

• localization text

• tests around chain continuity

A normal text search can find words. But it does not always explain the path between things.

I wanted something that could answer questions like:

• What calls this method?

• What will be affected if I change this service?

• Which tests are close to this behavior?

• Which files are likely part of this feature?

• Can I trust the indexed graph, or is it stale?

• Are there old docs or notes that point to code that no longer exists?

That is the kind of context I want before asking an AI assistant to make changes.

What CodeMeridian does

CodeMeridian indexes a codebase into a local Neo4j graph and exposes that graph through MCP.

The AI assistant is still the assistant. CodeMeridian is the map. It does not replace Copilot, Codex, Claude Code, or other coding tools. Instead, it gives them a structured way to ask about the project before editing.

For Driftya, that means I can index the codebase and let the assistant ask more precise questions.

Instead of only guessing from open files, it can query the graph for callers, dependencies, documentation, diagnostics, tests, and possible implementation surfaces. That makes the assistant less blind. Not perfect. Just less blind.

Why I use a graph

Code has a natural graph shape. Files contain classes.
Classes contain methods.
Methods call other methods.
Interfaces have implementations.
Tests call production code.
Documentation mentions concepts.
Features cross boundaries.

A graph database fits that shape well. This is especially useful when a change is not isolated. If I am working on a feature in Driftya, I often want to know the route through the system, not only the file names.

A graph lets CodeMeridian ask relationship-based questions:

• how a controller reaches a repository

• which services sit between a feature and persistence

• which classes are central or risky to change

• where architecture boundaries might be crossed

• how far a change might spread

That kind of context is hard to get from plain search alone.

The part I care about most: trust

One of the risks with any indexing tool is stale context. A graph can be useful, but a stale graph can be dangerous. If an AI assistant trusts old information, it may confidently edit the wrong thing.

So one of the important ideas in CodeMeridian is that graph results should carry trust signals.

A result can be exact. Or only file-level. Or heuristic. Or stale.

CodeMeridian can also check whether the graph appears to have drifted from the working tree.

That matters to me because I do not want the assistant to treat old knowledge as truth.

I want it to say: “This looks reliable.”
Or: “Re-index first.”

That small difference can prevent a lot of bad edits.

How this helps me in practice

A typical workflow looks like this:

1. I index the project.
2. I ask the AI assistant to use CodeMeridian before editing.
3. The assistant checks the likely implementation surface.
4. It resolves exact symbols where possible.
5. It checks freshness and drift.
6. It builds a minimal context pack.
7. Then it starts making changes.

The useful part is not that this removes all manual review. It does not. I still care about architecture, naming, tests, logging, async behavior, and whether the change actually fits Driftya.

But CodeMeridian helps the assistant begin with a better map. That can reduce random file exploration and make the first suggestion more grounded.

A small example

If I want to change something around note reports, I do not only want to search for the word “report”. I want to know what the report flow touches.

There may be application services, domain rules, repository queries, API endpoints, UI state, localization strings, and tests. There may also be markdown documents that describe how reporting should work. CodeMeridian can connect those pieces better than a flat search.

It can help answer:

• where the report behavior is implemented

• which code paths use it

• what nearby tests exist

• what related documentation says

• whether the graph is fresh enough to trust

That gives me a better starting point before editing.

It is not magic

CodeMeridian is not a magic coding machine. It does not understand every business rule by itself. It does not replace tests. It does not replace code review. It does not remove the need to think.

It is closer to a local memory layer for the project. A way to keep structure available across sessions. A way to help AI tools ask better questions before they touch the code. That is enough to make it useful.

Why I built it locally

I wanted CodeMeridian to be local-first. The graph runs in my own Neo4j instance. The indexer reads my project. The MCP server exposes the graph to tools that support MCP.

That fits how I want to work. I do not want every piece of project structure to depend on a hosted service just to become useful. I want the code knowledge to stay close to the codebase. For a project like Driftya, where the design values are careful and intentionally constrained, that local ownership feels right.

What I want to improve next

The next step is not only adding more graph features. The important part is making the workflow easier. I want CodeMeridian to feel simple to start:

dotnet tool install --global CodeMeridian.Indexer
codemeridian init  #client
codemeridian serve --no-start  #server 
codemeridian index .

Then the assistant should be able to ask the graph useful questions immediately. I also want better product-level commands, like:

codemeridian doctor

To show whether Neo4j, the MCP server, the indexer, and the project graph are healthy. A powerful tool is not enough. It has to be easy to trust.

Final thought

Working on Driftya taught me that AI coding tools are most useful when they understand the shape of the project.

Not just the open file. Not just a few search results. The shape.

CodeMeridian is my attempt to give AI assistants that shape in a local, inspectable way. It is not the AI. It is the map I hand to the AI before it starts walking through the code.