Litho (deepwiki-rs): C4-Dokumentation aus dem Code, mit einem LLM im Analysepfad

Das Problem: Architekturdokumentation, die den Commit nicht überlebt

Die README beschreibt den Ausgangszustand ungewöhnlich direkt: veraltete, unvollständige oder fehlende Dokumentation, manuelle Updates, die hinter den Codeänderungen zurückbleiben, inkonsistente Formatierung, und am Ende meist nur eine Handvoll Markdown-Dateien. Wer schon einmal ein Repository übernommen hat, in dem das docs-Verzeichnis zwei Jahre alt ist, erkennt das Muster. Die eigentliche Frage ist nicht, ob Dokumentation veraltet, sondern wer sie nachzieht und wann. Litho setzt an genau dieser Stelle an und verspricht, den Zustand aus dem Quellcode neu abzuleiten, statt ihn fortzuschreiben. Adressiert sind laut README Entwicklungsteams jeder Größe, Open-Source-Projekte und Enterprise-Entwickler. Praktisch relevant ist das vor allem dort, wo die Struktur groß genug ist, dass niemand sie im Kopf hat, und klein genug, dass kein Architekt dafür abgestellt wird. Ein weiterer Punkt aus der README ist die Zielgruppe der Werkzeuge selbst: Das Projekt wirbt mit Kontext, der für intelligente Agenten aufbereitet ist, nicht nur für menschliche Leser.

Der Analysepfad: Quellcode rein, C4-Ebenen raus

Litho ist laut README eine Engine, die Quellcode analysiert und daraus Architekturdiagramme im C4-Modell erzeugt: Context, Container, Component und Code. Dazu kommen nach eigener Beschreibung die Extraktion von Kommentaren, Strukturen und Beziehungen sowie ein Vorlagensystem für die Ausgabe. Die topics des Repositories nennen claude, deepseek, mistral, openai und openrouter, was darauf hindeutet, dass mehrere Anbieter als Modell-Backend angebunden sind. Wie die Pipeline im Einzelnen aufgebaut ist, welche Zwischenrepräsentation entsteht und wie die Diagramme gerendert werden, lässt sich aus dem vorliegenden Material nicht ableiten. Das ist eine echte Lücke, denn genau dort entscheidet sich die Qualität: Ein LLM, das über einen abstrahierten Codegraphen arbeitet, produziert andere Ergebnisse als eines, dem Dateiinhalte direkt vorgelegt werden. Die README nennt außerdem zwei Erweiterungen, die über reine Codeanalyse hinausgehen. Externe Wissensquellen lassen sich als Knowledge Sources einbinden, genannt werden PDF, Markdown und SQL. Und es gibt Datenbankdokumentation. Beides verschiebt den Charakter des Werkzeugs: Es dokumentiert dann nicht mehr nur, was im Repository steht, sondern auch, was daneben liegt.

Installation und Betrieb: crates.io, Modell-Endpunkt, Konfiguration

Vertrieben wird Litho als Crate namens deepwiki-rs, die README verlinkt die crates.io-Seite und die Dokumentation unter docs/en beziehungsweise docs/zh. Die naheliegende Installation ist damit cargo install deepwiki-rs. Für die eigentliche Ausführung ist ein Modellanbieter nötig; die Themenliste des Repositories und die beworbene Anbieterunterstützung legen nahe, dass Endpunkt und Schlüssel konfiguriert werden müssen. Konkrete Schlüsselnamen, Dateipfade oder Beispielaufrufe gibt die README an der vorliegenden Stelle nicht her. Wer das Werkzeug evaluiert, sollte deshalb zuerst die Dokumentationsseiten im Repository aufschlagen und die dortige Konfigurationsreferenz prüfen, statt Namen zu raten. Klar benannt ist dagegen ein Integrationsweg: Litho lässt sich in CI/CD-Pipelines einbinden, sodass die Dokumentation bei jedem Commit neu entsteht. Das verändert die Betriebsrechnung erheblich, weil dann nicht mehr ein Entwickler gelegentlich einen Lauf startet, sondern jeder Commit einen Modellaufruf auslöst. Die README spricht außerdem von Unterstützung für mehrere Programmiersprachen und nennt Rust, Python, Java, Go, C# und JavaScript.

Die Lizenz ist MIT, die Modellkosten sind es nicht

Der Code steht unter MIT, also einer permissiven Lizenz, die kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange Copyright-Hinweis und Lizenztext erhalten bleiben. Das ist für den Einsatz in einem Unternehmen die einfachste denkbare Ausgangslage. Der Hinweis auf die Lizenz des Quellcodes sagt allerdings nichts über die Kosten des Betriebs. Litho erzeugt die Dokumentation nach eigener Beschreibung mit einem LLM, und die topics des Repositories listen kommerzielle Anbieter. Ein CI-Lauf, der bei jedem Commit die gesamte Codebasis analysiert, ist ein wiederkehrender Posten, dessen Höhe von Modellwahl, Kontextlänge und Analysetiefe abhängt. Lizenzpflichten und Betriebskosten fallen hier auseinander, und die README behandelt nur die erste Seite. Wer die Kosten planen will, muss vor dem Rollout messen, wie viele Tokens ein Lauf über das eigene Repository tatsächlich verbraucht; aus dem Repository selbst lässt sich das nicht ableiten.

Wartung: das Projekt hat einen Nachfolger, und das ist die wichtigste Randnotiz

Die README enthält einen Hinweis, der jedes andere Argument überstimmt: Litho hat sich zu Terrain weiterentwickelt. Terrain wird als lebendige Karte der Codebasis für Agenten beschrieben, mit einer Wissensbasis, die synchron zum Code bleibt, breiterer Sprach- und Framework-Unterstützung, Anbindung an Agenten wie Claude Code, Codex und DeepSeek Harness über ACP sowie einem eingebauten Litho Book. Der entscheidende Satz steht daneben: Litho bleibt der schnelle, fokussierte C4-Dokumentationsgenerator. Das Repository ist nicht archiviert, und die letzte Veröffentlichung 1.5.0 stammt vom April 2026, der letzte Push vom August 2026. Wer neu einsteigt, sollte diese Aufteilung verstehen, bevor er Aufwand investiert: Litho ist nicht eingestellt, aber es ist auch nicht mehr die Stelle, an der die Weiterentwicklung stattfindet. Für eine Adoption heißt das, den Umfang bewusst zu wählen. Wer genau einen C4-Generator braucht, ist hier richtig. Wer eine dauerhaft gepflegte Wissensbasis für Agenten aufbauen will, wird auf Terrain verwiesen, und die README tut das selbst.

Grenzen: Modellabhängigkeit, kein Beleg für Diagrammformate, dünne Konfigurationsdokumentation

Die deutlichste Einschränkung folgt aus dem Entwurf. Wenn die Dokumentation von einem Modell erzeugt wird, ist sie nicht deterministisch: Zwei Läufe über denselben Commit können unterschiedliche Formulierungen und unterschiedlich gezogene Grenzen zwischen Komponenten liefern. Für einen Diff in der Versionskontrolle ist das unangenehm, weil jede Regenerierung Rauschen erzeugt, auch wenn sich am Code nichts geändert hat. Wer Dokumentation als prüfbares Artefakt braucht, etwa für Audits, bekommt hier ein Erzeugnis, dessen Reproduzierbarkeit von einem externen Dienst abhängt. Ein zweiter Punkt betrifft die Ausgabeform. Die README spricht durchgehend von Diagrammen, nennt aber kein Zielformat und kein Renderwerkzeug. Ob am Ende Mermaid, PlantUML oder etwas anderes entsteht, ist aus dem Material nicht zu klären; das ist vor einer Adoption zu prüfen, weil davon abhängt, ob die Diagramme in die eigene Dokumentationsplattform passen. Drittens die Betriebsdetails: Die README ist an der vorliegenden Stelle eine Feature- und Marketingseite. Konfigurationsschlüssel, Standardwerte, Umgang mit Ausschlussmustern, Grenzen bei großen Repositories und Fehlerverhalten bei nicht erreichbarem Modellendpunkt werden nicht genannt. Ein Werkzeug, das eine ganze Codebasis in einen Modellkontext bringen muss, stößt bei großen Monorepos an Grenzen; wie Litho damit umgeht, ob es chunkt, zusammenfasst oder abbricht, steht nicht im Material. Wer ein Repository mit mehreren hunderttausend Zeilen dokumentieren will, sollte das vorab an einem Teilbaum testen.

Alternative: Code-Analyse ohne Modell im Pfad

Der naheliegende Gegenentwurf ist ein Generator, der die Struktur direkt aus dem Code ableitet, etwa über einen Parser oder Compiler-Frontend, und daraus Diagramme und Referenzseiten baut. Der Unterschied liegt nicht im Ausgabeformat, sondern im Erzeugungsweg. Ein parserbasierter Generator ist deterministisch, läuft offline, kostet pro Lauf nichts und liefert bei unverändertem Code unveränderten Output. Dafür formuliert er keine Prosa: Er kann Abhängigkeiten, Module und Aufrufbeziehungen präzise auflisten, aber nicht erklären, warum ein Dienst so geschnitten ist. Litho setzt genau dort an und bezahlt mit Modellabhängigkeit. Die ehrliche Einordnung ist deshalb keine Entweder-oder-Frage. Für die Referenzebene, also Modullisten und Abhängigkeitsgraphen, ist der deterministische Weg überlegen. Für die erklärende Ebene, also Kontext- und Containerbeschreibungen, ist ein Sprachmodell das Werkzeug, das überhaupt Text produzieren kann. Wer Litho einsetzt, sollte sich bewusst sein, dass er die zweite Ebene kauft und die erste mitbezahlt.

Redaktionelles Fazit

Litho passt zu Teams, die eine bestehende, mehrsprachige Codebasis schnell mit einer C4-orientierten Wiki-Struktur hinterlegen wollen und dafür einen LLM-Anbieter konfigurieren können. Wer deterministische, offline reproduzierbare Dokumentation braucht oder keine API-Schlüssel in der Build-Umgebung zulassen darf, sollte es nicht einsetzen. Vor dem Ausrollen ist zu klären, welche Konfigurationsschlüssel die eigene Version tatsächlich liest und ob die generierten Diagramme im Zielformat vorliegen, denn beides lässt sich aus der README allein nicht belegen.

Offizielle Quellen

1. License: MIT
2. Project website
3. README
4. Releases
5. sopaco/deepwiki-rs on GitHub