Graphify Getest: Een Knowledge Graph Index voor Claude Code
Ik had Graphify bijna afgedaan als weer zo'n speeltje met npx-smaak.
De pitch klonk te mooi: "wijs het naar een willekeurige map, krijg een knowledge graph, bevraag de graph in plaats van bestanden opnieuw te lezen, en kijk hoe je tokenverbruik instort." Ik heb een gezonde reflex bij alles wat een vertienvoudiging van kostenbesparing belooft met één enkel commando. Meestal klopt de rekening bij de demo maar valt hij uit elkaar op een echte codebase.
Toen draaide ik het op een project waar ik al een maand mee worstelde — een agentschap-repo met zeven app-modules, een kluwen van gedeelde services en een docs/-map die ik stilletjes ontweek. De eerste build duurde minder dan drie minuten op mijn MacBook. De graph die eruit kwam vertelde me iets over mijn eigen architectuur dat ik een half jaar over het hoofd had gezien — een circulaire afhankelijkheid tussen facturatielogica en een notificatieservice die nooit van elkaars bestaan hadden mogen weten.
Dat was het moment waarop ik stopte Graphify te behandelen als een tokenbesparend kunstje en het ging zien als een code-reviewtool die toevallig ook tokens bespaart.
Dit artikel beschrijft wat ik leerde toen ik het op drie echte codebases draaide — wat het werkelijk doet, hoe de installatie er echt uitziet, waar de tokenberekeningen eerlijk zijn, waar het marketing is, en welke workflows het voor mij veranderde. Een eerlijk verhaal, geen persbericht. Als je een Claude Code-gebruiker bent die /cost steeds ziet stijgen telkens als je iets vraagt over een onbekende repo, dan zijn de komende twintig minuten misschien het nuttigste dat je deze week leest.
Het Probleem dat Graphify Werkelijk Oplost
Dit is de workflow waar de meesten van ons in vastzitten.
Je opent Claude Code in een repo die je niet uit je hoofd kent. Je stelt een vraag — "waar wordt deze user_id gevalideerd?" of "welke services raken de facturatiemodule?" of gewoon "leg uit hoe deze app is opgebouwd." Claude begint bestanden te lezen. Het leest het bestand dat je noemde. Dan het bestand dat dat bestand importeert. Dan het bestand dat het bestand importeert dat het bestand importeert. Twintig tool-calls later heb je een antwoord en een contextvenster dat voor 70% vol zit voordat je één regel code hebt geschreven.
Dit is de tokentaks. Elk gesprek betaalt hem. Elke keer dat je een nieuwe sessie start, betaal je hem opnieuw. Elke keer dat je context comprimeert, betaal je hem opnieuw. De codebase verandert niet tussen dinsdag en donderdag, maar je agent leest hem elke keer van nul.
Semantisch zoeken — grep, ripgrep, vector-embeddings — bijt een stukje van het probleem af maar lost het niet op. grep vindt strings, geen concepten. Embeddings vinden paragrafen die lijken op je zoekopdracht, niet de structurele relaties die je code daadwerkelijk heeft. Geen van beide vangt het antwoord op "welke functies roept RateLimiter uiteindelijk aan, drie hops diep?" omdat dat antwoord niet in één enkel bestand staat. Het leeft in de graph tussen bestanden.
De weddenschap van Graphify is dat je die graph één keer moet bouwen, naast je repo moet opslaan, en je agent de graph moet laten bevragen in plaats van elke keer de broncode te doorploegen. De graph is ruwweg twee megabyte JSON. Je bronmap kan honderden megabytes zijn. De agent leest de graph en grijpt pas naar ruwe bestanden wanneer hij daadwerkelijk code moet schrijven of wijzigen.
Als je al AI-ondersteund onderzoek hebt gedaan op grote codebases, weet je al waarom die weddenschap interessant is. De rest van dit artikel gaat over of het zich in de praktijk uitbetaalt.
Het Kernidee: Een Graph als Index
Voordat ik bij de installatiehandleiding kom, wil ik ervoor zorgen dat je het juiste mentale model hebt. De meeste artikelen over Graphify slaan dit deel over en het is juist het deel dat bepaalt of de tool nuttig is voor jouw repo.
Een knowledge graph bestaat uit slechts twee dingen: nodes (de entiteiten — functies, klassen, modules, doc-secties, concepten) en edges (de relaties — roept aan, importeert, erft van, hangt af van, verwijst naar, lijkt op). Graphify bouwt beide deterministisch voor code en semantisch voor documentatie.
Voor code gebruikt het tree-sitter om je broncode te parsen naar AST's en de structurele relaties te extraheren zonder ooit een token naar een LLM te sturen. Dat deel is snel, gratis en exact. Tree-sitter weet dat functie A functie B aanroept omdat de syntax dat zegt — geen inferentie nodig.
Voor docs, PDF's, markdown en afbeeldingen gebruikt Graphify een LLM (naar keuze — Claude, GPT, Gemini, Kimi, DeepSeek, lokale Ollama) om entiteiten te extraheren en relaties af te leiden. Dat deel is langzamer en kost tokens vooraf — eenmalig, tijdens de build. Daarna blijft de graph bestaan. Je betaalt de extractiekosten de eerste keer en amortiseert ze over elke query gedurende weken.
Vervolgens draait het Leiden-communitydetectie op de gecombineerde graph. Leiden is een clusteralgoritme dat dicht verbonden nodes groepeert in communities — in feite de vraag stellend "welke delen van deze graph horen bij elkaar?" De output is de natuurlijke modulestructuur van je repo, afgeleid van hoe de code werkelijk verbonden is, niet van hoe de mappen toevallig zijn georganiseerd. Soms komen die twee structuren overeen. Soms zijn ze het hevig oneens, en juist die onenigheid is het meest interessante signaal in de hele build.
Wanneer je de graph bevraagt, wandelt je agent langs edges in plaats van bronbestanden te lezen. "Laat me de auth-flow zien" wordt een graphtraversal die misschien drieduizend tokens aan gestructureerde nodes en edges retourneert, in plaats van vijftigduizend tokens ruwe broncode. Dat is de compressie. Daar zit de besparing.
De kanttekening — en we komen hierop terug — is dat graph-queries geweldig zijn voor het lezen van je codebase en waardeloos voor het schrijven ervan. Wanneer je code moet wijzigen, heb je nog steeds het ruwe bestand nodig. Graphify vervangt je bronmap niet; het vervangt je verkenning van je bronmap.
Installatie: Hoe Het er Werkelijk Uitziet in 2026
De repo staat op github.com/safishamsi/graphify. Er is een eigenaardigheid die je vooraf moet weten: de PyPI-pakketnaam is graphifyy met een dubbele y terwijl de oorspronkelijke naam wordt teruggehaald, maar het CLI-commando is nog steeds graphify. De README is hier open over — laat het je niet verwarren.
Graphify vereist Python 3.10 of nieuwer. Als je al op een moderne stack zit, ben je klaar. Als je nog op 3.9 zit, is dit je duwtje om te upgraden.
Ik installeer Python-tools tegenwoordig met uv omdat het de enige Python-tooling is die me niet het verlangen geeft alles in Rust te herschrijven. Het enkele commando dat je een werkende installatie geeft is:
uv tool install graphifyy
Dat zet graphify automatisch op je PATH — geen venv-gegoochel, geen pipx-ceremonie. Als je de voorkeur geeft aan pipx, dan werkt dat ook:
pipx install graphifyy
En als je een glutton for punishment bent en gewone pip wilt:
pip install graphifyy
…dan moet je ervoor zorgen dat ~/.local/bin (Linux) of ~/Library/Python/3.x/bin (Mac) op je PATH staat, of het aanroepen als python -m graphify. Ik raad uv of pipx aan — er is geen voordeel aan het vechten met PATH voor een CLI-tool.
Controleer of het er is:
graphify --version
Als je een versienummer terugkrijgt, ben je klaar met de installatie. Totale tijd op mijn machine: minder dan dertig seconden.
Graphify Registreren als Claude Code Skill
Dit is het deel dat Graphify daadwerkelijk nuttig maakt binnen je agent. De CLI is prima. De skill-registratie is het moment waarop Claude Code stopt met je vragen om graphify handmatig te draaien en het zelf gaat gebruiken wanneer het een repo moet verkennen.
Draai:
graphify install
Dat ene commando doet drie dingen. Het kopieert het platformspecifieke skill-manifest naar ~/.claude/skills/graphify/ zodat Claude Code het kan ontdekken. Het updatet (of maakt) je project CLAUDE.md met instructies voor de assistent om naar graphify query te grijpen voordat het terugvalt op het lezen van ruwe bestanden. En het registreert de slash-commando's — /graphify query, /graphify path, /graphify explain — die je direct aanroept wanneer je zelf de queries wilt sturen.
Als je Codex, OpenCode, Cursor, Gemini CLI of een van de meer dan tien andere assistenten gebruikt die Graphify ondersteunt, detecteert hetzelfde graphify install-commando de meeste automatisch en schrijft het juiste manifest naar de juiste plek. De README heeft een volledige matrix. Als je op Windows zit of expliciet wilt zijn, kun je --platform claude of --platform codex meegeven om het doel te forceren.
Na het draaien van graphify install is de juiste sanity-check om Claude Code te openen, / te typen en te kijken of de graphify-commando's in de kiezer staan. Als ze er zijn, is de skill correct geregistreerd. Als ze er niet zijn, controleer dan of ~/.claude/skills/graphify/ bestaat en een SKILL.md bevat — dat is het bestand dat Claude Code bij het opstarten leest.
Dit is hetzelfde skill-laadpatroon dat ik behandelde in mijn gids over geavanceerde Claude Code skills, en het wordt het dominante integratiepatroon in het ecosysteem. Skills, niet MCP-servers, zijn waar de meeste waardevolle tooling in 2026 mee wordt geleverd.
Je Eerste Graph Bouwen
Nu het interessante deel. Vanuit de repo die je wilt indexeren, draai:
graphify build
Dat is alles. Standaardinstellingen geven je een werkende graph. Graphify scant de map, geeft codebestanden aan tree-sitter voor AST-extractie, geeft docs en andere bestanden aan je geconfigureerde LLM voor semantische extractie, draait Leiden-communitydetectie en schrijft de output naar een graphify-out/-directory.
Maar je zult bijna altijd bewuster willen zijn dan de standaarden. De flags waar ik het vaakst naar grijp:
--mode deep— draait een aggressievere semantische extractiepass over docs en commentaren. Kost meer tokens vooraf, vindt meer conceptuele edges (die welke niet in de AST verschijnen).--update— incrementele rebuild. Herverwerkt alleen bestanden waarvan de SHA256 is gewijzigd sinds de vorige run. Dit is de flag die je 95% van de tijd gebruikt na de initiële build.--cluster-only— draait Leiden-communitydetectie opnieuw op de bestaande graph zonder opnieuw te extraheren. Handig wanneer je nieuwe handmatige edges hebt toegevoegd of clusteringparameters hebt afgestemd en het effect wilt zien.--no-viz— slaat de interactieve HTML-output over. Snellere builds, slankere output. Gebruik wanneer je alleengraph.jsonnodig hebt voor een agent en de visualisatie niet wilt bekijken.--watch— houdt Graphify draaiend en herextraheert gewijzigde bestanden bij opslaan. Ik gebruik dit niet bij normale ontwikkeling omdat ik een stabiele graph wil, maar het is nuttig wanneer je actief de architectuur hervormt en de clustering in realtime wilt zien verschuiven.
Voor de agentschap-repo die ik noemde, was de eerste build een graphify build --mode deep en het duurde ongeveer twee minuten en veertig seconden op een codebase van tienduizend bestanden. De tokenkosten voor de LLM-gedreven semantische extractie waren bescheiden — minder dan een dollar API-uitgaven tegen Sonnet-prijzen — omdat tree-sitter het leeuwendeel van het structurele werk afhandelde zonder LLM-betrokkenheid. Volgende graphify build --update-runs na kleine commits waren klaar in minder dan vijftien seconden.
Een opmerking over extractiebereik. Graphify ondersteunt code-only, code+docs en volledig-multimodale modi (de multimodale modus reikt in PDF's, afbeeldingen en zelfs videotranscripten als je de optionele afhankelijkheden hebt geïnstalleerd). Voor een typische app-repo houd ik het op code+docs. De volledig multimodale modus is oprecht nuttig wanneer je docs/-map architectuurdiagrammen als PNG's bevat en je de visuele inhoud wilt extraheren — maar het kost tokens en tijd, dus zet het alleen aan wanneer je dat soort materiaal daadwerkelijk hebt.
Wat de Output Werkelijk Is
Wanneer graphify build klaar is, heb je een graphify-out/-directory met drie primaire bestanden die ertoe doen:
graph.html — een interactieve visualisatie die je in je browser opent. Nodes zijn geschaald naar community-lidmaatschap en connectiviteit. Edges zijn gekleurd naar relatietype. Je kunt filteren op community, bestandstype, relatietype en je kunt op elke node klikken om de buren te zien en de oorspronkelijke bron te lezen. Dit is het bestand dat je je team laat zien in een vergadering. Het is ook het bestand dat mijn circulaire afhankelijkheid aan het licht bracht — ik kon de lus letterlijk op het scherm zien getekend.
graph.json — de machineleesbare graph. Dit is wat je agent leest wanneer het vragen beantwoordt. Ongeveer twee megabyte voor een middelgrote repo. Gestructureerde nodes-en-edges JSON die elke tool kan parsen. Dit is het bestand dat het daadwerkelijke tokenbesparende werk doet.
GRAPH_REPORT.md — een auditrapport in gewoon Nederlands. Het somt je "god nodes" op (de sterk verbonden bestanden die alles raken — meestal een teken dat je een architecturele geur hebt), onverwachte links die de LLM opmerkte die niet in één enkel bestand voorkomen, en een set voorgestelde vragen die je aan de graph zou willen stellen. De eerste keer dat ik er een las, was het alsof ik de onboarding-notities van een senior engineer over mijn eigen codebase kreeg.
Er is ook een cache/-directory met SHA256-hashes per bestand. Zo weet --update welke bestanden daadwerkelijk zijn gewijzigd — het is een content-hash, geen timestamp, dus hernoemde-maar-ongewijzigde bestanden activeren geen herextractie.
Een Echte Query, met Echte Outputvorm
De schoonste manier om te laten zien hoe queries aanvoelen is er een uit te voeren. Vanaf de CLI:
graphify query "wat verbindt de auth-laag met de database?"
Of, als je de skill hebt geregistreerd, hetzelfde binnen Claude Code:
/graphify query "wat verbindt de auth-laag met de database?"
Wat terugkomt is een subgraph — een gestructureerd antwoord dat de relevante nodes opsomt (de auth-middleware, de gebruikerssessieservice, de connection pool, de gebruikersrepository) en de edges ertussen (welke functies welke aanroepen, welke modules welke importeren, welke docs naar welk concept verwijzen). Op een corpus van vijfhonderdduizend woorden retourneert zo'n query typisch een paar duizend tokens, terwijl het lezen van dezelfde bestanden rauw honderdduizenden tokens zou hebben gekost.
De twee andere commando's die het waard zijn om te onthouden:
graphify path "UserService" "DatabasePool"
Dat retourneert het kortste pad tussen twee benoemde entiteiten — de daadwerkelijke keten van functieaanroepen of module-imports die ze verbindt. Dit is de query die je gratis impactanalyse geeft. "Als ik UserService wijzig, via welke paden propageert die wijziging dan?" Drie commando's, één antwoord.
En:
graphify explain "RateLimiter"
Dat retourneert een samenvatting in gewone taal van een node — wat het doet, wat het aanroept, wat het aanroept, met welke concepten het geclusterd is in de Leiden-output. Het is de "wat is dit ding"-query. Het eerste dat ik draai wanneer ik in een onbekende repo word gedropt.
Er zijn rijkere querypatronen — buurtuitbreiding, community-scoped queries, semantisch zoeken over de docs-subgraph — en de README behandelt ze. Maar deze drie (query, path, explain) zijn degene die ik dagelijks gebruik.
Incrementele Updates: Houd de Graph Actueel
Het versheid-probleem is het voor de hand liggende bezwaar: "mijn code verandert elke dag, moet ik dit ding elke ochtend herbouwen?"
Nee. Je gaat draaien:
graphify build --update
…en het zal alleen de bestanden herextraheren waarvan de content-hash is gewijzigd sinds de laatste build, ze samenvoegen in de bestaande graph en opnieuw clusteren. Op een repo van tienduizend bestanden met een handvol gewijzigde bestanden duurt dit seconden, geen minuten.
Beter nog, Graphify kan git-hooks installeren die automatisch een incrementele update triggeren bij commit of checkout. Ik heb dit ingeschakeld op mijn belangrijkste werk-repo. Elke keer dat ik push, wordt de graph bijgewerkt. Elke keer dat ik van branch wissel, weerspiegelt de graph de structuur van de nieuwe branch. Ik denk niet meer na over versheid.
Als je mijn tokenoptimalisatiereeks hebt gevolgd, herken je dit patroon: laad het dure werk vooraf, cache het en grijp naar de cache tijdens interactieve sessies. Graphify is gewoon een ongewoon schone implementatie van dat idee.
Extensies die de Moeite Waard Zijn
Een paar extensie-flags duwen Graphify voorbij "code-intelligentietool" naar iets interessanters.
--obsidian genereert een complete Obsidian-vault vanuit je graph. Elke node wordt een markdown-notitie. Elke edge wordt een backlink. Je opent Obsidian, wijst het naar de gegenereerde vault, en je hebt een navigeerbare wiki van je codebase die elke keer wordt bijgewerkt wanneer je opnieuw extraheert. Dit is de workflow die direct aansluit bij Karpathy's LLM Wiki-idee — ik ging diep in op dat patroon in mijn Karpathy Obsidian RAG-analyse en Graphify is de schoonste implementatie ervan die ik heb gebruikt specifiek voor codebases.
--neo4j exporteert een cypher.txt-bestand dat je kunt afspelen in een Neo4j-instantie. Als je een RAG-pipeline bouwt die echte graphtraversal nodig heeft — multi-hop redenering, gewogen paden, echte Cypher-queries — dan is dit je brug. Bouw de graph met Graphify, sla hem op in Neo4j, bevraag hem vanuit je applicatie. Ik heb dit precies één keer gebruikt, voor een klant die een enterprise-grade graph-opslag nodig had, en het werkte bij de eerste poging.
--mcp start Graphify als een MCP stdio-server. Als je een opzet draait waarin meerdere agents dezelfde graph-index moeten delen, is MCP de juiste grens — je graph wordt een service en elke MCP-bewuste client kan hem bevragen. Ik behandelde de bredere MCP-vs-skills-spanning in mijn stuk over of MCP uitsterft; Graphify's MCP-modus is een van de gevallen waarin MCP nog steeds zinvol is, omdat de graph oprecht een gedeelde resource is.
De Obsidian-export is degene die mij het meest verraste. De graph wordt een navigeerbaar artefact — iets dat je leest, iets waarnaar je linkt, iets dat je commit naar een wiki-repo. Het is niet langer een tokenoptimalisatietactiek en wordt documentatie die zichzelf onderhoudt.
De Eerlijke Tokenberekening
Dit is het deel waar de meeste beschrijvingen stil worden. Laat me specifiek zijn.
Het grote getal in het marketingmateriaal is "71,5x minder tokens per query." Dat getal is echt — het komt van een benchmarkrun op een gemengd corpus dat PDF's, afbeeldingen en videotranscripten bevat. Multimodale corpora blazen het ruwe basislijntokenverbruik dramatisch op (je leest PDF's niet goedkoop; je betaalt om ze te converteren en reconverteren). De compressie die Graphify biedt op dat soort corpus is werkelijk enorm.
Op een pure code-repo — wat de meesten van jullie daadwerkelijk hebben — is de realistische compressie eerder 5x tot 10x voor typische "verken deze codebase"-queries. Dat is nog steeds aanzienlijk. Een query die vijftigduizend tokens aan ruwe bestandslezingen zou hebben gekost, kost misschien vijf- tot tienduizend tegen de graph. Over een werkdag is dat echt geld. Over een werkmaand op een betaald API-plan is het het verschil tussen op Sonnet blijven voor alles en je constant zorgen maken over Opus-kosten.
Maar de besparingen zijn niet uniform. Hier is waar Graphify werkelijk wint en waar niet.
Waar het groot wint: Inwerken in een repo die je nog nooit hebt gezien. Impactanalyse bij een refactor. Dwarsverbandvragen zoals "elke plek waar we Stripe aanroepen." Architectuurreview. Alles waarbij je structurele relaties probeert te begrijpen in plaats van specifieke code te lezen.
Waar het niet helpt: Nieuwe code schrijven. Bestaande functies wijzigen. Een specifieke foutmelding debuggen. Alles waarbij je de daadwerkelijke broninhoud nodig hebt, niet de structurele samenvatting. Voor die workflows moet je agent nog steeds ruwe bestanden lezen — de graph vertelt hem welke bestanden hij moet lezen, maar vervangt het lezen zelf niet.
Dit is het deel waarover ik duidelijk wil zijn, want ik zie mensen het oversellen. Graphify is geen vervanging voor je codebase. Het is een index over je codebase. Indexen zijn geweldig voor opzoeken. Ze zijn niet het ding dat je bewerkt. Behandel het dienovereenkomstig en je haalt er veel waarde uit. Behandel het als een wondermiddel en je zult verward zijn wanneer je refactorsessie toch tokens verbrandt.
Wat er Veranderde in Mijn Workflow
Na drie weken draaien op mijn eigen repo's en twee klant-codebases, hier is waar Graphify uiteindelijk terechtkwam in mijn daadwerkelijke gereedschapsgordel.
Inwerken in een nieuwe repo. Eerste commando op een verse clone is nu graphify build --mode deep. Binnen drie minuten heb ik een graph en een GRAPH_REPORT.md. Ik lees het rapport. Ik open de HTML. Ik vraag mijn agent /graphify explain voor de drie meest verbonden nodes. Aan het eind van vijftien minuten heb ik een beter mentaal model dan ik zou krijgen van een uur grep-gedreven verkenning. Deze enkele workflow heeft de tijd die ik besteedde aan het leren van Graphify al terugverdiend.
Cross-repo audits. Wanneer een klant vraagt "gebruikt dit ding eigenlijk de bibliotheek waarvoor we betalen?" — draai ik Graphify, bevraag de graph voor de hoofd-ingangspunten van de bibliotheek en lees het antwoord. Voorheen was dit een handmatige code-review van veertig minuten. Nu is het vijf minuten.
Impactanalyse vóór refactoring. Voordat ik een functie aanraak waarvan ik verwacht dat hij dragend is, draai ik graphify path "<functienaam>" "<ver-weg-ding>" om te zien wat van wat afhangt. De kortste-pad-output vangt de afhankelijkheden die ik gemist zou hebben.
Documentatieversheid. Ik genereer de Obsidian-vault vanuit de graph en commit hem. De docs zijn nu een afgeleide van de code, geen apart artefact dat afdrijft. Wanneer de code verandert, verandert de vault. Wanneer ik Obsidian open om een nieuw artikel te schrijven, kan ik direct backlinken naar de codebase-nodes die ik beschrijf.
Waar ik nog steeds grep gebruik. Wanneer ik precies weet wat ik zoek — een specifieke string, een foutmelding, een configuratiesleutel — is grep nog steeds sneller dan welke graph-query dan ook. Graphify verdient zijn plek bij vragen waar ik nog niet weet wat de juiste grep is. Het is de wat zou ik moeten zoeken-tool, niet de ik weet al wat ik zoek-tool.
Waar ik nog steeds een sub-agent gebruik. Wanneer de vraag open en creatief is — "is er een betere architectuur hiervoor?" — wint een plannings-sub-agent met een lang contextvenster nog steeds. Graphify geeft de sub-agent betere startcontext (kleiner, dichter, structureel bewust), maar het redeneren moet nog steeds op modelniveau gebeuren.
Deze combinatie — graph voor structuur, grep voor strings, sub-agents voor redeneren — heeft op een manier gecompoundeerd die ik niet verwachtte. Het zijn geen concurrerende tools. Het is een stack. De graph vertelt de sub-agent welke bestanden ertoe doen. Grep vertelt de agent waar in die bestanden hij moet kijken. De agent doet het denkwerk. Elke laag voedt de volgende.
Als je het bredere patroon rond het stapelen van tools als deze wilt, behandelt mijn Claude Code skills stack-walkthrough de meta-architectuur waar ik nu standaard naartoe ga.
Waar Graphify Faalt
Ik ben je de eerlijke lijst van faalmodi verschuldigd, want de gevallen die ik tegenkwam zijn niet theoretisch.
Heel kleine repo's hebben het niet nodig. Als je codebase comfortabel in Claude's contextvenster past, is het bouwen van een graph overkill. Het break-evenpunt in mijn tests lag ergens rond twintigduizend regels code of vijftig-plus markdowndocumenten. Kleiner dan dat en de bouwkosten wegen niet op tegen de querybesparingen.
Talen met zwakke tree-sitter-dekking. De structurele extractie is slechts zo goed als de tree-sitter-grammatica voor je taal. Gangbare talen — Python, TypeScript, JavaScript, Go, Rust, Java, PHP — zijn uitstekend. Exotischere talen kunnen dunnere graphs produceren, met minder aanroep-edges. Test met je stack voordat je erop vertrouwt.
Doc-zware repo's met ongestructureerde tekst. De LLM-extractie voor docs is gevoelig voor hoe de tekst is gestructureerd. Duidelijke koppen, heldere entiteitsnamen en consistente terminologie produceren geweldige graphs. Stroom-van-bewustzijn wikidumps produceren ruizigere. Dit is op te lossen — herstructureer de docs, draai opnieuw — maar het is geen magie.
Tokenkosten bij de initiële build voor zeer grote multimodale corpora. Als je Graphify richt op een map van vijftig gigabyte aan PDF's en video's, is de eerste build niet gratis. Het is eenmalig, maar het is niet gratis. Plan daarvoor. Voor pure code-repo's is dit geen probleem.
Semantische precisie is modelafhankelijk. De kwaliteit van de LLM-gedreven edges hangt af van welk model je hebt geconfigureerd. Claude Sonnet, GPT en Gemini produceren allemaal solide resultaten in mijn tests. Kleinere lokale modellen produceren dunnere, ruizigere graphs. Er zijn geen gepubliceerde precision-recall-benchmarks voor de semantische extractie — behandel de afgeleide edges als suggesties, niet als waarheid.
Geen van deze is een dealbreaker. Allemaal zijn ze het waard om te weten voordat je een workflow op de tool gokt.
Moet je Het Installeren?
Hier is mijn beslisboom, gedestilleerd uit drie weken dagelijks gebruik.
Installeer Graphify vandaag als: Je een Claude Code-, Codex- of Cursor-gebruiker bent. Je werkt aan codebases groter dan tienduizend regels. Je wordt regelmatig in onbekende repo's gedropt. Je ziet je tokenverbruik stijgen tijdens verkennssessies. Je onderhoudt een docs/-map die je graag door een LLM wilt laten lezen.
Wacht een paar releases als: Je alleen aan kleine projecten werkt. Je stack een nichetaal gebruikt met slechte tree-sitter-dekking. Je geen lokale Python 3.10+-omgeving hebt en die niet wilt opzetten.
Installeer het niet als: Je op zoek bent naar een magische refactortool. Graphify schrijft geen code. Het herstelt je architectuur niet. Het vertelt je wat je architectuur is — wat je met die informatie doet is nog steeds aan jou.
Voor mij is dit de schoonste implementatie van Karpathy's "de LLM is de programmeur, de wiki is de codebase"-idee die ik op echte code heb gebruikt (niet alleen notities). Het past natuurlijk bij de manier waarop ik Claude Code al gebruik, het overleeft dagelijks gebruik zonder kapot te gaan, en de onderhouder levert releases snel genoeg dat de gebreken die ik deze week zou noemen volgende week misschien al verholpen zijn.
De graph voor de repo waarmee ik dit artikel begon is nu naast de broncode gecommit. Elke PR herbouwt hem. Elk onboardingdocument verwijst ernaar. De "hoe ziet deze codebase er eigenlijk uit"-vraag die een uur kostte, kost nu negentig seconden. Dat is de workflowverschuiving, en het is de reden dat ik over Graphify schrijf in plaats van door te scrollen naar het volgende glimmende ding in mijn feed.
Als je maar één ding doet na het lezen hiervan: open een terminal, draai uv tool install graphifyy, dan graphify install, dan graphify build in de repo die je stilletjes hebt vermeden. De graph die het bouwt zal je waarschijnlijk verrassen — en misschien in verlegenheid brengen, op de meest nuttige manier. Dat is het doel.
Veelgestelde Vragen
Wat doet Graphify precies?
Graphify zet een map met code, docs en andere bestanden om in een bevraagbare knowledge graph zodat je AI-assistent vragen over de structuur kan beantwoorden zonder ruwe bronbestanden opnieuw te lezen. Het gebruikt tree-sitter voor deterministische code-parsing en een LLM voor semantische extractie over docs, clustert vervolgens het resultaat met Leiden-communitydetectie. De output is een graph.json die je agent bevraagt in plaats van je codebase te doorzoeken.
Hoe installeer je Graphify op Claude Code?
Draai uv tool install graphifyy (of pipx install graphifyy) om de CLI te installeren, dan graphify install om het als Claude Code skill te registreren. Het install-commando schrijft het skill-manifest naar ~/.claude/skills/graphify/ en werkt CLAUDE.md bij zodat Claude Code naar de graph grijpt voordat het ruwe bestanden doorleest. Totale installatietijd is minder dan een minuut op een moderne machine.
Is de 70x tokenreductie echt?
Het getal van 71,5x is echt maar corpusafhankelijk — het komt van een gemengde multimodale benchmark waarbij PDF's en afbeeldingen de ruwe basislijn opblazen. Op pure code-repo's kun je ruwweg 5x tot 10x tokencompressie verwachten bij structurele queries. Dat is nog steeds aanzienlijk, maar het is niet het kopcijfer. De besparingen concentreren zich in verkennings- en inwerkworkflows, niet bij het schrijven van code.
Vervangt Graphify grep of vector search?
Nee — het is complementair. Graphify wint bij structurele vragen ("wat roept wat aan", "kortste pad tussen twee modules"). Grep wint nog steeds wanneer je de exacte string weet waarnaar je zoekt. Vector search wint nog steeds voor fuzzy semantische gelijkenis over lange tekst. De sterkste opzet stapelt alle drie, met de graph als de structurele indexlaag.
Kan de graph actueel blijven terwijl code verandert?
Ja. Draai graphify build --update om alleen gewijzigde bestanden te herextraheren (gedetecteerd via SHA256-hashes) en samen te voegen in de bestaande graph. Je kunt ook git-hooks installeren die automatisch een incrementele update triggeren bij commit of checkout, zodat de graph in sync blijft met je repo zonder handmatige tussenkomst.
Laten We Samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows of het opschalen van je tech-infrastructuur? Ik help je graag.
- Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
