Karpathy's LLM Wiki: Have Your Agents Write One for You and Your Team

Anyone who works with several coding agents at once knows the feeling of falling behind them. Each session makes a few decisions, raises a question or two and learns something about the product, and within a day or two you can no longer say what was decided, what is still open, or why the code looks the way it does. The agents keep going without trouble, and you are the one who ends up overwhelmed. We wrote a separate post on why working with coding agents gets overwhelming.

In April, Andrej Karpathy posted a short document on GitHub called “LLM Wiki” that points at a way out. Instead of asking an LLM to rediscover the same knowledge from raw material every time, you let it build and maintain a wiki, and you read the wiki. We build Nimbalyst, a workspace where people and their coding agents work together, and our Wiki follows the same idea: your agents write a wiki for you, distilled from their activity, so you can think, organize, prioritize and set direction. This post walks through Karpathy’s pattern, what it means for a person directing agents, and what changes when a whole team does it.

What Karpathy’s LLM wiki is

Karpathy published the gist on April 4, 2026, as a follow-up to an April 2 post on X titled “LLM Knowledge Bases,” in which he wrote that “a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge.” He framed the gist as an “idea file”: you paste it into your own agent (“OpenAI Codex, Claude Code, OpenCode / Pi, or etc.”) and the agent builds a version for your needs.

His design has three layers. Raw sources are your collected documents, which the LLM reads but never modifies. The wiki is a directory of markdown pages the LLM generates, and “the LLM owns this layer entirely.” The schema is a file such as CLAUDE.md or AGENTS.md that tells the agent how the wiki is structured and which workflows to follow, and you and the LLM refine it together over time.

Two files keep the wiki navigable. An index.md catalogs every page and gets updated on each ingest, and a log.md records what happened and when. On top of that, he describes three operations. Ingest reads a new source and updates the pages it touches, which can be 10 to 15 pages for a single source. Query answers a question from the wiki, and “good answers can be filed back into the wiki as new pages.” Lint periodically checks for contradictions, stale claims, orphan pages and missing cross-references.

He sums up the division of labor in one line: “You read it; the LLM writes it.”

The wiki is for the person

The line we keep coming back to is this one: “The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.”

Karpathy also explains why wikis have always died: “Humans abandon wikis because the maintenance burden grows faster than the value.” The LLM takes over the maintenance, and what is left for the person is the thinking and the directing. We read this as the most important idea in the gist. The wiki exists so the person can understand what is going on and decide what happens next.

This matters more for coding agents than for research reading. When the raw material is your agents’ own sessions, plans and code changes, it piles up faster than anyone can read it. A wiki that distills that activity into the decisions made, the questions still open, the principles you are working from and what was learned along the way gives you back a view of your own project.

What you need from it when you direct agents

Karpathy’s examples ingest papers, articles and books, so his wiki mostly summarizes sources. A person directing agents needs something narrower. Summarizing every session produces a pile nobody reads. We use a stricter test for what earns a place: a strong model would get it wrong without the note, a person chose it or needed it to choose, and it will still matter after the code changes. What passes that test is mostly notes, open questions, decisions with their reasons, and principles, which is exactly what you need to think, organize, prioritize and set direction.

You also need to work in it, not only read it. A wiki you can edit is a place to think: you rewrite a principle, reorder priorities, or answer an open question in the page where it sits, and the agents pick up from there.

What changes when a team runs it

Karpathy wrote the gist for personal use, and his subtitle says so: “A pattern for building personal knowledge bases using LLMs.” He does list the team case among his examples, though: “an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls.”

A git repo of markdown files works well for one person and one agent. When five people each run several agents against the same product, the overwhelm multiplies and a few practical questions show up. What happens when two agents touch the same page at once? How do teammates see each other’s changes while they are happening instead of after a pull? Where do the questions that are waiting on a person show up, so someone answers them before an agent guesses?

There is also consistency. In a team wiki, pages rest on each other: a pricing decision affects the onboarding page, a customer page and a marketing principle. Karpathy’s lint pass catches contradictions after the fact. A wiki that knows how its pages connect can do better, so that when a decision changes, every page that rests on it is updated too.

Building it yourself vs the Nimbalyst Wiki

If you are working alone, the do-it-yourself version is a fine place to start: an Obsidian vault, a schema file in CLAUDE.md or AGENTS.md, and git for history. Karpathy himself uses Obsidian as the viewer (“Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase”). We compare that setup with ours in Nimbalyst Wiki vs Obsidian with a coding agent, and cover where CLAUDE.md, auto memory and a wiki each fit in Claude Code memory vs a wiki.

The personal wiki in Nimbalyst keeps the shape Karpathy describes. Its pages are plain files in your project, in nimbalyst-local/wiki by default, so your agents and the nim CLI can read and edit them like any other file. The Nimbalyst Wiki plugin lets Claude Code, Codex, Cursor, VS Code, Cowork or any MCP agent create and maintain it, with no app or account, and you read and edit it in your browser by asking your agent to open it. The step-by-step guides are How to keep a project wiki with Claude Code and How to keep a project wiki with Codex. The same folder also opens in the Nimbalyst desktop app.

In Nimbalyst, your agents write a wiki for you from their activity. While they work, they turn sessions into notes, open questions, decisions and principles and write them into pages organized by area, so you start with a wiki instead of a blank page. Every decision is marked with who made it, when, and what was not chosen, open questions show who owns them, and the home page collects what needs you and what changed recently.

The wiki is yours to work in. Rewrite a page, reorder priorities, settle an open question or sketch an idea, and your agents pick up from what you wrote. Pages are rich documents: write in markdown and drop in mockups, diagrams and 2x2s, all editable in place. Ask your agent to track competitors, customers or features and it creates a typed database with the right fields, fills it in, and shows it as a table you can read at a glance. Underneath, pages, questions and decisions link to each other as a graph, so when something changes, your agent follows those links and updates every page connected to it, and the wiki tells one consistent story.

Your personal wiki is free. With Wiki Teams, the wiki goes multiplayer, and you, your teammates and all of your agents work in the same pages in real time. See Wiki Teams for the team version.

FAQ

Is Karpathy’s LLM wiki a product I can install? No. Karpathy calls the gist an “idea file” for your own agent to build from, and he says it is “intentionally abstract” because it describes the idea rather than an implementation.

Can a team use an LLM wiki? Yes, and Karpathy lists the team case himself. For a team, the questions become how teammates see each other’s edits, how pages stay consistent when a decision changes, and where open questions surface for a person to answer.

Do I need RAG or a vector database? Not at moderate scale. Karpathy says an index.md catalog “works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.”