BlastRadius: asking a graph what will break before you change the code

Changing one function in a large codebase can silently break many others, and first-time open source contributors are often afraid of exactly that. For Graph Hacks 2026 (Team Why Graph) I built BlastRadius, an agent that answers "what will break if I change this?" using a FalkorDB graph, and shows the path behind every answer.

Code: https://github.com/triyanshag777/blastradius
Demo video: https://youtu.be/cyB5jUHiZ4M

The problem

"Find usages" shows direct callers, but the real question is about connections: who depends on this through three other functions, which tests reach it, and who knows this code. That is a graph question, and a language model that only sees pieces of text is weak at it.

What it does

BlastRadius reads a Python repository with ast (code is never executed) and stores it in FalkorDB: Function nodes, Person nodes, CALLS and EDITED edges. On psf/requests that is 615 functions and 1058 call edges.

You ask a question in English. An LLM agent picks from a fixed set of graph tools exposed over MCP: impact, tests_for, experts, explain_path, criticality. It never writes Cypher itself. The dashboard shows the neighbourhood of the changed function, animates the exact path behind the answer, and can generate a ready pull request comment.

How FalkorDB is used

Blast radius is a variable-length traversal:

MATCH p = (d:Function)-[:CALLS*1..5]->(f:Function {name: $name})
WHERE d.in_tests = false AND d.name <> $name
RETURN d.name AS dependent, min(length(p)) AS hops

The same pattern starting from test functions tells you which tests to run. shortestPath explains how two functions connect, and the built-in algo.pageRank ranks how critical a function is. For Session.prepare_request it reports 16 dependents, 49 tests that reach it, and the top 5.9 percent by PageRank, which becomes a HIGH risk level.

Change Check: errors your change introduces

The feature I like most compares your uncommitted changes with the last commit. It finds removed, renamed or re-signatured functions, asks the graph who calls them, and checks every call site against the new signature. Only problems introduced by your change are reported, never old ones. When I made prepare_request require a new argument, it found 13 broken calls (12 tests and Session.request), suggested a fixed call for each, re-checked each fix against the new signature, and produced a patch. After applying it, the check reported zero new problems. It never applies or commits anything by itself, and changes to what a function does inside cannot be checked statically, so it tells you which tests to run.

Why a graph? A small test

I gave a plain LLM only sessions.py and asked what depends on prepare_request. It found 8 of the 16 dependents and missed every function in api.py. This is an illustrative test, not a benchmark, and a bigger context window would help on small repos, but whole repositories do not fit in a prompt and the graph also returns a verifiable path.

What went wrong, and what I learned

• My first parser linked os.environ.get() to Session.get because it matched calls by name, which created false paths. Skipping common method names and matching self.x() inside the same file first cut the edges from 1754 to 1058.
• A cycle (Session.send is reachable from its own dependents) made the changed function show up as its own dependent until I excluded it.
• shortestPath is only allowed in WITH or RETURN in FalkorDB. I found that out from the error message.
• The free tier of my LLM provider limits tokens per minute, so the agent has to retry and keep tool results small.

Limits

Python only. Calls are matched by name, so dynamic dispatch, aliases and decorators are not resolved. Reviewers come from file-level git history. These limits are listed in the README.

Thanks to WeMakeDevs and FalkorDB for the hackathon.