This post is a side-step. If you’ve been following this blog, you know it’s about one thing: using Claude Code to ship .NET code faster. Practical workflows, real examples, no hype.
Today I’m stepping outside that lane. Not because I’ve run out of Claude Code topics — far from it — but because something happened in the AI space this week that I think every developer using AI agents should pay attention to. Even if you don’t build knowledge systems. Even if you’ve never heard of RAG.
Andrej Karpathy published an idea, and it clicked.
Who dropped what
On April 2, Andrej Karpathy — former head of AI at Tesla, OpenAI co-founder, and one of the most respected voices in deep learning — posted on X that a growing share of his LLM token usage was going not into code, but into knowledge. Organizing it, connecting it, maintaining it.
Two days later he published a GitHub Gist titled “LLM Wiki.” Not a framework. Not a library. An idea file — a document you paste into your AI agent so it can help you build a knowledge base following his pattern.
The gist got 5,000+ stars and nearly 3,000 forks in days. Implementations started popping up within hours. VentureBeat covered it. The developer community ran with it.
Why? Because it named a problem most of us feel but haven’t articulated.
The problem with asking the same thing twice
Here’s how most people use LLMs with their own documents today. You have a collection of files — maybe research papers, meeting notes, technical docs. You use some form of RAG: the system chunks your documents, stores embeddings in a vector database, and retrieves relevant fragments when you ask a question.
It works. But there’s a fundamental limitation: every query starts from scratch. The LLM re-discovers knowledge each time. It doesn’t remember that yesterday it already figured out the relationship between two concepts in your documents. It doesn’t accumulate understanding.
If you’ve ever asked an AI the same question about your codebase in two different sessions and gotten two different (equally mediocre) answers — you’ve felt this problem.
Karpathy’s insight: what if the LLM didn’t just retrieve from your documents, but actively maintained a knowledge base? What if every question made the system smarter, not just you?
The LLM Wiki pattern
The architecture is surprisingly simple. Three layers:
Layer 1: Raw sources. Your original documents — articles, papers, transcripts, data files. These are immutable. The LLM reads them but never touches them.
Layer 2: The wiki. A collection of markdown files that the LLM writes and maintains. Summaries, concept pages, entity pages, comparisons, cross-references. This is the LLM’s workspace. You rarely edit it directly.
Layer 3: The schema. Configuration files (think CLAUDE.md or AGENTS.md) that tell the LLM how to maintain the wiki. What structure to follow, what conventions to use, what workflows to run.
That’s it. Markdown files in folders. No vector database. No embedding pipeline. No infrastructure beyond a text editor and git.
Three operations, not one
The real innovation isn’t the storage format — it’s the workflow. Karpathy defines three operations:
Ingest. You drop a new source into the raw folder and ask the LLM to process it. It reads the document, writes a summary page, updates relevant concept and entity pages, adds cross-references, and logs the action. One source typically touches 10 to 15 wiki pages.
Query. You ask questions, but against the wiki — not the raw sources. The LLM reads the index, finds relevant pages, and synthesizes an answer with citations. If the answer is valuable enough, it goes back into the wiki as a new page. Your exploration becomes a knowledge artifact.
Lint. Periodically, you ask the LLM to audit the wiki. Find contradictions. Flag stale claims. Identify orphan pages. Spot missing cross-references. Suggest knowledge gaps worth filling. This is the maintenance pass that keeps the system honest.
This is what makes it different from a chat session. Chat is ephemeral. A wiki compounds.
Why developers should care
You might be thinking: “I write code, not research papers. Why should I care about a note-taking pattern?”
Three reasons.
Your AI agent already has this problem. If you use Claude Code, Codex, or any agentic coding tool with a CLAUDE.md or similar context file — congratulations, you’re already maintaining a mini knowledge base. The LLM Wiki pattern is a more principled version of what you’re already doing when you write project instructions for your agent.
Knowledge work is eating code work. Karpathy said it directly: a growing fraction of his token throughput goes to knowledge, not code. If you’re building features with AI, you’re spending more time on context, decisions, and architecture than on typing code. The LLM Wiki pattern acknowledges this shift.
The tooling is stuff you already know. Obsidian (or any markdown editor), git for version control, files in folders. No new infrastructure. No vendor lock-in. If you can read markdown and use git, you can use this pattern.
What I find compelling about it
There are two things about Karpathy’s approach that resonated with me specifically.
First: the LLM as bookkeeper, not oracle. Karpathy frames it well — the tedious part of maintaining knowledge isn’t the reading or thinking. It’s the bookkeeping. Cross-references. Summary updates. Consistency checks. That’s exactly the kind of work LLMs are good at: systematic, repetitive, requiring attention but not creativity.
Second: the idea file as distribution format. Karpathy didn’t publish a tool. He published a pattern — a document you paste into your agent that teaches it a new capability. That’s a distribution model that only works in the age of AI agents. No installation. No dependencies. Just a well-written prompt. The fact that dozens of implementations appeared within days proves the model works.
This is also, by the way, exactly how Claude Code skills work. A well-structured instruction file that teaches the agent a workflow. Karpathy’s gist is essentially a skill definition for knowledge management.
The limits
I wouldn’t be honest if I didn’t mention the constraints.
Scale. The pattern works well for personal research and small team contexts — roughly up to a few hundred sources. Beyond that, pure index-based navigation probably isn’t enough, and you’d need some form of retrieval layer on top. Karpathy acknowledges this.
Drift. A wiki maintained by an LLM can consolidate errors just as convincingly as it consolidates insights. The lint pass helps, but it doesn’t replace human judgment. Someone needs to own the quality of the knowledge base, especially in team settings.
Curation. The system assumes you’re deliberately choosing high-quality sources. It’s a compiler for curated knowledge, not a web crawler. Garbage in, confidently-written garbage out.
These are real limitations. But for the sweet spot — personal research, bounded domains, team knowledge — the pattern is remarkably practical.
The bigger picture
What Karpathy is really saying, underneath the architecture, is this: stop treating your LLM as just an answer machine. Treat it as a knowledge worker.
An answer machine gives you responses and forgets. A knowledge worker builds artifacts that persist and compound. The LLM Wiki is one implementation of that idea, but the principle is broader.
Every developer who uses AI agents daily is, whether they realize it or not, figuring out how to make AI work accumulate rather than evaporate. How to turn ephemeral chat sessions into durable value. The LLM Wiki pattern offers one clear answer.
Want to try it?
If you want to experiment with this pattern:
- Read Karpathy’s original gist — it’s the primary source and surprisingly readable
- Pick a topic you’ve been researching
- Create a folder with
raw/,wiki/, and an instruction file for your agent - Drop in a few sources and ask your agent to process them
You don’t need any special tooling. Obsidian works well as a viewer, but any markdown editor will do. Git gives you version history for free.
The pattern is the product. That’s the whole point.
Next week we’re back to our regular programming: Claude Code workflows for .NET developers. But sometimes the most practical thing you can do is step back and notice when someone frames a problem better than you’ve been thinking about it.