Source — Karpathy: LLM Wiki (2026-04-04)

Source — Karpathy: LLM Wiki

Raw source: raw/articles/2026-04-04_karpathy-llm-wiki.md (immutable)
Originally published: 2026-04-04, by Andrej Karpathy. This is an “idea file”, designed to be copy-pasted to your own LLM Agent to convey high-level concepts; the concrete implementation is built collaboratively by the Agent and you.

One-line summary

Use an LLM to incrementally build and maintain a persistent, interlinked personal knowledge-base wiki that sits between you and the raw sources — rather than re-running RAG from scratch on every query.

Core arguments

• The problem with RAG: pulling snippets from raw at query time means rediscovering knowledge from scratch each time, with no accumulation; ask one good question that requires synthesizing five documents and the LLM has to re-find and re-assemble them every single time.
• The wiki alternative: the LLM continuously compiles and keeps the wiki up to date. Cross-references are already in place, contradictions are already flagged, and synthesis already reflects everything read. This is a compounding artifact.
• Human–machine division of labor: you almost never write the wiki yourself — you find sources, investigate, and ask the right questions; the LLM does all the grunt work (summarizing, cross-referencing, filing, bookkeeping). In practice: open an LLM Agent on one side and Obsidian on the other, and browse the results in real time. Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase.

Use cases (examples)

• Personal: goals, health, psychology, self-improvement; archiving diaries, articles, podcast notes.
• Research: deep-diving a topic over weeks to months, incrementally building a synthesis wiki with evolving arguments.
• Reading: archive chapter by chapter, build character/theme/plot-line pages, like a Tolkien Gateway style fan wiki.
• Business/team: an internal wiki fed by Slack discussions, meeting transcripts, project docs, customer calls.
• Competitive analysis, due diligence, itinerary planning, class notes, hobby deep-dives — anywhere you accumulate knowledge long-term and want to organize rather than scatter it.

Three-layer architecture (see three-layer-architecture)

1. Raw sources — immutable source files, the source of truth.
2. The wiki — LLM-generated markdown directory, fully owned by the LLM.
3. The schema — the contract file that tells the LLM the structure/conventions/process (this wiki’s AGENTS).

Three operations (see three-operations)

• ingest — Drop a source into raw; the LLM reads it, discusses the key points, writes a summary page, updates the index, updates related pages, and appends to the log. Recommended one source at a time with active participation; batch / lightly-supervised mode also works.
• query — Ask questions of the wiki; the LLM searches relevant pages, reads them, and synthesizes an answer with citations (markdown page / comparison table / Marp slides / matplotlib figure / canvas). Good answers can be saved back into the wiki as new pages, so that investigation compounds.
• lint — Periodic health check: contradictions, stale claims, orphan pages, missing-concept pages, missing cross-references, gaps fillable by web search.

Index & log (see index-and-log)

• index.md — content-oriented table of contents: one link per page, a one-line summary, optional metadata; the LLM updates it on every ingest and reads it first to locate pages before answering. Works very well at medium scale (~100 sources, hundreds of pages) without embedding-based RAG.
• log.md — time-ordered, append-only, records ingest/query/lint. Recommended entry prefix is consistent (e.g. ## [2026-04-02] ingest | Article Title) so grep "^## \[" log.md | tail -5 can parse it.

Optional CLI tools

• qmd — local markdown search engine, hybrid BM25/vector + LLM re-ranking, fully on-device; ships both a CLI and an MCP server. For small scale the index suffices; you’ll want it once the wiki grows.

Tips & tricks

• Obsidian Web Clipper — browser extension that turns web articles into markdown for fast ingestion into raw.
• Download images locally — set Obsidian’s Attachment folder path (e.g. raw/assets/), bind a “Download attachments” hotkey; after the LLM reads the text it can look at images separately.
• graph view — the best way to see the wiki’s shape (who links to whom, who is a hub, who is an orphan).
• Marp — a markdown slide format; there’s an Obsidian plugin.
• Dataview — runs queries over page frontmatter to produce dynamic tables/lists.
• The wiki is just a git repo — version history, branching, and collaboration come for free.

Why it works (see knowledge-compounding)

The most annoying part of maintaining a knowledge base is bookkeeping, not reading or thinking; people give up when the maintenance burden outweighs the value. The LLM doesn’t tire, never forgets to update cross-references, and can touch 15 files in a single pass. With near-zero maintenance cost, the wiki actually sticks around.

Notes

The document is deliberately abstract — it conveys only the pattern, not a concrete implementation; directory structure, schema conventions, page format, and tools all depend on the domain/preference/LLM and are fully optional and modular. The correct usage is to hand it to your LLM Agent and collaborate to instantiate a version that fits you.

Extended discussion (taken from gist comments, not the original document body)

• schema as contract: a comment notes that CLAUDE.md is prose = instructions, which an Agent may not follow and whose violation nobody catches. The schema layer should be made typed + validated (like the SIGN spec’s @doc/@vocab/@def) rather than narrative. See schema-as-contract.
• blind spots of lint: when notes describe systems that change on their own, linting notes against notes alone is insufficient; claims about code should carry file and line numbers, and be flagged stale when the code changes.