A codebase nobodyfully remembers.
One reading of the system that every engineer and every assistant queries, generated from the code rather than written down.
Tribal knowledge does not scale.
In a large codebase the architecture lives in a handful of heads and a diagram that went stale two quarters ago. Everyone else works from the file in front of them, and the cost lands as onboarding time and as regressions nobody could have predicted.
Assistants make it sharper, not softer. They generate code faster than anyone can build the mental model to review it, and each one starts every session knowing nothing about the system it is editing.
Three things, at monorepo scale.
Re-parsed only where the code changed, hosted or on your own machines.
A map that is generated
Every repository gets an interactive graph and a report naming its communities and god nodes. Nobody maintains it.
Blast radius, before
The callers of a function, their callers, and the configs and tests that name them. The question behind most incidents.
One layer, every assistant
The same graph answers in all 17, over MCP, so the team is not standardising on an editor to standardise on context.
It is not org-wide code search. It maps the repositories you point it at, on the machines you point it from. If thousands of repositories in one index is the requirement, a platform is the right shape and this is not one.
And it does not judge the architecture. It says what calls what and where each claim came from. Whether the thing should have been built that way is still yours.
One repository, then the rest.
Start on the hosted product, or run the first one yourself as a command rather than a project.