Ich installierte einen Knowledge Graph in Claude Code. 14 Tage später zerstörte das Audit meine Begeisterung.

Als ich zum ersten Mal von graphify hörte, dachte ich, es würde meinen Code verbessern und meine Token reduzieren. Vor 15 Tagen installierte ich es in 2 Produktionsprojekten. Ich war mir sicher, dass ich meinen Agent aufgerüstet hatte. Zwei Wochen später prüfte ich die JSONL-Transkripte. Ich musste die Zahlen zweimal lesen.

Über 60 Sessions hinweg feuerte der Agent etwa 1.500 Hook-Erinnerungen ab und rief den Graph exakt 0 Mal auf. Das grep gewann jedes einzelne Mal die Arbitrage, nicht weil der Graph schlecht war, sondern weil der Graph einen zusätzlichen Schritt kostete.

Ich wollte, dass das funktioniert. Verzweifelt.

Ich setzte voll auf graphify. Dreifaches Versprechen: persistenter Speicher der Codebase, auditierbare Graphen, die du wie eine Karte lesen kannst, dokumentübergreifende Überraschungen, die der LLM-Cache nicht sehen kann. Veröffentlichte Zahlen im Bereich von 49-71x für Token-Einsparungen bei Abfragen, die den Graph sauber treffen. Jede Box abgehakt.

Ich ließ den kompletten Durchgang auf beiden Projekten laufen: ein Next.js-Storefront auf einem Convex-Backend (etwa 290 Dateien) und eine Content-Pipeline, zu der ich immer wieder zurückkehre (387 TypeScript-Dateien). Ein AST-Durchgang plus eine semantische Extraktionsschicht, etwa $0,30 bis $1 pro Projekt auf Sonnet. Der Post-Commit-Git-Hook ging rein, der MCP-Server wurde deklariert, die CLAUDE.md-Regel wurde wortgetreu von graphify claude install eingefügt. 7 Tools im Panel sichtbar. Sauber.

Dann trieb ich es weiter. Usage-Log-Datei zum Tracking der Erfolge. Dediziertes Claude-Memory nur für graphify-Feedback. Review-Datum 7 Tage raus, auf 14 verschoben, als die Daten dünn wirkten. Ich hatte den Evaluationskalender geschrieben, bevor ich einen einzigen Datenpunkt hatte, was im Nachhinein der Zug von jemandem ist, der die Antwort bereits will. (Du hast auch schon mal so einen Kalender geschrieben, ich bin nicht der Einzige.)

Ich war mir sicher, dass ich gerade meinen Agent aufgerüstet hatte. Der MCP-Server atmete. Der Graph war warm. Der Hook feuerte. Ich musste nur auf die Gewinne warten.

Das Audit, das meinen Enthusiasmus tötete

Claude Code führt ein Transkript jeder Session als .jsonl-Datei unter ~/.claude/projects/<repo>/. Jeder Tool-Aufruf wird mit Name und Eingaben geloggt. Ein echter Aufruf sieht aus wie "type":"tool_use","name":"mcp__graphify__...". Das Startup-deferred_tools_delta listet die verfügbaren Tools auf, ist aber kein Aufruf. Ich grep'te nach dem ersten, ignorierte das zweite.

Hier ist, was 14 Tage "Ich bin sicher, das funktioniert" tatsächlich produzierten.

grep "tool_use" ~/.claude/projects/pbn/*.jsonl | grep graphify
grep "tool_use" ~/.claude/projects/rentier/*.jsonl | grep graphify

Die Zahlen, nebeneinander:

• CLI-Aufrufe von graphify query / path / explain: 0 bei pbn, 0 bei rentier
• MCP graphify-Tools vom Agent aufgerufen: 0 bei pbn, 0 bei rentier
• Aktive Lesevorgänge von GRAPH_REPORT.md: 1 bei pbn, 0 bei rentier
• Zeilen zu meinem Usage-Log hinzugefügt: 1 Zeile bei pbn, Datei bei rentier nie erstellt
• Projekt-Memories, die Graph-Insights zitieren: 0 bei beiden

Die Infrastruktur machte ihren Job perfekt. 290 Commits in der Content-Pipeline und 38 im Storefront wurden vom Post-Commit-Hook ohne einen einzigen Fehler verdaut. Null Kostenüberschreitungen, null Reibung, der Graph blieb durch jeden Push frisch. Der MCP-Server bootete sauber in jeder Session, die 7 Tools waren im Panel sichtbar, die Regel saß oben in der CLAUDE.md, wo der Agent sie angeblich bei jedem Kaltstart liest. Alles, was ich mechanisch kontrollieren konnte, funktionierte. Das eine, was ich nicht kontrollieren konnte, das Lesen selbst, passierte nicht.

Der eine dokumentierte produktive Einsatz war ein 404-Bug auf einer Partner-Site, den ich am 2. Mai debuggte. Der Report zeigte auf das richtige Modul-Cluster. Gut. Die erste Diagnose war trotzdem falsch, der Agent beschuldigte humanize.ts, der echte Übeltäter war mesh.ts:tryInsertLink. Der Graph half, die Zone einzugrenzen. Er löste nicht. Ich musste gegen die tatsächlichen .meta.json-Dateien verifizieren, um die Diagnose umzudrehen. Ich sparte vielleicht 500 Token grep-Arbeit und 3 Datei-Lesevorgänge. Marginal verglichen mit den veröffentlichten Zahlen um 49-71x Token-Einsparungen, wie von Mustafa Genc auf GoPenAI und dem CLSkills-Integrationsguide dokumentiert (April 2026). Diese Zahlen werden in kontrollierten Benchmarks gemessen, wo ein Agent den Graph nutzen muss. Mein Audit misst das Gegenteil. Was ein Agent macht, wenn er die Wahl hat.

Das Grep gewann, weil Grep kürzer ist

Ein KI-Agent führt bei jedem Schritt eine Echtzeit-Arbitrage durch. Was ist der billigste Weg zum Ziel? Text-Regeln gehen in diese Arbitrage als Signale ein, nicht als Gesetze. Yajin Zhou brachte es in seinem März-2026-Post sauber auf den Punkt: für KI sind Regeln keine Gesetze, sondern Vorschläge. Christoph Schweres dokumentierte die architektonische Seite einen Monat früher: nach der Kontext-Kompression ändert CLAUDE.md den Status, es hört auf, eine Regel zu sein, und wird zu Information, die der Agent gewichten kann oder auch nicht. Genau das spielte sich über meine 1.500 ignorierten Hook-Erinnerungen ab.

Zwei konkrete Gründe, warum graphify die Arbitrage verlor.

Grund 1, der kurze Weg gewinnt immer. Um "wo ist X definiert", "wer ruft Y auf", "was berührt Z" zu beantworten: grep -r gibt exakte Zeilen in 1-2 Sekunden. GRAPH_REPORT.md lesen gibt 500 Token thematische Zusammenfassung, dann muss der Agent trotzdem die Dateien öffnen. Ein Schritt versus zwei. Die Echtzeit-Arbitrage wählt den kurzen Weg, egal was du in Großbuchstaben in die CLAUDE.md geschrieben hast. Das ist kein Bug. Das ist die Gewichtung, wie sie trainiert wurde.

Grund 2, Text-Regeln haben keine persistente Disziplin. Mein PreToolUse:Bash-Hook feuerte über 1.500 Erinnerungen ab, die dem Agent sagten "3 relevante Datei(en) geändert, führe /graphify update erneut aus". Keine einzige löste eine Graph-Konsultation aus. Die Erinnerungen wurden zu Rauschen zum Parsen und Überspringen. Das Muster ist jetzt stark dokumentiert: GitHub Issues #18660, #22022, #19635 und das ganz aktuelle #57200 vom 8. Mai (der Reporter verbrannte 85K Token beim Wiederentdecken einer Entscheidung, die bereits im Speicher war, weil die laws.md-Regeln die Kontext-Kompression nicht überlebten). Mustafa Morbel formulierte die Unterscheidung gut in seinem April-Stück: CLAUDE.md ist von Natur aus beratend, Hooks sind deterministisch. Text wird debattiert. Mechanik nicht.

Ich schrieb schon über CLAUDE.md-Hygiene, 47 Zeilen in meiner CLAUDE.md und warum Claude 50 Anweisungen verbrennt, bevor meine überhaupt laden. Dieser Artikel sagte: schreibe bessere Regeln. Dieser hier sagt: selbst die bestgeschriebene Regel bleibt beratend und verliert gegen die Arbitrage. Beides ist wahr. Keines ist ausreichend.

Wo ich es hätte verwenden sollen (und wo du es wahrscheinlich solltest)

Ich machte einen Setup-Fehler. Zwei davon, eigentlich.

Fehler 1, ich installierte ein Discovery-Tool auf vertrautem Terrain. Die graphify-Docs sind explizit über die Ziel-Use-Cases: eine Codebase, die du zum ersten Mal berührst, eine Leseliste (Papers, Tweets, Notizen), ein Forschungskorpus, ein persönlicher /raw-Ordner, wo du alles hinwirfst. Keines meiner beiden Projekte ist davon etwas. Ich schrieb die Hälfte des Codes und las den Rest viele Male wieder. Genauso für Claude, das Arbeitsgedächtnis des Modells für diese Repos war bereits warm. Die dokumentübergreifenden Überraschungen, die ein Community-Detection-Durchgang aufdecken soll, überraschen niemanden, der die Links bereits kennt. Ich installierte einen Kompass in einer Wohnung, in der ich seit 5 Jahren lebe.

Fehler 2, ich deployete es kalt statt heiß. Ein Kontext-Tool gewinnt die Echtzeit-Arbitrage, wenn der Agent keine billigere Alternative hat. Bei einem frischen Repo ist grep immer noch teuer (der Agent sucht blind), also wird zuerst den Graph zu lesen zum kurzen Weg. Nach 3-6 Monaten Exposition hat grep einen Wärme-Cache, und der Graph wird wieder zum Umweg. Ich hatte diese Linie bei beiden Projekten bereits vor Monaten überschritten. Als graphify ankam, hatte der Agent bereits aufgebaut, was als Muskelgedächtnis in einem staatenlosen System durchgeht, und dieses Muskelgedächtnis sagte "grep zuerst, Fragen nie stellen."

Hier ist die Usage-Map, die ich von Tag eins an respektiert haben sollte.

Onboarding bei einem geerbten Repo, das du übernimmst, ohne es zu kennen. Der Graph gewinnt wahrscheinlich, weil grep am Anfang blind ist und eine thematische Karte echte Lesezeit spart. Das ist der Fall, für den Jo Van Eyck in seinem "AI coding agents are useless on large codebases"-Video argumentierte, und in diesem spezifischen Frame hat er recht. Je größer die unbekannte Oberfläche, desto mehr verdient sich eine globale Karte ihren Platz.

Cross-Modul-Security-Audit bei einem Legacy-Repo, wo du versteckte Abhängigkeiten jagst. Expliziter Fall aus den graphify-Docs, und er macht Sinn, da der Agent eine globale Sicht braucht, die kein einzelnes grep gibt. Du suchst nicht nach einem String, du suchst nach einer Topologie.

Gemischte Leseliste (Papers + Notizen + Tweets + Referenz-Code), wo Community-Detection wirklich eine Sicht aufdeckt, die kein grep produzieren kann. Wahrscheinlich der stärkste Use-Case und der, der der ursprünglichen /raw-Philosophie am nächsten kommt, die die ganze Unterhaltung startete. Heterogene Korpora profitieren am meisten von struktureller Extraktion, gerade weil grep über Formate hinweg ein schlechter Witz ist.

Nicht für die Wartung eines Projekts, das du bereits kennst. Das ist, was ich tat, und es war die falsche Anwendung.

Diese Nuance rettet meine Erfahrung nicht. Sie klärt, was ich zuerst hätte testen sollen. Rajistics hat ein YouTube-Stück mit dem Titel "GraphRAG (you probably don't need it)", das von der RAG-Seite zu einer ähnlichen Position kommt. Die Erkenntnis ist dieselbe bei Knowledge Graphs: von Fall zu Fall, nicht immer.

(Nebenbemerkung, die nirgendwo hinführt: Mir fällt immer wieder auf, dass die Tools, die ich mit dem meisten Enthusiasmus installiere, die sind, über die ich vorher am wenigsten lese. Die langweiligen Tools, die ich einmal überfliege und vergesse, sind meist die, die ich 6 Monate später noch verwende. Da ist wahrscheinlich eine Lektion drin darüber, wie Enthusiasmus die Bewertung verzerrt. Oder vielleicht habe ich einfach schlechten Geschmack bei Tools. Schwer zu sagen, ehrlich gesagt.)

Die echte Lektion: Text ändert Agent-Verhalten nicht. Mechanik schon.

Dieses Muster ist größer als graphify. Du gibst dem Agent ein neues Tool, ein neues Doc, eine neue Regel. Du schreibst es gut. Du erinnerst ihn in der CLAUDE.md. Du setzt einen Hook, der pingt. Der Agent nickt. Dann macht er etwas anderes. Das Muster taucht über GitHub Issues, r/ClaudeAI-Threads und mindestens ein Dutzend aktuelle Medium-Stücke auf. Es ist der dominante Fehlermodus von kontextuellem Tooling in 2026.

Was tatsächlich funktioniert, sind 3 mechanische Hebel.

Hebel 1, blockieren statt erinnern. Ein PreToolUse-Hook, der die alternative Aktion verweigert, erzwingt den Pfad. Mustafa Morbel dokumentierte den Kontrast bereits: CLAUDE.md ist beratend, Hooks sind deterministisch. Jede Regel, die ignoriert werden kann, wird ignoriert, sobald die Echtzeit-Arbitrage eine kürzere Route findet. Die Lösung ist nicht bessere Formulierung. Die Lösung ist, die Alternative aus dem Menü zu entfernen. Wenn dein Hook nur erinnert, hast du eine höfliche Stimme gebaut, die der Agent lernt zu überhören. Wenn dein Hook den Aufruf blockiert, hast du eine Wand gebaut.

Hebel 2, mache das Tool zum kurzen Weg, nicht zum Umweg. Ein Knowledge Graph, der die Frage beantwortet, gewinnt. Ein Knowledge Graph, der auf Dateien zeigt, die der Agent trotzdem öffnen muss, verliert, weil er einen Schritt hinzufügte statt einen zu entfernen. Gleiches Prinzip für MCP-Server: ein Server, der N Tool-Aufrufe eliminiert, gewinnt, ein Server, der N+1 hinzufügt, verliert. Ich argumentierte dasselbe über CLIs versus MCP in why CLIs beat MCP for AI agents: CLIs gewinnen genau deshalb, weil sie sich in den nativen Pfad des Agents einfügen, statt ihn zu bitten, in einen JSON-RPC-Handshake abzubiegen. Der Mechanismus verallgemeinert sich auf jedes kontextuelle Tool. Wenn es einen Schritt hinzufügt, verliert es. Wenn es einen entfernt, gewinnt es. Das ist das ganze Spiel.

Hebel 3, führe das Tool zum richtigen Moment ein. Ein Kontext-Tool gewinnt beim Kaltstart, nicht bei warmer Wartung. Das ist der Fehler, den ich mit graphify machte, aber es ist auch der Fehler, den Entwickler machen, wenn sie 200 Zeilen zu ihrer CLAUDE.md hinzufügen, 6 Monate in ein Projekt hinein. Zu spät. Bis dahin ist das Verhaltensmuster des Agents für dieses Repo durch die bestehenden Tools fixiert (grep, ls, cat, der Dateibaum, den er bereits zu navigieren gelernt hat). Ein neues Tool obendrauf muss Trägheit überwinden, und Trägheit in einer Echtzeit-Arbitrage bedeutet "dieser Pfad war letztes Mal billig, nimm ihn wieder."

Die 3 Hebel kosten etwas. Sie machen das Tooling invasiver. Ein blockierender Hook nervt dich, wenn du eine Ausnahme machen willst. Ein Kurz-Pfad-Tool ersetzt die Flexibilität von grep durch die Starrheit eines festen Schemas. Ein Kaltstart-Tool bedeutet, dass du dein Tooling planen musst, bevor du ein Projekt hast, was die meisten von uns nie tun, weil wir Tools installieren, wenn wir den Schmerz spüren, nicht vorher. Also greifen alle stattdessen zur beratenden Schicht, schreiben mehr Zeilen in die CLAUDE.md, setzen noch eine Erinnerungs-Hook und sagen sich, die Regeln sind diesmal klar genug. Ich habe das gemacht. Du wahrscheinlich auch. Die beratende Schicht ist komfortabel, gerade weil sie uns vortäuschen lässt, wir hätten das Verhalten des Agents geändert, ohne die Kosten zu zahlen, es tatsächlich zu ändern.

Eigentlich, warte. Lass es mich anders ausdrücken. Die beratende Schicht ist wie eine scharfe E-Mail an dein vergangenes Selbst zu schreiben und zu erwarten, dass dein zukünftiges Selbst gehorcht. Viel Glück damit. 😅

Die Lektion gilt über Claude Code hinaus. Wenn du einen KI-Workflow baust, der davon abhängt, dass das Modell geschriebenen Regeln folgt, setzt du auf eine Eigenschaft, die das Modell nicht hat. Das Modell hat Gewichte, keine Gesetze. Ich schrieb über einen verwandten Winkel in Vibe Coding, For Real: Vibe-Coder glauben, die richtigen Regeln für den Agent zu schreiben reicht zum Shippen. Shippen kommt von der Mechanik des Builds, nicht von der Prosa drumherum. Gleiches Prinzip hier, auf die Tooling-Ebene hochskaliert.

Auditiere deine eigenen Transkripte, bevor du deinen eigenen Regeln vertraust

Mein Befund zu graphify ist nicht, dass das Tool schlecht ist. Das Tool funktioniert wie beworben, wenn der Agent es tatsächlich verwendet. Das Problem ist, dass Tool-Adoption durch Agents 10 Mal schwerer ist als Tool-Installation. Jedes Tool, das einen Agent bittet, seinen Standard-Pfad zu ändern, geht durch dieselbe Echtzeit-Arbitrage. Meine CLAUDE.md geht dadurch, meine Erinnerungs-Hooks gehen dadurch, sogar die Prompts, auf die ich am stolzesten bin, gehen dadurch. Jeder hat sein graphify, und sie wissen es nicht, bis sie auditieren.

Also auditiere. Der Befehl passt auf eine Zeile:

grep "tool_use" ~/.claude/projects/<repo>/*.jsonl | grep <tool_name>

Zähle die echten Aufrufe. Vergleiche mit dem, was deine CLAUDE.md, deine Hooks und deine Regeln vorgeben, dass der Agent tun sollte. Die Lücke sind die tatsächlichen Kosten dessen, was du in Worten geschrieben hast. Wenn die Lücke null ist, weißt du, was als nächstes zu tun ist: verschiebe die Regeln, die wichtig sind, von Text zu Mechanik. Der Rest kann beratend bleiben, niemand liest es sowieso.

Ein Knowledge Graph, den der Agent nicht liest, ist kein Tool. Es ist Dokumentation. Gilt genauso für deine Regeln. C'est la vie.

Quellen

• graphify Repository und Docs, github.com/safishamsi/graphify
• Christoph Schweres, Claude Code Ignores the CLAUDE.md, HOW Is That Possible? (Feb 2026)
• Yajin Zhou, Why an AI Agent Broke Its Own Rules (März 2026)
• Mustafa Morbel, Taming Claude Code: A Guide to CLAUDE.md and Hooks (April 2026)
• Mustafa Genc, Graphify: Build a Knowledge Graph From Your Entire Codebase (GoPenAI, April 2026)
• GitHub Issues anthropics/claude-code #18660, #22022, #19635, #57200
• Jo Van Eyck, AI coding agents are useless on large codebases. Unless you do THIS. (YouTube)
• Rajistics, GraphRAG (you probably don't need it) (YouTube)

Dieser Post kann Affiliate-Links enthalten. Wenn du sie klickst, verdiene ich möglicherweise eine kleine Provision, kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel für dein Lesevergnügen zu liefern.