LLM wikis: everyone compiles, nobody recompiles

Karpathy's gist was updated two days ago. A beginner setup guide for the pattern has 466,000 views. Google shipped a vendor-neutral standard for it this month. Somewhere in the last quarter, "point an LLM at your sources and let it write the wiki" went from a clever idea in a text file to the most-copied knowledge management pattern of 2026.

The pattern deserves the attention. It solves something real, and it solves it better than what most people were doing before.

Here is the question nobody in that pile of tutorials is asking: what does your LLM wiki look like in November?

Not the day you build it, when the concept pages are crisp and the cross-references are dense and the whole thing feels like cheating. Four months later. After the library you documented shipped two majors. After one of those papers got retracted. After the "current best practice" you compiled became the thing people migrated away from. The wiki will still be there, still well-organized, still reading like confident prose. It just won't be true anymore, and nothing in the pattern will have told you.

What is an LLM wiki?

An LLM wiki is a personal knowledge base where you curate the raw sources and an LLM writes and maintains the synthesis on top of them. Instead of retrieving from raw documents on every question, the model compiles them once into a directory of interlinked markdown files (entity pages, concept pages, cross-references) that you read and it writes.

Karpathy's version has three layers:

1. Raw sources. Your immutable, curated collection: papers, articles, PDFs, transcripts. You choose what goes in. Nothing here gets edited.
2. The wiki. A directory of markdown files owned by the LLM. Entity pages, concept pages, a log. You read it; the model writes it.
3. The schema. Configuration (a CLAUDE.md, an AGENTS.md) telling the model how to ingest a new source, how to format pages, how to cross-link.

The insight underneath is a compiler metaphor, and it is a good one. You don't re-run your source code every time you want the program. You compile once and run the binary.

Retrieval-augmented generation makes the model re-read the sources on every question, reconstructing the same understanding from scratch each time. The LLM wiki compiles that understanding once and reads the artifact after that.

Anyone who has watched a RAG system confidently stitch together two chunks that had nothing to do with each other understands the appeal immediately.

If you want the fastest possible version of this: pick ten sources you actually care about, write a schema file describing the pages you want, and let a coding agent compile it. You will have something useful inside an hour. Set up your first desk if you'd rather the compiling and the upkeep live in the same place.

Is an LLM wiki better than RAG?

For a stable, curated body of knowledge, usually yes. For anything that changes underneath you, the answer flips, and that flip is the whole point of this article.

Notice the last two rows. RAG at least re-reads the index, so if you update a document, the next answer reflects it. The LLM wiki reads the compiled artifact, which means a source can change and the wiki will keep confidently telling you the old thing. The compiler metaphor is doing something the people who adopted it didn't intend: real compilers get re-run when the source changes, because a build system watches the files and knows the binary is stale.

The LLM wiki has no build system. There is no make for your knowledge base. Nobody is watching the sources.

The compile step is a snapshot

This is the part the pattern gets wrong, and it is worth being precise about it rather than gesturing at it.

Compilation is a point-in-time operation. You compiled on April 12th. The wiki is an accurate synthesis of the world as your sources described it on April 12th. Every day after that, it is a slightly more confident and slightly more wrong account of a world that kept moving.

The failure mode is nastier than a plain stale note, for three reasons.

The synthesis hides the source. When you read your own note, you remember writing it, and you carry a rough sense of when and how sure you were. A compiled concept page has no such halo. It reads like reference material. It reads like a wiki, which is exactly what it was designed to read like, and reference material carries an implicit claim of currency that a scribbled note never made.

The provenance thins out with every hop. A concept page synthesizes six sources. An entity page cross-references four concept pages. By the time a claim reaches the page you actually read, it has been paraphrased, merged, and reconciled twice. Which underlying PDF is responsible for this sentence, and is that PDF still saying it? The pattern's own structure makes that progressively harder to answer.

Confidence is uniform. The model writes the shaky inference and the load-bearing fact in the same steady register. Nothing in the output distinguishes "three sources agreed on this" from "one preprint claimed this and nothing contradicted it."

None of this is unique to wikis. Any store an AI writes to has the same asymmetry: memory is write-heavy and has no retraction step, so quality drops even when every individual write was correct on the day.

This is knowledge decay with better typography. Everything in your notes has an information half-life, and compiling it into cleaner prose doesn't extend that half-life by a single day. It just makes the decay harder to see.

Three ways a compiled wiki rots

Abstractions are easy to nod along to, so here are the concrete ones.

The source updated. You compiled a page on a framework's auth flow from its docs in April. In June the framework deprecated the middleware order you documented. The docs changed. Your wiki did not. You will find out when you follow your own instructions and they fail, which is the single most expensive way to discover a stale note, because you trusted it enough to act on it. It is the same mechanism that rots every runbook an engineering team ever wrote, arriving now in a folder that looks far more authoritative than a runbook ever did.

The source got retracted. If your raw sources include papers, this is not hypothetical. Retraction Watch maintains a database of tens of thousands of retracted papers, and retractions frequently land years after publication and long after the finding has been cited downstream. Your wiki compiled the claim. The claim was withdrawn. The concept page still states it as fact, still cross-linked into four other pages, quietly load-bearing.

The source was superseded. Nothing was wrong and nothing was retracted. The field simply moved. The technique you compiled as current practice is now the thing people are migrating off. No error was made at any point, and the page is still wrong in the way that matters: it will lead you to do the wrong thing.

None of these three announce themselves. That's the shared property. A broken link is loud, a 404 tells you immediately. A silently superseded best practice is quiet for months and then expensive all at once.

What a maintenance step would actually require

Naming a gap is cheap. Here is the mechanism, because "the AI handles it" is exactly the kind of claim this pattern doesn't need more of.

A maintenance loop for an LLM wiki needs five things:

1. Source addresses, not source copies. The wiki has to know where each claim came from, as something re-fetchable. A URL, a DOI, a repo path. Not just "synthesized from the sources folder."
2. A schedule. Re-check runs on a cadence you set, not when you remember. The entire failure mode is that you don't remember, so any design that depends on you remembering has already lost.
3. A diff. Fetch the source again, compare it to what the wiki says, and show the delta. Not a rewrite. A diff, with the old text and the new text side by side.
4. A citation. Every flag points to the specific source that changed, so you can check the machine's work instead of trusting it. If the tool can't show you why it thinks a page is stale, it's asking for the same blind trust the compiled wiki already asked for.
5. A human gate. You accept or reject. An LLM that silently rewrites your knowledge base on a cron job has replaced a wiki that goes quietly stale with a wiki that quietly changes its mind, which is worse.

Look at that list and notice it's the same shape as the compile step, pointed backward. The compiler reads sources and writes pages. The maintainer re-reads sources and flags pages. Same three layers, same schema file, run on a loop instead of once. The pattern is one step away from being complete, and the step is not exotic.

This is what AI verification does in Scribelet: background agents re-check what your notes claim against current sources on a schedule you set, then show you a diff with citations. Green for what's new, red for what no longer holds. You accept or dismiss. The same loop that fact-checks notes before you reuse them is the loop a compiled wiki is missing.

This is a pattern of missing phases

If this argument feels familiar, that's because it keeps happening, and the repetition is the interesting part.

Zettelkasten has capture, atomize, and link, with no step for revisiting whether a permanent note is still true. PARA sorts by actionability, and filing is not maintaining. Digital gardens went furthest by borrowing a metaphor that is mostly weeding, then built tooling that only publishes, which is why everyone plants and nobody weeds. Every note-taking method is missing the same phase.

The LLM wiki is the newest member of this family, and it arrives with a twist. Previous methods asked you to maintain and you didn't have time. The LLM wiki automates the part you were already doing (writing and organizing) and leaves un-automated the part you were already failing at (checking whether it's still true). It automated the wrong half. The half it automated was tedious; the half it skipped was the one that actually decides whether the artifact is worth anything in month six.

Karpathy's gist is explicit that it's an idea file, not a product. That's fair and it's honest. But the tutorials, the desktop implementations, and the standards proposals built on top of it have all inherited the same omission without inheriting the disclaimer.

Two shapes of a self-maintaining knowledge base

There's a second axis here worth separating out, and we've written about it before: there are two directions for a self-maintaining knowledge base.

Karpathy's direction is compiled external knowledge. You curate what to read; the LLM authors the synthesis. Scaled up, it converges toward a personalized copy of the internet.

The inverse direction is your own writing, maintained. You write the notes (the half-formed thoughts, the meeting fragments, what you actually decided on Tuesday), and the LLM never authors a first draft. It cross-references, flags contradictions, catches drift. Scaled up, it converges toward a persistent copy of your own thinking.

Both need the maintenance loop. Neither ships with one by default. And if you're building the first kind inside a vault, the AI options for Obsidian are worth understanding before you assume a plugin closes this gap, because most of them are compile-side too: they generate, summarize, and link. Generating more pages faster does not help a folder whose problem is that its pages quietly stopped being true.

When you don't need any of this

Honest limits, because the pattern is genuinely good and this isn't a hit piece.

If your sources don't change, none of this applies. A wiki compiled from Marcus Aurelius is not going to drift. History, literature, closed corpora, a fixed set of interview transcripts, a finished project's documentation: compile it, enjoy it, ignore everything above. Stable sources are exactly the right use case for the pattern as written, and it's a strong one.

The maintenance problem shows up precisely where the pattern is most attractive: fast-moving technical fields, active research areas, anything where you picked the LLM wiki because there was too much to keep up with. The size of the reading pile is what makes the pattern appealing, and the churn rate underneath that pile is what makes the compiled artifact rot. Those are the same property. The wikis that most need compiling are the ones that most need recompiling.

The step after the compile step

Build the LLM wiki. The pattern is good, the tooling is getting real (open-source implementations are shipping updates weekly), and a compiled synthesis genuinely beats re-reading a folder of PDFs forever.

Then put a date on it. Ask yourself, honestly, what happens to it in November, when the concept pages still read beautifully and a third of them are describing a world that moved on. Compiling is a build step. Nobody ships a build system that never re-runs.

Your wiki is going to keep telling you what was true in April. You already know which of those pages you'd be nervous to act on today. Point AI verification at those first.