The Knowledge Base That Builds Itself

You solved the reading problem. Now solve the writing problem. Andrej Karpathy’s LLM Wiki pattern lets your AI agent maintain your knowledge base — so you never edit ctx.md again.

In The Context Wall, I described what happens when your AI knowledge base outgrows a single file — and how QMD solves the retrieval problem by searching your markdown files instead of loading them wholesale into the context window.

That article solved one half of the equation. There’s another half.

QMD fixes how your AI reads your knowledge base. But it doesn’t touch the harder problem: who writes and maintains that knowledge base in the first place?

You do. Manually. And as I confessed in that article — manually maintaining a knowledge base can be a mess. You’re the bottleneck. Every meeting insight, every architecture decision, every edge case you discover has to be manually written down, filed in the right place, cross-referenced with related knowledge. The bookkeeping is relentless.

In April 2026, Andrej Karpathy published an idea that reframes this entire problem. Karpathy is one of the most influential figures in AI — founding member of OpenAI, former Director of AI at Tesla where he built the Autopilot vision team from scratch, Stanford PhD under Fei-Fei Li, and creator of some of the most-watched AI education content on the planet. He’s also the person who coined the term "vibe coding." When Karpathy shares something, both researchers and engineers pay attention.

His LLM Wiki gist went viral: 17 million views, 13,000+ GitHub stars, and dozens of implementations within a week. The idea clearly struck a nerve.

The core insight is elegant: let the LLM maintain the knowledge base. You provide raw sources. The AI reads them, extracts the important parts, writes summaries, updates entity pages, maintains cross-references, and keeps the whole thing consistent. The tedious bookkeeping that humans abandon — the LLM handles it tirelessly.

This article is the complete guide: what the LLM Wiki pattern is, how it works technically, how to implement it with Claude Code, when to use it, when not to, and how it combines with QMD for the full knowledge management stack.

Two Problems, Not One

When your AI knowledge base stops working, it’s tempting to treat it as a single problem. But there are actually two distinct problems hiding under the surface:

The reading problem: Your knowledge base is too large for the context window. Your AI can’t see everything you’ve documented. Information gets missed.

The writing problem: Your knowledge base is too tedious to maintain. You stop updating it. Knowledge that should be documented never gets written down. Cross-references go stale. The file becomes a mess.

QMD solves the reading problem. The LLM Wiki solves the writing problem. They’re complementary — different tools for different pain points. Understanding which problem you’re actually facing determines which tool you need.

The LLM Wiki Pattern

Karpathy’s key insight: most people use LLMs as search engines over their documents. Upload files, retrieve chunks, get an answer. The LLM rediscovers knowledge from scratch on every question. Nothing compounds.

The LLM Wiki flips this. Instead of retrieving raw documents every time, the LLM reads sources once, extracts key information, and integrates it into an evolving structured knowledge base. Knowledge is compiled once and kept current — not re-derived on every query.

In Karpathy’s words: "The wiki is a persistent, compounding artifact."

His analogy: "Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase."

An Idea, Not an App

Here’s the fascinating part: Karpathy didn’t publish code. No library. No CLI tool. No npm package. He published a markdown document — an "idea file" describing the pattern. That’s it.

His reasoning: "In this era of LLM agents, there is less of a point/need of sharing the specific code/app, you just share the idea, then the other person's agent customizes & builds it for their specific needs."

Read that again. The most influential AI engineer in the world decided that sharing an idea in plain English is more useful than sharing an implementation. Because your AI agent can read the idea and build a version tailored to your specific project, your domain, your conventions.

This is exactly what I’ve been arguing throughout this series. In Human Language Is the Best Programming Language, I wrote about how natural language is becoming the primary interface for building software. In Spec-Driven Agentic Development, I showed how a well-written specification drives agent output more effectively than code examples. Karpathy’s idea file is living proof: a clear description of what you want, written for an AI agent to implement — no code required.

And implement they did. Within a week of Karpathy’s gist, the community produced dozens of implementations:

SamurAIGPT/llm-wiki-agent (1,495 stars) — Full Python implementation supporting Claude Code, Codex, and Gemini
claude-obsidian (299 stars) — Claude + Obsidian integration with /wiki, /save, /autoresearch commands
llm-wiki-compiler (288 stars) — "Raw sources in, interlinked wiki out"
obsidian-wiki (252 stars) — Framework for AI agents to build Obsidian wikis
llmwiki.app (167 stars) — Open-source web interface

But here’s the thing: you don’t need any of these. The entire implementation I describe in this article — the directory structure, the CLAUDE.md schema, the ingest/query/lint workflows — works with nothing but Claude Code and a file system. You paste the idea into your CLAUDE.md, and Claude Code becomes your wiki maintainer. No external tools, no dependencies, no setup beyond what you already have.

That’s the meta-lesson: in AI-native engineering, a well-articulated idea is the implementation. The gap between concept and working system has collapsed to the width of a prompt.

The Three-Layer Architecture

The pattern organizes knowledge into three distinct layers, each with clear ownership:

Layer 1: Raw Sources

What: The original documents — articles, papers, meeting transcripts, Slack exports, design docs, images. Stored in a raw/ directory.

Who owns it: You. These are immutable. The LLM reads them but never modifies them. This is the source of truth you can always verify against.

Why it matters: When the LLM makes a mistake in the wiki (and it will), you can always trace back to the original source. This layer is your insurance policy against hallucination compounding.

Layer 2: The Wiki

What: LLM-generated markdown files — summaries, entity pages, concept pages, comparisons, synthesis. Stored in a wiki/ directory.

Who owns it: The LLM. It creates, updates, cross-references, and maintains consistency. Humans read it; the LLM writes it.

Why it matters: This is the compiled knowledge. Instead of reading a 20-page research paper every time you need a fact from it, you read the LLM’s distilled summary with cross-references to related concepts. The compilation is done once. Every future query benefits from it.

Layer 3: The Schema

What: A configuration document (your CLAUDE.md) that tells the LLM how the wiki is structured — naming conventions, page formats, workflows, tag taxonomy.

Who owns it: You and the LLM together. You set the initial structure; the LLM suggests improvements as the wiki evolves.

Why it matters: This is what turns the LLM from a generic chatbot into a disciplined wiki maintainer. Without the schema, the LLM produces inconsistent, unstructured output. With it, every page follows the same format, every cross-reference uses the same conventions, every ingest follows the same workflow.

The Directory Structure

project/
  CLAUDE.md              # Schema — wiki conventions, workflows, formats
  raw/                   # Immutable source documents
    articles/
    papers/
    meeting-notes/
    assets/              # Images, PDFs
  wiki/                  # LLM-generated, LLM-maintained
    index.md             # Master catalog of all pages
    log.md               # Chronological activity record
    entities/            # People, organizations, projects
    concepts/            # Ideas, frameworks, theories
    sources/             # Per-source summaries
    synthesis/           # Cross-source analysis pages

The Three Operations

Everything the LLM does with the wiki falls into three operations:

Ingest

You drop a source into raw/ and tell the LLM to process it. Here’s what happens:

The LLM reads the source document
Discusses key takeaways with you (optional but recommended)
Writes a summary page in wiki/sources/
Updates the master index.md
Updates or creates relevant entity pages (people, organizations mentioned)
Updates or creates relevant concept pages (ideas, frameworks discussed)
Adds cross-references between new and existing pages
Appends an entry to log.md

A single source might touch 10–15 wiki pages. This is the bookkeeping that humans abandon — and the exact work LLMs excel at. Karpathy recommends ingesting one source at a time with supervision, especially early on, to calibrate the quality.

Query

Ask questions against the wiki. The LLM reads index.md first (the master catalog), finds relevant pages, reads them, and synthesizes an answer.

The powerful insight: good answers get filed back into the wiki as new pages. If your query produces a valuable synthesis — a comparison between two frameworks, a decision analysis, a gap identification — that becomes a permanent wiki page. Your explorations compound into reusable knowledge.

Lint

Periodic health checks. Tell the LLM to audit the wiki for:

Contradictions — two pages claiming different things about the same topic
Stale claims — information that may have changed since it was compiled
Orphan pages — pages with no inbound links from other pages
Missing concepts — topics referenced frequently but without their own page
Gaps — areas where a web search could fill in missing knowledge

This is wiki hygiene. The LLM does in minutes what would take a human hours — and unlike a human, it won’t skip it because it’s tedious.

The Two Special Files

index.md — The Master Catalog

This is the most important file in the wiki. It’s a content-oriented catalog of every page, organized by category, with one-line summaries. The LLM reads this first when answering any query — it’s the table of contents that lets it navigate the entire knowledge base.

Karpathy reports this approach "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure." The index is small enough to fit in context, and descriptive enough to guide the LLM to the right pages.

When the wiki outgrows what index.md can handle, that’s where QMD comes in. More on that later.

log.md — The Activity Record

A chronological, append-only record of everything that happens in the wiki: ingests, queries, lint passes. Each entry uses a consistent format:

## [2026-04-09] ingest | "Payment Reconciliation Architecture"
Source: raw/articles/payment-recon.md
Pages created: concepts/settlement-processing.md, entities/stripe.md
Pages updated: index.md, concepts/payment-flows.md
Cross-references added: 7

## [2026-04-09] query | "How do settlement timelines differ by provider?"
Pages consulted: concepts/settlement-processing.md, entities/stripe.md, entities/adyen.md
Result filed as: synthesis/settlement-timeline-comparison.md

The log gives you a complete audit trail. You can see exactly when knowledge was added, which sources informed which pages, and how the wiki evolved over time.

Implementing With Claude Code

Here’s how to set this up in practice with Claude Code.

Step 1: Create the Directory Structure

mkdir -p raw/articles raw/papers raw/meeting-notes raw/assets
mkdir -p wiki/entities wiki/concepts wiki/sources wiki/synthesis
touch wiki/index.md wiki/log.md

Step 2: Configure CLAUDE.md

Add the wiki schema to your CLAUDE.md. This is the key configuration that turns Claude from a generic assistant into a disciplined wiki maintainer:

## LLM Wiki

This project maintains a knowledge wiki in `wiki/`.
Raw sources live in `raw/` (immutable — never modify).

### Page Format
Every wiki page uses this structure:
- YAML frontmatter: title, created, updated, tags, sources
- **TLDR** section: 2–3 sentence summary
- Main content with H2/H3 sections
- **Related** section: links to related wiki pages
- **Sources** section: links back to raw/ documents

### Ingest Workflow
When asked to ingest a source:
1. Read the source in raw/
2. Create a summary page in wiki/sources/
3. Create or update relevant entity pages in wiki/entities/
4. Create or update relevant concept pages in wiki/concepts/
5. Add cross-references between new and existing pages
6. Update wiki/index.md with new entries
7. Append to wiki/log.md

### Query Workflow
When asked a question:
1. Read wiki/index.md to find relevant pages
2. Read those pages
3. Synthesize an answer
4. If the answer is valuable, file it as a new page in wiki/synthesis/

### Lint Workflow
When asked to lint:
- Check for contradictions between pages
- Flag stale claims
- Identify orphan pages with no inbound links
- Suggest missing concepts that should have their own page

### Naming Conventions
- Files: lowercase, kebab-case (e.g., payment-reconciliation.md)
- Tags: lowercase (e.g., architecture, payments, compliance)
- One concept per page. Split if a page exceeds 500 lines.

Step 3: Ingest Your First Source

Drop a document into raw/ and tell Claude:

Ingest raw/articles/payment-reconciliation-architecture.md

Claude reads it, creates summary and entity pages, updates the index, and logs the activity. Watch it work the first few times — this is where you calibrate quality and adjust the schema if needed.

Step 4: Query the Wiki

How do settlement timelines differ between Stripe and Adyen?

Claude reads the index, navigates to the relevant pages, synthesizes an answer with citations back to wiki pages and original sources. If the answer is valuable, ask Claude to file it as a new synthesis page.

Step 5: Periodic Maintenance

Lint the wiki

Claude audits the entire wiki structure, reports contradictions, flags stale content, identifies orphan pages, and suggests improvements. Do this weekly — or whenever the wiki has grown significantly since the last lint.

The Full Stack: QMD + LLM Wiki Together

This is where it gets powerful. QMD and the LLM Wiki solve different problems, and they combine naturally.

LLM Wiki alone: The LLM maintains your knowledge base. At moderate scale (~100 sources, hundreds of wiki pages), index.md is enough for the LLM to navigate the wiki. No search infrastructure needed.

But as the wiki grows past ~100 sources, the index itself becomes too large for the context window. The LLM can’t hold the full table of contents anymore. Sound familiar? It’s the same wall we described in The Context Wall — just applied to the wiki’s index instead of your ctx.md.

QMD + LLM Wiki: QMD indexes the entire wiki directory. Instead of reading index.md to find relevant pages, Claude calls qmd query to search across all wiki pages semantically. The LLM still writes and maintains the wiki; QMD handles retrieval at scale.

project/
  CLAUDE.md              # Schema + QMD instructions
  .qmdrc                 # QMD indexes wiki/
  raw/                   # Immutable sources (you add these)
  wiki/                  # LLM-maintained (Claude writes these)
    index.md             # Small/medium wikis: Claude reads this
    ...                  # Large wikis: QMD searches instead

The progression:

Start simple: One ctx.md file, manually maintained. Works up to ~3,000 lines.
Hit the reading wall: Add QMD for search-based retrieval. Still manually maintained.
Hit the writing wall: Add the LLM Wiki pattern. Claude maintains the knowledge base. QMD handles retrieval.

You don’t need to jump to step 3 from day one. Each step addresses a specific pain point. Adopt them as you feel the pain, not before. KISS still applies.

When Each Approach Makes Sense

Stay With a Single ctx.md When:

Your knowledge base is under 3,000 lines
You’re the only person contributing knowledge
The project is stable — not much new knowledge flowing in weekly
You enjoy the curation process and it doesn’t feel like a burden
You want maximum transparency — one file, fully visible, no magic

Add QMD When:

Your context file exceeds 3,000–6,000 lines
You notice Claude missing information you documented
You’re trimming knowledge to keep the file manageable
The reading is the bottleneck — too much to fit in context

Add LLM Wiki When:

You’re receiving knowledge from many sources (meetings, docs, Slack, research)
You find yourself not documenting things because the maintenance is too tedious
Cross-references between knowledge areas are getting stale or missing
You want knowledge to compound — each new source enriching the whole base
The writing is the bottleneck — too tedious to maintain manually

Use Both When:

Your wiki grows past ~100 sources or hundreds of pages
The wiki’s own index.md becomes too large for the context window
You want the full stack: automated writing and scalable reading

Honest Limitations

The LLM Wiki pattern is powerful. It’s also imperfect. Here are the real tradeoffs:

Hallucination Compounding

The most serious risk. If the LLM makes a subtle error when compiling a source — a slight misinterpretation, a wrong attribution — that error becomes a permanent fact in the wiki. Future queries reference it. Future ingests build on it. The error compounds.

Mitigation: the raw sources layer is your safeguard. You can always verify wiki claims against originals. Periodic lint passes can cross-check. But this requires discipline — trust but verify.

Knowledge Drift

Over time, the wiki may gradually diverge from source truth through accumulated small edits. Each individually reasonable, together they shift the meaning. This is especially risky when switching between LLM models or across long time periods.

Mitigation: every wiki page links back to its source documents. The log.md tracks every change. Git history provides full version control. The audit trail is built in.

The "Brain Gap" Problem

This is the philosophical objection, and it’s worth taking seriously. If the LLM does all the synthesis, do you actually learn? The Zettelkasten tradition argues that the act of writing is the act of thinking — that friction is cognition. Remove the friction, and you might remove the understanding.

One Hacker News commenter described experiencing "persistent brain gap tech debt" from over-reliance on LLM-generated notes.

The pragmatic response: use the wiki as input to your thinking, not a replacement for it. Read what the LLM compiles. Challenge it. Ask follow-up questions. The wiki is a starting point for understanding, not the destination. Let the machine build the map — then walk the territory yourself.

Cost at Scale

Each ingest touches 10–15 pages. At scale, this consumes significant tokens. For individuals with generous API access or tools like Claude Code, this is manageable. For budget-constrained use cases, the token cost of maintaining a large wiki adds up.

Not For Everything

The pattern works best for stable, research-oriented knowledge — architecture decisions, domain concepts, synthesis of multiple sources. It works less well for highly dynamic contexts where information changes daily, like project management status or sprint planning. For that, simpler approaches win.

81 Years in the Making

In 1945, Vannevar Bush — the man who coordinated the Manhattan Project — published "As We May Think" in The Atlantic Monthly. He described the Memex: a personal, curated knowledge store with associative trails between documents. A private library where the connections between documents were as valuable as the documents themselves.

Bush’s vision inspired Ted Nelson (who coined "hypertext"), Doug Engelbart (who invented the mouse and the hyperlink), and eventually the World Wide Web. But the web that emerged was public and chaotic — the opposite of Bush’s private, curated vision.

The part Bush couldn’t solve: who does the maintenance? Who keeps the cross-references current? Who flags contradictions? Who updates the trails when new information arrives? Humans tried wikis, personal knowledge management systems, Zettelkasten — and eventually abandoned them all because the maintenance burden grew faster than the value.

LLMs solve this. They don’t get bored. They don’t forget to update a cross-reference. They can touch 15 files in one pass without complaint. The LLM Wiki is, in a very real sense, the first practical implementation of what Vannevar Bush imagined 81 years ago.

Karpathy himself acknowledges this: "Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that."

The Full Picture

Zoom out and you can see the complete knowledge management evolution for AI-native engineering:

Single file — You write it, Claude reads it. Simple, transparent, manual. (The Knowledge Equation)
QMD — You write it, QMD searches it. Scales reading, still manual writing. (The Context Wall)
LLM Wiki — Claude writes it, Claude reads it. Scales both. You curate sources and ask questions. (This article.)
LLM Wiki + QMD — Claude writes it, QMD searches it. The full stack. Scales everything.

Each step is an upgrade path, not a starting point. Start simple. Adopt complexity only when you feel the pain. The best knowledge management system is the one you actually use — and the simplest approach you can get away with is always the right one.

As I wrote in The Knowledge Equation, domain knowledge is the real differentiator in AI-native engineering. The tools to capture, maintain, and retrieve that knowledge are maturing rapidly. What hasn’t changed — and won’t change — is that the knowledge itself has to come from somewhere. From your experience. Your domain expertise. Your years in the trenches.

The infrastructure is getting better. The hard part stays the same.

The Context Wall — When your knowledge base outgrows a single file, and how QMD helps
The Knowledge Equation — Why domain knowledge is the real AI differentiator
The Architect's Protocol — The complete AI-native development workflow
KISS Your AI Workflow — Keep it simple until you can’t