Stefan Zörner
03.08.2026
DeepWiki von Cognition versteht sich als AI-Dokumentation, in der sich trefflich stöbern lässt. Und Chatten kann man mit ihr auch. Mittlerweile gibt es verschiedene Nachahmer des kommerziellen Tools, auch aus dem Open-Source-Umfeld. Schreiben wir Architekturdokumentation bald nicht mehr selbst?
Neulich machte ich im Austausch mit Claude.ai eine interessante Beobachtung. Bei Fragen rund um Implementierungsdetails von PlantUML verwies die AI in Antworten wiederholt auf DeepWiki als Quelle. Dazu muss man wissen: DeepWiki ist AI-generierte Dokumentation. Normalerweise würde ich mit der offiziellen Webseite von PlantUML oder anderen verlässlichen Ressourcen (z.B. The Hitchhiker’s Guide to PlantUML) als Beleg rechnen. Eine AI zitiert eine andere AI – verrückt.
DeepWiki leitet aus einem Repository eine strukturierte Dokumentation ab. Inhalt sind Texte mit Verweisen auf den zugrunde liegenden Quellcode und Abbildungen in Mermaid, z.B. Überblicksdiagramme zur Struktur oder ausgewählte Abläufe.
Which repo would you like to understand? (DeepWiki-Slogan)
Die proprietäre Lösung stammt von Cognition, der Hersteller bietet DeepWiki als Software-as-a-Service im Rahmen seiner Devin-Produkte an.
Für öffentliche Repositories ist die Verwendung von DeepWiki kostenlos. Viele prominente Open-Source-Lösungen sind dort bereits indexiert, z.B. das Spring Framework oder Visual Studio Code. Und auch PlantUML, weswegen Claude es zitiert hat. Tatsächlich hat Cognition den Index zum Start im Mai 2025 mit über 50.000 der populärsten öffentlichen Repos vorbefüllt und betreibt einen kostenlosen, remote und ohne Authentifizierung nutzbaren MCP-Server (kurz für Model Context Protocol, Details siehe Cognition-Blog).
Abb. 1 zeigt die Startseite von DeepWiki. Auf dieser könnt ihr nach bereits erzeugten Wikis suchen und auch euer eigenes (public) Repo zum Analysieren angeben.
Ich habe das für den Java-Quelltext meines arc42-Beispiels DokChess, der öffentlich auf GitHub bereitsteht, gemacht und mich in eine Warteschlange eingereiht. Wenige Stunden später erhielt ich eine E-Mail: “We’ve finished indexing your repo. You can view the wiki at the following link: …”. Das Ergebnis könnt ihr hier auf DeepWiki einsehen. Abb. 2 zeigt einen Screenshot daraus.
Die inhaltliche Qualität der generierten Seiten, inklusive wichtiger Abläufe in Form von Sequenzdiagrammen, kann sich sehen lassen. Darüber hinaus bietet die Oberfläche von DeepWiki auch ein Chat-Interface an, um Fragen zur Lösung zu stellen (in Abb. 2 unten im Bild zu sehen).
Ich wollte beispielsweise wissen, ob DokChess auch Dame spielen kann. Die Antwort war erwartungskonform und korrekt “nein”. Fundiert begründet mit Nennung zahlreicher schachspezifischer Schnittstellen, Konzepte und Implementierungen in DokChess.
Ja, es ist theoretisch möglich, DokChess zu erweitern, um Dame zu spielen, aber es wäre sehr aufwändig und erfordert erhebliche architektonische Änderungen … (DeepWiki im Chat)
Auch die Frage, ob es schwierig wäre, es um Dame-spezifische Dinge zu erweitern, und wie ich das angehen könnte, wurde zufriedenstellend beantwortet (Anfang der Antwort siehe oben). Mit Bezügen zum Quelltext, Vorschlägen für Abstraktionen und der Identifikation wiederverwendbarer Teile, wie etwa der Minimax-Implementierung. Ich war beeindruckt. Ist das die Zukunft der Architekturdokumentation?
DeepWiki erschien in einer ersten Fassung bereits im Frühjahr 2025. Mittlerweile findet sich einiges an davon inspirierter Software im Internet, so stellte Google beispielsweise Ende 2025 Google Code Wiki vor, siehe Abb. 3 oder auch Ranja2025.
Viele Unternehmen und Organisationen haben allerdings mit DeepWiki (und anderen proprietären Software-as-a-Service-Angeboten) ein Problem. Sie sind nicht bereit, ihren oft schützenswerten Quelltext einem Internet-Dienst zu überlassen, der ihn womöglich intransparent an Dritte und deren Sprachmodelle weiterreicht.
Da es mittlerweile aber auch einige frei verfügbare “Nachahmer” von DeepWiki gibt, liegt eine Lösung auf der Hand: Man betreibt die Software zum Generieren der Dokumentation, die Zugriff auf den Quelltext benötigt, selbst. Die verfügbaren Implementierungen unterscheiden sich im Detail, schauen wir uns das genauer an!
Einer der frühesten Nachbauten aus dem Open-Source-Umfeld ist DeepWiki-Open. Es hat eine Zwei-Schicht-Architektur mit browserbasiertem Frontend in TypeScript (Screenshot der Startseite siehe Abb. 4) und Python-Backend, das die Sprachmodelle per API anspricht.
DeepWiki-Open versucht seine “Vorlage” von oben funktional nachzubilden. Über das Frontend lassen sich die bereits generierten Wikis durchsehen. Nach Angabe einer Repository-URL erzeugt die Software zusätzliche Dokumentation oder aktualisiert sie bei Bedarf. Auch ein AI-Chat steht bereit.
Während beim ursprünglichen DeepWiki die genaue Funktionsweise nicht offenliegt, ist der Quelltext von DeepWiki-Open auf GitHub einsehbar, er steht unter MIT-Lizenz. Wir können also untersuchen, wie es im Detail arbeitet.
Abb. 5 zeigt zum Einstieg eine Kontextabgrenzung von DeepWiki-Open im Zusammenspiel mit Nutzergruppen und Fremdsystemen. Auf der rechten Seite sind neben dem Git-Hosting die Provider für AI-Modelle zu sehen, mit denen DeepWiki-Open interagiert. Es ist da per Konfiguration sehr flexibel, was Anbieter und Large Language Models (kurz LLMs) angeht. Neben Inferenz in der Cloud z.B. über OpenRouter mit Modellen von OpenAI, Anthropic und Co., unterstützt es auch selbst betriebene Open-Weight-Modelle in Ollama.
Wer es genauer wissen will: Abb. 6 zeigt den Ablauf einer Wiki-Generierung als Sequenzdiagramm. Nach Angabe der Repository-URL liest DeepWiki-Open zunächst nur Dateibaum und README über die API des Git-Hosters ein. Erst dann klont es den Quelltext, vektorisiert ihn Chunk-weise und baut mit den Embeddings einen FAISS-Index für RAG auf (FAISS = Facebook AI Similarity Search, RAG = Retrieval-Augmented Generation).
Anschließend erstellt DeepWiki-Open aus dem README und dem Dateibaum mit einem LLM die Struktur des Wikis. Daraus generiert es dann, ebenfalls per LLM und diesmal unter Zuhilfenahme von RAG, die einzelnen Wikiseiten in Markdown mit eingebettetem Mermaid. Die Orchestrierung des Ablaufs liegt im Frontend. Das Backend reichert die vom Frontend formulierten Prompts mit Kontext an. Es hält dazu keinen Zustand, legt Index und Wiki-Cache aber im Dateisystem ab.
Im Wiki lässt sich dann stöbern und mit ihm chatten. Die Inhalte stehen auch als Download bereit, wenn man sie anderweitig weiterverarbeiten möchte. Abb. 7 zeigt den Ausschnitt einer Ausgabe von DeepWiki-Open für DokChess gegen das Open-Weight-Modell Qwen3 (32B) in einem selbst betriebenen Ollama.
Bei DeepWiki-Open ist es nicht geblieben. GitHub ist gut bevölkert mit Projekten in unterschiedlichsten Programmiersprachen und Reifestadien, und es kommen regelmäßig neue dazu. Hier einige Beispiele:
Besonders spannend finde ich Lösungen, bei denen sich die Generierung per Kommandozeile anstoßen lässt. Sie lassen sich leichter in eine CI/CD-Pipeline integrieren als z.B. DeepWiki-Open. Dort findet der Workflow in JavaScript im Browser statt. Eine Architekturentscheidung, die nicht unmittelbar zur Resilienz beiträgt. Wer während der Generierung aus Versehen das Browser-Tab schließt, kann die Generierung nur neu anstoßen.
Zu den Lösungen, die komplett über Kommandozeile laufen, gehört neben deepwiki-rs das vergleichsweise junge CodeWiki von FPT Software und der University of Melbourne, nicht zu verwechseln mit dem fast gleichnamigen Angebot von Google oben.
CodeWiki ist in Python realisiert und steht ebenfalls unter MIT-Lizenz. Die Arbeitsweise unterscheidet sich stark von DeepWiki-Open. Kernidee ist eine erste Phase, die den Quelltext parst und daraus AST-gestützt (AST, kurz für Abstract Syntax Tree) eine Baumstruktur aufbaut. CodeWiki unterstützt dafür eine begrenzte Menge an Programmiersprachen (aktuell aber immerhin sieben Stück, darunter C++, Java und Python). Die nachfolgende Modularisierung und die Erzeugung der eigentlichen Dokumentation erfolgen dann LLM-gestützt, wobei CodeWiki ähnlich zu DeepWiki-Open unterschiedliche Provider ansprechen kann. Darunter auch ein selbst betriebenes Ollama mit Open-Weight-Modellen.
CodeWiki nutzt dabei keinen RAG-Ansatz und bietet auch keinen Chat. Es produziert einfach eine Dokumentation aus Markdown-Dateien und Mermaid-Diagrammen, die sich dann mit einem geeigneten HTML-Wrapper im Browser erkunden lässt. Zur Illustration siehe Abb. 8 mit einem Ausschnitt einer mit CodeWiki erzeugten Dokumentation (LLM: DeepSeek V4 Flash).
Das Paper “CodeWiki: Evaluating AI’s Ability to Generate Holistic Documentation for Large-Scale Codebases” (siehe Hoang+2026) beschreibt die zugrundeliegenden Ideen genauer und liefert auch Benchmarks bezüglich der generierten Inhalte, u.a. gegen DeepWiki und DeepWiki-Open. Es vergleicht die Ergebnisse für die unterschiedlichen DeepWiki-Varianten mit CodeWiki inhaltlich, macht allerdings keine Aussagen über Laufzeiten.
Das Ableiten einer Doku mit DeepWiki & Co dauert durchaus Zeit und kann je nach Betriebsmodell auch ins Geld gehen. Beim Original wissen wir die Dauer nicht ganz genau, weil wir uns in eine Warteschlange einreihen. Bei selbst gehosteten Nachbauten wie CodeWiki lässt sich das natürlich messen.
Damit ihr eine Idee bekommt: Tabelle 1 zeigt Daten, die ich mit CodeWiki gesammelt habe. Die Software lief dabei in der Hetzner-Cloud und griff über OpenRouter auf das LLM zu (jeweils Qwen3 Coder Flash). Die Dauer der Generierung hängt von vielen Faktoren ab. Insbesondere vom Umfang des Repos, und wie tief sich CodeWiki in den Quelltext hineinbohren soll. Auch die Wahl des LLMs und zugehörige Parameter spielen eine Rolle, nicht nur für die Laufzeit, sondern auch für die Qualität der generierten Dokumentation.
Die Kosten variieren je nach LLM und Abrechnungsmodell ebenfalls stark. Als ein Vergleichspunkt: Das gleiche Setting mit OpenRouter lag mit Claude Sonnet 5 für DokChess bei 3,62 US-Dollar (die Dauer der Generierung war mit 21:54 Minuten etwas schneller). Das sind die reinen LLM-Kosten. Die Hetzner-Cloud schlägt auch noch zu Buche, und ein Modell als Alternative mit Ollama selber zu hosten ist auch nicht umsonst.
| Software (Repo verlinkt) | Umfang des Quelltextes | Ergebnis, Anzahl generierter Markdown-Dateien | Dauer der Generierung in Stunden (hh:mm:ss) | Kosten (OpenRouter, Qwen3 Coder Flash) |
|---|---|---|---|---|
| umoria | 51 C++- und 26 Header-Dateien, 23.9k LOC | 10 (1.897 Zeilen) | 00:10:15 | 0,26 $ |
| dokchess-en | 77 Java-Dateien, 4.1k LOC |
28 (4.011 Zeilen) | 00:24:31 | 0,56 $ |
| pixel-dungeon | 505 Java-Dateien, 40.8k LOC |
79 (13.323 Zeilen) | 01:26:48 | 1,88 $ |
Bei den dokumentierten Software-Systemen in der Tabelle handelt es sich übrigens um überschaubare Repos. DokChess ist klein, und auch das mit textbasierter Graphik ausgestattete The Dungeons of Moria (C++) und die Android-App Pixel Dungeon haben lediglich 5-stellige Lines of Code (LOC). Im Paper beschreiben die Autoren von CodeWiki auch Läufe mit deutlich größeren Repos, bis 1.446 k LOC in C.
Die Zeiten und Kosten lassen sich wegen der vielen unterschiedlichen Konfigurationsmöglichkeiten (LLM, LLM-Provider, Laufzeitumgebung, Konfiguration LLM und CodeWiki …) nicht leicht übertragen. Sie geben euch eine Idee, mit was ihr rechnen müsst, bevor ihr es selber mal ausprobiert.
CodeWiki ist meiner Erfahrung nach diesbezüglich weniger frickelig in Betrieb zu nehmen als DeepWiki-Open. Insbesondere bei einem selbst betriebenen Open-Weight-Modell. Es ist mein aktueller Favorit. Ich habe auch Läufe gegen Ollama damit gemacht, lokal auf einem modernen MacBook Pro und in der Hetzner-Cloud. Die Sachen liefen dann noch etwas länger.
Bei großen Repos reden wir auf jeden Fall eher über Stunden als über Minuten für eine Generierung. Was die Frage aufwirft, wie oft man Doku in einem realen Entwicklungsprojekt in dieser Form aktualisieren möchte. Und auch, was passiert, wenn man aktualisiert.
Berücksichtigt man tatsächlich nur Änderungen oder baut man sie komplett neu? Da das Ergebnis nicht reproduzierbar ist, kann ein neu generiertes Wiki komplett anders aussehen. Nicht nur in Nuancen, sondern durchaus auch im Aufbau des Wikis. Einige DeepWiki-Klone adressieren dieses Problem mit strukturerhaltenden Maßnahmen.
Eine interessante Herausforderung stellen für die Werkzeuge verteilte Systeme dar, die nicht in einem einzelnen Repo wohnen. Microservices-Lösungen beispielsweise, oder einfacher noch Front- und Backend in getrennten Repositories. Die Verbindung müsst ihr aktuell selber schaffen.
Weiterhin beschreiben die Tools die Repositories regelmäßig sehr ausführlich. Gute Architekturdokumentation ist pointiert und lässt Implementierungsdetails aus. Wer entscheiden will, was wichtig genug ist, um erklärt zu werden, muss die Ziele des Vorhabens kennen. Und die stehen nicht im Quelltext.
DeepWiki und verwandte Ansätze abstrahieren den Quelltext und leiten eine strukturierte und navigierbare Dokumentation ab. Das können auch konventionelle Werkzeuge ganz ohne GenAI bewerkstelligen. Nämlich solche, die sich auf das Parsen des Quelltextes und statische Code-Analyse verstehen. So ist Doxygen beispielsweise seit langem in der Lage, für umfangreiche Repositories eine navigierbare Dokumentation abzuleiten. Quelltextkommentare finden sich dort an passender Stelle wieder, falls es welche gibt.
Genau diese Lücke schließen DeepWiki und seine Artverwandten durch das Generieren von Texten. Ob diese tatsächlich stimmig sind, solltet ihr auf jeden Fall für eure Vorhaben prüfen. Es ist je nach LLM regelmäßig verblüffend, was dort allein aus den Bezeichnern im Quelltext zusammengefabelt wird, wenn Informationen aus Kommentaren fehlen. Falls die Fachlichkeit im genutzten LLM verankert ist, wie etwa beim Computer-Schach, überraschen die Kommentare durchaus. Sie können aber auch falsche Sicherheit suggerieren.
Nun stellt sich allerdings die Frage, wer die Inhalte prüfen soll, und wie. Die Generierung dauert vielleicht nur eine Stunde und kostet wenige Euro. Aber das Review? Für Pixel Dungeon sind über 13.000 Zeilen Markdown entstanden. Niemand liest das gern Korrektur.
Der Quelltext erzählt nicht die ganze Geschichte.
(Simon Brown in Software Architecture for Developers)
Ohnehin bleiben DeepWiki und seinen Verwandten bestimmte Aspekte auch völlig verborgen. Sie können sich den Technologie-Stack und ggf. auch Muster erschließen. Aber ob der Einsatz eines Frameworks eine Vorgabe war oder eine Entscheidung des Entwicklungsteams, können sie nicht ermitteln. Und falls es eine Entscheidung war, lassen sich in der Regel weder betrachtete Alternativen noch die Beweggründe sicher rekonstruieren. Auch die Zielsetzung des Vorhabens und Annahmen, die das Team getroffen hat, lassen sich nicht aus dem Quelltext herauslesen.
DeepWiki und seine Nachbauten sind nicht die Zukunft der Architekturdokumentation. Die Werkzeuge helfen dabei, auch große Quelltextmengen aufzuschließen. Eine Nachvollziehbarkeit der Lösung erreichen sie aber nicht. Ihr Output ist gut aufbereitete Code-Dokumentation, keine Architekturdokumentation. Aber die Tools sind immerhin das Ende der Ausrede, dass es für ein Legacy-System überhaupt keine Doku gibt.
Möglicherweise sind die Konsumenten dieser Texte ohnehin immer seltener Menschen und immer öfter AI-Lösungen, mit denen wir im Dialog stehen. Wie zu Beginn meines Beitrags geschildert. Statt PDFs zu wälzen oder uns in Wikis zu verlieren, chatten wir künftig mit etwas, das sich Quelltext und Zusammenhänge erschließt. DeepWiki & Co. werden sich in Laufzeiten und Qualität der Ausgabe noch verbessern.
Gleichwohl kann auch dieser Gesprächspartner nur wiedergeben, was irgendwo steht. Ziele, Randbedingungen und die Beweggründe hinter Entscheidungen gehören nach wie vor festgehalten. Von denen, die sie erarbeitet und getroffen haben.