The LLM Wiki — Notes that maintain themselves

Yesterday I was drafting a reply on Twitter. I wanted to name a mechanism: Jevons paradoxA 19th-century economics observation: when something becomes more efficient, total consumption of it tends to rise rather than fall. Coined by William Stanley Jevons in 1865, watching coal use grow as engines got more efficient.Learn more → for knowledge work. Before I shipped, a rule fired — any named AI mechanism in a draft gets checked against ~/Notes/AI Knowledge Base/ first. I checked. The wiki didn't have Jevons. And when I thought about it, the stretch between Jevons's original framing and knowledge work wasn't clean. I renamed the mechanism and shipped a different framing.

The wiki caught it before I did.

This is what changes when your notes start doing that. Every notes system you've tried became a graveyard because maintenance was your job. PARA's four folders ended up empty, Notion databases went unused, Obsidian vaults stalled — every system in this space broke on the same thing: the filing was the work, and developers don't want to file. LLMs don't have that cost. You stop being the filer. You curate sources, ask questions, and the wiki gets written and maintained by the thing you'd be asking anyway.

Andrej Karpathy sketched the shape in April: three layers (raw sources, wiki, schema), three operations (ingest, query, lint). What follows is what it looks like when you actually run it on your own working material.

Over time, queries against your own wiki start beating agentic web-search for knowledge work. Web-search pulls from the internet. The wiki pulls from the sources you chose to trust, with the reasoning trail intact. For anything where your prior context matters — which is most knowledge work — that's a different signal.

My first one is called, unimaginatively, AI Knowledge Base. It lives at ~/Notes/AI Knowledge Base/. The raw/ folder has about 40 source documents — podcast transcripts, blog posts, a few PDFs. The wiki/ folder has about 30 concept pages, all markdown, all linked with [[wikilinks]]. The schema is a CLAUDE.md at the root that says: concepts go in concepts/, people go in people/, every page has frontmatter with title, category, sources, tags; here's how to lint; here's how to ingest.

I curate sources. Most come in through Obsidian's Web Clipper — Karpathy recommended it in the same gist, and the capture friction dropped enough that I actually use it now. One click on an article or podcast transcript and it lands in raw/ as a markdown file, already formatted, ready to ingest. Every few days I ask Claude Code to process the new batch. The ingest touches 10–15 files at a time: new concept pages get drafted, existing ones get updated with the new source, cross-references get added where applicable. I review the diff. I approve or correct. The wiki grows.

When I need to draft something — a reply, an essay opener, a strategy decision — I query the wiki. The query goes through CLAUDE.md first (it knows where to look), reads the relevant concept pages, answers with citations back to raw sources. If the answer surprises me, I can trace it to the primary source in five seconds.

Once every week or two I ask for a lint. The agent walks the wiki, looks for orphan pages (ingested but never linked), broken wikilinks, contradictions between concept pages, stale dates. Last lint turned up one broken link and one silent contradiction between two pages written three weeks apart. I haven't done this by hand on any knowledge system I've ever run, because it's the kind of work humans don't do.

That's the canonical use case — the one Karpathy described. Personal niche, curated sources, LLM-maintained wiki, you ask questions.

The second one I keep surprising myself with is the same pattern in a different domain.

The folder is ~/Notes/Marketing Knowledge Base/. Same three-layer architecture. Same schema file, shaped for marketing concepts instead of AI ones. The sources are SEO podcasts, growth playbooks, Twitter-strategy posts, startup-founder newsletters. The wiki has about 70 concept pages now.

Yesterday I added 14 new ones. A Grumpy SEO Guy podcast plus a WebLinkr Reddit sticky — both into raw/, then ingest. The agent produced new concept pages: four-ranking-variables, pagerank-cumulative-authority, seo-is-competition-not-checklist, and ten more.

Today I asked the agent to update my site's SEO strategy document. It loaded the new pages, then opened a 400-line strategy doc I'd written weeks before those pages existed. It found three silent contradictions between what the strategy said and what the new concept pages said — I was treating authority as something editorial would "earn," and the new pages disagreed. It rewrote the relevant sections, added a new subsection called "Link-building stance (and why)" that engaged the tension explicitly, updated a kill-gate metric, and left citations inline to the new wiki pages.

The strategy document was older than the concept pages it was now citing. The wiki rewrote work that predated it.

I didn't do the rewriting. I curated the ingest, asked for the update, reviewed the diff. The actual work — finding the contradictions, figuring out how to reconcile them, writing the new subsection — happened in the space between reading my strategy and reading the new pages. The wiki was the thing that could hold both at once.

Here's where I'd stop, if this were a productivity post: tell you to go build one.

But the honest counter-case: there's a floor below which the pattern overweights.

I tried the architecture on a tiny project — three sources, one topic, maybe 1,500 words of raw material. The overhead of maintaining the schema, doing the ingest, running lint passes — all of it cost more than the value the wiki gave back. A single text file, or a small folder with three markdown files and no cross-references, would have been strictly better.

The threshold isn't a specific number. It depends on how often you query, how unrelated the sources are, how much you'd otherwise be cross-referencing by hand. Karpathy mentions 400K words as the point where simple index files stop working and you want a search tool on top. The floor is mushier, but it's real: below maybe 20 sources in a single domain, the ceremony exceeds the benefit.

The insight Karpathy surfaced is about maintenance cost, and the caveat he doesn't emphasize is that the maintenance itself has a cost. It's just much smaller than the human cost was. Net of that overhead, the system is worth it once you're past the threshold.

If your CLAUDE.md or AGENTS.md is already several pages long and still growing, you've already started building the schema layer for one of these. A database designed around retrieval is one half of what a maintainable knowledge system needs. The wiki layer the model owns is the other half. Start with five sources and one lint pass. See what changes. See whether you stop being the filer.