A one line change can touch thirty other things. Your diff will not tell you. Orbit will.
💡 Inspiration
When I review a merge request I only see the diff. A few changed lines. What I never see is how far those lines actually reach.
| What the reviewer sees today | What they cannot see |
|---|---|
| The diff, a few changed lines | Every function that calls the changed code |
| The one file that changed | Whether the change ships to production |
| A green or red pipeline | Who owns the affected code, and what it might break |
A one line tweak to a small helper might be called from thirty places, while a scary looking three hundred line change can be completely isolated. grep cannot follow calls across a whole codebase, and if I ask a chatbot it just makes something up. I wanted the reviewer to see the real reach of a change before clicking approve. GitLab Orbit already turns a codebase into a queryable graph, so the data was sitting right there waiting to be used.
🛰️ What it does
Blast-Radius Reviewer is a GitLab Duo agent that reads a merge request, finds the function or class that changed, asks the Orbit knowledge graph how many things actually depend on it, and posts a short report straight on the merge request with a plain risk verdict.
Here is a real example from the demo. I made a docstring only change to the Response class in the requests library. It looks completely harmless. The agent commented on the merge request by itself:

Thirty one callers. High risk. No guessing. Every number comes straight from a graph query, so I can trust it and click through to check.
🔧 How we built it
| Piece | What it does |
|---|---|
| Orbit Remote | Indexes the codebase as a graph (I imported psf/requests, about 900 functions and classes plus all the call edges) |
orbit-blast-radius skill |
Holds the validated Orbit query recipes: count callers, list callers, find reviewers, check production reach, look for findings |
| GitLab Duo CLI + Orbit MCP | The agent that reads the MR, queries Orbit at https://gitlab.com/api/v4/orbit/mcp, and posts the note |
| AI Catalog | Where the agent is published so anyone can find and use it |
| Orbit Local (bonus) | An offline mode using a single binary and a DuckDB graph, same blast radius, no account needed |
One detail I really liked: when the agent got the query format slightly wrong on its first try, it called the schema tool, corrected itself, and ran the query again. It recovered on its own.
🧱 Challenges we ran into
- The option to attach an MCP server to an agent inside the AI Catalog web interface was not available yet, so the published agent could not reach Orbit from the browser. I ran the same agent through the GitLab Duo CLI instead, which connects to the Orbit MCP server directly.
- New GitLab accounts cannot run CI pipelines until you verify with a card, which I did not want to do for a hackathon. So I dropped the CI file and kept the checks runnable locally.
- The Orbit query language is strict about field names. Getting it exactly right took some back and forth, so I baked the correct format into the skill so the agent gets it right from the start.
🏆 Accomplishments that we're proud of
It actually works from end to end as a real agent, not a mockup. The agent reads a merge request, queries the live Orbit graph, and posts a blast radius comment by itself. And it answers a question that neither a diff viewer nor a plain language model can answer honestly: how far does this change really reach. That answer comes from a graph that understands the code and the project around it.
📚 What we learned
- The real power of Orbit is the graph, not search. A question like how many things call this is one query, not a guess.
- An agent paired with an MCP tool is a clean and forgiving pattern. Give it the right recipes and it can recover from its own small mistakes.
- Working solo on a tight clock, the thing that kept me sane was always having one path that definitely works, the offline mode and the validated queries, while I pushed on the fancier path.
🧭 What's next for Blast-Radius Reviewer
- [ ] Put the rest of the signals into the comment: does this change reach production, who has touched these callers before, and are there open security findings in the affected code (the queries are already written)
- [ ] Run on its own for every new merge request once flow triggers and in catalog MCP attachment are available, so nobody has to start it by hand
- [ ] Group callers by file and repository so the cross project fan out is obvious at a glance
🔗 Links
| 📦 Repo (MIT) | https://gitlab.com/blast-radius-lab1/blast-radius-reviewer |
| 🤖 Published agent | AI Catalog, search "Blast-Radius Reviewer" |
| 🧪 Live demo MR | https://gitlab.com/blast-radius-lab1/requests-demo/-/merge_requests/3 |
| 🎬 Demo video | https://youtu.be/XOb3ro8fR24 |

Log in or sign up for Devpost to join the conversation.