Graphify im Test: Ein Knowledge-Graph-Index für Claude Code
Ich hätte Graphify beinahe als ein weiteres npx-Spielzeug abgetan.
Das Versprechen klang zu glatt: „Richte es auf einen beliebigen Ordner, bekomme einen Knowledge Graph, frage den Graphen statt Dateien erneut zu lesen, und beobachte wie dein Token-Verbrauch zusammenbricht." Ich reagiere instinktiv skeptisch auf alles, was eine Kostenreduktion um eine Größenordnung mit einem einzigen Befehl verspricht. Meistens stimmt die Rechnung für die Demo und fällt bei einer echten Codebase auseinander.
Dann habe ich es auf einem Projekt laufen lassen, mit dem ich seit einem Monat kämpfte — ein Agentur-Repository mit sieben App-Modulen, einem Gewirr aus geteilten Services und einem docs/-Ordner, den ich stillschweigend gemieden hatte. Der erste Build dauerte auf meinem MacBook weniger als drei Minuten. Der Graph, den es ausspuckte, erzählte mir etwas über meine eigene Architektur, das ich ein halbes Jahr lang übersehen hatte — eine zirkuläre Abhängigkeit zwischen der Abrechnungslogik und einem Benachrichtigungsdienst, die voneinander nichts wissen sollten.
Das war der Moment, in dem ich aufhörte, Graphify als Token-Spar-Gimmick zu behandeln, und begann, es als Code-Review-Tool zu betrachten, das nebenbei auch noch Tokens spart.
Dieser Beitrag fasst zusammen, was ich beim Einsatz auf drei echten Codebases gelernt habe — was es tatsächlich tut, wie die Installation wirklich aussieht, wo die Token-Rechnung ehrlich ist, wo sie Marketing ist und welche Workflows es für mich verändert hat. Ein ehrlicher Bericht, keine Pressemitteilung. Wenn du ein Claude Code-Nutzer bist, der ständig beobachtet, wie /cost jedes Mal steigt, wenn du nach einem unbekannten Repository fragst, könnten die nächsten zwanzig Minuten das Nützlichste sein, was du diese Woche liest.
Das Problem, das Graphify tatsächlich löst
So sieht der Workflow aus, in dem die meisten von uns feststecken.
Du öffnest Claude Code in einem Repository, das du nicht auswendig kennst. Du stellst eine Frage — „Wo wird diese user_id validiert?" oder „Welche Services berühren das Abrechnungsmodul?" oder einfach „Erkläre mir, wie diese App aufgebaut ist." Claude beginnt, Dateien zu lesen. Es liest die genannte Datei. Dann die Datei, die diese Datei importiert. Dann die Datei, die die Datei importiert, die die Datei importiert. Zwanzig Tool-Aufrufe später hast du eine Antwort und ein Kontextfenster, das zu 70% voll ist, bevor du eine einzige Zeile Code geschrieben hast.
Das ist die Token-Steuer. Jede Konversation zahlt sie. Jedes Mal, wenn du eine neue Sitzung startest, zahlst du sie erneut. Jedes Mal, wenn du den Kontext komprimierst, zahlst du sie erneut. Die Codebase ändert sich zwischen Dienstag und Donnerstag nicht, aber dein Agent liest sie jedes Mal von Grund auf neu.
Semantische Suche — grep, ripgrep, Vektor-Embeddings — kratzt am Problem, löst es aber nicht. grep findet Zeichenketten, keine Konzepte. Embeddings finden Absätze, die deiner Anfrage ähnlich sehen, nicht die strukturellen Beziehungen, die dein Code tatsächlich hat. Keines von beiden erfasst die Antwort auf „Welche Funktionen ruft RateLimiter letztendlich auf, drei Ebenen tief?" — weil diese Antwort nicht in einer einzelnen Datei steckt. Sie lebt im Graphen zwischen den Dateien.
Graphifys Wette ist, dass du diesen Graphen einmal bauen, neben deinem Repository speichern und deinen Agenten den Graphen abfragen lassen solltest, anstatt jedes Mal den Quellcode zu durchforsten. Der Graph ist ungefähr zwei Megabyte JSON. Dein Quellordner kann Hunderte von Megabytes umfassen. Der Agent liest den Graphen und greift nur dann auf Rohdateien zu, wenn er tatsächlich Code schreiben oder ändern muss.
Wenn du bereits KI-gestützte Recherche auf großen Codebases durchführst, weißt du bereits, warum diese Wette interessant ist. Der Rest dieses Beitrags dreht sich darum, ob sie sich in der Praxis auszahlt.
Die Kernidee: Ein Graph als Index
Bevor wir zur Installationsanleitung kommen, möchte ich sicherstellen, dass du das richtige mentale Modell hast. Die meisten Beiträge über Graphify überspringen diesen Teil, und es ist genau der Teil, der bestimmt, ob das Tool für dein Repository nützlich sein wird.
Ein Knowledge Graph besteht aus zwei Dingen: Knoten (die Entitäten — Funktionen, Klassen, Module, Dokumentationsabschnitte, Konzepte) und Kanten (die Beziehungen — ruft auf, importiert, erbt von, hängt ab von, referenziert, ist ähnlich zu). Graphify erstellt beides: deterministisch für Code und semantisch für Dokumentation.
Für Code nutzt es tree-sitter, um deinen Quellcode in ASTs zu parsen und die strukturellen Beziehungen zu extrahieren, ohne jemals einen Token an ein LLM zu senden. Dieser Teil ist schnell, kostenlos und exakt. Tree-sitter weiß, dass Funktion A Funktion B aufruft, weil die Syntax es sagt — keine Inferenz erforderlich.
Für Dokumentation, PDFs, Markdown und Bilder nutzt Graphify ein LLM (deine Wahl — Claude, GPT, Gemini, Kimi, DeepSeek, lokales Ollama), um Entitäten zu extrahieren und Beziehungen abzuleiten. Dieser Teil ist langsamer und kostet vorab Tokens — einmalig während des Builds. Danach bleibt der Graph bestehen. Du zahlst die Extraktionskosten einmal und amortisierst sie über Wochen bei jeder Abfrage.
Dann führt es Leiden Community Detection auf dem kombinierten Graphen aus. Leiden ist ein Clustering-Algorithmus, der dicht verbundene Knoten zu Communities gruppiert — im Grunde fragt er: „Welche Teile dieses Graphen gehören zusammen?" Das Ergebnis ist die natürliche Modulstruktur deines Repositories, abgeleitet davon, wie der Code tatsächlich verbunden ist, nicht davon, wie die Ordner zufällig organisiert sind. Manchmal stimmen diese beiden Strukturen überein. Manchmal widersprechen sie sich heftig, und dieser Widerspruch ist das interessanteste Signal im gesamten Build.
Wenn du den Graphen abfragst, traversiert dein Agent Kanten, anstatt Quelldateien zu lesen. „Zeig mir den Auth-Flow" wird zu einer Graph-Traversierung, die vielleicht dreitausend Tokens an strukturierten Knoten und Kanten zurückgibt, anstatt fünfzigtausend Tokens an rohem Quellcode. Das ist die Kompression. Da liegen die Einsparungen.
Der Haken — und wir kommen darauf zurück — ist, dass Graph-Abfragen großartig zum Lesen deiner Codebase sind und schlecht zum Schreiben. Wenn du Code ändern musst, brauchst du immer noch die Rohdatei. Graphify ersetzt nicht deinen Quellordner; es ersetzt deine Erkundung deines Quellordners.
Installation: Wie es 2026 wirklich aussieht
Das Repository befindet sich unter github.com/safishamsi/graphify. Es gibt eine Besonderheit, die man vorab kennen sollte: Der PyPI-Paketname ist graphifyy mit Doppel-y, während der ursprüngliche Name zurückgewonnen wird, aber der CLI-Befehl ist weiterhin graphify. Die README erklärt das offen — lass dich davon nicht verwirren.
Graphify benötigt Python 3.10 oder neuer. Wenn du bereits auf einem modernen Stack bist, ist alles in Ordnung. Wenn du noch auf 3.9 bist, ist das dein Anstoß zum Upgrade.
Ich installiere Python-Tools heutzutage mit uv, weil es das einzige Python-Tooling ist, das mich nicht dazu verleitet, alles in Rust zu schreiben. Der einzelne Befehl, der dir eine funktionierende Installation liefert, ist:
uv tool install graphifyy
Das setzt graphify automatisch auf deinen PATH — kein Venv-Jonglieren, keine pipx-Zeremonien. Wenn du pipx bevorzugst, funktioniert das auch:
pipx install graphifyy
Und wenn du ein Masochist bist und reines pip willst:
pip install graphifyy
…musst du sicherstellen, dass ~/.local/bin (Linux) oder ~/Library/Python/3.x/bin (Mac) auf deinem PATH ist, oder es als python -m graphify aufrufen. Ich empfehle uv oder pipx — es gibt keinen Vorteil, für ein CLI-Tool mit PATH zu kämpfen.
Prüfe, ob es da ist:
graphify --version
Wenn du einen Versionsstring zurückbekommst, bist du mit der Installation fertig. Gesamtzeit auf meinem Rechner: unter dreißig Sekunden.
Graphify als Claude Code Skill registrieren
Das ist der Teil, der Graphify innerhalb deines Agenten tatsächlich nützlich macht. Das CLI ist in Ordnung. Die Skill-Registrierung ist der Moment, in dem Claude Code aufhört, dich aufzufordern, graphify manuell auszuführen, und anfängt, es selbst zu nutzen, wenn es ein Repository erkunden muss.
Führe aus:
graphify install
Dieser einzelne Befehl macht drei Dinge. Er kopiert das plattformspezifische Skill-Manifest in ~/.claude/skills/graphify/, damit Claude Code es entdecken kann. Er aktualisiert (oder erstellt) deine Projekt-CLAUDE.md mit Anweisungen für den Assistenten, graphify query zu nutzen, bevor er auf das Lesen von Rohdateien zurückfällt. Und er registriert die Slash-Befehle — /graphify query, /graphify path, /graphify explain — die du direkt aufrufen wirst, wenn du die Abfragen selbst steuern willst.
Wenn du Codex, OpenCode, Cursor, Gemini CLI oder einen der zehn weiteren Assistenten verwendest, die Graphify unterstützt, erkennt derselbe Befehl graphify install die meisten davon automatisch und schreibt das richtige Manifest an die richtige Stelle. Die README enthält eine vollständige Matrix. Wenn du auf Windows bist oder explizit sein willst, kannst du --platform claude oder --platform codex übergeben und das Ziel erzwingen.
Nach dem Ausführen von graphify install ist der richtige Funktionstest, Claude Code zu öffnen, / einzugeben und nach den graphify-Befehlen in der Auswahl zu suchen. Wenn sie dort sind, hat sich der Skill korrekt registriert. Wenn nicht, prüfe, ob ~/.claude/skills/graphify/ existiert und eine SKILL.md enthält — das ist die Datei, die Claude Code beim Start liest.
Das ist dasselbe Skill-Lademuster, das ich in meinem Leitfaden zu fortgeschrittenen Claude Code Skills behandelt habe, und es wird zum dominierenden Integrationsmuster im Ökosystem. Skills, nicht MCP-Server, sind das, womit die meisten wertvollen Tools 2026 ausgeliefert werden.
Deinen ersten Graphen erstellen
Jetzt kommt der interessante Teil. Führe innerhalb des Repositories, das du indexieren willst, aus:
graphify build
Das war's. Die Standardeinstellungen liefern dir einen funktionierenden Graphen. Graphify scannt den Ordner, übergibt Code-Dateien an tree-sitter zur AST-Extraktion, übergibt Dokumentations- und andere Dateien an dein konfiguriertes LLM zur semantischen Extraktion, führt Leiden Community Detection aus und schreibt das Ergebnis in ein graphify-out/-Verzeichnis.
Aber du wirst fast immer überlegter vorgehen wollen als die Standardeinstellungen. Die Flags, die ich am häufigsten verwende:
--mode deep— führt eine aggressivere semantische Extraktionsrunde über Dokumentation und Kommentare durch. Kostet vorab mehr Tokens, findet aber mehr konzeptuelle Kanten (die, die nicht im AST auftauchen).--update— inkrementeller Rebuild. Verarbeitet nur Dateien neu, deren SHA256 sich seit dem letzten Lauf geändert hat. Das ist das Flag, das du nach dem initialen Build zu 95% der Zeit verwenden wirst.--cluster-only— führt Leiden Community Detection auf dem bestehenden Graphen erneut aus, ohne etwas neu zu extrahieren. Nützlich, wenn du neue manuelle Kanten hinzugefügt oder Clustering-Parameter angepasst hast und den Effekt sehen willst.--no-viz— überspringt die interaktive HTML-Ausgabe. Schnellere Builds, schlankere Ausgabe. Verwende es, wenn du nurgraph.jsonfür einen Agenten brauchst und die Visualisierung nicht ansehen willst.--watch— hält Graphify laufend und extrahiert geänderte Dateien beim Speichern neu. Ich nutze das in der normalen Entwicklung nicht, weil ich einen stabilen Graphen will, aber es ist nützlich, wenn du aktiv die Architektur umgestaltest und das Clustering in Echtzeit verschieben sehen willst.
Für das Agentur-Repository, das ich erwähnt habe, war der erste Build ein graphify build --mode deep und dauerte etwa zwei Minuten und vierzig Sekunden bei einer zehntausend-Dateien-Codebase. Die Token-Kosten für die LLM-gesteuerte semantische Extraktion waren moderat — unter einem Dollar an API-Ausgaben zum Sonnet-Preis — weil tree-sitter den Großteil der strukturellen Arbeit ohne LLM-Beteiligung erledigte. Nachfolgende graphify build --update-Läufe nach kleinen Commits waren in unter fünfzehn Sekunden fertig.
Ein Hinweis zum Extraktionsumfang. Graphify unterstützt Nur-Code-, Code+Doku- und voll-multimodale Modi (der multimodale Modus greift auf PDFs, Bilder und sogar Video-Transkripte zu, wenn du die optionalen Abhängigkeiten installiert hast). Für ein typisches App-Repository halte ich es bei Code+Doku. Der voll-multimodale Modus ist wirklich nützlich, wenn dein docs/-Ordner Architekturdiagramme als PNGs enthält und du den visuellen Inhalt extrahieren willst — aber er kostet Tokens und Zeit, also schalte ihn nur ein, wenn du tatsächlich solches Material hast.
Was die Ausgabe wirklich ist
Wenn graphify build fertig ist, hast du ein graphify-out/-Verzeichnis mit drei wichtigen Dateien:
graph.html — eine interaktive Visualisierung, die du im Browser öffnest. Knoten sind nach Community-Zugehörigkeit und Konnektivität dimensioniert. Kanten sind nach Beziehungstyp eingefärbt. Du kannst nach Community, Dateityp, Beziehungstyp filtern und jeden Knoten anklicken, um seine Nachbarn zu sehen und den Originalquelltext zu lesen. Das ist die Datei, die du deinem Team in einem Meeting zeigst. Es ist auch die Datei, die meine zirkuläre Abhängigkeit aufgedeckt hat — ich konnte die Schleife buchstäblich auf dem Bildschirm gezeichnet sehen.
graph.json — der maschinenlesbare Graph. Das ist es, was dein Agent liest, wenn er Fragen beantwortet. Etwa zwei Megabyte für ein mittelgroßes Repository. Strukturiertes Knoten-und-Kanten-JSON, das jedes Tool parsen kann. Das ist die Datei, die die eigentliche Token-Einsparungsarbeit leistet.
GRAPH_REPORT.md — ein Audit-Bericht in Klartext. Er listet deine „Gott-Knoten" auf (die hochvernetzen Dateien, die alles berühren — meist ein Zeichen für einen Architektur-Geruch), unerwartete Verbindungen, die das LLM bemerkt hat und die in keiner einzelnen Datei erscheinen, sowie eine Reihe vorgeschlagener Fragen, die du den Graphen stellen könntest. Als ich zum ersten Mal einen dieser Berichte las, war es, als bekäme ich die Onboarding-Notizen eines Senior-Ingenieurs zu meiner eigenen Codebase.
Es gibt auch ein cache/-Verzeichnis mit SHA256-Hashes pro Datei. So weiß --update, welche Dateien sich tatsächlich geändert haben — es ist ein Inhalts-Hash, kein Zeitstempel, sodass umbenannte-aber-unveränderte Dateien keine Neuextraktion auslösen.
Eine echte Abfrage mit echtem Ausgabeformat
Der sauberste Weg, um zu zeigen, wie sich Abfragen anfühlen, ist eine auszuführen. Vom CLI aus:
graphify query "Was verbindet die Auth-Schicht mit der Datenbank?"
Oder, wenn du den Skill registriert hast, dasselbe innerhalb von Claude Code:
/graphify query "Was verbindet die Auth-Schicht mit der Datenbank?"
Was zurückkommt, ist ein Teilgraph — eine strukturierte Antwort, die die relevanten Knoten (die Auth-Middleware, den User-Session-Service, den Connection Pool, das User-Repository) und die Kanten zwischen ihnen auflistet (welche Funktionen welche aufrufen, welche Module welche importieren, welche Dokumentation welches Konzept referenziert). Bei einem fünfhunderttausend-Wörter-Corpus gibt eine solche Abfrage typischerweise ein paar tausend Tokens zurück, während das Lesen derselben Dateien im Rohformat Hunderttausende gekostet hätte.
Die zwei anderen Befehle, die es sich zu merken lohnt:
graphify path "UserService" "DatabasePool"
Das gibt den kürzesten Pfad zwischen zwei benannten Entitäten zurück — die tatsächliche Kette von Funktionsaufrufen oder Modul-Imports, die sie verbindet. Das ist die Abfrage, die dir Impact-Analysen gratis liefert. „Wenn ich UserService ändere, welche Pfade propagiert diese Änderung?" Drei Befehle, eine Antwort.
Und:
graphify explain "RateLimiter"
Das gibt eine Zusammenfassung eines Knotens in Klartext zurück — was er tut, was ihn aufruft, was er aufruft, mit welchen Konzepten er im Leiden-Output geclustert ist. Es ist die „Was ist dieses Ding"-Abfrage. Das Erste, was ich ausführe, wenn ich in ein unbekanntes Repository geworfen werde.
Es gibt reichhaltigere Abfragemuster — Nachbarschaftserweiterung, Community-bezogene Abfragen, semantische Suche über den Doku-Teilgraph — und die README führt durch sie. Aber diese drei (query, path, explain) sind die, die ich täglich verwende.
Inkrementelle Updates: Den Graphen aktuell halten
Das Aktualitätsproblem ist der offensichtliche Einwand: „Mein Code ändert sich jeden Tag, muss ich das Ding jeden Morgen neu bauen?"
Nein. Du wirst Folgendes ausführen:
graphify build --update
…und es wird nur die Dateien neu extrahieren, deren Inhalts-Hash sich seit dem letzten Build geändert hat, sie in den bestehenden Graphen einmergen und das Clustering erneut ausführen. Bei einem zehntausend-Dateien-Repository mit einer Handvoll geänderter Dateien dauert das Sekunden, nicht Minuten.
Noch besser: Graphify kann Git-Hooks installieren, die ein inkrementelles Update automatisch bei Commit oder Checkout auslösen. Ich habe das in meinem Haupt-Arbeitsrepository aktiviert. Jedes Mal, wenn ich pushe, aktualisiert sich der Graph. Jedes Mal, wenn ich den Branch wechsle, spiegelt der Graph die Struktur des neuen Branches wider. Ich denke nicht mehr über Aktualität nach.
Wenn du meine Token-Optimierungsserie verfolgt hast, wirst du dieses Muster erkennen: die teure Arbeit vorab erledigen, sie cachen und während interaktiver Sitzungen auf den Cache zugreifen. Graphify ist einfach eine ungewöhnlich saubere Implementierung dieser Idee.
Erweiterungen, die man kennen sollte
Einige Erweiterungsflags bringen Graphify über ein „Code-Intelligence-Tool" hinaus und machen es zu etwas Interessanterem.
--obsidian generiert einen vollständigen Obsidian-Vault aus deinem Graphen. Jeder Knoten wird zu einer Markdown-Notiz. Jede Kante wird zu einem Backlink. Du öffnest Obsidian, richtest es auf den generierten Vault, und du hast ein navigierbares Wiki deiner Codebase, das sich bei jeder Neuextraktion aktualisiert. Das ist der Workflow, der direkt auf Karpathys LLM-Wiki-Idee abbildet — ich bin tief in dieses Muster in meinem Karpathy Obsidian RAG-Breakdown eingetaucht, und Graphify ist die sauberste Implementierung davon, die ich speziell für Codebases verwendet habe.
--neo4j exportiert eine cypher.txt-Datei, die du in eine Neo4j-Instanz einspielen kannst. Wenn du eine RAG-Pipeline baust, die echte Graph-Traversierung benötigt — Multi-Hop-Reasoning, gewichtete Pfade, echte Cypher-Abfragen — ist das deine Brücke. Baue den Graphen mit Graphify, persistiere ihn in Neo4j, frage ihn von deiner Anwendung ab. Ich habe das genau einmal verwendet, für einen Kunden, der einen Enterprise-Grade Graph Store brauchte, und es funktionierte beim ersten Versuch.
--mcp startet Graphify als MCP-Stdio-Server. Wenn du ein Setup betreibst, in dem mehrere Agenten denselben Graph-Index teilen müssen, ist MCP die richtige Grenze — dein Graph wird zu einem Service, und jeder MCP-fähige Client kann ihn abfragen. Ich habe die breitere MCP-vs-Skills-Spannung in meinem Beitrag darüber, ob MCP ausstirbt behandelt; Graphifys MCP-Modus ist einer der Fälle, in denen MCP immer noch Sinn ergibt, weil der Graph tatsächlich eine geteilte Ressource ist.
Der Obsidian-Export hat mich am meisten überrascht. Der Graph wird zu einem navigierbaren Artefakt — etwas, das man liest, auf das man verlinkt, das man in ein Wiki-Repository committet. Er hört auf, eine Token-Optimierungstaktik zu sein, und wird zu Dokumentation, die sich selbst wartet.
Die ehrliche Token-Rechnung
Das ist der Teil, an dem die meisten Berichte verstummen. Lass mich konkret werden.
Die große Zahl, die im Marketingmaterial kursiert, ist „71,5-mal weniger Tokens pro Abfrage." Diese Zahl ist real — sie stammt aus einem Benchmark-Lauf auf einem gemischten Corpus, der PDFs, Bilder und Video-Transkripte enthält. Multimodale Corpora treiben die Roh-Baseline-Token-Zahl dramatisch in die Höhe (PDFs liest man nicht günstig; man zahlt für die Konvertierung und Rekonvertierung). Die Kompression, die Graphify auf diese Art von Corpus bietet, ist tatsächlich enorm.
Bei einem reinen Code-Repository — was die meisten von euch tatsächlich haben — liegt die realistische Kompression eher bei 5x bis 10x für typische „Erkunde diese Codebase"-Abfragen. Das ist immer noch erheblich. Eine Abfrage, die fünfzigtausend Tokens an Rohdatei-Reads verbraucht hätte, könnte gegen den Graphen fünf- bis zehntausend verbrauchen. Über einen Arbeitstag hinweg ist das echtes Geld. Über einen Arbeitsmonat bei einem kostenpflichtigen API-Plan ist es der Unterschied zwischen dem Bleiben auf Sonnet für alles und dem ständigen Sorgen um Opus-Kosten.
Aber die Einsparungen sind nicht gleichmäßig verteilt. Hier ist, wo Graphify wirklich gewinnt und wo nicht.
Wo es groß gewinnt: Onboarding in ein Repository, das du noch nie gesehen hast. Impact-Analyse bei einem Refactoring. Querschnittsfragen wie „jede Stelle, an der wir Stripe aufrufen." Architektur-Review. Alles, wo du versuchst, strukturelle Beziehungen zu verstehen, anstatt spezifischen Code zu lesen.
Wo es nicht hilft: Neuen Code schreiben. Bestehende Funktionen ändern. Einen spezifischen Fehler debuggen. Alles, wo du den eigentlichen Quellinhalt brauchst, nicht die strukturelle Zusammenfassung. Für diese Workflows muss dein Agent immer noch Rohdateien lesen — der Graph sagt ihm welche Dateien er lesen soll, ersetzt aber nicht das Lesen selbst.
Das ist der Teil, bei dem ich laut sein möchte, weil ich sehe, wie Leute es übertreiben. Graphify ist kein Ersatz für deine Codebase. Es ist ein Index über deine Codebase. Indizes sind großartig für Nachschlagen. Sie sind nicht das, was du bearbeitest. Behandle es entsprechend und du wirst viel Wert daraus ziehen. Behandle es als Wundermittel und du wirst verwirrt sein, wenn deine Refactoring-Sitzung immer noch Tokens verbrennt.
Was sich in meinem Workflow geändert hat
Nach drei Wochen Einsatz auf meinen eigenen Repositories und zwei Kunden-Codebases ist hier, wo Graphify in meinem tatsächlichen Werkzeugkasten gelandet ist.
Onboarding in ein neues Repository. Der erste Befehl bei einem frischen Clone ist jetzt graphify build --mode deep. Innerhalb von drei Minuten habe ich einen Graphen und einen GRAPH_REPORT.md. Ich lese den Bericht. Ich öffne das HTML. Ich bitte meinen Agenten /graphify explain für die drei am stärksten verbundenen Knoten. Am Ende von fünfzehn Minuten habe ich ein besseres mentales Modell, als ich in einer Stunde grep-getriebener Erkundung bekommen würde. Allein dieser Workflow hat die Zeit, die ich investiert habe, Graphify zu lernen, bereits zurückgezahlt.
Cross-Repository-Audits. Wenn ein Kunde fragt „Nutzt dieses Ding tatsächlich die Bibliothek, für die wir bezahlen?" — führe ich Graphify aus, frage den Graphen nach den Haupteinstiegspunkten der Bibliothek und lese die Antwort. Vorher war das ein vierzigminütiges manuelles Code-Review. Jetzt sind es fünf Minuten.
Impact-Analyse vor dem Refactoring. Bevor ich eine Funktion anfasse, von der ich erwarte, dass sie tragend ist, führe ich graphify path "<funktionsname>" "<entferntes-ding>" aus, um zu sehen, was wovon abhängt. Die Kürzester-Pfad-Ausgabe fängt die Abhängigkeiten auf, die ich übersehen hätte.
Dokumentationsaktualität. Ich generiere den Obsidian-Vault aus dem Graphen und committe ihn. Die Doku ist jetzt ein Derivat des Codes, kein separates Artefakt, das abdriftet. Wenn sich der Code ändert, ändert sich der Vault. Wenn ich Obsidian öffne, um einen neuen Artikel zu schreiben, kann ich direkt zu den Codebase-Knoten verlinken, die ich beschreibe.
Wo ich immer noch nach grep greife. Wenn ich genau weiß, wonach ich suche — einen bestimmten String, eine Fehlermeldung, einen Config-Key — ist grep immer noch schneller als jede Graph-Abfrage. Graphify verdient seinen Platz bei Fragen, bei denen ich noch nicht weiß, was ich grepen soll. Es ist das Was sollte ich suchen-Tool, nicht das Ich weiß schon, was ich suche-Tool.
Wo ich immer noch nach einem Sub-Agenten greife. Wenn die Frage offen und kreativ ist — „Gibt es eine bessere Architektur dafür?" — gewinnt immer noch ein Planungs-Sub-Agent mit einem langen Kontextfenster. Graphify gibt dem Sub-Agenten besseren Startkontext (kleiner, dichter, strukturbewusst), aber das Reasoning muss immer noch auf der Modellebene stattfinden.
Diese Kombination — Graph für Struktur, grep für Strings, Sub-Agenten für Reasoning — hat sich auf eine Weise potenziert, die ich nicht erwartet hatte. Sie sind keine konkurrierenden Tools. Sie sind ein Stack. Der Graph sagt dem Sub-Agenten, welche Dateien wichtig sind. Grep sagt dem Agenten, wo in diesen Dateien er schauen soll. Der Agent macht das Denken. Jede Schicht speist die nächste.
Wenn du das breitere Muster rund um das Stapeln von Tools wie diesen kennenlernen willst, behandelt mein Claude Code Skills Stack Walkthrough die Meta-Architektur, die ich jetzt standardmäßig verwende.
Wo Graphify versagt
Ich schulde dir die ehrliche Liste der Fehlermodi, denn die, die ich erlebt habe, sind nicht theoretisch.
Sehr kleine Repositories brauchen es nicht. Wenn deine Codebase bequem in Claudes Kontextfenster passt, ist das Erstellen eines Graphen übertrieben. Der Break-Even-Punkt in meinen Tests lag irgendwo bei zwanzigtausend Zeilen Code oder fünfzig-plus Markdown-Dokumenten. Kleiner als das überwiegen die Build-Kosten die Abfrage-Einsparungen.
Sprachen mit schwacher tree-sitter-Abdeckung. Die strukturelle Extraktion ist nur so gut wie die tree-sitter-Grammatik für deine Sprache. Mainstream-Sprachen — Python, TypeScript, JavaScript, Go, Rust, Java, PHP — sind ausgezeichnet. Exotischere Sprachen können dünnere Graphen produzieren, mit weniger erfassten Aufruf-Kanten. Teste mit deinem Stack, bevor du dich darauf verlässt.
Doku-lastige Repositories mit unstrukturierter Prosa. Die LLM-Extraktion für Dokumentation ist empfindlich gegenüber der Strukturierung der Prosa. Saubere Überschriften, klare Entitätsnamen und konsistente Terminologie produzieren großartige Graphen. Stream-of-Consciousness-Wiki-Dumps produzieren rauschigere. Das ist behebbar — strukturiere die Doku um, führe es erneut aus — aber es ist keine Magie.
Token-Kosten beim initialen Build für sehr große multimodale Corpora. Wenn du Graphify auf einen fünfzig-Gigabyte-Ordner mit PDFs und Videos richtest, wird der erste Build nicht kostenlos sein. Er ist einmalig, aber nicht kostenlos. Plane dafür. Für reine Code-Repositories ist das kein Problem.
Semantische Präzision ist modellabhängig. Die Qualität der LLM-gesteuerten Kanten hängt davon ab, welches Modell du konfiguriert hast. Claude Sonnet, GPT und Gemini produzieren in meinen Tests alle solide Ergebnisse. Kleinere lokale Modelle produzieren dünnere, rauschigere Graphen. Es gibt keine veröffentlichten Precision-Recall-Benchmarks für die semantische Extraktion — behandle die abgeleiteten Kanten als Vorschläge, nicht als Grundwahrheit.
Keines davon ist ein K.O.-Kriterium. Aber alle sind wissenswert, bevor du einen Workflow auf das Tool setzt.
Solltest du es installieren?
Hier ist mein Entscheidungsbaum, destilliert aus drei Wochen täglicher Nutzung.
Installiere Graphify heute, wenn: Du ein Claude Code-, Codex- oder Cursor-Nutzer bist. Du an Codebases arbeitest, die größer als zehntausend Zeilen sind. Du häufig in unbekannte Repositories geworfen wirst. Du beobachtest, wie dein Token-Verbrauch während Erkundungssitzungen steigt. Du einen docs/-Ordner pflegst, den ein LLM tatsächlich lesen soll.
Warte ein paar Releases, wenn: Du nur an kleinen Projekten arbeitest. Dein Stack eine Nischensprache mit schwacher tree-sitter-Abdeckung verwendet. Du keine lokale Python 3.10+-Umgebung hast und keine einrichten willst.
Installiere es nicht, wenn: Du nach einem magischen Refactoring-Tool suchst. Graphify schreibt keinen Code. Es repariert deine Architektur nicht. Es sagt dir, was deine Architektur ist — was du mit dieser Information machst, liegt immer noch bei dir.
Für mich ist das die sauberste Implementierung von Karpathys „Das LLM ist der Programmierer, das Wiki ist die Codebase"-Idee, die ich auf echtem Code verwendet habe (nicht nur auf Notizen). Es passt natürlich zur Art, wie ich Claude Code bereits nutze, es überlebt den täglichen Einsatz ohne Ausfälle, und der Maintainer liefert Releases schnell genug, dass die Macken, die ich diese Woche bemängeln würde, nächste Woche verschwunden sein könnten.
Der Graph für das Repository, mit dem ich diesen Beitrag begonnen habe, ist jetzt neben dem Quellcode committet. Jeder PR baut ihn neu auf. Jedes Onboarding-Dokument referenziert ihn. Die Frage „Wie sieht diese Codebase überhaupt aus?", die früher eine Stunde dauerte, dauert jetzt neunzig Sekunden. Das ist die Workflow-Verschiebung, und es ist der Grund, warum ich über Graphify schreibe, anstatt zum nächsten glänzenden Ding in meinem Feed weiterzuziehen.
Wenn du nach dem Lesen nur eine Sache tust: Öffne ein Terminal, führe uv tool install graphifyy aus, dann graphify install, dann graphify build innerhalb des Repositories, das du stillschweigend gemieden hast. Der Graph, den es baut, wird dich wahrscheinlich überraschen — und möglicherweise in Verlegenheit bringen, auf die nützlichste Art. Das ist der Punkt.
Häufig gestellte Fragen
Was macht Graphify eigentlich?
Graphify konvertiert einen Ordner mit Code, Dokumentation und anderen Dateien in einen abfragbaren Knowledge Graph, damit dein KI-Assistent Fragen über die Struktur beantworten kann, ohne Quelldateien erneut zu lesen. Es nutzt tree-sitter für deterministisches Code-Parsing und ein LLM für semantische Extraktion über Dokumentation, dann clustert es das Ergebnis mit Leiden Community Detection. Die Ausgabe ist ein graph.json, den dein Agent abfragt, anstatt deine Codebase zu durchforsten.
Wie installiert man Graphify in Claude Code?
Führe uv tool install graphifyy (oder pipx install graphifyy) aus, um das CLI zu installieren, dann graphify install, um es als Claude Code Skill zu registrieren. Der Install-Befehl schreibt das Skill-Manifest in ~/.claude/skills/graphify/ und aktualisiert CLAUDE.md, damit Claude Code den Graphen nutzt, bevor es Rohdateien durchforstet. Die gesamte Installationszeit liegt auf einem modernen Rechner unter einer Minute.
Ist die 70-fache Token-Reduktion real?
Die 71,5-fache Zahl ist real, aber corpus-abhängig — sie stammt aus einem gemischten multimodalen Benchmark, bei dem PDFs und Bilder die Roh-Baseline aufblähen. Bei reinen Code-Repositories kannst du bei strukturellen Abfragen mit ungefähr 5- bis 10-facher Token-Kompression rechnen. Das ist immer noch erheblich, aber nicht die Schlagzeilenzahl. Die Einsparungen konzentrieren sich auf Erkundungs- und Onboarding-Workflows, nicht auf das Code-Schreiben.
Ersetzt Graphify grep oder Vektorsuche?
Nein — es ergänzt sie. Graphify gewinnt bei strukturellen Fragen („Was ruft was auf", „kürzester Pfad zwischen zwei Modulen"). Grep gewinnt immer noch, wenn du genau den String kennst, den du suchst. Vektorsuche gewinnt immer noch bei unscharfer semantischer Ähnlichkeit über Langformtext. Das stärkste Setup stapelt alle drei, mit dem Graphen als struktureller Index-Schicht.
Kann der Graph aktuell bleiben, wenn sich der Code ändert?
Ja. Führe graphify build --update aus, um nur geänderte Dateien (erkannt über SHA256-Hashes) neu zu extrahieren und in den bestehenden Graphen einzumergen. Du kannst auch Git-Hooks installieren, die inkrementelle Updates bei Commit oder Checkout auslösen, sodass der Graph ohne manuelles Eingreifen mit deinem Repository synchron bleibt.
Lass uns zusammenarbeiten
Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.
- Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Enterprise-Lösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
