codesight: ein Repository-Scanner, der KI-Kontextdateien aus dem AST erzeugt

Welches Problem codesight adressiert und für wen

Jede neue Sitzung mit einem KI-Assistenten beginnt mit derselben Arbeit: Der Assistent liest Dateien, um herauszufinden, wo die Routen liegen, welche Modelle existieren und welche Datei beim Ändern einer anderen bricht. Die README beschreibt genau diesen Vorgang als Token-Verschwendung und nennt als Gegenmittel einen einzigen Befehl. Die Zielgruppe ist damit klar umrissen: Entwickler, die täglich mit Claude Code, Cursor, Copilot, Codex, Windsurf, Cline oder Aider arbeiten und wiederkehrend denselben Projektkontext bezahlen. Wer nur gelegentlich einen Assistenten öffnet, hat kaum etwas zu sparen. Interessant ist das Werkzeug auch für Teams, die ihre Kontextdateien versionieren wollen: Die Ausgabe landet in .codesight/ und lässt sich mitcommitten, sodass alle Beteiligten denselben Stand sehen. Die README nennt als Herkunft HouseofMVPs und Kailxlabs, als Lizenz MIT.

Der Mechanismus: AST für TypeScript, Regex für alles andere

codesight ist ein TypeScript-Projekt mit Node.js >= 18 und laut README ohne Laufzeitabhängigkeiten. Die Analyse ist zweigeteilt. Für TypeScript-Projekte liest das Werkzeug nach eigener Angabe den abstrakten Syntaxbaum und gewinnt daraus Strukturinformationen. Für JavaScript, Python, Go, Ruby, Elixir, Java, Kotlin, Rust, PHP, Dart, Swift, C# und BrightScript/BrighterScript greift eine Regex-Erkennung, die dieselben über 30 Framework-Erkennungen und 14 ORM-Parser bedient. Das ist die zentrale Designentscheidung des Projekts und zugleich seine größte Schwachstelle: Ein Regex-Treffer kann einen Import in einem Kommentar oder in einem String als echte Abhängigkeit zählen. Für den Wiki-Modus wird ausdrücklich kein LLM aufgerufen. Die README beschreibt den Wiki-Aufbau als Kompilat aus dem AST, nicht als Modellausgabe, und nennt als Laufzeit rund 200 Millisekunden. Die Artikel (index.md, overview.md, auth.md, payments.md, database.md, users.md, ui.md) entstehen aus Routen, Schema, Middleware und Blast-Radius, die die Analyse ohnehin ermittelt. Ein log.md hält jede Wiki-Operation fest.

Installation und die Befehle, die tatsächlich Konfiguration erzeugen

Der Einstieg ist ein Aufruf im Projektwurzelverzeichnis: npx codesight. Laut README sind weder Konfigurationsdatei noch API-Schlüssel nötig. Die für den Alltag relevanten Schalter sind: npx codesight --init erzeugt CLAUDE.md, .cursorrules, codex.md und AGENTS.md. npx codesight --wiki legt die Wissensbasis unter .codesight/wiki/ an. npx codesight --profile claude-code erzeugt eine auf ein bestimmtes Werkzeug zugeschnittene Konfiguration. npx codesight --mcp startet den Server mit 14 Werkzeugen für Claude Code und Cursor. npx codesight --blast src/lib/db.ts zeigt, welche Dateien von einer Änderung betroffen wären. npx codesight --benchmark gibt eine Aufschlüsselung der Token-Ersparnis aus. npx codesight --watch und --hook halten das Wiki beim Coden beziehungsweise bei jedem Commit aktuell. Für den Wissensmodus lautet der Aufruf npx codesight --mode knowledge, optional mit Pfad, etwa ./docs oder ~/vault für einen Obsidian-Vault. Die Ausgabe ist dann .codesight/KNOWLEDGE.md. Als Opt-in existiert --native-ast für zusätzliche Sprachen über WASM-Plugins; die README verweist dafür auf docs/wasm-plugins.md.

Die MCP-Werkzeuge als eigentlicher Integrationspunkt

Interessanter als die statischen Dateien ist der MCP-Pfad. Die README nennt 14 Werkzeuge, von denen drei ausschließlich dem Wiki dienen: codesight_get_wiki_index liefert den Katalog mit rund 200 Token, codesight_get_wiki_article liest einen einzelnen Artikel nach Namen, codesight_lint_wiki prüft auf verwaiste Artikel, fehlende Querverweise und veraltete Inhalte. Das ist ein anderes Modell als das Einfügen einer großen Kontextdatei: Der Assistent holt sich gezielt einen Ausschnitt. Die README illustriert das mit einer Tabelle, in der die Frage nach der Authentifizierung ohne Wiki rund 12.000 Token über acht oder mehr Dateien kostet und mit Wiki rund 300 Token aus auth.md. Solche Zahlen sind Herstellerangaben aus der Projektdokumentation, keine unabhängige Messung, und hängen stark davon ab, wie der jeweilige Assistent Dateien nachlädt. Der Lint-Befehl ist trotzdem der nützlichste Teil des Sets, weil eine veraltete Wissensbasis schlimmer ist als gar keine: Der Assistent argumentiert dann selbstsicher auf Basis falscher Struktur.

Wo das Werkzeug an seine Grenzen stößt

Die Sprachaufteilung ist die offensichtlichste Einschränkung. Volle AST-Präzision gibt es nur für TypeScript. Ein Go- oder Ruby-Monorepo erhält dieselbe Regex-Behandlung wie ein beliebiges anderes Projekt, und die README räumt das offen ein. Wer ein Polyglot-Repository betreibt, sollte damit rechnen, dass die Framework- und ORM-Erkennung in den Nicht-TypeScript-Teilen unvollständig oder falsch sein kann. Ein zweiter Punkt betrifft die Wissensbasis selbst: Sie wird committet und wächst mit dem Projekt. Ohne --watch oder --hook veraltet sie still, und der Lint-Befehl ist die einzige eingebaute Kontrolle dagegen. Drittens ist der Nutzen stark vom Assistenten abhängig. Ein Werkzeug, das ohnehin eigenständig Dateien liest, spart weniger als eines, das strikt dem übergebenen Kontext folgt. Die README nennt 4.000 Downloads, 149 Tests und Tests auf 25 Open-Source-Projekten; das sind Angaben des Projekts, keine Bewertung der Reife. Releases wurden für dieses Repository nicht abgerufen, die Versionsstände in der README (v1.6.2 für das Wiki, v1.9.3 für den Wissensmodus) sind daher der einzige Anhaltspunkt für den Entwicklungsstand.

Der Unterschied zu generischen Wiki- und Repo-Map-Werkzeugen

Die naheliegende Alternative ist ein Werkzeug, das ebenfalls eine Wissensbasis erzeugt, dafür aber ein Sprachmodell einsetzt, etwa ein Assistent, der aus den Quelldateien selbstständig Artikel schreibt. Der Unterschied liegt im Datenfluss. Ein LLM-gestütztes Wiki ruft ein Modell auf, kostet pro Generierung Geld und Zeit und kann Strukturen halluzinieren, die im Code nicht existieren. codesight extrahiert nach eigener Darstellung zuerst Routen, Schema, Middleware und Blast-Radius und formuliert daraus erst die Artikel. Die README nennt das eine narrative Schicht über Daten, die der Code bereits enthält, und betont, dass keine API-Aufrufe anfallen. Der Preis dafür ist Starrheit: Ein Modell kann erklären, warum ein Modul existiert, ein AST kann nur sagen, dass es existiert. Für die Frage, wie ein Assistent schnell die richtige Datei findet, ist die zweite Herangehensweise ausreichend. Für Einarbeitungsdokumentation für Menschen reicht sie nicht. Eine zweite Alternative ist der Verzicht auf jede Vorabanalyse: Der Assistent liest bei Bedarf selbst. Das kostet pro Sitzung Token, verlangt aber keine committete Datei, die gepflegt werden muss.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu prüfen ist

Der laufende Aufwand besteht aus drei Teilen. Erstens muss die Wissensbasis aktuell bleiben; dafür sind --watch oder --hook vorgesehen, sonst veraltet .codesight/wiki/ unbemerkt. Zweitens erzeugt --init mehrere Dateien (CLAUDE.md, .cursorrules, codex.md, AGENTS.md), die bei Änderungen am Werkzeug oder an den Konventionen des Teams angepasst werden müssen. Drittens wächst das Repository um die committeten Wiki-Artikel, was bei jedem Pull Request zu Konflikten in generierten Dateien führen kann, wenn mehrere Personen gleichzeitig regenerieren. Die Lizenz ist MIT. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass der Urheberrechtshinweis und der Lizenztext erhalten bleiben. Für die Ausgabe des Werkzeugs, also die generierten Markdown-Dateien, macht die MIT-Lizenz keine gesonderten Vorgaben; wer die Artikel weiterverbreitet, sollte den Hinweis auf das erzeugende Werkzeug nicht entfernen. Das ist keine Rechtsberatung, sondern nur die Beschreibung dessen, was die Lizenzkennung im Repository bedeutet. Vor einem festen Einsatz in einer Pipeline lohnt ein Probelauf mit npx codesight --benchmark im eigenen Projekt, um zu sehen, wie viel der Assistent tatsächlich lädt, und ein Blick in .codesight/wiki/ nach dem ersten Lauf, um zu beurteilen, ob die erkannten Routen und Modelle der Realität entsprechen.

Redaktionelles Fazit

Sinnvoll ist codesight für Teams, die ausschließlich TypeScript schreiben und den vollen AST-Pfad nutzen, sowie für alle, die eine committbare Wissensbasis in .codesight/wiki/ wollen. Wer viele Sprachen im Monorepo hat, sollte zuerst prüfen, wie stark die Regex-Erkennung bei den eigenen Dateien daneben liegt. Vor dem Einsatz lohnt ein Lauf mit npx codesight --benchmark, um die tatsächliche Ersparnis im eigenen Projekt zu sehen, statt sie aus der README zu übernehmen.

Offizielle Quellen

1. Houseofmvps/codesight on GitHub
2. Issues
3. License: MIT
4. Project website
5. README