LLM Wiki: Karpathy's Pattern, Built for a Paying Client

It earns its keep when two things are true: the sources keep arriving, and you keep needing answers that span several of them. A single report does not need a wiki. Forty customer interviews, a year of competitor announcements or every paper on one research question do, because no one rereads all of them before answering a question, and the wiki means no one has to.

It is a poor fit for knowledge that changes by the minute (an order system, a live dashboard) or for material nobody will ever query. Point those at the source system, not at a wiki.

RAG (retrieval-augmented generation) is the usual way to point a model at documents: split them into chunks, store the chunks in a vector database, and fetch the closest matches for each question. It works, but every answer starts from fragments, and two sources that disagree are both handed to the model with nothing to say which is current. An LLM wiki settles those conflicts at ingest, once, and writes the result down where you can read it. Karpathy notes that at around a hundred sources and a few hundred pages, the index file alone works well without any embedding infrastructure.

A second brain is the third term people compare, and it overlaps with both:

They are not exclusive. A second brain run with Claude Code already behaves like a small LLM wiki; the Claude Code and Obsidian second brain guide sets one up. And a wiki that outgrows its index can add search over the compiled pages, so each search starts from summarized, linked pages instead of raw fragments.

Obsidian fits because it does not own the files. It opens an ordinary folder of markdown, shows [[wikilinks]] as links and backlinks, and redraws its graph as the agent writes. Nothing about the pattern depends on it, though: VS Code, any markdown editor, or GitHub's own file view will display the same pages. Keep the wiki in plain markdown and the choice of viewer stays yours.

One habit to borrow from the gist: let the model do the writing and you do the reading. Editing wiki pages by hand works, but then the schema is no longer the only source of the rules, and lint starts flagging your edits as drift.

The pattern is not tied to one model. What it needs is an LLM running as an agent, meaning it can open files, write files and follow instructions across many steps. Claude Code is that for Claude; other coding agents do the same for other models, which is why the schema file is plain text and the wiki is plain markdown. Swap the model next year and the wiki comes with you.

This is where the pattern turns into client work, and where most published builds stop. A wiki you keep for yourself can tolerate gaps: you are the only reader, and when an answer is wrong you notice. A wiki a business depends on cannot. Four things change when the wiki is for a paying client:

• The sources are theirs, and some are wrong. Old pricing decks, a policy nobody follows, two versions of the same process. The schema needs a rule for which source wins and a way to mark a claim as unconfirmed, or the wiki confidently repeats the outdated one.
• The schema becomes the contract. What counts as a source, who may edit the wiki, what the agent must refuse to answer. You write it with the client, because they will live with it after you leave.
• Lint becomes a test. Before handover, run a set of real questions from the team and score the answers. The second brain retrieval test is a scorecard for exactly this. A wiki that has never been tested is a guess.
• The handoff is the product. The client needs a named owner, a weekly ingest and lint routine, and a short note on where the wiki is weakest. If it only works while you are running the agent, you have delivered a demo.

That shape, scoping the sources, building the wiki, testing retrieval and handing it over, is a bounded engagement a consultant or service provider can quote, deliver and finish. The tools are the same plain folders and the same Claude Code session you would use for your own.