KI-Coding-Agenten scheitern an großen Codebases, weil sie Quellcode wie einen Haufen Textdateien behandeln. Sie zerlegen Dateien in Chunks, berechnen Embeddings und hoffen, dass die Kosinus-Ähnlichkeit die richtige Funktion aus 4.000 Kandidaten findet. Meistens tut sie das nicht. GitNexus, ein Open-Source-Projekt mit über 10.000 GitHub-Sternen seit Anfang 2026, dreht den Ansatz um: Es indexiert das gesamte Repository in einen Property Graph und berechnet dabei jede Abhängigkeit, Call Chain, jeden Cluster und Ausführungspfad bereits beim Indexieren vor. Wenn der KI-Agent fragt “Was geht kaputt, wenn ich diese Funktion ändere?”, kommt die Antwort in einem Aufruf zurück, nicht nach zehn Retrieval-Runden.
GitNexus läuft in zwei Modi. Als CLI baut es eine KuzuDB-Graphdatenbank, die lokal im Verzeichnis .gitnexus/ gespeichert wird, und stellt sie über einen MCP-Server bereit, der sich direkt mit Claude Code, Cursor und Windsurf verbindet. Als Web-App läuft der komplette Stack im Browser via WebAssembly: Tree-sitter WASM zum Parsen, KuzuDB WASM für die Datenbank und transformers.js für Embeddings. Kein Server, keine Daten verlassen den Rechner.
Warum KI-Coding-Agenten den Kontext verlieren
Das Grundproblem kennt jeder, der Cursor, Claude Code oder GitHub Copilot auf einer Codebase mit mehr als ein paar hundert Dateien eingesetzt hat. Diese Tools nutzen eine Form von Retrieval, um relevanten Code vor der Antwortgenerierung zu finden. Das Retrieval ist typischerweise semantische Suche: Die Frage des Nutzers wird eingebettet, Code-Chunks werden eingebettet, die nächsten Nachbarn werden gesucht.
Für einfache Fragen wie “Wo ist die Login-Funktion?” funktioniert das. Bei strukturellen Fragen versagt es: “Welche Services hängen von diesem Datenbankschema ab?” oder “Wenn ich dieses Interface umbaue, welche nachgelagerten Consumer brechen?” Diese Fragen erfordern ein Verständnis der Graphstruktur des Codes, nicht der textuellen Ähnlichkeit einzelner Dateien.
Eine Analyse von Zep AI aus 2025 dokumentierte drei Fehlermodi von herkömmlichem RAG: Es kann keine Multi-Hop-Beziehungen verfolgen, verpasst zeitliche Änderungen in Daten und ruft Kontext ab, der semantisch nah, aber funktional irrelevant ist. Alle drei Probleme treffen direkt auf Code-Retrieval zu. Die Signatur einer Funktion mag fünf anderen ähneln, aber nur eine wird tatsächlich von dem Code aufgerufen, den man gerade bearbeitet.
Wie GitNexus seinen Knowledge Graph aufbaut
GitNexus löst das Retrieval-Problem, indem es im klassischen Sinne gar nicht auf Retrieval setzt. Stattdessen berechnet es die strukturellen Beziehungen bereits beim Indexieren in einer mehrstufigen Pipeline vor.
Phase 1: Parsen mit Tree-sitter
Der erste Schritt ist das Parsen jeder Datei mit Tree-sitter-Grammatiken. GitNexus unterstützt 12 Sprachen: TypeScript, JavaScript, Python, Java, Go, Rust, C, C++, C#, Ruby, PHP und Swift. Tree-sitter erzeugt konkrete Syntaxbäume, aus denen GitNexus Symbole (Funktionen, Klassen, Interfaces, Typen), Import-/Export-Beziehungen, Aufrufstellen und Vererbungsbeziehungen extrahiert.
Im Gegensatz zu Regex-basierten Indexern, die Randfälle übersehen, verarbeitet Tree-sitter verschachtelte Generics, Decorator-Muster und komplexe Typ-Annotationen korrekt. Der Parser läuft im Browser als WebAssembly, portabel ohne Genauigkeitsverlust.
Phase 2: Graph-Konstruktion in KuzuDB
Die extrahierten Symbole und Beziehungen fließen in einen KuzuDB-Property-Graph. KuzuDB ist eine eingebettete Graphdatenbank (vergleichbar mit SQLite, nur für Graphen), die Cypher-Abfragen, HNSW-Vektorindizes für semantische Suche und Volltextsuche unterstützt. Jeder Knoten im Graph repräsentiert eine Code-Entität: eine Funktion, Klasse, ein Modul oder eine Datei. Kanten stellen Beziehungen dar: “ruft auf,” “importiert,” “erweitert,” “implementiert.”
Der Graph speichert auch Metadaten: Dateipfade, Zeilennummern, Komplexitätswerte und semantische Embeddings via transformers.js. Diese hybride Struktur ermöglicht Abfragen sowohl über Graph-Traversierung (“zeig mir alles zwei Hops von dieser Funktion”) als auch über semantische Ähnlichkeit (“finde Funktionen, die mit Authentifizierung zu tun haben”).
Phase 3: Clustering und Flow-Analyse
Nach dem Aufbau des Roh-Graphen führt GitNexus Clustering-Algorithmen aus, um zusammenhängende Module zu identifizieren, erkennt Ausführungsflüsse (z.B. Einstiegspunkt bis Datenbankaufruf) und bewertet die Kantenvertrauenswürdigkeit. Das Ergebnis ist ein Graph, in dem jede Abfrage nicht nur rohe Verbindungen zurückgibt, sondern eine Einschätzung, wie stark zwei Komponenten gekoppelt sind.
Diese Vorberechnung ist die zentrale Architekturentscheidung. Herkömmliche RAG-Systeme machen ihr Reasoning zur Abfragezeit, was bedeutet, dass das LLM Beziehungen selbst über mehrere Retrieval-Runden entdecken muss. GitNexus verlagert diese Arbeit nach vorne, sodass der Agent sofort entscheidungsrelevanten Kontext bekommt.
Der MCP-Server: Anbindung an den Coding-Agenten
Der CLI-Modus ist der praktischste Weg für den täglichen Einsatz. Nach dem Indexieren eines Repositories mit gitnexus index startet das Tool einen MCP (Model Context Protocol)-Server, an den sich jeder kompatible Coding-Agent anbinden kann.
GitNexus stellt sieben spezialisierte MCP-Tools bereit:
Hybrid Search: Kombiniert BM25-Keyword-Matching, semantische Vektorsuche und Reciprocal Rank Fusion (RRF). Genauer als reine semantische Suche, weil exakte Token-Treffer neben der Bedeutung gewichtet werden.
Symbol Context Lookup: Zu einem gegebenen Funktions- oder Klassennamen liefert es die vollständige Definition, Aufrufer, Aufgerufene und den zugehörigen Cluster. Das macht “zeig mir alles, was diese Funktion aufruft” zu einem einzelnen Tool-Aufruf.
Blast Radius Analysis: Das Highlight-Feature. Zu einem Symbol berechnet es jeden nachgelagerten Consumer, bewertet das Änderungsrisiko und liefert eine priorisierte Liste von Dateien, die aktualisiert werden müssten. Vorher war das manuelle grep-und-trace-Arbeit.
Git-Diff Impact Mapping: Nimmt einen Diff (gestagede Änderungen, Branch-Vergleich, spezifischer Commit) und mappt ihn gegen den Knowledge Graph, um zu zeigen, welche Teile der Codebase betroffen sind.
Multi-File Refactoring: Koordiniert Änderungen über mehrere Dateien basierend auf der Graphstruktur. Wenn man ein Interface umbenennt, weiß es, welche Implementierungen, Tests und Consumer Updates brauchen.
Grep: Musterbasierte Code-Suche über das indexierte Repository.
Read/Highlight: Liest spezifische Dateien oder hebt relevante Abschnitte hervor.
Ein globales Registry bedeutet: Ein MCP-Server kann mehrere indexierte Repositories bedienen, ohne dass man pro Projekt die Konfiguration anpassen muss. Einmal einrichten, überall nutzen.
Browser-Modus: Code Intelligence ohne Server
Nicht jeder Anwendungsfall erfordert eine CLI. GitNexus läuft auch komplett im Browser via WebAssembly. Man gibt eine GitHub-URL ein oder lädt eine ZIP-Datei hoch, und die gesamte Indexierungspipeline läuft clientseitig: Tree-sitter WASM parst den Code, KuzuDB WASM speichert den Graph, und Browser-Embeddings (via transformers.js) ermöglichen die semantische Suche.
Die Browser-Oberfläche visualisiert den Knowledge Graph mit Sigma.js und Graphology als interaktive Knoten-Kanten-Diagramme, in denen man sich durch Abhängigkeiten und Aufrufketten klicken kann. Ein eingebauter Graph RAG Agent, angetrieben von einer LangChain ReAct-Schleife, beantwortet natürlichsprachige Fragen zur Codebase. Der Agent hat fünf Tools: Suche, Cypher-Abfragen, Grep, Datei lesen und Code-Highlighting.
Die Datenschutzseite ist klar: Nichts verlässt den Browser. Der gesamte Stack läuft lokal. Für Unternehmen im DACH-Raum, die proprietären Code nicht an Drittanbieter-Server schicken dürfen, ob aus DSGVO-Gründen oder wegen interner Compliance-Vorgaben, ist das ein entscheidender Vorteil.
Wo GitNexus im Code-Intelligence-Stack steht
GitNexus besetzt eine spezifische Nische. Es ersetzt nicht den Language Server der IDE (der Echtzeit-Typprüfung, Autovervollständigung und Inline-Diagnose übernimmt). Es ersetzt nicht den Coding-Agenten (Cursor, Claude Code oder Windsurf generieren weiterhin den eigentlichen Code). Es ist die strukturelle Kontextschicht zwischen Codebase und Agent, die sicherstellt, dass der Agent die Graphstruktur des Codes versteht, statt ihn als Stapel Textdateien zu behandeln.
Der nächste Vergleich wären Sourcegraphs Code-Intelligence-Features oder JetBrains’ strukturelle Suche. Aber diese sind proprietär, serverabhängig und nicht dafür gebaut, Kontext an LLM-basierte Agenten zu liefern. GitNexus ist Open Source (MIT-Lizenz), läuft lokal und gibt Kontext im Format aus, das MCP-kompatible Agenten erwarten.
Für Teams, die an großen Codebases arbeiten (50.000+ Zeilen), ist der Unterschied zwischen einem Agenten, der den Abhängigkeitsgraph versteht, und einem, der simples Retrieval nutzt, der Unterschied zwischen einem nützlichen Coding-Partner und einer teuren Autovervollständigung. GitNexus schließt diese Lücke, indem es strukturelle Code Intelligence als Standard-MCP-Tool verfügbar macht.
Erste Schritte
Die Installation ist unkompliziert:
npm install -g gitnexus
Repository indexieren:
cd dein-projekt
gitnexus index
MCP-Server starten:
gitnexus serve
Dann den MCP-Server in der Konfiguration des Coding-Agenten eintragen. Bei Claude Code in den MCP-Einstellungen, bei Cursor im MCP-Panel. Das globale Registry sorgt dafür, dass weitere Repositories nur ein gitnexus index brauchen, ohne den Server neu zu konfigurieren.
Für die Browser-Version: gitnexus.vercel.app aufrufen, GitHub-URL eingeben und loslegen.
Häufig gestellte Fragen
Was ist GitNexus und wie hilft es KI-Coding-Agenten?
GitNexus ist ein Open-Source-Tool, das Codebases in Knowledge Graphs indexiert und dabei jede Abhängigkeit, Call Chain und jeden Ausführungspfad abbildet. Es stellt diesen strukturellen Kontext über einen MCP-Server für KI-Coding-Agenten wie Claude Code, Cursor und Windsurf bereit, sodass diese die Codebase wirklich verstehen statt auf einfaches Text-Retrieval angewiesen zu sein.
Wie unterscheidet sich GitNexus von herkömmlichem RAG für Code?
Herkömmliches RAG zerlegt Code in Textchunks und sucht nach semantischer Ähnlichkeit, wobei strukturelle Beziehungen wie Aufrufketten und Abhängigkeiten übersehen werden. GitNexus berechnet diese Beziehungen beim Indexieren in einem Property Graph vor, sodass Abfragen zur Code-Struktur in einem einzigen Aufruf genaue Ergebnisse liefern.
Welche Programmiersprachen unterstützt GitNexus?
GitNexus unterstützt 12 Programmiersprachen: TypeScript, JavaScript, Python, Java, Go, Rust, C, C++, C#, Ruby, PHP und Swift. Es nutzt Tree-sitter-Grammatiken zum Parsen, was die präzise Extraktion von Symbolen, Aufrufstellen und Typbeziehungen sicherstellt.
Werden meine Code-Daten an externe Server gesendet?
Nein. GitNexus läuft komplett lokal. Das CLI speichert den Knowledge Graph in einem .gitnexus/-Verzeichnis auf dem eigenen Rechner, und die Browser-Version führt alles in WebAssembly aus, sodass kein Code den Browser verlässt. Das macht es geeignet für proprietäre Codebases und DSGVO-konforme Umgebungen.
Was ist die Blast-Radius-Analyse in GitNexus?
Die Blast-Radius-Analyse ist ein GitNexus-Feature, das zu einem gegebenen Code-Symbol wie einer Funktion oder Klasse jeden nachgelagerten Consumer berechnet, das Änderungsrisiko bewertet und eine priorisierte Liste von Dateien liefert, die aktualisiert werden müssten. Das verwandelt manuelle grep-und-trace-Arbeit in eine einzelne Operation.