DEV Community: N3MO

I cloned the repo. I was lost. So I built the map.

N3MO — Sat, 27 Jun 2026 01:30:00 +0000

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

Python was my first language. I forgot about it for years. Then I built a code intelligence engine with it.

N3MO — Sun, 21 Jun 2026 13:14:25 +0000

Python was the first language I ever wrote code in.

I was a beginner. Ran some scripts. Never built anything meaningful. Then college started and I moved to Java and C++ — Python was forgotten.

Years later, everyone's talking about ML and AI. Python is the language of the moment. I'm not into ML, but I picked it back up.

The moment that started everything

I was trying to get into GSoC. Found a project I liked, cloned the repo, opened the codebase.

Hundreds of files. Thousands of functions. Zero context.

I didn't know what called what, what was connected to what, what I could safely touch. I closed the tab.

That feeling — of being lost in someone else's code — became the problem I couldn't let go.

What I built

N3MO is a local-first code intelligence engine. It parses your codebase, builds a call graph with symbols and relationships, stores everything in Postgres, and lets you query it.

Written entirely in Python. Built with tree-sitter for parsing, psycopg2 for Postgres, networkx for the graph layer.

Numbers that matter

Indexes Django: 3,021 files, 43k+ symbols, 181k+ call edges
Cold index time: dropped from ~23 minutes to ~2.5 minutes after a SQL optimization (SPLIT_PART rewrite)
Available as a PyPI package, MCP server (Cursor/Claude Desktop), GitHub App with webhook reindexing

pip install n3mo

What I learned

Python was the right choice. Not because of ML. Because the ecosystem — tree-sitter bindings, Postgres drivers, graph libraries — was all there.

Every problem I hit, there was a library for it. Every optimization I needed, Python didn't get in the way.

The language that gave me my first print("hello world") ended up being the one I shipped something real with.

Repo + docs: github.com/RajX-dev/N3MO

Tags: python opensource programming beginners showdev

I indexed the entire Django codebase and traced 317 blast-radius references. Here's what I learned building the tool.

N3MO — Thu, 18 Jun 2026 01:43:52 +0000

A few months ago I was mid-refactor on a Python codebase and grep -r gave me 12 results. I changed the function, ran the tests, and broke 4 things grep hadn't caught. Classic.

That afternoon I started building N3MO.

What N3MO does

N3MO answers one question: "what breaks if I change this?"

It parses your repository's ASTs using Tree-sitter, stores every symbol and call edge in PostgreSQL, then walks the call graph using recursive CTEs to return the full transitive blast radius of any function, method, or class.

pip install n3mo
n3mo index
n3mo impact "authenticate_user" --graph

Output:

◈ IMPACT ANALYSIS
──────────────────────────────────────────────────
Target: authenticate_user

◉ Direct Callers (3 symbols)
 ▸ login_endpoint       api/auth.py:12
 ▸ refresh_token        api/token.py:23
 ▸ validate_session     middleware/auth.py:89

◎ Ripple Effects (5 symbols)
 ╰─▸ POST /login        routes.py:67
 ╰─▸ admin_login        admin/views.py:34
 ╰─▸ require_auth       decorators.py:12

──────────────────────────────────────────────────
Total impacted: 8 references │ depth ≤ 3

Why Postgres as the graph store

The obvious question: why not Neo4j or a dedicated graph DB?

A few reasons:

It's already in most stacks. Asking a team to spin up a new DB just for code intelligence is friction. Asking them to run n3mo setup (which starts a Docker container) is much less.
Recursive CTEs are powerful enough. PostgreSQL's WITH RECURSIVE handles arbitrary-depth graph traversal cleanly. For the query volumes involved (this is a dev tool, not a production API), it's fast enough.
The data is relational. Symbols have names, files, line numbers, types. Calls have callers and callees. This is a table, not a document or a property graph. The schema is roughly:

CREATE TABLE symbols (
  id SERIAL PRIMARY KEY,
  name TEXT,
  file TEXT,
  line INT,
  type TEXT  -- function, class, method
);

CREATE TABLE calls (
  caller_id INT REFERENCES symbols(id),
  callee_id INT REFERENCES symbols(id)
);

The blast radius query uses a recursive CTE to walk calls from a given symbol outward to arbitrary depth.

The Django benchmark

I needed a real-world test case — not a toy repo. Django is public, large, and well-structured. Here's what indexing it looked like:

Metric	Value
Files	3,021
Symbols	~43,000
Call edges	~181,000
Cold index time	~11 minutes
Impact query on `dispatch`	317 references, <2s

The biggest optimization came from fixing the call name matching query. Initial version used:

WHERE call_name LIKE '%' || s.name

This was doing a full table scan on every symbol lookup. Replaced with:

WHERE SPLIT_PART(call_name, '.', -1) = s.name

Cut indexing time from ~23 minutes to ~11 minutes on Django.

Other things N3MO does

Beyond the CLI, there are a few integrations I built:

GitHub App webhook — installs on a repo, runs on every PR, posts a markdown blast radius report as a PR comment. Useful for catching unintended impact before merge.

MCP server — N3MO exposes a Model Context Protocol server so AI coding tools (Cursor, Claude Desktop, Windsurf) can query the codebase structure before suggesting refactors. The idea is that if an agent knows dispatch has 317 downstream callers, it won't casually rename it.

Interactive graph UI — --graph flag launches a vis.js visualizer in your browser with a depth slider and node highlighting. Click a node to deep-link into your local IDE.

What's next

The tool is technically complete. The current focus is on getting real teams using it and finding the rough edges.

If you work on a large Python codebase and want to try it:

pip install n3mo
n3mo setup   # starts Postgres in Docker
n3mo index   # parse and store
n3mo impact "your_function" --graph

GitHub App and full source: github.com/RajX-dev/N3MO

AGPL-3.0. Free for open source and projects under 15k LOC.

How I cut Django indexing from 23 minutes to 11 minutes with one SQL change

N3MO — Wed, 10 Jun 2026 11:56:37 +0000

The problem

I'm building N3MO — an open source code intelligence
engine that maps Python codebases into a knowledge
graph stored in PostgreSQL.

When I tested it on Django (3,021 Python files,
181,000+ function calls), the full index took
23 minutes. Extraction was 8 minutes. Linking
was 15 minutes.

Linking was the bottleneck.

Why linking was slow

N3MO's linking phase resolves which function calls
which. The original query used LIKE:

WHERE c.call_name LIKE '%%.' || s.name

This matches calls like module.function or
self.function by checking if the call name
ends with the function name.

The problem: a leading wildcard LIKE query
cannot use indexes. PostgreSQL has to compare
every call against every symbol.

For Django: 181,000 calls × 43,000 symbols =
7.8 billion comparisons. That's why it took
15 minutes.

The fix

Replace LIKE with SPLIT_PART:

WHERE SPLIT_PART(c.call_name, '.', -1) = s.name

SPLIT_PART splits the call name at '.' and takes
the last part. module.function becomes function.
Then it's an exact match — which CAN use indexes.

The result

Before: 23 minutes
After: 11 minutes
Speedup: 2x faster from one line change

What I learned

When you have a performance problem in SQL:

Leading wildcard LIKE = no index possible
SPLIT_PART + exact match = index friendly
Always check if your WHERE clause can use indexes

N3MO is open source: github.com/RajX-dev/N3MO