Introducing IMPACT: Why Does This PR Actually Affect?

Omar Moustafa — Sun, 18 Oct 2026 14:55:00 +0000

Did you ever look at a one-line code change and thought, okay, but what else could this break?

That question led me to build IMPACT, a Python PR review tool for Graph Hacks by WeMakeDevs and FalkorDB. 🚀

A diff shows what changed. It doesn't always show the functions that call that code, or which tests might be affected. IMPACT maps these relations in FalkorDB, then follows them to produce a graph you can inspect.

Testing the idea

I started with a small checkout repo instead of a huge project. It has pricing, cart, checkout, receipts, and a few tests—enough for one change to travel through different files.

Then I broke the coupon calculation on purpose:

# Before
discount_cents = min(subtotal_cents, coupon_cents)

# After
discount_cents = coupon_cents

A $30 coupon on a $20 cart now gives a negative total. The receipt test expects 0 but gets -1000. The checkout test raises an error because it refuses to charge a negative amount. The normal-coupon test still passes.

One line later...

I wanted IMPACT to find those tests from the code relationships, and to show me why it picked them.

The graph selects the relevant tests; the test runner records what actually happened.

Following the calls

IMPACT stores files and functions in FalkorDB, with a CALLS connection whenever one function calls another. In the demo, checkout eventually reaches the changed apply_coupon function through cart and pricing code.

When apply_coupon changes, IMPACT walks those connections backwards. It finds seven reachable callers, including three tests. One of the test paths is four calls long—something I wouldn't get from looking at the diff alone.

Me after seeing how far one line can travel.

This is the Cypher query behind it:

MATCH p = (caller:Function)-[:CALLS*1..4]->(changed:Function {id: $id})
RETURN caller.id, caller.is_test, length(p), [n IN nodes(p) | n.id]

The HTML report uses those same paths. Click a test, and you can follow its connection back to the changed code.

Selecting a test reveals the exact path connecting it to the changed function.

Getting there took a few tries. I got stuck connecting to FalkorDB at first, and later had to fix a shortest-path query to use the syntax FalkorDB accepts. The doctor command now checks the connection and graph queries before I run a review.

Who should review the change?

I added another question to the demo: who knows this part of the code, and why was it written this way?

For that, I made a small, fictional company dataset. It links a code file to its owner, her team, and three source records: a decision about coupon limits, a support ticket about negative charges, and a team chat. IMPACT puts those links in FalkorDB alongside the call graph. Ask it about apply_coupon, and it suggests Maya Chen as a reviewer and points to the records behind that suggestion.

You can see the same context in the HTML report next to the test paths. It's a demo of the idea, with synthetic people and documents; it doesn't connect to a real company's Slack or ticket system yet.

The AI part

At first, I thought an AI agent for this hackathon might have to be a chatbot. For IMPACT, the useful action turned out to be choosing what to inspect and which test to prioritize.

The AI step is optional. The model calls a FalkorDB tool, looks at the affected code, and picks a test to inspect first. IMPACT checks that the choice is actually connected to the change. Then the test runner supplies the real pass, fail, or error result.

If I leave out the AI API key, the graph analysis and test selection still work.

Taking it to a real PR

The broken checkout demo was useful, but I also wanted to see what IMPACT would say about a fix. So I put the checkout code in a separate sample repo and opened a PR that caps oversized coupons.

IMPACT picked three tests from the graph and ran them on both commits. Two failed on the base and passed on the PR; the normal-coupon test passed on both. That tells me more than a list of tests to run: I can see whether the change actually fixed the cases it was meant to fix. Here's the report with the paths and results.

The same graph-selected tests on both commits: two now pass, with no new failures.

I then put the same review into GitHub Actions. A Python PR now starts a temporary FalkorDB instance, generates the graph and report, compares the tests, and updates a comment on the PR. I tested that with an automatic run. The workflow doesn't need an AI key; the graph and test results are enough for this part.

I also tried IMPACT on a larger HTTPie PR. It found 18 test targets that expanded to 43 cases: 34 passed, nine remote-service cases skipped, and none failed. I like the small checkout example for explaining the idea, but this one showed me what the report looks like with a lot more code.

The parser is still static Python analysis. Dynamic calls and runtime imports may be missed, so a call path means possible impact. I want to keep trying it on different repositories and improve the coverage where it falls short.

I'm entering IMPACT in Track 01: Agents That Act on Connected Data and Track 03: Company Brain. The first follows the code graph to help review a change; the second adds the people and decisions connected to that code.

If you review Python PRs, would seeing both the path to a suggested test and the reason behind a past decision help you? 🤔