Karpathys LLM Wiki — Warum Ihr Firmenwissen endlich nicht mehr veraltet

Jedes Unternehmen kennt das: Confluence wird eingeführt, alle sind begeistert, nach drei Monaten schreibt niemand mehr rein, nach sechs Monaten vertraut niemand mehr den Inhalten. Das Wiki wird zum digitalen Friedhof.

Warum? Weil der Wartungsaufwand schneller wächst als der Nutzen. Jede neue Seite erzeugt potenzielle Widersprüche zu bestehenden Seiten. Jede Prozessänderung macht fünf Dokumentationen obsolet. Und niemand hat die Aufgabe — oder die Lust — das alles aktuell zu halten.

Die typische Eskalationskette:

1. Monat 1–3: Enthusiasmus. Viele neue Seiten.
2. Monat 4–6: Erste Widersprüche. "Steht das hier richtig?"
3. Monat 7–12: Vertrauensverlust. Mitarbeiter fragen lieber Kollegen als das Wiki.
4. Monat 12+: Das Wiki wird nur noch für Onboarding-Dokumente genutzt, die seit einem Jahr nicht aktualisiert wurden.

Das Problem ist nicht das Tool. Das Problem ist, dass Menschen keine guten Wiki-Maintainer sind. Sie vergessen Cross-Referenzen zu aktualisieren, übersehen Widersprüche und haben Besseres zu tun als 15 Seiten zu durchforsten, wenn sich ein Prozess ändert.

Andrej Karpathy — ehemaliger Director of AI bei Tesla, Mitgründer von OpenAI, einer der einflussreichsten KI-Forscher der Welt — hat im April 2026 ein Pattern veröffentlicht, das er "LLM Wiki" nennt.

Die Kernidee: Sie schreiben das Wiki nie selbst. Das LLM schreibt und pflegt alles. Sie sind zuständig für Quellen, Exploration und die richtigen Fragen. Karpathys eigenes Ergebnis: 100 Artikel und 400.000 Wörter — ohne ein einziges Wort selbst geschrieben zu haben.

"You never write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions."
— Andrej Karpathy

Die drei Schichten

Schicht	Beschreibung	Wer kontrolliert
Raw Sources	Quelldokumente: Artikel, Papers, Meeting-Notizen, Slack-Exports. Unveränderlich.	Mensch
Wiki	LLM-generierte Markdown-Dateien: Zusammenfassungen, Entitäts-Seiten, Synthesen	LLM
Schema	Struktur, Konventionen, Workflows für Ingestion und Maintenance	Mensch + LLM gemeinsam

Die entscheidende Metapher:

"Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."
— Andrej Karpathy

Vier Operationen, die das Wiki am Leben halten

Ingest: Neue Quelle einspeisen. Das LLM liest, diskutiert, schreibt eine Zusammenfassung und aktualisiert 10–15 bestehende Wiki-Seiten. Wie eine Bibliothekarin, die ein neues Buch nicht nur ins Regal stellt, sondern den gesamten Katalog aktualisiert.

Query: Eine Frage stellen. Das LLM navigiert über den Index zu relevanten Seiten, synthetisiert eine Antwort — und legt besonders wertvolle Antworten als neue Wiki-Seiten ab. Die Recherche verschwindet nicht in der Chat-History.

Lint: Regelmäßiger Health-Check. Widersprüche zwischen Seiten finden, veraltete Claims markieren, fehlende Querverweise ergänzen, Lücken identifizieren. Wie eine Bibliothekarin, die den Katalog regelmäßig prüft und repariert.

Log: Chronologisches Protokoll aller Aktionen. Append-only, maschinenlesbar. Das institutionelle Gedächtnis des Systems.

Die meisten Unternehmen, die heute KI für Wissensmanagement einsetzen, nutzen RAG (Retrieval-Augmented Generation): ChatGPT, NotebookLM oder ähnliche Tools, die bei jeder Frage relevante Dokumente zusammensuchen und eine Antwort generieren.

Karpathys zentrale Kritik: RAG entdeckt Wissen bei jeder Frage neu. Nichts akkumuliert. Eine Frage, die fünf Dokumente synthetisieren muss, zwingt das LLM jedes Mal, die Fragmente zu finden und zusammenzufügen.

Dimension	RAG	LLM Wiki
Wissensspeicher	Vektordatenbank (Embeddings)	Strukturierte Markdown-Seiten mit Links
Bei jeder Frage	Dokumente neu suchen und synthetisieren	Über Index navigieren, vorverdichtetes Wissen nutzen
Querverweise	Existieren nicht (jede Antwort ist isoliert)	Bereits vorhanden — LLM hat sie beim Ingest erstellt
Widersprüche	Werden nicht erkannt	Werden beim Lint geflagt
Compounding	Kein Compounding — jede Frage startet bei null	Jede Interaktion macht das Wiki besser
Wartung	Embeddings aktualisieren	LLM pflegt automatisch

"Das Wiki ist ein persistentes, sich verdichtendes Artefakt. Die Querverweise existieren bereits. Die Widersprüche wurden bereits geflagt. Die Synthese reflektiert bereits alles, was du gelesen hast."
— Andrej Karpathy

Der entscheidende Unterschied: RAG ist stateless, ein LLM Wiki ist stateful. Bei RAG ist jede Antwort so gut wie die Retrieval-Qualität in diesem Moment. Beim LLM Wiki wird jede Antwort Teil des kollektiven Wissens — und die nächste Antwort kann darauf aufbauen.

Der Token-Effizienz-Vorteil ist messbar: Bei fokussierten Wissensbasen kann ein LLM Wiki den Token-Verbrauch um bis zu 95% reduzieren im Vergleich zu naivem Document Loading — weil das Wissen bereits vorverdichtet und strukturiert ist.

Ehrliche Einordnung: Wann RAG doch besser ist

Ab einer Schwelle von 50.000–100.000 Tokens stößt das Wiki-Pattern an seine Grenzen: Der Index passt nicht mehr ins Context Window, und eine Retrieval-Schicht wird zwingend nötig. Für Wissensbasen mit hunderttausenden Dokumenten bleibt RAG der skalierbarere Ansatz. Die smarte Lösung: Hybrid — ein LLM Wiki für die wichtigsten 200–500 Seiten, RAG als Fallback für den Long Tail.

Die Implementierung eines LLM Wiki ist überraschend pragmatisch. Sie brauchen kein Enterprise-Tool, keine Vektordatenbank, keine Cloud-Infrastruktur. Ein lokaler Markdown-Editor und Zugang zu einem LLM reichen.

Schritt 1: Wählen Sie Ihr "IDE"

Obsidian (empfohlen) — lokale Markdown-Dateien, Graph View für Verlinkungen, kostenlos. Alternativen: Logseq, Notion (mit Einschränkungen). Entscheidend: Das Tool muss Markdown-Dateien als Einzeldateien speichern, damit das LLM sie direkt lesen und schreiben kann.

Schritt 2: Definieren Sie das Schema

Eine Datei die beschreibt: Welche Ordner gibt es? Welche Namenskonventionen? Welche Metadaten (Frontmatter) braucht jede Seite? Welche Regeln gelten für Links? Das ist Ihr "Betriebssystem" — das LLM liest es bei jeder Session und hält sich daran.

Schritt 3: Erstellen Sie den Index

Eine zentrale _Index.md Datei mit den 30–50 wichtigsten Seiten, jeweils mit Einzeiler-Beschreibung. Das LLM liest den Index zuerst und navigiert von dort zu relevanten Seiten. Karpathy: "Works surprisingly well at moderate scale."

Schritt 4: Starten Sie mit Ingest

Füttern Sie das System: Artikel, Meeting-Notizen, Prozessdokumentationen. Bei jedem Ingest schreibt das LLM nicht nur eine Zusammenfassung, sondern aktualisiert alle relevanten bestehenden Seiten. Ein einziger Ingest berührt typischerweise 10–15 Seiten.

Schritt 5: Etablieren Sie den Lint-Rhythmus

Einmal pro Woche: Das LLM prüft den gesamten Bestand. Widersprüche? Veraltete Informationen? Fehlende Querverweise? Lücken, die recherchiert werden sollten? Der Lint hält das Wiki gesund — ohne dass ein Mensch daran denken muss.

Zeitaufwand für Setup: 2–4 Stunden für ein funktionsfähiges System. Danach: 30 Minuten pro Woche für Ingest und Lint-Review.

Wir reden nicht theoretisch. Seit Anfang 2026 betreiben wir unser eigenes LLM-Wiki-System — einen Obsidian Vault mit über 2.500 Dateien, gepflegt von Claude Code mit einem eigenen Schema (CLAUDE.md), 7 spezialisierten Workflows und einem wöchentlichen Lint-Rhythmus.

Unser Stack

Komponente	Tool	Funktion
IDE	Obsidian	Graph View, lokale Dateien, Markdown
LLM	Claude Code (Opus/Sonnet)	Ingest, Query, Lint, Synthese
Schema	CLAUDE.md	Regeln, Konventionen, Workflows
Index	_Index.md	Agent-Einstiegspunkt, Top-40 Seiten
Workflows	7 Custom Skills	/youtube, /meeting, /idea, /decision, /person, /vault-health, /deep-dive

Konkrete Ergebnisse

• 2.571 Dateien — strukturiert, verlinkt, mit Frontmatter und Naming Conventions
• 15 YouTube-Channels systematisch analysiert — jedes Video wird zu 3 Dateien (Hauptartikel, Kernaussagen, Nachbau-Anleitung)
• Kundenprojekte, Strategien, Forschung — alles im selben System, alles verlinkt
• Blog-Artikel werden im Vault geboren — aus Vault-Synthesen entstehen veröffentlichungsreife Artikel

Der Flywheel-Effekt

Das System wird mit jeder Nutzung wertvoller. Jedes Video, jedes Meeting, jeder Artikel wird nicht nur gespeichert, sondern in das bestehende Wissen integriert. Neue Verbindungen entstehen automatisch. Nach 4 Monaten kennt unser System Zusammenhänge, die wir selbst übersehen hätten.

"Die Zukunft gehört nicht den größten Teams, sondern den besten Systemen."
— EconLab AI

Ein Entwickler mit einem Brainware-System kann mehr kontextbezogenes Wissen abrufen als ein 10-köpfiges Team ohne. Das ist keine 10x-Verbesserung — das ist eine strukturelle Asymmetrie.

Ein LLM Wiki funktioniert nicht nur für Einzelpersonen. Karpathy beschreibt explizit den Business/Team-Use-Case — und hier wird es für Unternehmen richtig interessant.

Use Case 1: Meeting Intelligence

Jedes Meeting-Transkript wird ingestiert. Das LLM extrahiert Entscheidungen, Action Items und offene Fragen — und aktualisiert alle betroffenen Projektseiten im Wiki. Nach drei Monaten hat das Team ein lückenloses institutionelles Gedächtnis.

Use Case 2: Onboarding-Wiki

Neue Mitarbeiter bekommen Zugang zum LLM Wiki. Statt veraltete Confluence-Seiten zu lesen, stellen sie Fragen — und das Wiki synthetisiert aktuelle Antworten aus allen relevanten Quellen. Das Onboarding wird schneller und die Antworten sind immer aktuell.

Use Case 3: Competitive Intelligence

Wettbewerber-Analysen, Markttrends, Pressemitteilungen — alles wird ingestiert. Das Wiki baut automatisch Wettbewerber-Profile auf, trackt Veränderungen über Zeit und flaggt Widersprüche zu bisherigen Annahmen.

Use Case 4: Projekt-Dokumentation

Architektur-Entscheidungen, Post-Mortems, Sprint-Retrospektiven — alles fließt ins Wiki. Bei neuen Projekten kann das Team fragen: "Welche Entscheidungen haben wir bei ähnlichen Projekten getroffen? Was hat funktioniert, was nicht?"

Use Case 5: Compliance & Audit

Regulatorische Anforderungen, interne Policies, Audit-Findings — das Wiki hält alles aktuell und flaggt automatisch, wenn eine Policy-Änderung Auswirkungen auf bestehende Prozesse hat. Besonders wertvoll für regulierte Branchen.

Enterprise-Herausforderungen — ehrlich benannt

Ein lokaler Ordner mit Markdown-Dateien ist ein persönliches Produktivitäts-Tool, keine Enterprise-Architektur. Für den Unternehmenseinsatz müssen drei Probleme gelöst werden:

• Multi-User Access: Mehrere Agenten, die gleichzeitig dasselbe Wiki aktualisieren, erzeugen Schreibkonflikte. Lösung: Git-basierte Versionierung oder ein zentraler Orchestrator.
• Zugriffskontrolle: Nicht jeder Mitarbeiter darf alles sehen. Lösung: Ordner-basierte Berechtigungen oder verschlüsselte Bereiche.
• Qualitäts-Validierung: Ein LLM kann falsche Fakten in das Wiki schreiben — und andere Agenten bauen darauf auf. Lösung: Human-in-the-Loop bei kritischen Seiten, Confidence Scores, regelmäßiger Lint.

Diese Probleme sind lösbar — aber sie erfordern Architektur-Entscheidungen, die über "Obsidian installieren" hinausgehen. Genau hier liegt der Wert eines erfahrenen Implementierungspartners.

Skalierung: Von persönlich zu Team zu Organisation

Ebene	Quellen	Nutzen
Persönlich	Eigene Notizen, Lesezeichen, Ideen	Persönliches Wissensmanagement
Team	+ Meetings, Slack, Projektdaten	Gemeinsames Projektgedächtnis
Organisation	+ Strategy, HR, Legal, Finance	Institutionelles Wissen als Asset

Karpathy verweist auf Vannevar Bushs "Memex" von 1945: Die Vision eines persönlichen, kuratierten Wissensspeichers mit assoziativen Pfaden zwischen Dokumenten. Bush war seiner Zeit 80 Jahre voraus — seine Vision war näher an dem, was wir hier bauen, als an dem, was das Web geworden ist.

"The idea is related to Vannevar Bush's Memex (1945) — a personal, curated knowledge store. The part he couldn't solve was who does the maintenance. The LLM handles that."
— Andrej Karpathy

Was Bush 1945 nicht lösen konnte — die automatische Pflege eines persönlichen Wissenssystems — hat Karpathy 2026 gelöst. Nicht mit komplexer Infrastruktur, sondern mit einem LLM und Markdown-Dateien.

Die Implikation für Unternehmen: Wissen ist das einzige Asset, das mit Nutzung wertvoller wird — vorausgesetzt, jemand (oder etwas) pflegt es. Ein LLM Wiki macht genau das: Es verwandelt die chaotische Ansammlung von Dokumenten, Slack-Nachrichten und Meeting-Notizen in ein lebendes, sich selbst verbesserndes System.

Karpathys LLM Wiki ist kein theoretisches Konzept — es ist ein pragmatisches Pattern, das heute mit verfügbaren Tools umsetzbar ist. Die Idee ist bestechend einfach: Lassen Sie das LLM die Arbeit machen, die Menschen nicht gerne (und nicht gut) tun: Wiki-Maintenance, Cross-Referencing, Widerspruchserkennung, Verdichtung.

Was Sie gewinnen:

• Ein Wissenssystem, das mit jeder Nutzung besser wird — statt zu verfallen
• Antworten, die auf vorverdichtetem Wissen basieren — nicht auf spontaner Dokumentensuche
• Institutionelles Gedächtnis, das nicht an einzelne Köpfe gebunden ist
• Automatische Erkennung von Widersprüchen, Lücken und veralteten Informationen

Was Sie investieren:

• 2–4 Stunden für das Setup
• 30 Minuten pro Woche für Ingest-Review und Lint-Check
• LLM-API-Kosten (ca. $50–200/Monat je nach Nutzung)

Der ROI ist klar: Ein sich selbst pflegendes Wiki spart nicht nur die Zeit, die normalerweise für Maintenance draufgeht. Es macht Wissen zugänglich, das sonst in Köpfen, Chat-Historien und veralteten Confluence-Seiten verloren geht.

Wollen Sie ein solches System für Ihr Unternehmen?

Wir bei EconLab AI bauen und betreiben unser eigenes LLM-Wiki-System seit Anfang 2026 — mit über 2.500 Dateien, 7 spezialisierten Workflows und einem wöchentlichen Self-Improvement-Loop. Wir helfen Ihnen, das gleiche System für Ihr Unternehmen aufzusetzen: Von der Architektur über das Schema bis zum laufenden Betrieb.