Of course you’ve got document stores. But be honest, how much ongoing love do they all have? Is every one of your onboarding guides on point, and how many of the “current architecture” diagrams show databases that were deprecated before you joined?

The problem is not that people do not value documentation. Maintaining it costs more than the value it provides, incrementally, every day. Someone has to update cross-references when a concept changes. Someone has to notice that the new ADR contradicts a page three levels deep in the architecture section. Even if some of this happens, the wikis still rot.

Andrej Karpathy has a pattern that solves this. He calls it LLM Wiki. The key insight is deceptively simple: let the LLM do the maintenance.

The difference between RAG and LLM Wiki Link to heading

Most LLM-powered knowledge systems work the same way: upload documents, ask questions, get answers. The LLM retrieves relevant chunks at query time and synthesises a response. This is RAG — the default approach for most enterprise knowledge tools built between 2023 and 2025.

With RAG, every query starts from scratch. The LLM re-derives the answer from raw sources each time. Ask something that requires synthesising five documents and it has to find and piece together the fragments on every single query. Nothing compounds.

Most frustratingly, ask a question that could source from many documents and it’ll pick a few and ignore the rest.

LLM Wiki is different. Instead of querying raw sources at runtime, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files. When you add a new source, the LLM reads it, extracts the key information, and integrates it into the existing wiki: updating entity pages, revising topic summaries, flagging where new data contradicts old claims. The knowledge is compiled once and kept current.

The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. As the librarian, the LLM also surfaces gaps and inconsistencies you would never have noticed otherwise.

The three layers Link to heading

Raw sources — your curated collection of source documents: articles, papers, meeting transcripts, Slack exports, customer calls, architecture docs. These are immutable. The LLM reads from them but never modifies them.

The wiki — a directory of LLM-generated markdown files: summaries, entity pages, concept pages, comparisons, an evolving synthesis. The LLM owns this layer entirely. You read it; the LLM writes it.

The schema — a file (CLAUDE.md for Claude Code, AGENTS.md for Codex) that tells the LLM how the wiki is structured and what to do when ingesting, querying, or linting. This is the key configuration file. You and the LLM co-evolve it over time as you figure out what works for your domain.

As Karpathy describes it:

The LLM is the programmer, the wiki is the codebase, and you are the engineering manager — sourcing problems, making decisions, improving.

Operations Link to heading

Ingest. You drop a new source into the raw collection and tell the LLM to process it. It writes a summary page, updates the index, and touches all related entity and concept pages. A single source might update many wiki pages.

Query. You ask questions against the wiki. The LLM reads the index first, drills into relevant pages, and synthesises an answer with citations. Good answers get filed back into the wiki as new pages — your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki: contradictions between pages, stale claims, concepts that lack their own page, missing cross-references. The LLM will also suggest new sources to investigate. This is arguably the most powerful operation — the system actively directs you to improve it.

The index and the log Link to heading

index.md — a catalog of every page with a link and a one-line summary, by category. The LLM updates it on every ingest and reads it first when answering queries. At moderate scale this works without any vector database.

log.md — an append-only record of ingests, queries, and lint passes. Each entry with a consistent prefix (e.g. ## [2026-05-10] ingest | Article Title) is parseable with simple shell tools and gives the LLM context about what has been done recently.

Why this works Link to heading

The tedious part of maintaining a knowledge base is not the reading or the thinking — it is the bookkeeping. Many wikis have been abandoned because the maintenance burden grew faster than the value. LLMs do not get bored, do not forget to update a cross-reference, and can touch fifteen files in one pass.

This is what Vannevar Bush was imagining in 1945 with the Memex — a personal, curated knowledge store with connections between documents. Bush could not solve the maintenance problem, but the LLM now has.

Applying this to a team Link to heading

Karpathy describes this as a personal pattern, but the value compounds as sources grow. Combining team knowledge — decisions, incident post-mortems, customer calls, sprint retrospectives — with the reasoning capability of a frontier model is powerful.

Instead of these living in unread Notion pages and Confluence exports, they become a structured, interlinked wiki the LLM keeps current. The result: an onboarding tool that reflects how the system works today, a decision log that surfaces prior context automatically, and institutional memory that does not walk out the door when a senior engineer leaves.

The human in the loop handles curation and sourcing. The LLM handles the maintenance. That is a good division of labour.

Getting started Link to heading

Karpathy’s gist is deliberately abstract — it describes the pattern, not a specific implementation. Share it with your LLM agent and build the version that fits your domain together. In our own trials I started with this implementation, and with it ingesting 200 documents cost around £10 in API calls; 2,000 documents cost around £30 — cheap enough to experiment freely.

A few pieces of added value:

  • Obsidian as the wiki IDE. The graph view shows which pages are hubs and which are orphans — great for showing the knowledge base off.
  • Claude Code or Codex as the LLM agent. Put the schema in CLAUDE.md and it is picked up automatically in every session.
  • A git repo as the storage layer — version history and collaboration for free.

Start with one type of source and one output page format. Get the ingest loop working before adding complexity. The schema should describe what you have, not what you aspire to have.

Further reading Link to heading