Karpathy's living LLM wiki

Andrej Karpathy published a short, practical proposal for an “LLM wiki” — a living, machine-friendly archive of ideas that an LLM continually reads and rewrites into a structured Markdown wiki. (gist.github.com) Instead of treating a model like a search engine that fetches raw files on every query, Karpathy describes a pipeline where the model ingests new sources, synthesizes concise wiki pages, updates indexes and backlinks, and appends a changelog so the knowledge base grows cumulatively. (gist.github.com) That workflow flips a common production pattern. Many teams use retrieval-augmented generation (RAG): split documents into shards, embed them in a vector database, then retrieve and stitch context at query time. Karpathy’s pattern compiles the same source material into explicit, versioned pages so the model consults an already-organized knowledge layer rather than re-searching raw text each time. (venturebeat.com) Karpathy’s notes are concrete about how the system behaves: the LLM becomes a “compiler” that turns raw inputs — papers, blog posts, meeting notes — into interconnected Markdown articles, slides, charts, and a maintenance log that the agent can consult and extend. He lays out ingest → compile → query → maintain as a loop rather than a one-shot retrieval step. (academy.dair.ai) Builders who run API platforms should picture the difference like this: with a RAG stack every API call may trigger fresh retrieval work and brittle context assembly; with a living wiki the heavy work is done ahead of user queries, and the model reads a curated, versioned document whose structure you control. That reduces surprise from noisy retrievals and makes the content inspectable by engineers and auditors. (venturebeat.com) Karpathy’s examples point to local-first Markdown tooling such as Obsidian and to outputs that are filed back into the repo: presentation slides, charts, and cross-referenced conceptual pages. Practitioners discussing the idea report practical scales — on the order of hundreds of articles and hundreds of thousands of words for deep subject wikis — and emphasize auto-linting and health checks as part of the maintenance step. (gist.github.com) For a principal engineer deciding whether to deepen on the IC track or move into management, the idea has two concrete implications. Technically, the pattern invites platform APIs that publish machine-readable, versioned documentation — not just OpenAPI specs but structured concept pages and changelogs the LLM can consume. Product-wise, it makes documentation itself a platform surface that you instrument, test, and ship as a product. (startupfortune.com) I infer that teams adopting this pattern will also need new signals: document-change observability, model-facing lint rules, and test suites that validate the wiki’s summaries against source truth. That inference follows from Karpathy’s emphasis on continuous maintenance and community writeups that call out linting and monitoring as necessary operational work. (academy.dair.ai) Karpathy’s post is short and practical: a working example flow, tooling notes, and the proposition that a model-maintained, Markdown-first archive can make LLMs reliably useful for long-running projects. The original gist and sample workflow remain available on his GitHub so teams can read the exact recipe and try a small pilot. (gist.github.com)