Andrej Karpathy posted last week that a large fraction of his token throughput is now going "less into manipulating code, and more into manipulating" knowledge. He described a pattern: dump raw materials (papers, articles, repos, notes) into a folder, point an LLM at it, and let the model compile and maintain a structured wiki. Cross-references, summaries, entity pages, concept links. All maintained by the AI. One research topic grew to 100 articles and 400,000 words without Karpathy writing a single page himself.
He published the idea as a gist, not a repo. His reasoning: in the era of LLM agents, you share the idea and let each person's agent build a version for their needs.
The pattern is designed for personal research. But the real unlock is at the team level.
The documentation problem nobody solves
Every engineering team has a documentation problem they have stopped trying to fix.
A Confluence space with pages last updated in 2023. A README that describes an architecture two refactors ago. Decisions buried in Slack threads nobody can find. Context in people's heads that walks out the door when they leave.
Teams have tried wikis, Notion databases, architecture decision records, onboarding docs. All of them go stale. Not because engineers are lazy. Because maintaining documentation is bookkeeping, and bookkeeping is the first thing that gets cut when there is real work to do.
Karpathy named this directly: "The tedious part of maintaining a knowledge base is not the reading or the thinking. It is the bookkeeping." LLMs are good at bookkeeping. They do not get bored. They do not deprioritize it when a deadline hits. They will cross-reference your architecture docs with your incident reports at 2am on a Sunday and not complain about it.
The pattern, adapted for teams
Karpathy's architecture has three layers. Raw sources (immutable, the LLM reads but never modifies). The wiki (LLM-generated markdown, structured and interlinked). The schema (a config file specifying structure and conventions, co-evolved by humans and the model).
For an engineering team, this translates directly:
The raw sources are your codebase, your ADRs, your incident postmortems, your design docs, your Slack exports, your onboarding notes. Anything that captures how the team thinks and works. You do not rewrite these. You just make them accessible.
The wiki is the compiled layer. The LLM reads across all your raw sources and builds pages: how the auth system works, why you chose Postgres over DynamoDB, what happened in the March 2025 outage and what changed afterward, how deploys work, what the on-call rotation covers. Each page links to the raw source it was compiled from.
The schema is where you define what matters. What topics should the wiki cover? How granular should architecture pages be? Should it track decisions or just current state? This is the file your team evolves over time. It is the editorial judgment layer.
Three operations keep it alive. Ingest: when someone adds a new ADR or postmortem, the LLM reads it, updates relevant wiki pages, adds cross-references, logs the change. Query: anyone on the team can ask questions and get answers synthesized from the wiki, with citations back to raw sources. And lint: periodic sweeps that flag contradictions, stale pages, or gaps where the wiki references something that no longer exists in the codebase.
What this actually changes
Onboarding stops being a three-month project. A new engineer can query the wiki instead of booking 15 coffee chats to learn how things work. The wiki does not replace human context, but it handles the "how does the deploy pipeline work?" and "why is this service split into two repos?" questions that currently eat the first month.
Bus factor drops. The Turing Post has been writing about this: AI knowledge layers make teams resilient against single-person departures. When the person who understands the payment system leaves, their knowledge does not leave with them if it was ingested into the wiki months ago. The wiki is not a replacement for that person. But it is the difference between "we have no idea how this works" and "we have a starting point."
Decisions get trails. Most teams make architectural decisions in meetings or Slack threads. The decision happens, the context evaporates, and six months later someone asks "why did we do it this way?" and nobody remembers. If your ADRs feed into the wiki, the LLM maintains the connection between the decision, the reasoning, and the current state of the system. You can ask "why do we use Redis for session storage?" and get the answer with the original discussion linked.
Code reviews get faster. A reviewer who can query the wiki for "what are the conventions in the payments service?" before reviewing a PR in that service has more context than a reviewer working from memory. This matters more as teams get smaller and individuals own more surface area.
The practical version
You do not need a custom platform. You need a folder structure and an LLM with a long context window.
Start with a raw/ directory. Put your ADRs, postmortems, and design docs in it. If you have onboarding docs, add those. If you have a CLAUDE.md or similar context file, that becomes part of your schema.
Point Claude or a similar model at the raw directory with a prompt that says: read all of these, build a structured wiki in wiki/, create an index page, and cross-reference everything. Let it run. Review what it produces. Fix the schema. Run it again.
The first pass will be rough. The tenth will be useful. By the twentieth, you will stop opening Confluence.
Anthropic's own engineering team uses background agents to auto-clean stale docs and submit cleanup PRs. That is the lint operation in practice. You can start simpler: run the lint sweep manually once a week and let the LLM flag what is out of date.
What this has to do with hiring
Teams with externalized context hire differently.
When your team's institutional knowledge lives in a wiki instead of people's heads, you are less dependent on finding someone who already knows your stack. You can hire for judgment and learning speed instead of specific experience, because the ramp-up cost drops. A strong engineer with good AI habits can query the wiki, understand your architecture, and start contributing faster than someone who "has 5 years of experience with your exact framework" but cannot navigate a knowledge system.
It also changes what you lose when someone leaves. If the knowledge is externalized, a departure is a capacity loss, not a knowledge loss. That is a different kind of problem, and a more solvable one.
We built Fairground's entire company context as a living wiki. Every strategy doc, competitive analysis, and product decision lives in a traversable markdown graph. New team members onboard against the wiki, not against a person's calendar. It took days to build the first version. It gets better every week.
Get started with Fairground in just few mins.
Plug and Play. Works well with your existing ATS.
100 Free Credits
