Article
I have never liked updating documentation. I never understood the point. You spend 30 minutes finding the right words. Then a colleague makes a change and your work goes down the drain. In our US healthcare project at Nitor, we stopped updating documentation by hand. With an LLM Wiki it updates itself every night.
Documentation is nice when it is fresh. Then time passes and nobody trusts it anymore. How many times have you asked a new team member to “update the onboarding material if something is not accurate”?
The AI era makes this worse. A human sees that a page is 6 months old and takes it with a pinch of salt. Most AI agents I have worked with take it as fact. Current models are smart enough to dig deeper and find the truth from the source. But that takes time and tokens. It also fills the context with wrong information and redundant memories.
At Nitor we work on a large and complex project for US healthcare. The agents there need to know what is accurate and what is not. They cannot read 100,000 lines of code every time. We started solving this with a pattern called LLM Wiki.
The pattern
The pattern was introduced earlier this year by Andrej Karpathy, co-founder of OpenAI. The idea is simple. Stop writing pages. Start writing instructions.
The pattern has 3 parts and needs a capable AI agent to run them. In this post I go through each part and show how to set it up for yourself.
The first part is the sources. This is the content your wiki is built from. Mostly it is text. With current multimodal models it can also be images, sound or even video. It is whatever you would want in your own Wikipedia.
The second part is the instructions. This is the heart of the pattern. They define how you want your wiki to look and feel.
The third part is the gardener, or more generally linting. It keeps your wiki free of duplicate and stale information.
Instructions
Instructions are like AGENTS.md or CLAUDE.md, but for your wiki. At minimum it is 1 markdown file where you define how agents work in your wiki. A good file answers questions like these:
Who is the wiki for? Agents, humans or both?
Should it have executive summaries, or is the audience only engineers?
Should sources be visible on the wiki pages?
Which tool do you use to read it as a human? What kind of linking do you want between files?
Should the final content be .md files, HTML or images?
What happens when 2 sources disagree? Does the newer one win, or is there a hierarchy?
All of this is up to you.
Once you have sources and instructions, define your linting rules. You can start from Karpathy’s example. Also think about historical files. Do you delete them or mark them as deprecated?
Our setup
Now you know the parts. Here is how we run it. We work in a fast-paced US customer project. Every Thursday we get the tasks for the following week. Every Thursday they need to be ready. We have no time for documentation work. Not even for our coding agents.
Start with the sources
We started by defining the sources. Our main material is merged pull requests. After that come our weekly transcripts, some emails and third party documents.
Write better pull requests
To make this easy, we put effort into our pull requests. Each one says clearly what it changes and what is “now true”. This makes the next step in the pipeline easier.
Filter and distil
From all merged PRs we filter out the ones without relevant content for the wiki. These are small fixes, dependency updates and other maintenance work. From the rest we distil the essentials. For example, 5 merged changes can be 1 bigger change from a documentation point of view.
Let the agent write
The distilled material fuels the wiki. Our agent follows our instructions file. It writes and rewrites the wiki pages that the material touches. After that we run linting. It checks that information is fresh and links work. Historical data is either removed or clearly marked.
Treat mistakes as instruction bugs
We also made a rule for mistakes. When we find one in the wiki, we aim to change the instruction that caused it, or add a rule that prevents it. Write instructions, not pages. This means we still spend some time on maintenance after the setup. But it is far less than we would spend with agentic wiki updates alone.
Run it nightly
And the best part? It all runs nightly. None of us has to think about it.
What we got
Over the last 6 months our wiki has grown to 800+ pages. It holds executive summaries, runbooks and architecture diagrams. All of it updates automatically and is made for both humans and agents.
Our planning agents have a reading step. They find and read the relevant pages before planning a task. This gives them the latest understanding without reading through the whole implementation every time. For us humans, it means more time for the actual work.
Not only for code
The pattern is not only for technical documentation like in our case. You can use it for any content where new information keeps coming in. Onboarding material? Local lunch place reviews? Set up a folder and start dropping things in.
How to get started
First, gather the material. A few documents are enough. Then draft the instructions file. You can answer the questions above, or start from Karpathy’s example.
Combine these with any modern AI agent that has enough context and a bit of thinking. You do not need the absolute frontier model.
After the first generation, look at your wiki. If you are not happy with the output, change the instructions and let the LLM rewrite the wiki. When you land on a version that brings you joy, automate the triggers. When should new material be ingested? How often should linting run?
What comes next
Now that writing documentation has no friction, what is the next step? What can we build on top of this?
Written by
Timo has spent the last decade in the IT industry, both building software and leading teams. With the AI shift, he moved to building and managing AI agents and agentic solutions. On the human side, he has surrounded himself with psychologists for the past 10 years, in relationships ranging from marriage to co-founders. Timo is a Surprisingly Human AI Engineer.
