You join a new team. The codebase has 200,000 lines. The people who wrote it are busy, the documentation is outdated or doesn’t exist at all, and the architecture lives mostly in someone’s head. Where do you start?
I’ve seen this scenario repeat itself for twenty years, and the answer has barely changed: you read files one at a time, ask whoever has the patience to help you, and little by little you build a mental model that’s wrong in three places you won’t discover until you’re in production. The cost of that ramp-up is enormous, and we generally pretend it doesn’t exist because it’s hard to put on a spreadsheet.
The interesting part is that now we have AI agents in the mix, and they have exactly the same problem — just faster. Give an agent a specific function to fix and it does it well. Ask it “how does authentication flow through this system?” and it starts opening files one at a time, burning through context, losing the thread halfway through. The agent isn’t bad with code. It’s bad with codebases. It doesn’t have a map.
Understand-Anything is an attempt to give both — the human and the agent — that map.
What it does concretely
It’s a Claude Code plugin that runs a multi-agent pipeline over your project and builds a knowledge graph of every file, function, class, and dependency. Then it delivers you an interactive dashboard to explore everything visually. Each node comes with a clear-language summary of what it does, what depends on it, and where it sits in the architecture.
The design philosophy is stated plainly in the project: the goal isn’t a graph that impresses you with how complex your system is — it’s one that teaches you, without noise, how the pieces fit together. That distinction matters. Most code visualization tools produce a tangle that confirms your codebase is complicated without helping you understand it. This one is built around comprehension, not spectacle.
The pipeline does the obvious structural parsing, but adds semantic meaning on top: assignment of architectural layers (API, Service, Data, UI, Utility), natural language descriptions, and a set of guided tours — auto-generated walkthroughs ordered by dependency, so you learn the system in the order that makes sense instead of alphabetically.
Some capabilities worth highlighting for those thinking about it from a team operations perspective:
- Onboarding tours. A committed graph means someone joining opens a visual map of the architecture on day one and takes an ordered walkthrough by dependencies, instead of blind grep-searching for a week.
- Semantic search. You ask “what parts handle auth?” in natural language and get relevant nodes ranked across the graph — not a list of files that happen to contain the string
auth. - Diff impact analysis. Before you commit, you see what parts of the system your changes impact. This is the feature I’d most want my teams to use.
- Profile-adjusted detail. The dashboard adjusts how much it shows you based on whether you describe yourself as a junior dev, PM, or senior engineer.
It runs as a native Claude Code plugin but works with Cursor, Codex, GitHub Copilot, Gemini CLI, and a dozen other runtimes — auto-detected through plugin configuration files in most cases. It’s MIT-licensed, and at this point it’s accumulated over 51,000 stars, with most of that growth happening recently. That kind of curve usually means the tool touched a nerve that a lot of people have been quietly feeling.
The trap worth naming
A knowledge graph is a snapshot. Unless you activate the post-commit hook for auto-update, it drifts from the codebase the moment people start merging. A team that builds an onboarding graph and forgets to regenerate it before a big release is going to hand new people a confidently wrong map — which might be worse than having no map at all. This isn’t so much a flaw as a matter of operational discipline: the graph is infrastructure, and infrastructure nobody maintains rots.
Why I think this matters
The frame that keeps turning over in my head is that comprehension is becoming a shared layer between humans and agents. We spent two years optimizing how agents write code. We’ve devoted much less to how they understand the code that already exists — which, for any company older than a weekend, is where the real work lives.
A persistent, queryable, semantically rich map of your system isn’t just an onboarding convenience. It’s the substrate that lets an agent answer architectural questions instead of structural ones, and it’s what turns “the knowledge is in Carlos’s head” into something the whole team — and its tools — can consult. For an engineering organization carrying a large legacy codebase, that’s not a toy. It’s a cost you’ve been paying in lost hours for years.
It’s still early. The community is active, the tool evolves, and the license is permissive enough that trying it costs you almost nothing. Given where it’s heading, it’s an easy experiment to run.