von generativer KI erstellt.
KI-Coding-Agenten wie Claude Code, Codex oder Cursor haben ein Grundproblem: Sie kennen deine Codebase nicht. Bei jeder Frage suchen sie sich den Kontext neu zusammen, Datei für Datei, grep für grep. Das kostet Tokens, Zeit und Kontextfenster. Und wenn der Agent dann Code schreibt, gibt es kein Werkzeug, das misst, wie gut dieser Code eigentlich ist.
Repowise will beide Lücken schließen. Das Open-Source-Tool indexiert ein Repository einmal und stellt danach kuratierte Antworten per MCP bereit, dazu Health-Scores für den Code, den deine KI ausliefert. Laut Doku spart das bis zu 96 Prozent der Tokens beim Kontext-Laden. Solche Zahlen prüfen wir grundsätzlich selbst nach. Also haben wir Repowise auf unserem eigenen Website-Repo installiert und gegen tokensave antreten lassen, ein Code-Graph-Tool, das bei uns bereits eingerichtet war.
Was Repowise ist
Repowise ist ein Python-CLI unter AGPL-3.0, lokal gehostet, mit optionaler Managed-Version. Es baut aus deinem Repository fünf Intelligenzschichten auf:
Graph: Abhängigkeiten auf Symbol-Ebene, geparst mit Tree-Sitter für 15 Sprachen.
Git: Hotspots aus Churn und Komplexität, Ownership, Bus-Faktor.
Docs: LLM-generierte Wikis pro Modul mit semantischer Suche. Optional, braucht einen API-Key.
Decisions: Architekturentscheidungen, gesammelt aus mehreren Quellen und mit Belegen verknüpft.
Health: Deterministische Code-Health-Scores, deren Defekt-Risiko an einem echten Bug-Korpus geeicht wurde.
Für den KI-Agenten sieht das Ganze wie ein MCP-Server mit neun Werkzeugen aus. Weil MCP ein offener Standard ist, gilt das für Claude Code genauso wie für Codex, Cursor und jeden anderen MCP-fähigen Agenten. Statt Dateien zu durchsuchen, fragt der Agent etwa get_answer oder get_risk und bekommt eine fertige Antwort mit Quellenangabe. Der Kern läuft komplett ohne LLM-Key. Nur die Wiki- und Decisions-Schicht braucht einen.
Installation unter Windows: ein Stolperstein
Die Doku verspricht ein simples pip install repowise. Bei uns scheiterte das zweimal: Unter Python 3.14 und auch unter 3.12 wollte die Abhängigkeit litellm aus dem Quellcode gebaut werden und verlangte dafür eine Rust-Toolchain, die auf dem Rechner fehlte. Der Ausweg: uv verwenden und den Source-Build für das Paket verbieten, dann zieht der Installer das fertige Wheel.
Danach lief alles glatt. Der Indexlauf auf unserem Repo dauerte 48 Sekunden und ergab 2.312 Symbole mit 3.136 Abhängigkeiten. Dabei respektiert Repowise die .gitignore, ließ also vendor und node_modules mit über 30.000 Dateien sauber links liegen. Am Ende stand eine Zahl, die uns neugierig machte: Von den 20 Dateien mit den schlechtesten Health-Scores hatten 5 in den letzten sechs Monaten einen Bugfix, mehr als das Elffache der Basisrate. Der Score scheint also tatsächlich etwas zu messen.
Das Test-Setup
Testobjekt war unsere eigene Website: Statamic auf Laravel, davor Alpine.js und Antlers-Templates. Als Vergleichskandidat trat tokensave an, ein Code-Graph-MCP-Server mit rund 100 feingranularen Werkzeugen. Getestet haben wir in Claude Code, die Antworten kämen aber in Codex oder Cursor identisch an, weil beide Tools schlicht MCP sprechen. Beide bekamen dieselben fünf Aufgaben:
Das Repository indexieren.
Eine Fachfrage beantworten: Wo wird die Newsletter-Anmeldung verarbeitet und welcher Bot-Schutz greift?
Die riskantesten Dateien des Projekts nennen.
Toten Code finden.
Die Abhängigkeiten eines Templates auflösen.
Runde 1: Indexierung
Repowise: 48 Sekunden. tokensave: Der erste Indexlauf hing nach über 70 Minuten immer noch, wir haben ihn abgebrochen. Der anschließende erzwungene Neuaufbau war dann in unter einer Sekunde fertig, die schwere Arbeit war also bereits erledigt. Trotzdem bleibt ein schiefes Bild: tokensave indexierte auch die minifizierten JavaScript-Bundles aus dem Build-Ordner, teilweise doppelt. Solche Artefakte blähen den Index auf und verfälschen später die Analysen.
Auf demselben Rechner lag übrigens noch ein älterer, falsch aufgesetzter tokensave-Index. Der hatte statt eines Projekts das halbe Benutzerverzeichnis erfasst, 43.000 Dateien und 3,6 Gigabyte, inklusive Paket-Caches und Mail-Anhängen. Auf Fragen zum Projekt antwortete er mit Rust-Code aus fremden Bibliotheken. Die Lehre daraus gilt für jedes Indexierungs-Tool: Nach dem Setup prüfen, was wirklich im Index gelandet ist.
Runde 2: Die Fachfrage
Bei der Newsletter-Frage lieferten beide Tools ab. tokensave fand die zuständige Gate-Klasse und zeigte den kompletten Code inline, inklusive Captcha-Verifikation und Rate-Limit. Die stärkste Einzelantwort im ganzen Test. Repowise brauchte zwei Anläufe, und genau das fanden wir bemerkenswert. Das erste Werkzeug verzichtete auf eine geratene Antwort und meldete stattdessen: keine Wiki-Daten vorhanden, nutze die Symbol-Suche. Die traf dann exakt, mit Dateipfaden und Zeilennummern für Listener und Bot-Schutz.
Dieses kalibrierte Eingeständnis ist mehr wert, als es klingt. Ein Tool, das bei dünner Datenlage lieber auf ein anderes Werkzeug verweist als zu raten, verhindert genau die Sorte Fehler, die bei KI-gestützter Entwicklung am teuersten ist: die überzeugend klingende Falschauskunft.
Runde 3: Riskante Dateien
Hier trennte sich das Feld. Repowise wertet die Git-Historie aus und nannte exakt die Dateien, die wir aus eigener Erfahrung als Baustellen kennen, allen voran das zentrale JavaScript und den am häufigsten umgebauten Service. tokensave hat keine Git-Schicht. Sein Hotspot-Begriff meint Graph-Konnektivität, und die höchste Konnektivität hatte eine forEach-Funktion aus dem minifizierten axios-Bundle. Formal korrekt gezählt, praktisch wertlos.
Für uns war diese Runde die wichtigste. Die Frage, wo eine Änderung wehtun wird, beantwortet kein Abhängigkeitsgraph allein. Dafür braucht es die Historie: Was wurde oft geändert, und wo saßen die letzten Bugs.
Runde 4: Toter Code und ein Fund, der keiner war
Dead-Code-Erkennung ist bei beiden Tools mit Vorsicht zu genießen, aus unterschiedlichen Gründen. Repowise fand echte Leichen, etwa eine verwaiste Livewire-Komponente, die seit über 400 Tagen niemand angefasst hat, und leere Sprachdateien. Daneben aber auch Fehlgriffe auf Framework-Ebene: Der zentrale ServiceProvider von Laravel wurde als sicher löschbar markiert, weil ihn keine Datei importiert. Dass Laravel ihn per Konvention lädt, weiß der Graph nicht.
tokensave leistete sich den gravierenderen Schnitzer. Es meldete private Methoden als toten Code, die drei Zeilen weiter in derselben Klasse aufgerufen werden. Wir haben es per grep gegengeprüft: Der Aufruf steht direkt im Code, das Tool sieht ihn schlicht nicht. Wenn die Aufruf-Auflösung innerhalb einer einzelnen PHP-Klasse versagt, kann man den Analysen zu Aufrufern und totem Code in diesem Sprachraum nicht trauen. Von den 116 gemeldeten Funden war ein Großteil dieser Sorte.
Runde 5: Templates, der blinde Fleck beider Tools
Die letzte Frage verloren beide. Welche Templates binden unser SEO-Snippet ein? Repowise kannte die Antlers-Datei gar nicht, tokensave meldete null Abhängigkeiten. Antlers parst keins der beiden Tools, und für Shopify-Arbeit gilt dasselbe: Liquid steht bei keinem auf der Sprachenliste. Wer wie wir viel in Template-Sprachen arbeitet, bekommt Codebase-Intelligence nur für die App-Code-Hälfte des Projekts. Das ist keine Kleinigkeit, denn gerade Template-Abhängigkeiten sind es, die bei Änderungen gern unbemerkt brechen.
Was wir nicht getestet haben
Fairerweise: Repowise trat bei uns mit angezogener Handbremse an. Die Wiki- und Decisions-Schicht, laut Anbieter das Herzstück für die großen Token-Ersparnisse, blieb ohne LLM-Key ungetestet. Auch das Lernen aus Claude-Code-Transkripten, bei dem durchgesetzte Konventionen automatisch in künftigen Kontext wandern, haben wir nicht bewertet. Die 96 Prozent aus der Doku können wir deshalb weder bestätigen noch widerlegen. Was wir bestätigen können: Schon die kostenlose Index-Schicht liefert brauchbare Antworten, und die Git-Analyse ist besser als alles, was wir bisher per MCP im Einsatz hatten.
Unser Fazit
Repowise gewinnt diesen Vergleich. Nicht wegen eines spektakulären Features, sondern wegen der Grundlagen: ein sauberer Index und ehrliche Confidence-Signale, dazu eine Git-Schicht, die im Alltag wirklich etwas beiträgt. tokensave punktete mit Code-Antworten inline und damit, dass es Markdown-Dokumentation mit indexiert. Sein PHP-Graph hat aber Löcher, die für uns disqualifizierend sind.
Bleibt die Einordnung ins große Bild. Codebase-Intelligence ist die dritte Ebene eines effizienten KI-Setups: RTK kürzt Befehlsausgaben, Headroom komprimiert den Kontext, und ein Tool wie Repowise sorgt dafür, dass der Agent von vornherein die richtigen Stellen kennt, statt zu suchen. Wie diese Bausteine zusammenspielen, zeigt unser AI-Coding-Werkzeug-Stack. Und wenn du dein eigenes Setup aufbauen willst: Melde dich bei uns.
Tobias Graeger
Inhaber & Shopify-Entwickler
Tobias leitet alle Projekte persönlich. Mit über 50 abgeschlossenen Shopify-Projekten kennt er die Plattform vom Liquid-Template bis zur API-Integration. Sein Fokus: technisch saubere Lösungen, die mit dem Business mitwachsen.
LinkedInHat dir der Beitrag gefallen?
Ein Klick reicht und wir wissen, welche Themen wir weiter vertiefen sollen.
Feedback konnte gerade nicht gespeichert werden.
Das könnte euch auch interessieren
Caveman Mode für Claude Code: kürzere Ausgaben, weniger Tokens
Caveman Mode lässt Claude Code wie ein Höhlenmensch antworten: Artikel und Füllwörter fallen weg, die technische Substanz bleibt. Wir zeigen Installation, Stufen und wo der Token-Vorteil real ist und wo nicht.
RTK installieren: Token-Kosten bei Claude Code, Codex & Cursor senken
RTK, der Rust Token Killer, ist ein token-optimierter CLI-Proxy, der Dev-Befehle vor der KI kürzt und laut Doku 60 bis 90 Prozent Tokens spart. Werkzeugübergreifend für Claude Code, Codex und Cursor. Wir zeigen, warum Claude Code so viele Tokens frisst, wie du RTK Schritt für Schritt einrichtest und was die Ersparnis in unserer Agentur-Praxis bringt, inklusive der Namens-Kollision, die viele in die Irre führt.