An LLM will happily "diagram" this repo for you. It will also invent a couple of modules that were never there, quietly drop the ones that didn't fit its context window, and give you a different answer every time you ask. You cannot onboard onto a guess. You need the map that matches the code — the one you can click into and verify line by line.

This page runs against a small, honest fixture that ships in the repo (examples/scenarios/orphan_monolith) so every command and every line of output below is real — you can run it yourself and get the same result.

Generate a map you can trust

One command turns the whole tree into a single interactive HTML file. It opens offline, makes zero network requests, and never imported or ran a line of the target code.

$ py-code-visualizer visualize examples/scenarios/orphan_monolith -o map.html

Open map.html and every node is a real function; click any edge and it shows you the exact file:line where that call happens. Where two different clean() functions could be the target of one call, the tool does not pick one and pretend — it draws the edge dashed and keeps both candidates:

the honest edge, from the JSON graph

AMBIGUOUS: app.transforms.summarize → app.helpers.clean candidates = ['app.helpers.clean', 'app.legacy.clean'] at app/transforms.py:16

That single dashed line is the whole philosophy: a tool that markets ground truth is not allowed to bluff.

Get a grade you can defend

Before you touch anything, you want a number. health scores the architecture A–F from the graph itself — coupling, cycles, hub risk, orphans, ambiguity — and shows its work.

$ py-code-visualizer health examples/scenarios/orphan_monolith

Architecture Health: D+ (69/100) — orphan_monolith Component penalties: coupling -25 cycles +0 hub_risk +0 orphans -4 ambiguity -2 Cycles: 0 · God-nodes: 0 · Orphans: 2 · Cross-module: 64%

Now you can say something concrete in your first standup: "It's a D+. The problem isn't cycles — it's coupling and orphaned code. Here's the plan." And because the score is deterministic, you can put it in CI and watch it move on every PR.

Find the code nobody calls

Half of onboarding is learning which code is actually live. check --dead-code lists functions unreachable from any detected entry point (main, run, dunders, framework-decorated handlers). It's conservative — a review list, not a delete list.

$ py-code-visualizer check examples/scenarios/orphan_monolith --dead-code

✅ Architecture check passed: no rule or cycle violations. 🟡 3 function(s) with no in-project callers (review — may be public API): app.legacy.archive app.legacy.clean app.storage.load_from_csv

Three functions the departed contractors left behind, surfaced in seconds — each one a candidate for deletion once you confirm nothing external calls it.

What you got. In three commands and no code execution: a verifiable interactive map (16 functions, 11 calls, 1 honestly-flagged ambiguous edge), a defensible D+ (69/100) health grade with the reason spelled out, and a 3-function dead-code review list. No hallucinated modules, no "trust me" — every claim clicks through to a line of source.

Every number on this page was produced by running the commands above against examples/scenarios/orphan_monolith in the repository. Scale it up: the same pipeline maps a real ~100k-line project in about five seconds — see the measured benchmarks. Reproduce them with python benchmarks/bench.py.

← All use cases