Karpathy's LLM Wiki: Build a Personal Knowledge Base That Compiles

In April 2026, Andrej Karpathy published a short GitHub Gist describing a pattern he called the "LLM Wiki." It got less attention than his usual tweets, but the idea underneath it is one of the few genuinely new things to come out of the LLM era in the last six months.

The one-sentence version: instead of having the LLM re-read your raw documents every time you ask a question, build a persistent, structured wiki once and keep it updated forever.

The problem it's solving

Most people using LLMs for personal knowledge management do something like this: dump PDFs and notes into a folder, build a RAG pipeline, and hope the LLM finds the right chunk. This works for "what did I read about X." It falls apart for "what do I believe about X, after everything I've read." The LLM has to re-derive your answer from raw material on every query, and it can't — because the raw material is too noisy, too redundant, and too contradictory.

An article on Medium by Urvil Joshi summarizes Karpathy's framing: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase." The wiki is the binary. Every time you add a new document, the LLM doesn't just index it — it integrates the new information into the existing topic pages, updating claims, adding references, and surfacing conflicts.

How it actually works

Three layers, all version-controlled:

1. Raw sources (immutable) — your original documents, in their original form. PDFs, markdown notes, meeting transcripts, web clippings.
2. The wiki (LLM-generated, incrementally updated) — markdown files organized by topic. Each page has claims, evidence links, and revision history.
3. The schema (conventions for the LLM) — a markdown file that tells the LLM how to structure new pages, what counts as a claim, when to merge, when to split.

The maintenance loop:

`` You add a new source → LLM reads it → LLM finds the relevant topic pages in the wiki → LLM edits those pages: adds claims, cites the source, flags contradictions → You review the diff → Commit ``

This is not auto-pilot. It's a reviewable artifact. The wiki is source code, not a chat transcript.

Real implementations

One practitioner built a 2,188-document personal wiki by running every deliverable from a year of Manus AI research through an LLM for categorization, then having the LLM incrementally build topic pages over a few weeks of focused sessions. The output was a searchable, cross-linked knowledge base that — crucially — the practitioner could edit and correct.

An analysis on mono.software calls this the "structural fix" for personal knowledge management failure modes: the rotting Obsidian vault, the "misc" folder dumping ground, the 47 unprocessed inbox items. Most PKM systems fail because they're passive — you put things in and hope the structure emerges. LLM Wiki is the opposite: structure is the deliverable, and the LLM is the one keeping it current.

Why this is different from RAG

RAG is faster to set up and easier to scale. LLM Wiki is slower to bootstrap but cheaper to query and easier to trust, because every claim has a visible source and a visible edit history. For personal knowledge bases that you actually want to use a year from now, LLM Wiki is the better fit.

When to use it

• You have more than 100 documents you want to be able to query.
• The information changes over time and you want the structure to track the changes.
• You care about being able to correct the LLM's mistakes and have those corrections stick.
• You're willing to spend a few hours a week reviewing diffs.

If you have 20 notes and just want search, Obsidian search is enough. If you have 2,000 documents and you want the LLM to know what you believe, LLM Wiki is the only design that actually works.

The honest caveat

LLM Wiki is a manual practice, not a product. There's no "Sign up for LLM Wiki" button. You're running a script (or a Claude Code session, or a Goose task) that reads your schema, reads your sources, edits your wiki, and asks you to review. The tooling is in the same state as dotfiles management in 2010 — everyone has a slightly different setup, none of them are pretty, and the best one is the one you'll actually use.

That's not a knock. Most of the personal knowledge tools that actually work in 2026 look like this. The question is whether you're willing to maintain one.

---