Karpathy's LLM Wiki for Engineering Teams: The Fourth Layer

TL;DR

1. Karpathy's LLM Wiki pattern (ingest, query, lint over a structured markdown knowledge base) was designed around a single researcher reading documents. Engineering teams break nearly every assumption in that setup.

2. To run a wiki for a team, you need a fourth architectural layer the original spec doesn't address: passive capture from the work surfaces where operational knowledge actually originates (Slack threads, terminals, incident channels), along with scope-aware retrieval and a split between operational and reference regimes.

Karpathy's Pattern Is Personal-First

In April 2026, Andrej Karpathy published a short gist called llm-wiki.md describing a pattern for building personal knowledge bases with LLMs. Instead of running RAG over raw documents at query time, an LLM agent incrementally compiles sources into a structured, cross-linked markdown wiki of entity pages, concept pages, a summary, and an index. The wiki is the compiled artifact; the raw sources sit untouched behind it. Knowledge accumulates instead of being rediscovered on every question.

The write-up is elegant and self-aware about its scope. Re-read the examples Karpathy lists: personal journaling, deep research on a topic, reading a book with a companion fan-wiki, competitive analysis, trip planning. Team usage is mentioned once, almost in passing. The entire operational model (drop a source in, query against the wiki, run occasional lint passes) assumes one human who curates the raw collection and directs the agent's attention.

Engineering teams do not work this way. Nobody curates. Nobody drops documents into a folder. The most important operational knowledge, the kind an on-call engineer actually needs at 2 a.m., was never written as a document in the first place.

The Source Problem: Teams Don't "Add Documents"

In Karpathy's pattern, the ingest flow begins with a source entering the raw collection. A paper. An article. A PDF. The agent reads it and updates the wiki accordingly.

For an engineering team, that framing inverts reality. The high-value knowledge in a company is produced as a byproduct of work: a Slack thread where two engineers figured out why the auth service started 502ing after a deploy, a terminal session where someone ran seven kubectl describe commands and found a misconfigured sidecar, an incident channel where the resolution was a single message reading "rolled back commit abc123, issue gone." None of this is a document. None of it will ever become a document unless someone stops doing their job to write one.

The consequence: a wiki whose ingest operation requires a curated source collection will stay near-empty for exactly the questions engineers most need answered. The wiki will have a beautiful entity page for the architecture diagram someone bothered to draw, and nothing at all on the three production bugs that actually consume the team's weekly on-call cycles.

The Permission Problem: Knowledge Has a Scope

Karpathy's wiki sits in an Obsidian vault. The implicit access control is "the person who owns the laptop."

In a team context, knowledge has scope. A runbook for the payments service should be visible to the payments engineers; a security incident retro should not be automatically visible to the intern. Permissions are not an afterthought you bolt onto retrieval. They change what the wiki fundamentally is. The same underlying facts may appear in different pages for different audiences, and a query against the wiki is not "find relevant pages," it is "find relevant pages the querier is allowed to see."

This has architectural consequences. The flat index.md Karpathy describes, a catalog the LLM reads to locate relevant pages, does not survive first contact with a real permission model. You need scope-aware retrieval. You need team structures derived from the org's actual work surfaces (Slack channels, IdP groups) rather than a config file someone typed out by hand. And you need those permissions enforced at query time, not at ingest, because the same wiki page may be legitimately readable by different subsets of users as membership changes.

The Operational/Reference Split

Not all engineering knowledge has the same lifecycle. Reference knowledge (system architecture, data models, API contracts) is relatively stable and benefits from exactly the compounding, cross-linked treatment Karpathy describes. Operational knowledge (how we actually deploy this service, what breaks when Redis is under pressure, why that flaky test is flaky) is tacit, constantly churning, and tied to specific incidents and people.

Karpathy's lint operation assumes a single wiki surface where contradictions are flagged and stale claims are superseded. That works when the corpus is one person's evolving understanding of a research topic. It does not work when half the wiki is supposed to track a moving target and the other half is supposed to be load-bearing. A wiki for engineering teams needs to separate these regimes: at minimum, a different retention and staleness policy for operational pages than for reference pages, and a different editorial posture about what "contradiction" even means.

Extending the Pattern

The core insight of Karpathy's pattern is correct and worth preserving: compiling knowledge once at ingest time beats re-deriving it on every query. A persistent, structured artifact compounds. RAG over raw documents does not.

What engineering teams need is that same core idea, wrapped in three extensions:

1. Passive capture as a first-class ingest mode. Work surfaces are sources. A Slack thread marked with a reaction, a terminal session wrapped in a capture tool, an incident channel transitioning from "firing" to "resolved": these should produce wiki entries without a human deciding to write one.

2. Scope-aware retrieval from day one. Team membership, channel visibility, and resource permissions must be reflected in the index and enforced at query time, not grafted on later.

3. Separate operational and reference regimes with different authoring, retention, and staleness semantics, so the wiki can hold both without one degrading the other.

The pattern Karpathy published is a good starting point precisely because it is scoped. For team engineering work, the scope has to expand, and most of the interesting architectural decisions happen in that expansion, not in the original gist.