Understand Anything — waarom je eerst de kaart moet tekenen voordat je code schrijft

Vorige maand zat ik met een klant die me zijn "AI-strategie" liet zien. Drie developers, elk met een eigen coding agent, die elk tegen dezelfde legacy codebase van 200.000 regels aan het duwen waren. Het resultaat? Drie verschillende interpretaties van hoe de authenticatie-flow werkt. Drie keer dezelfde bugs opgelost. Nul gedeeld begrip.

Ik vroeg: "Hebben jullie een kaart van die codebase?" Hij keek me aan alsof ik vroeg of ze een plattegrond van het gebouw hadden. "We hebben de code toch?"

Precies daar wringt het. Je kunt geen stad verbouwen zonder plattegrond. Waarom denken we dat we codebases kunnen verbouwen zonder kaart?

Wat het is

Understand-Anything lost dit op. Het is een tool die van elke codebase een interactieve knowledge graph maakt, bestanden, functies, classes, dependencies, architectuurlagen, businessdomeinen, in één doorzoekbaar, visueel model. Je runt /understand, en vijf minuten later heb je een JSON-bestand dat je hele team kan gebruiken. Commit het, en nieuwe teamleden hebben instant context.

Het project is jong, twee maanden oud, maar de tractie liegt niet: 42.000 stars, 3.300 forks, MIT-licentie. Het werkt op Claude Code, Codex, Cursor, Copilot, Gemini CLI, OpenCode, Hermes, Antigravity, en nog acht andere platformen. Dit is geen niche-tool. Dit wordt een categorie.

Stillness before action

De kernfilosofie staat in de README: "Graphs that teach > graphs that impress." Het doel is niet een plaatje dat laat zien hoe complex je codebase is. Het is een kaart die je leert hoe alles in elkaar steekt.

Dit raakt aan een principe dat ik al jaren predik: oriëntatie vóór actie. Je agent laten graven in een onbekende codebase zonder eerst een mentaal model te bouwen, is vragen om fouten. Understand-Anything dwingt je dat model eerst te maken, en vervolgens te delen met je hele team. Geen drie interpretaties van de auth-flow. Eén gedeelde waarheid.

De tool maakt codebase-kennis overdraagbaar. Je runt het één keer, committed de JSON, en iedereen die daarna aan de code werkt, of dat nu een mens of een AI-agent is, start met dezelfde kaart. Dit is wat ik "structural onboarding" noem, en het is een use case die elke organisatie met meer dan drie developers heeft.

De architectuur die het waar maakt

De techniek is een slimme combinatie van deterministisch en semantisch. Tree-sitter parseert source files naar concrete syntax trees: imports, exports, functies, klassen, callsites, inheritance. Dit deel is reproduceerbaar, dezelfde code geeft altijd dezelfde structurele graaf.

Daar bovenop draaien LLM agents die toevoegen wat parsers niet kunnen: samenvattingen in gewone taal, architectuurlaag-classificatie, businessdomein-mapping, guided tours. De graaf is structureel betrouwbaar én semantisch rijk.

De pipeline draait parallel: vijf agents tegelijk, 20 tot 30 bestanden per batch. Incrementele updates via fingerprinting, alleen gewijzigde bestanden worden opnieuw geanalyseerd. En het resultaat is één JSON-bestand dat je kunt delen, committen en versioneren.

Het is een persistent artefact, geen vluchtig AI-antwoord. Dat is het verschil met agents die willekeurige bestanden lezen, een fragiel mentaal model opbouwen en context verliezen zodra het gesprek voorbij is.

Wat me enthousiast maakt

Multi-platform. Dit project ondersteunt veertien platformen. Voor mijn heterogene stack, Claude Code, OpenCode, OpenClaw, Hermes, is dat relevant. Geen single point of dependency. De tool past zich aan jouw tooling aan, niet andersom.

Domain view. De mogelijkheid om code te mappen naar businessprocessen is strategisch interessant. Voor enterprise architecture, product-mode werken en architectuurbesluitvorming is dat waardevoller dan alleen technische dependency graphs.

Sovereign AI compatible. Tree-sitter is lokaal. De LLM-stap kan tegen een lokale Ollama. De output is een statisch JSON-bestand. Dit hele proces kan air-gapped draaien. Geen data die het gebouw verlaat. Dit is BIO2-vriendelijk, en dat is bij de meeste AI-tools niet het geval.

De risico's die je moet kennen

Supply-chain. De README beveelt curl -fsSL ... | bash aan. Dat is exact het patroon dat je in een gereguleerde omgeving niet wilt gebruiken. Clone handmatig, pin een specifieke release, inspecteer de installatiescripts. Geen shell pipe vanaf internet.

Data-classificatie. De LLM-stap verwerkt je broncode. Als die analyse via cloudmodellen loopt, kan broncode buiten je eigen trust boundary terechtkomen. Voor productiecode: forceer lokale inferentie of een enterprise-approved endpoint. En voeg een strikte .understandignore toe vóór de eerste run, sluit .env, secrets, keys, credentials en customer data uit.

Graph correctness. Structurele edges uit Tree-sitter zijn betrouwbaar. Maar businessdomain mapping, architectural layer assignments en guided tours blijven modelinterpretaties. De tool heeft een graph-reviewer, maar dat is geen formele verificatie. Behandel LLM-samenvattingen als advisory, niet als autoritatieve waarheid.

Geen enterprise hardening. Ik zie tests, linting en build-instructies, maar geen security policy, signed artefacts, SBOM of threat model in de publieke repository. De GitHub-markering "Security and quality: 0" bevestigt dat. Dit is een project met tractie, niet met enterprise-grade supply-chain governance.

Hoe je het veilig test

Niet blind installeren. Gebruik deze volgorde:

1. Fork de repository
2. Pin een specifieke release (v2.7.x), niet main
3. Inspecteer install.sh, package.json, plugin skills en agents
4. Draai eerst in een disposable sandbox op een synthetische repo
5. Voeg .understandignore toe en sluit gevoelige bestanden uit
6. Forceer lokale inferentie voor semantische analyse
7. Markeer de knowledge-graph output als gevoelig tot validatie
8. Valideer tegen een tweede tool: dependency graph, tests, handmatige architectuurreview

Pas daarna toepassen op repositories met echte vertrouwelijkheid. En dan alleen als observability- en onboardinglaag, niet als bron van waarheid voor compliance of security review.

Waar dit past in mijn stack

Understand-Anything is geen vervanger van SAST, architecture decision records of secure code review. Het is een aanvullend oriëntatielaagje bovenop bestaande workflows. De combinatie die voor mij werkt:

• codebase-memory-mcp voor AST-first retrieval en token-efficiënte navigatie
• Understand-Anything voor visuele graaf, guided tours en teamonboarding
• GraphRAG voor duurzame kennislaag over repositories heen
• LiteLLM/local models voor gecontroleerde providerkeuze en dataclassificatie

Samen geven die je wat coding agents alleen nooit bereiken: gedeeld begrip dat blijft bestaan nadat de chat gesloten is.

Conclusie

Understand-Anything vult een reëel gat. Ontwikkelaars en AI-agents missen een gedeeld, visueel en semantisch model van hun codebase. Deze tool levert dat, als JSON-bestand, zonder vendor lock-in, zonder cloud-dependency.

Voor mijn publieke-sector klanten is de sovereign AI-compatibiliteit de doorslaggevende factor. Een tool die een codebase analyseert zonder data die de deur uitgaat, is een tool die je kunt inzetten zonder DPIA.

Maar: wel testen, niet blind operationaliseren. De supply-chain volwassenheid is onvoldoende voor blind vertrouwen. Fork, pin, sandbox, valideer. Het is een sterke tool voor developer onboarding en codebase comprehension, niet voor compliance-attestation of security-audit.

En de volgende keer dat iemand je vraagt waar te beginnen in een codebase van 200.000 regels, heb je een antwoord: teken eerst de kaart.