Das LLM-Wiki nach Andrej Karpathy: Ein Paradigmenwechsel im KI-gestützten Wissensmanagement

Wissensmanagementsysteme in Unternehmen und Projekten leiden historisch unter einem fundamentalen Problem: Sie kollabieren unter ihrer eigenen Last (vgl. Boudro, 2026)^[1]. Je mehr Dokumentation geschrieben wird, desto schwieriger wird es, sie aktuell, konsistent und durchsuchbar zu halten – eine Herausforderung, die auch in aktuellen Industrieeinschätzungen zur Datenfragmentierung (vgl. Microsoft, 2026)^[2] als zentraler Engpass identifiziert wird. Traditionelle Abhilfe versprachen zuletzt Retrieval-Augmented Generation (RAG) Systeme (grundlegend eingeführt durch Lewis et al., 2020)^[3], die mittels Vektordatenbanken semantische Suchen über riesige Dokumentenberge ermöglichen und die gefundenen Informationen als Kontext direkt in die Textgenerierung der KI einspeisen.

Im Frühjahr 2026 stieß der KI-Forscher Andrej Karpathy mit einem vielbeachteten Konzept eine alternative Denkrichtung an: Das LLM-Wiki (vgl. Karpathy, 2026)^[4]. Statt eine KI lediglich als intelligentes Suchwerkzeug über unstrukturierten Daten (RAG) einzusetzen, wird die KI zum aktiven Kurator und Maintainer einer strukturierten, menschenlesbaren Wissensbasis. Die Resonanz auf diesen Architekturansatz war enorm; entsprechende Open-Source-Implementierungen erreichten binnen kürzester Zeit Tausende von Sternen auf GitHub (vgl. GitHub, 2026)^[5].

Dieser Artikel fokussiert die Architektur dieses Konzepts, grenzt es von klassischen RAG-Ansätzen ab und untersucht kritisch das Potenzial sowie die Grenzen dieser Methode – insbesondere als Vorstufe für autonome agentische Systeme.

1. Das Kernkonzept: Wissenspflege als Systemarchitektur

Das LLM-Wiki ist, wie Boudro (2026) treffend formuliert, kein fertiges Softwareprodukt, sondern ein Architektur-Pattern. Es nutzt Large Language Models (LLMs) – häufig gekoppelt mit lokalen Coding-Agenten wie Claude Code –, um aus unstrukturierten Rohdaten (Dokumente, Transkripte, Tickets) eine hochstrukturierte, vernetzte Markdown-Wissensbasis aufzubauen.

Die Architektur basiert auf einer strikten Trennung in drei Schichten (Boudro, 2026; Gahn, 2026)^[1][6]:

Schicht 1: raw/ (Die unveränderliche Quelle der Wahrheit)

In diesem Verzeichnis landen alle Ursprungsdokumente in ihrem Rohformat. Wichtig ist hier die strikte Trennung von primären Arbeitsdaten und dem historischen Wissen. Das Prinzip lässt sich auf unterschiedlichste Domänen anwenden:

• Beispiel Projekt- und Unternehmenswissen: Hier landen Meeting-Transkripte, unterzeichnete Verträge, PDF-Handbücher, HR-Richtlinien oder finale Konzeptpapiere. Die eigentlichen operativen Daten verbleiben in den jeweiligen Fachsystemen (z. B. ERP oder CRM); das Wiki speichert lediglich die Belege und getroffenen Entscheidungen.
• Beispiel Softwareentwicklung: Hier landen geschlossene Tickets, Architektur-Entscheidungen (ADRs) oder Pull-Request-Zusammenfassungen. Der eigentliche Quellcode wird weiterhin klassisch in einem Versionskontrollsystem (wie Git) versioniert; das Wiki speichert keine Code-Repositories, sondern lediglich die Dokumentation der Projektentwicklung.

Diese Dateien im raw/-Ordner sind „immutable“ (unveränderlich). Dies folgt einem Prinzip ähnlich dem Event Sourcing^[7]: Ein einmal erfasstes Dokument dokumentiert historisch, warum und wie sich ein Projekt oder System zu einem bestimmten Zeitpunkt verändert hat. Entwickelt sich das Projekt permanent weiter, wird das alte Belegdokument nicht umgeschrieben; stattdessen landet ein neues Dokument (z. B. ein neues Transkript oder Ticket) als aktueller Baustein im Ordner. So bildet der raw/-Ordner eine unbestechliche, chronologische Faktenbasis für das aktuelle Wissen, die stets synchron zur realen Projektwelt (z. B. dem aktuellen Git-Stand) ist.

Schicht 2: wiki/ (Der synthetisierte Knowledge Layer)

Dies ist das eigentliche “Zweite Gehirn”. Das LLM liest die Rohdaten und generiert daraus strukturierte Markdown-Dateien. Das Wissen wird hierbei synthetisiert, zusammengefasst und durch Wikilinks ([[Konzept]]) netzwerkartig miteinander verknüpft. Diese Schicht ist sowohl für Maschinen (Agenten) als auch für Menschen optimal lesbar, durchsuchbar und visuell als Graph erfassbar.

Exkurs: Die Wahl des Werkzeugs (VS Code vs. Obsidian)

Das LLM-Wiki basiert architektonisch auf reinem Markdown und kann mit jedem Standard-Editor (wie Notepad++, VS Code) gelesen und gepflegt werden. Die häufige Nennung spezialisierter Frontends wie Obsidian (Gahn, 2026)^[6] erklärt sich durch deren Umgang mit den charakteristischen Wikilinks: Sie wandeln die Textklammern ([[Konzept]]) in klickbare Navigationen, interaktive Wissensgraphen und automatische Rückverweise (Backlinks) um. Architektonisch bleibt das System jedoch völlig werkzeugagnostisch und bewahrt Nutzer vor einem Vendor-Lock-in.

Schicht 3: AGENTS.md – Die Governance

Diese Schicht definiert die Spielregeln. Während Karpathy in seinem ursprünglichen Setup noch werkzeugspezifisch eine CLAUDE.md nutzte, etabliert sich in plattformunabhängigen Architekturen hierfür meist eine zentrale AGENTS.md oder ein dediziertes Schema-Dokument. Sie enthält Metaprompts, Konventionen und Schemata, wie das Wiki aufgebaut sein muss. Hier wird festgelegt, wie Metadaten (Frontmatter) zu formatieren sind, wie mit Widersprüchen umzugehen ist und welche formale Struktur ein Wissensobjekt haben muss (vgl. Karpathy, 2026)^[4].

Zwei einfache Beispiele für solche Regeln aus der Praxis:

• Metadaten-Zwang: “Jede generierte Wiki-Seite muss im Kopfbereich (Frontmatter) zwingend die Felder last_verified: [Datum] und source_of_truth: [Dateiname] enthalten.”
• Umgang mit Widersprüchen: “Wenn Informationen aus einer neu eingelesenen Rohdatei dem bestehenden Wissen widersprechen, darfst du als KI den alten Text nicht stillschweigend überschreiben. Füge stattdessen einen Abschnitt “Konflikt” ein und stelle die abweichenden Fakten zur menschlichen Klärung gegenüber.”

2. Die Mechanik: Ingest, Query und Lint

Ein LLM-Wiki ist kein statisches Archiv, sondern ein dynamisches System, das durch drei operative Kernprozesse am Leben gehalten wird (Boudro, 2026; Gahn, 2026)^[1][6]:

• Ingest (Aufnahme): Wenn eine neue Datei im raw/-Ordner abgelegt wird, tritt das LLM nicht automatisch durch einen Hintergrunddienst in Aktion, sondern der Prozess wird aktiv getriggert. Dies geschieht typischerweise manuell durch den Nutzer (z. B. über einen CLI-Befehl wie /wiki-ingest in Claude Code). Sobald der Ingest ausgelöst ist, analysiert das Modell das neue Dokument, extrahiert die Kernkonzepte, aktualisiert bestehende Wiki-Seiten, erstellt bei Bedarf neue Seiten und webt die neuen Informationen über Wikilinks in den bestehenden Wissensgraphen ein.
• Query (Abfrage): Die Beantwortung von Fragen. Das LLM nutzt das hochstrukturierte wiki/-Verzeichnis, um präzise, faktenbasierte und stets mit Quellen belegte Antworten zu generieren.
• Lint (Gesundheitsprüfung): Dies ist der vielleicht wichtigste und innovativste Schritt. Ähnlich einem Code-Linter durchsucht das LLM regelmäßig das Wiki nach strukturellen und inhaltlichen Fehlern. Dedizierte Open-Source-Tools wie der llm-wiki-compiler prüfen dabei auf verwaiste Seiten (Orphans), Widersprüche (Contradictions), Abweichungen von der definierten Struktur (Schema Drift) und veraltete Informationen (Staleness) (vgl. ClaudePluginHub, 2026)^[6].

3. Paradigmenwechsel: Warum Markdown RAG überlegen sein kann

Die klassische Herangehensweise der letzten Jahre, um KI-Modellen spezifisches Firmenwissen beizubringen, war RAG (Retrieval-Augmented Generation). Um den Paradigmenwechsel des LLM-Wikis zu verstehen, hilft ein kurzer Blick auf dieses Prinzip: Da ein Standard-LLM von Haus aus keine internen Projektdaten kennt, wird ihm bei RAG eine intelligente Suchmaschine vorgeschaltet. Dabei werden alle vorhandenen Unternehmensdokumente zunächst in kleine Textabschnitte („Chunks“) zerteilt, in mathematische Repräsentationen (Vektoren) umgewandelt und in einer speziellen Datenbank gespeichert. Stellt ein Nutzer eine Frage, sucht das System nach den Textstücken, die der Bedeutung der Frage am nächsten kommen. Diese Handvoll gefundener Schnipsel wird dem LLM dann wie ein „Spickzettel“ übergeben, aus dem es die finale Antwort formulieren soll. In der Praxis stoßen solche Systeme bei sehr großen, sich oft ändernden Datenmengen jedoch schnell an architektonische und kontextuelle Grenzen (vgl. z.B. diese Reddit-Diskussion).

Das Karpathy-Muster dreht den Ansatz um und bietet spezifische Vorteile:

1. Transparenz und Erklärbarkeit: Vektordatenbanken sind “Blackboxen”. Ein LLM-Wiki besteht aus reinem Markdown. Der Mensch kann den Wissensgraphen visuell inspizieren, Fehler manuell korrigieren und die Relationen zwischen Konzepten physisch sehen (Gahn, 2026)^[6].
2. Kognitive Kompression: RAG pumpt bei jeder Anfrage rohe Chunks in den Kontext des Modells, die sich oft wiederholen oder widersprechen. Das LLM-Wiki hat diesen Synthese-Schritt bereits vor der Abfrage (beim Ingest) erledigt. Das Resultat ist eine deutlich höhere Token-Effizienz (weniger Kontext-Verbrauch bei Abfragen) und eine präzisere Antwortqualität.
3. Wissens-Evolution: Während eine klassische, unstrukturierte Dokumentenablage im Laufe der Zeit unweigerlich im Chaos versinkt, wächst das LLM-Wiki organisch zu einer “persönlichen persistenten Wissensquelle” heran (Prosch, 2026)^[8]. Die KI aktualisiert aktiv den Status Quo der Wahrheit.

4. Kritische Würdigung: Die Grenzen der Delegation

Obwohl das Konzept in der Open-Source-Community Erfolge feiert, stößt es in der Praxis und aus erkenntnistheoretischer Sicht auf berechtigte Kritikpunkte, die bei einer Implementierung zwingend berücksichtigt werden müssen (vgl. z.B. auch Christopher Schack (2026)^[9]):

• Der Verlust der kognitiven Synthese: Der eigentliche Wert eines “Second Brains” (wie der Zettelkasten-Methode) liegt nicht in der reinen Ablage von Wissen liegt, sondern im Akt des Verknüpfens. Wenn ein LLM-Agent festlegt, welche Konzepte miteinander verwandt sind, wird dem Menschen der wichtigste Teil des Denkens abgenommen. Das Wiki droht zur maschinellen Infrastruktur zu werden, deren innere Logik der Nutzer schlimmstenfalls nicht mehr durchdringt.
• Staleness und Drift-Risiken: Sobald die Menge an generiertem Wiki-Markdown eine gewisse Größe erreicht, wird das “Linting” fehleranfällig. Ohne strenge Governance und Metadaten (wie Validierungs-Zeitstempel) besteht die Gefahr, dass die KI alte Wahrheiten nicht überschreibt, sondern inkonsistente Parallel-Wahrheiten generiert. Die Entwicklung dedizierter Compiler-Tools (wie auf dem ClaudePluginHub zu sehen) zeigt, dass “Freshness” (Aktualität) kontinuierlich durch empirische Stichproben auditiert werden muss, da Modelle dazu neigen können, abweichende Systemzustände zu übersehen.
• Die “Alles-ist-Text”-Illusion: Das Modell funktioniert hervorragend für maschinenlesbare Konzepte, stößt aber an architektonische Grenzen, wenn das Wissen aus Architektur-Skizzen, gescannten Dokumenten oder handschriftlichen Notizen besteht.

5. Fazit: Das Fundament für Agentic AI

Trotz berechtigter Kritikpunkte und anfänglicher Hürden zeigt die Entwicklung eine klare Tendenz, die von frühen Adoptern durch erfolgreiche Praxiseinsätze in IT-Projekten untermauert wird: Das LLM-Wiki nach Karpathy ist weniger ein Ersatz für persönliche Notizen und vielmehr ein Knowledge Layer für Systeme. Wie Artur Kokoev (2026)^[10] anhand seiner eigenen Projekte treffend beobachtet, verschiebt sich in der KI-Welt die teilbare Einheit von der bloßen Code-Implementierung hin zum Konzept (“Das Konzept ist die teilbare Einheit. Dein Agent baut die Implementierung”).

Genau hier offenbart der Ansatz sein wahres Potenzial: Nicht primär als Endprodukt für den menschlichen Leser, sondern als verlässliche, strukturierte Wahrheitsquelle für autonome KI-Agenten. Wenn ein KI-Agent in der Lage sein soll, eigenständig Code zu schreiben, Architekturen zu bewerten oder Prozesse auszuführen, benötigt er genau dieses Fundament – eine maschinenlesbare, auditierbare und persistente Definition der Systemrealität.

Wie sich dieser theoretische Knowledge Layer konkret als Herzstück einer skalierbaren Agentic AI Architektur implementieren lässt – um nicht nur passives Wissen zu verwalten, sondern proaktive Entwicklungs- und Governance-Prozesse (wie Audits, Verifikationen und Release-Gates) zu steuern –, wird Gegenstand des nachfolgenden zweiten Artikels sein.

---

References

1. Dylan Boudro (2026): How to Build Karpathy's LLM Wiki: The Complete Guide to AI-Maintained Knowledge Bases. DEV Community / Starmorph 2026, visited: 27.06.2026.
2. Microsoft (2026): Announcing Knowledge as a Service for Azure Logic Apps. Microsoft Community Hub 2026, visited: 27.06.2026.
3. Patrick Lewis and Ethan Perez and Aleksandra Piktus and Fabio Petroni and Vladimir Karpukhin and Naman Goyal and Heinrich Küttler and Mike Lewis and Wen-tau Yih and Tim Rocktäschel and Sebastian Riedel and Douwe Kiela (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In: Advances in Neural Information Processing Systems (NeurIPS), 2020.
4. Andrej Karpathy (2026): llm-wiki.md. GitHub Gist 2026, visited: 27.06.2026, (Konzeptioneller Ursprung des LLM-Wiki-Ansatzes.).
5. GitHub (2026): karpathy/llm-wiki.md – GitHub Gist Repository. 2026, visited: 27.06.2026, (Repository und Community-Kommentare.).
6. Florian Gahn (2026): Claude Code + Obsidian: So baut Karpathy ein KI-Second-Brain ohne Vektordatenbank. florian-gahn.de 2026, visited: 27.06.2026.
7. Martin Fowler (2005): Event Sourcing. 2005, (Kanonisches Architektur-Grundlagenwerk zum Event-Sourcing-Pattern).
8. Nick Prosch (2026): Wissensmanagement mit KI (Andrej Karpathys llm-wiki). 2026.
9. Christopher Schack (2026): Karpathys LLM Wiki ist brillant. Ich baue es trotzdem nicht nach.. LinkedIn 2026, visited: 27.06.2026.
10. Artur Kokoev (2026): Karpathys LLM Wiki: Zweites Gehirn mit KI bauen. digiak.ai 2026, visited: 27.06.2026.