DEV Community: N3MO

Automatically Answering "What Does This PR Break?" Building Blast Radius Analysis Into GitHub Reviews

N3MO — Tue, 21 Jul 2026 09:42:59 +0000

(this is an open core project so please visit to the github repositry to contribute any contribution would be helpful)

Automatically Answering "What Does This PR Break?" Building Blast Radius Analysis Into GitHub Reviews

Every large codebase has the same recurring question in code review: what else does this change touch?

Text search misses indirect dependencies. Unit tests only catch what they were written to catch. And in a codebase with thousands of files, nobody can hold the full dependency graph in their head.

I built N3MO to answer this automatically, and recently shipped the feature I think matters most: it now posts the answer directly as a PR comment.

How it works

When a PR opens, N3MO:

Parses the diff to find every symbol added, deleted, or modified
Traces each symbol through a call graph built from the repo's AST
Posts a structured report as a PR comment direct callers, total downstream impact, per-symbol status

No dashboard to check. No separate tool to open. It shows up exactly where review already happens.

Why AST parsing instead of grep

Text search finds textual matches. It can't tell you that a renamed function is called indirectly through three layers of abstraction, or that a modified return type breaks a caller two files away that never appears in a simple search.

N3MO builds a real structural map: parse each file into an AST (Tree-sitter, 27 languages), extract symbol definitions and call sites, and store the graph in Postgres using recursive CTEs to trace transitive dependencies. That's what lets it answer "what breaks if I change this?" with certainty instead of a guess.

Performance at scale

Indexing needs to work on real codebases, not toy examples. Current benchmarks:

TensorFlow (14.6k files, 480k+ edges): ~14 minutes cold-start
Re-indexing after a PR is incremental only changed files get re-parsed, so it stays fast on subsequent runs

Security model

Since this runs on private repos, code never leaves the user's environment. Indexing happens in place, and nothing is sent to an external server for analysis.

Where it's at

N3MO has been in daily active use by ~8k developers via the local CLI/MCP integration (Cursor, Claude Desktop). The SaaS/PR-comment feature is newer and is what I'm actively building toward — turning individual CLI usage into a tool teams adopt for code review.

Try it on your repo

Log in, connect your repository, and a 15-day free trial activates automatically. Follow the setup steps and N3MO runs on every PR from that point on — indexing in place, re-indexing only what changed, nothing leaving your repo.

If you work in a codebase where "what depends on this?" comes up often in review, I'd genuinely like feedback:[n3mo.shop]

I made my portfolio website today , please give feedbacks

N3MO — Sat, 18 Jul 2026 13:20:20 +0000

I have been busy working on my project (https://github.com/RajX-dev/N3MO), Which you can also check, but yeah whenever I got free time I worked on making my portfolio site right now unable to buy the domain I want but yeah it's this - https://rajx-dev.vercel.app/

today ran my own tool over the whole django repo it indexed it in 2.5 minutes and generated a whole graph for each function i searched, its always awesome to look at something you build on your own works. T-T

N3MO — Wed, 15 Jul 2026 15:49:35 +0000

AI agents are hallucinating on your monorepo. Here is why I used PostgreSQL to fix it.

N3MO — Tue, 14 Jul 2026 04:52:04 +0000

We need to talk about the elephant in the room: AI coding agents are failing on massive codebases.

Whether you are using Cursor, Claude, or Windsurf, if you point an LLM at a 30,000-file enterprise monorepo and ask, "What breaks if I rename this utility function?", the AI will likely hallucinate. Why? Because LLMs rely on flat-file text search (grep) or semantic vector embeddings, neither of which actually understand the structural call graph of your code.

To fix this, developers have started building local AST (Abstract Syntax Tree) parsers. But I noticed a fatal flaw in the popular ones: they were dumping the entire AST graph into static JSON files.

If you try to load a 500,000-edge JSON graph into memory to traverse a dependency tree, your machine is going to choke.

I knew there had to be a better way to scale this, so I built N3MO.

The N3MO Approach: PostgreSQL + Recursive CTEs

Instead of relying on fragile JSON files, I decided to treat source code like enterprise data. N3MO uses Tree-sitter to parse 27 different programming languages into ASTs, but instead of keeping them in memory, it batch-inserts the symbols and function calls directly into PostgreSQL.

Why Postgres? Because of Recursive CTEs (WITH RECURSIVE).

Instead of writing a slow Breadth-First Search algorithm in Python to figure out the "blast radius" of a function change, N3MO pushes the traversal directly down to the C-optimized database engine.

-- A simplified version of how N3MO calculates blast radius in milliseconds
WITH RECURSIVE impact_chain AS (
    SELECT id, source_symbol_id, 1 as depth, ARRAY[source_symbol_id] as path
    FROM calls WHERE resolved_symbol_id = %s

    UNION ALL

    SELECT c.id, c.source_symbol_id, ic.depth + 1, ic.path || c.source_symbol_id
    FROM calls c
    JOIN impact_chain ic ON c.resolved_symbol_id = ic.source_symbol_id
    WHERE ic.depth < 4 AND NOT (c.source_symbol_id = ANY(ic.path))
)

By leveraging Postgres cycle guards (c.source_symbol_id = ANY(ic.path)) to prevent infinite recursive loops, N3MO can trace the blast radius of a function across tens of thousands of files in under 50 milliseconds.

Connecting it back to AI (MCP)
Once the code graph was living in Postgres, I built an MCP (Model Context Protocol) server. Now, when Claude or Cursor looks at my code, it doesn't just read text—it queries the PostgreSQL database to understand the exact, deterministic call graph before it refactors anything.

Join the Community
N3MO is completely open-source. We are actively looking for contributors to help us add more Tree-sitter languages, optimize our database migrations (Alembic), and build out the AI layer.

⭐ Check out the code: https://github.com/RajX-dev/N3MO
💬 Talk Architecture: https://discord.gg/cTgZKHf2G
If you are tired of your LLM agents hallucinating, drop the JSON files and come use a real database.

I am tired because of today's condition of project market

N3MO — Thu, 09 Jul 2026 12:01:52 +0000

I have been posting everywhere Hacker news, reddit , devto every possible platform.
I am Raj shekhar, a fourth year college student , I have been working on a project for the last 7 months, like i had a huge problem that i tried solving and while solving the problem i realized that this can be turn into a huge Dev tool that everyone can use , so i made it work like everyday almost while having the semester exams in between (for context i am a electrical engineering student and I dont even like electrical, I am a tech lover) so I have to focus on the exams also, while i was building it, I never though it will be become this complex and its pretty helpful also it become a huge thing.

Now when it come to post the project on the internet every kid in his home making some cheap vibe coded app/website, the market is filled with garbage projects written by ai, I am not saying that i havent used any AI but I have used it to debug the code and cleaning the repo and for readme. But my point is these people are making some cheap things with just prompting producing same slop and posting everywhere , whereas people like me who worked hard in solving complex problem getting sideline because of these slop posts and slop projects.

ill be just attaching the github profile not the project because I am so done , if you like give a visit and understand the project give me legit feedback I want to know if its good or bad , my placements are like 1 month away I cant promote the SaaS anymore if this post will get sideline again ill just stop writing.

Github profile- https://github.com/RajX-dev

Ai agents kept get in the loop of hallucination, so i resolved it

N3MO — Fri, 03 Jul 2026 13:42:41 +0000

I love using AI coding agents. But recently, I noticed a frustrating pattern when asking them to execute complex, multi-file refactors.

I would ask an agent to modify a core utility function—let's call it validate_session(). The agent would enthusiastically rewrite the function, and then confidently hallucinate dependencies. It would tell me it updated files that didn't exist, or completely miss the downstream API endpoints that relied on the old function signature.

The problem wasn't the LLM's intelligence. The problem was how it was retrieving context.

When an AI agent (or even a human developer) searches a codebase, we rely on vector embeddings or basic substring matching (grep). But code isn't just a collection of text documents. It's a highly structured, relational graph.

When you modify validate_session(), you don't care where the string "validate_session" appears in a random markdown file. You care about:

What function calls it?
What functions call that function?
What is the ultimate downstream impact?

I needed something that didn't guess.

Building the Map

I realized that if I wanted to truly understand the transitive blast radius of a change, I needed to parse the actual structure of the code, not just text.

So I built N3MO.

Instead of relying on embeddings, N3MO uses Tree-sitter (the exact same parsing engine GitHub uses) to parse source code into Abstract Syntax Trees (ASTs) locally.

It takes those ASTs and maps every function, class, and method into a queryable relational database. There are zero LLM calls during the indexing phase—it is pure, deterministic static analysis.

Scaling it Up

Initially, I tested it on small projects. But I wanted to see if a relational graph could handle enterprise scale without falling over.

So, I threw the TensorFlow codebase at it.

Files: 14,611
Symbols extracted: 79,523
Relational edges mapped: 480,851

N3MO parsed and indexed the entire repository into a queryable local graph in just 14.06 minutes.

Built for Engineers, Not Just Bots

I didn't just build this for AI. I built it to act as a structural insurance policy for human engineering teams.

Now, instead of running a slow grep and getting hundreds of noisy text matches, you can use N3MO to completely map your repository:

The CLI: Run n3mo impact "validate_session" in your terminal to instantly see the full blast radius before you touch the code.
CI/CD PR Bots: Hook N3MO into GitHub Actions. On every Pull Request, N3MO automatically calculates the blast radius of the modified files and drops a markdown report directly into the PR comments. You know exactly what will break before you merge.
Interactive Visualizer: Boot up the local dashboard and visually explore the orbiting call graph to untangle massive legacy repos.

Giving the Map Back to the AI

Of course, once I had a deterministic graph, I couldn't resist giving it to the AI agents that inspired it in the first place.

I wrapped the N3MO engine in a native Model Context Protocol (MCP) server. Now, when I use Cursor or Claude Desktop, the agent can actively query the N3MO server alongside its normal workflow.

Instead of guessing context, the agent asks N3MO: "What is the transitive blast radius?" And N3MO hands back the exact, verifiable relational graph. No more hallucinations. Just surgical, structural precision.

Try it out

I'm building N3MO in public, and it currently supports deep semantic call graph mapping for Python, JS/TS, and Java (with structural parsing for 24 other languages).

If you want to stop guessing what your code touches whether you are a human or an AI give it a shot.

🔗 Star N3MO on GitHub
🌐 Visit the Website


bash
# Get started instantly
pip install n3mo
n3mo index /path/to/your/repo
n3mo query callers "my_function" --depth 5

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