The promise is easy to state and hard to check: hand the tool a repository you did not write, and see the whole thing broken down visually. I wanted to know whether that actually lands or whether you get boxes with filenames, so I ran a real scan of a real monorepo through the product’s own code paths rather than a fixture. The answer is both, on different axes, and the split is the finding.
Start with the half that fails. The scan produces 1,101 nodes, 96 per cent of which are files, and 2,922 edges, 99.8 per cent of which are imports. The function that lifts that into a service-level diagram — the thing you would actually put on a wall — returns exactly one drawable connector: the analyzer talking to the database. Six database edges exist, and all six leave one file for one datastore, so lifting them collapses them into a single arrow. A board with one connector on it is not an architecture; it is boxes with filenames, and anybody who tells you otherwise is describing the mockup rather than the output.
Now the half that works, on the same graph. Ask a different question of it — not what talks to what, but what contains what and how much is where — and the answer is well-formed. Containment is complete at 1,059 of 1,059 files, with zero duplicates in the walk. The recursive and flat line-count totals agree exactly, at 275,837, which is the kind of agreement you only notice when it fails. And two packages hold 83 per cent of the repository.
That last number is the one worth defending, because it is a fact a newcomer cannot get from ls. Listing the packages directory tells you there are, say, a dozen packages, and implies twelve roughly equal things. The truth is that two of them are the repository and the rest are rounding. Rendering cell area proportional to lines puts that on screen without a sentence of prose, and a person who has been in the codebase for an hour already knows it while a person reading the directory listing does not.
So the structure axis delivers and the topology axis does not, and the interesting part is why.
The obvious fix presents itself immediately: roll the imports up to package level. I measured what that would buy before I thought about whether to do it — 320 cross-package imports collapse into 14 readable dependency edges, with the schema package as the foundation and the analyzer as the hub. Fourteen edges is a board. It would have looked like the product working.
Then I found the standing ruling, written down before I asked: an import is not a service-level claim. It has been decided three times, in three different features, with a written incident behind it, and a change four days earlier had cut the last disagreeing consumer from 162 rolled edges down to at most one. Shipping the obvious fix would have silently reversed a ruling inside the product whose entire promise is that what you see was grounded rather than guessed. The measurement stays on the record so the option remains visible; it was not taken.
This is the part I would want someone to take from it. The fix was available, cheap, and would have made the demo better, and every one of those is an argument for doing it. The reason not to is that the resulting arrow would have meant something different from what a reader would take it to mean — this service calls that service rather than this file mentions that file — and a diagram whose arrows quietly change meaning is worse than a diagram with one arrow on it.
Which leads to the actual diagnosis: the gap is in the data, not in the renderer. This particular monorepo is a set of libraries plus one database. There are no HTTP, gRPC or queue edges between its packages because there are none in the code, and a scanner that produced them anyway would have broken the only rule this thing has. The thin board is an accurate picture of a repository that genuinely has almost no runtime topology.
The consequence is one I did not expect and had to write down for my own benefit: testing sees the whole thing broken down visually against this repository will keep understating the product indefinitely. The test subject is wrong, not the tool. What the harness asks for now is a repository whose scan actually produces service-to-service edges — and until one is run, any claim I make about the topology view is a claim about a library monorepo dressed up as a claim about software in general.
I would rather ship a product that computes structure completely and knows exactly what it cannot draw than one that draws everything and is right about some of it. But I only get to say that because I measured both halves; had I run the scan, seen fourteen tidy edges after a two-line change, and shipped it, I would have written a very confident paragraph about visual architecture and been wrong in a way no screenshot would ever have revealed.