So there I was. A GSoC project I actually wanted to work on.
Cloned the repo. Opened VS Code.
Hundreds of files. Thousands of functions. Zero context.
I tried grepping. I tried scrolling. I opened random files hoping something would click.
Nothing clicked.
The problem wasn't skill. It was orientation.
I knew how to write code. I didn't know this code.
There's no onboarding doc that tells you: "function A calls function B which depends on module C." You're supposed to figure that out. Manually. By reading everything.
That's not how I work. That's probably not how you work either.
So instead of contributing to that project, I started building something else.
What if the codebase could explain itself?
Not an AI that hallucinates what your code does. Something that actually reads it. Parses it. Maps every function, every call, every dependency statically.
No guessing. No LLM making things up. Just: here's what exists, here's what calls what.
That became N3MO.
What it actually does
You point it at a repo. It indexes everything.
Django's 3,021 files indexed in ~2.5 minutes. 43,000+ symbols. 181,000+ call edges.
Every function knows what calls it. Every module knows what it imports. You can ask "where is this used?" and get an actual answer, not a guess.
It ships as a PyPI package, a GitHub App, an MCP server that works inside Cursor and Claude Desktop, and a REST API. All from the same engine.
The GSoC project I never contributed to
I never sent that PR.
But the problem it gave me turned into something I'm still building a year later.
Sometimes the codebase you can't understand is more valuable than the one you can.
Try it: pip install n3mo or n3mo.shop
Top comments (6)
Repo orientation is a real developer experience problem. A map does something grep cannot: it gives a newcomer a mental model before they start changing code. I would love to see more projects ship an architecture map next to the README, especially for agent-assisted work where context windows can wander fast.
exactly a mental model before you touch the code is the whole problem. grep finds text, it doesn't tell you relationships.
that's actually what N3MO does builds that map statically. call edges, symbol graph, dependency chains. so when an agent or a new contributor asks "what calls this function" there's an actual answer, not a search.
the agent-assisted work point is especially relevant, context windows filling up with the wrong code is a real problem when there's no structure to guide retrieval.
That static relationship graph is the missing bit for both humans and agents. The key is keeping it close enough to code that it does not become a stale architecture diagram. If the map can answer who calls this and what breaks if it moves, it becomes part of the dev loop.
that's exactly the design constraint. reindex on every push via webhook the graph tracks HEAD, not some snapshot you ran last quarter. the blast radius comment on PRs is the dev loop integration. before merge, not after.
Reindexing at HEAD is the key. A stale graph is worse than no graph because it gives the agent confidence with old facts. The PR comment angle is strong too: if the graph can show affected modules, owners, and likely blast radius before merge, it becomes part of the review loop instead of an after-the-fact map.
exactly pre-merge, not post-mortem. the graph shows call chains, not just file diffs. reviewers see what actually moves when you touch a function.
Have you tried N3MO yet?