Live graphs · real analysis
Six repositories you can pull apart.
Each of these was analyzed by the same nao analyze you get from the CLI, then
baked to a static snapshot. Start at Landmarks for the architecture, then open the
level up to see what sits underneath. Drag to pan, scroll to zoom, click any node for its
metrics.
This viewer is small on purpose — it draws one graph and gets out of the way. The full product interface, with its scope trees, filters and quality report, is hosted here too →
analysing…
Node colour — entity kind
Edge colour — relationship
Reading the shapes
- L1 / L2 / L3 — how much of the snapshot is drawn.
- Size — degree: how much of the codebase touches it.
- Red ring — the analyzer flagged a code smell.
- Clusters — modules that mostly talk to themselves.
- Bridges — the one node joining two clusters is where a refactor hurts.
What you are looking at
The whole graph, minus the dust.
A real analysis of a mid-size repository produces thousands of entities, most of them parameters and locals. Each snapshot here keeps the few hundred entities carrying the most structural weight — ranked by PageRank and degree — plus the classes and modules that own them, so no method appears without the container that explains it.
The counts in the sidebar are from the full analysis, not the trimmed view: when it says 3,450 entities and shows 321, the other 3,100 exist in the graph nao builds locally. In VS Code you get all of them, filtered interactively instead of ahead of time.
Why it is baked
A marketing site should not run your parser.
Letting visitors submit repositories would mean cloning arbitrary code and running a
parser on it, on a machine that is not theirs. Instead a maintainer runs llvator-bake offline, and the server does nothing at request time but hand
out bytes it loaded at startup.
Which is also the honest demo: the tool is a local binary. The right place to point it at your codebase is your machine.