Use case · Code review

Review a PR in minutes, not hours

A 40-file diff lands in a 200k-line repo. No reviewer can read every file. What they actually need is three things: what functions changed, what those changes can reach, and where to look — each one a click from the source.

review blast radius clickable file:line PR comment

Grep tells you where a name appears; it can't tell you the transitive reach of a change, or that an edit just closed a dependency loop three hops away. The call graph can — deterministically, so the same report goes in the PR every time. review reads the git diff, maps the changed lines onto functions, and hands the reviewer a focused map.

1

One command turns a diff into a map

Point it at the base branch. It reports the changed functions, the blast radius (transitive callers), the call sites to review, any risk flags, and a Mermaid diagram of just the changed neighborhood — every reference a clickable file:line.

$ py-code-visualizer review . --base origin/main

On a service where a refactor added an audit hook, the report reads:

## 🔍 Architecture Review 2 function(s) changed vs `main` · blast radius 4 caller(s) across 2 module(s). ### ✏️ What changed - core.persist (core.py:7) - service.audit (service.py:15) ### 🎯 Impacted area — review these call sites - core.persist is called by: service.place_order, service.cancel_order, service.audit - service.audit is called by: core.persist ### ⚠️ Risk flags - 🔴 Cycle involves a changed function: persist → audit → persist

The reviewer instantly knows the change touches persist (a function four callers depend on) and that it introduced a circular dependency — the thing easiest to miss by eye, surfaced automatically. In the real report each function name is a link straight to the line on GitHub.

2

Make it automatic on every PR

You don't want to remember to run it. One opt-in setup writes a GitHub Actions workflow that posts the report as a PR comment — nothing else added.

$ py-code-visualizer init --with review
Set up: review (CI: github) created: .github/workflows/pyvisualizer-review.yml

From the next PR on, reviewers open to a focused map instead of a wall of files. Add --fail-above N if your team wants to gate on an oversized blast radius — otherwise review stays a pure report and never blocks a merge.

What you got. Every PR now opens with the answer to "what do I actually need to look at here?" — the changed functions, a measured blast radius, the exact call sites, and automatic detection of newly introduced cycles, each one a click from the source. Large-repo review stops being archaeology.

The report is deterministic (same input → byte-identical output) and every reference is a real file:line — links resolve to GitHub when a remote is detected, plain text otherwise. See also the blast-radius & cycle-gate walkthrough.

← All use cases