Blast Radius Reviewer

Know what breaks before you merge. Blast Radius Reviewer uses GitLab Orbit's knowledge graph to automatically analyze MR impact, visualize dependency risk, and post AI-powered review comments.

Comment

Inspiration

Every code review I've done has the same blind spot. You open a PR, stare at the diff, and try to mentally trace what else might break. It's guesswork. You're reading changed files in isolation, with no visibility into what depends on them downstream.

I've been building LLM pipelines and agentic systems professionally, and the one thing that always frustrated me was that the dependency information exists - it's just buried in the codebase, inaccessible to reviewers in the moment they need it most.

When I saw that GitLab Orbit exposes a full traversable knowledge graph of your codebase, I immediately thought: this is the missing layer. Not another AI that summarizes diffs. Something that actually knows the graph.

What it does

Blast Radius Reviewer tells you exactly which files are at risk the moment an MR is opened.

It does two things:

Automated MR Comments - When a merge request is opened on GitLab, the agent automatically queries Orbit's knowledge graph, traces all downstream import relationships from the changed files, identifies the specific symbols at risk, and posts a structured analysis comment directly on the MR. The reviewer sees a risk table, affected files, and a pre-merge checklist without doing anything.

Interactive Dashboard - A visual dependency graph of the entire project, color-coded by directory (auth, api, utils, agent, test). Load any MR number and the graph highlights changed files in blue and at-risk files in amber with animated edges showing the impact path. Click any node to inspect what it imports, what imports it, and get a Claude-generated description. There's also a "Talk to your code" chat window that answers questions about the codebase using the Orbit graph as context.

How I built it

The stack is deliberately minimal. Every layer does one job.

Architecture

GitLab MR Event (webhook)
         |
         v
  FastAPI Backend
         |
    +----+----+
    |         |
    v         v
GitLab      GitLab
REST API    Orbit API
(MR diff)   (graph traversal)
    |         |
    +----+----+
         |
         v
  Claude Sonnet 4.6
  (synthesis + chat)
         |
         v
  MR Comment Posted
  +
  Dashboard API responses
         |
         v
  React + React Flow
  (dependency graph UI)

Orbit queries are the core. I use four distinct query patterns against the knowledge graph:

  • Project → CONTAINS → Branch → ON_BRANCH → File to enumerate the project
  • File → DEFINES → Definition to find what a changed file exports
  • File → IMPORTS → ImportedSymbol (filtered by exact module path) to find the blast radius
  • Aggregation queries over User → APPROVED → MergeRequest to suggest reviewers

FastAPI receives webhook events from GitLab, orchestrates the Orbit queries, and exposes /graph, /analyze, /describe, and /chat endpoints for the dashboard.

Claude Sonnet 4.6 synthesizes the raw graph data into a structured MR comment with risk levels, affected symbols, and a pre-merge checklist. For the chat feature, the full Orbit graph context is passed with every message so Claude can answer questions about actual dependency relationships.

React + React Flow + Dagre renders the dependency graph with automatic left-to-right topological layout. The backend is deployed on Railway, the frontend on Vercel.

Challenges I ran into

The Orbit DSL took time to figure out. The documentation was sparse and the query schema validation errors were not always descriptive. I had to systematically hit the /schema endpoint and experiment to understand the exact node/column/filter syntax that was valid. The op: "eq" vs op: "contains" distinction was a real gotcha - using contains caused cross-namespace noise where other hackathon participants' files appeared in my blast radius results.

Cross-namespace pollution. Because all hackathon projects live in the same gitlab-ai-hackathon group, Orbit queries that weren't scoped precisely enough returned files from other participants' projects. The fix was combining exact module path matching with a project file allowlist built from a separate Orbit query.

API key exposure. Mid-build I accidentally committed a test file with a hardcoded Anthropic API key to the public GitLab repo. Rotated immediately, but it caused an unexpected billing spike from the June 15 Claude Code billing change that hit the same day. Lesson learned the hard way: test files always use os.environ.

Accomplishments that I'm proud of

The thing I'm most proud of is that Orbit is doing real work here, not just decorating the output. The blast radius detection is only possible because of the graph traversal. You literally cannot replicate this from a diff alone.

I'm also proud of the dashboard design. It went through about eight iterations and landed on a split-panel layout - white sidebar and chat, graph in the center - that actually feels like a tool a developer would use daily, not a hackathon demo.

And the "Talk to your code" feature exceeded my expectations. Asking "what would break if token.py changed?" and getting a response that correctly cites the actual import relationships from Orbit - that's the kind of grounded AI answer that's genuinely useful.

What I learned

I learned the Orbit knowledge graph is significantly more powerful than advertised. The CALLS edge (Definition to Definition) means you can do call-graph traversal, not just import tracing. The security domain has vulnerability-to-file relationships. There's enough here to build a full static analysis layer on top of GitLab without touching the source files at all.

I also learned that good prompt engineering for synthesis tasks matters more than model choice. The first version of the MR comment generator was verbose and hard to read. The final version - with explicit instructions about format, length, and what not to include - produces comments that look like they were written by a senior engineer.

What's next for Blast Radius Reviewer

Multi-language support - Currently optimized for Python. The Orbit schema supports Ruby, Java, Kotlin, TypeScript, JavaScript, Rust, and C# too. Extending the blast radius queries to work across all supported languages is straightforward.

Call graph traversal - The CALLS edge in Orbit goes deeper than imports. A change to a function signature should trace through every caller, not just every importer. This would make the blast radius significantly more precise.

Risk scoring - Right now risk is binary (at risk / not at risk). A proper score based on how many things depend on a file, historical breakage rate from CI data, and whether the file is in a security-sensitive path would make the leaderboard more actionable.

GitLab AI Catalog publishing - The agent is designed to be published as a GitLab Duo skill so any team can install it on their project with a single click.

Built With

  • claude-sonnet-4.6-(anthropic-api)
  • dagre
  • fastapi
  • gitlab-orbit-api
  • gitlab-rest-api
  • python
  • railway
  • react
  • react-flow
  • vercel
  • vite
Share this project:

Updates