Is an LLM-maintained wiki in git a better fix than a context tool for engineering knowledge?
For one person or a small team with a few hundred pages, an LLM wiki in git is often enough and costs little. It breaks down when nobody reviews what the LLM writes, when the answer lives in Slack or a ticket that never reached the wiki, and when different readers may see different things. A context tool reads those sources directly and can check each answer against the asker's permissions.
Sometimes, yes: an LLM wiki in git is a good fix for one engineer or a small team with a few hundred pages. It stops being the better fix once the knowledge you need is mostly in Slack threads, tickets and incident channels, or once different people are allowed to see different things. An LLM wiki is a folder of markdown pages that a model writes and keeps up to date from source material you give it, stored in a git repo so every change has history. A context tool is a service that reads code, pull requests, tickets, docs and chat where they already live and answers a question from all of them at the moment it is asked. The wiki copies knowledge into one place ahead of time. The context tool goes and gets it when it is needed.
What the LLM wiki pattern is#
Andrej Karpathy wrote the pattern down in an April 2026 gist (Karpathy, LLM Wiki). His complaint about plain retrieval is that "the LLM is rediscovering knowledge from scratch on every question." His fix is a wiki the model owns: "You read it; the LLM writes it." There are three layers. Raw sources the model reads but never edits, the wiki pages it writes, and a schema file such as a CLAUDE.md that tells it how to behave. You run three jobs on it: ingest a new source, ask questions, and "periodically, ask the LLM to health-check the wiki."
Storage is plain. "The wiki is just a git repo of markdown files," and you get "version history, branching, and collaboration for free." The gist even names the team version: "an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts," "possibly with humans in the loop reviewing updates." That "possibly" is where the trouble for engineering teams starts.
When a wiki in git is enough#
For many people it is the right answer. Karpathy says the simple index approach "works surprisingly well at moderate scale (~100 sources, ~hundreds of pages)." If you are one engineer studying a codebase, or a team of five with one repo and a handful of design docs, that is your scale. The cost is a repository and some model calls, and the output is readable in any editor, easy to diff, and disposable.
It also suits knowledge that changes slowly. Build steps, naming rules and how a service is laid out stay true for months. Claude Code's own docs say project CLAUDE.md files hold "build and test commands, coding standards, architectural decisions" and are "shared with your team through version control" (Claude Code memory docs). A wiki is a larger version of that same idea. If your questions are mostly "how is this laid out" and "what are the rules here," start with the wiki.
Who curates it, and how it drifts#
Nobody writes most of it by hand, by design: "you never (or rarely) write the wiki yourself." Karpathy reads each update as it lands and suggests staying involved, but he also allows batch ingests "with less supervision." On a team, that reading slips first, and each ingest becomes a model summarizing a summary, with errors piling up quietly. A wrong line in page 40 becomes the source for page 41. We wrote about this loop in stop AI slop from contaminating team knowledge.
Wiki drift is the gap that opens when the code, tickets or decisions change and the wiki does not. It starts the moment the code moves without a new ingest. Here is a made-up example: a page says the payments service retries three times. A pull request changed it to five last week, and no one fed that PR to the wiki. Now the agent reads a confident, wrong page. The lint pass helps only if someone runs it.
Size works against you too. Claude Code's docs say to "target under 200 lines per CLAUDE.md file" because "longer files consume more context and reduce adherence." A February 2026 study of repository context files found that providing them "does not generally improve task success rates, while increasing inference cost by over 20% on average," for both model-written and human-written files (Gloaguen et al., arXiv). More pages in front of the agent is not the same as better answers, which is also why agent-written docs should not feed the next agent unchecked.
What a wiki in git cannot hold#
Three kinds of engineering knowledge never land in the wiki cleanly.
- Decisions made in chat. Take a made-up case: the reason a timeout is 30 seconds sits in a Slack thread or an incident channel. The wiki only has it if someone exported that thread and fed it in.
- Live work in tickets. Jira and Linear change every day. A wiki snapshot of a ticket is out of date by the next standup.
- Who may see what. GitHub grants access per repository: you "customize access to each repository in your organization" by role (GitHub docs). Anyone who can read the wiki repo can read every page in it. Summarize a private security channel or an HR-adjacent ticket into the wiki and you have just widened who can see it.
The last one is what tends to stall wiki projects at larger companies. You can split it into many repos, one per audience, but then you are running a permission system by hand.
When a context tool is the better fix#
Move when the questions you care about are "why" questions spread across several systems, and when the team has grown past the point where one repo of pages fits everyone.
| LLM wiki in git | Context tool | |
|---|---|---|
| Where knowledge lives | Copied into markdown pages | Read in place from each source |
| What keeps it current | Someone running ingest and lint | Automatic sync from each source |
| Slack, tickets, incidents | Only what someone fed in | Read directly |
| Permissions | Whole repo or nothing | Answers can be limited to what the asker may see |
| Good fit | One person or a small team, ~hundreds of pages | Many repos, teams and private channels |
In 194 conversations about homegrown context stacks, the most common failure was staleness with no owner, raised in more than 4 in 10 of the roughly 150 organizations. That post describes its methodology, including the selection bias in its numbers.
Unblocked takes the other approach: it reads code, PRs, issues, docs, Slack or Teams and incidents in place, answers inside Claude Code, Cursor and GitHub Copilot over MCP and in Slack, and keeps each source in sync without a manual re-ingest. With Data Shield turned on for a source, answers "only contain source material that the user posing the question is authorized to access." Nothing is copied into a shared page, so there is no second set of permissions to keep right.
You do not have to pick one forever. Keep a short, human-reviewed CLAUDE.md for the rules that rarely change. Let a context tool answer the questions whose answers live in last week's pull request or this morning's thread. To compare documentation tools first, see the best AI documentation tools for engineering teams.
