Different Types of Wikis and When to Use Them

You join a project, open the repository, and try to understand why a payment waits thirty seconds before it retries. The code can tell you where the delay is configured. The tests can tell you which behaviour somebody expected. Neither necessarily tells you about the incident that made the team put it there.

Somewhere, there is probably a document. Or a discussion attached to a closed issue. Or a person who remembers, provided they still work there.

This is the problem a wiki is supposed to help with. But the growing collection of AI wiki tools approaches it from different directions. Some explain the code. Some search the documents. Others maintain a written account of what those documents mean together. They look similar when you are reading an answer, which makes it surprisingly easy to choose one while expecting the behaviour of another.

The tools make more sense when you separate what you feed them from what you expect back:

flowchart LR
 Code[Code repository] -->|Explain| RepoWiki[Generated repository wiki]
 Code -->|Inspect dependencies| Analysis[Codebase analysis]
 Documents[Documents and decisions] -->|Retrieve and answer| Retrieval[RAG]
 Documents -->|Synthesise and maintain| Wiki[Linked knowledge wiki]
 Rules[Project rules] -->|Guide the work| Instructions[Agent instructions]

A maintained wiki can be human- or agent-written, and retrieval can search it too. OKF sits underneath these choices as a format for storing and exchanging pages, not another branch of the diagram.

The distinction becomes clearer when you follow that retry question a little further.

Start With What the Code Can Tell You#

A generated repository wiki is a sensible place to begin. Instead of opening twenty files to work out how requests move through the service, you get an overview, links to the implementation, and somewhere to ask follow-up questions. You still need to read the code, but you have a better idea of where to look.

DeepWiki and Google’s Code Wiki sit in this space. Code Wiki combines generated documentation, diagrams, source links and Gemini chat. For a public repository you are trying to understand, that is a useful starting point without first building your own documentation pipeline.

The catch is that the explanation belongs to a particular state of the repository. Google’s FAQ describes periodic refreshes, even though the homepage uses stronger language about updating after merges. Check when the wiki was generated before using it to reason about a recent change. The FAQ also still lists its private-repository Gemini CLI extension as planned, so the public experience is not a ready-made answer for your internal services.

If you want the generated pages to live alongside the code, LangChain’s OpenWiki takes that route. It writes into an openwiki/ directory and provides update operations that can be run through CI. That changes who owns the refresh process and how you review the result; it does not remove the need for either.

For our payment service, these tools can help locate the retry handler and explain how it interacts with the queue. But suppose the next question is whether reducing the delay will affect another part of the system. Now a readable explanation is only part of what you need.

Repowise is worth distinguishing here because it documents structural analysis of code, dependencies and git history, with optional model-assisted features on top. That can help investigate change impact rather than just describe a module. It is not a guarantee: an inferred relationship to a test is not measured coverage, and files that historically changed together did not necessarily fail together. The analysis gives you places to investigate, not permission to skip the tests.

For private code, there is another practical detail. Repowise’s privacy documentation distinguishes local processing from optional external services. A tool running on your laptop can still send context to a cloud model. Check the model, embedding and telemetry configuration before calling the whole workflow local. (The location of the terminal is not the location of the inference.)

All of this helps us understand the implementation. We still have not found out why the team chose thirty seconds.

Finding a Document Is Not the Same as Keeping an Explanation#

Suppose the incident review does exist. It describes a downstream provider that kept returning a temporary error, a retry storm, and the decision to back off more aggressively. A retrieval system can find that document and give the model enough context to answer the question.

That is the familiar RAG approach: retrieve relevant material, then generate an answer from it. It is often all you need. If your documents are already well maintained and the problem is finding the right passage, adding a second set of generated pages may just give you more material to maintain.

It would be wrong to say RAG has no memory. The original RAG paper explicitly combines the model with a persistent retrieval index. The distinction is that retrieving evidence does not, by itself, leave behind an updated explanation for the next reader.

Now imagine that the retry decision is spread across the incident review, a later provider update, and a design discussion about moving to a different queue. Each source makes sense on its own. Understanding the current position means putting them together and working out which conclusions still apply.

This is where Karpathy’s LLM Wiki pattern becomes interesting. The model does not only search the source collection. It maintains linked pages derived from it. When a new source arrives, it can update an existing explanation, connect related ideas and flag a contradiction. A useful answer can be filed back into the wiki instead of staying in a chat nobody will reopen.

Our retry page could then explain the original incident, link to the current implementation and record that the provider’s behaviour has since changed. The next engineer starts with that account, not another search through the same pile of documents.

A repository wiki helps you understand what the code does. A maintained knowledge wiki can help you recover the reasoning the code cannot explain.

The distinction is about maintenance, not mutually exclusive technology. You can use retrieval to search an LLM-maintained wiki. You can keep incident reviews in the same repository as the code. What matters is recognising that regenerating an implementation overview and revising a historical decision are different jobs.

There is a cost to making the explanation persistent, though. If the model misreads the incident review, its mistake can become the page that every later answer cites. Karpathy’s pattern preserves raw sources separately from the generated wiki; that separation is worth keeping. Review substantive updates against those sources, and leave conflicting accounts visible until someone can resolve them. A tidy page is not a reason to erase uncertainty.

The Human Wiki Has Not Gone Away#

At this point, an LLM wiki can sound like a replacement for the personal notes people already keep. In practice, the boundary is less dramatic. Karpathy describes browsing his generated wiki in Obsidian while the agent maintains the files. The person and the model are working with the same material, just doing different parts of the work.

A human-maintained digital garden places more of the writing and linking with the author. An agent-maintained wiki delegates more of that work. Neither arrangement decides what is worth keeping for you. Someone still has to recognise that the old retry incident matters, that a provider update changes the conclusion, or that two apparently contradictory documents describe different environments.

For personal research, I would choose between those approaches based on where the effort is going. If writing the note is how you develop the idea, automating all of it defeats part of the purpose. If you already know what matters and are spending your time updating links and filing summaries, an agent has a more useful job to do.

The same distinction applies when the reader is an agent. A project wiki might explain the retry policy, while AGENTS.md tells a coding agent which tests to run before changing it. Those are related documents, but one describes the system and the other directs the work. Keep the instructions short and link to the explanation rather than copying the whole wiki into them.

There is some empirical reason for restraint. In the tested settings of Evaluating AGENTS.md, revision 2, neither generated nor developer-provided context files significantly improved task success over having no file; developer-provided files did perform significantly better than generated ones. That does not make project constraints unnecessary. It does make “give the agent more pages” a poor substitute for deciding what it needs to know.

Where OKF Fits Into This#

Once you have useful pages, another question follows: can you move them to a different tool without losing what makes them useful?

The prose is usually the easy part. The awkward part is preserving where a claim came from, whether it was checked, and whether it is still current. That is why Open Knowledge Format belongs in this conversation, even though it is not another kind of wiki.

OKF v0.2 describes bundles of Markdown concepts with YAML frontmatter. Ordinary Markdown links connect the pages, while metadata can record sources, generation and verification events, lifecycle status and expiry. For our retry page, that could mean carrying the incident review as a source and recording when somebody last checked the explanation against the service.

The appeal is having conventions that another producer or consumer can recognise. You do not have to adopt the reference agent or turn the wiki into a data catalogue. Although the project’s examples include analytics-oriented bundles, those examples are not a mandatory taxonomy for your notes.

The metadata still needs software and people behind it. A stale_after timestamp cannot refresh a page, and listing a source does not prove that the source supports the sentence. There are also implementation limits to check: the documented Knowledge Catalog connector does not currently map verified, status or stale_after. The source format can hold information that a particular destination does not preserve.

I would consider OKF when that shared metadata contract is useful across tools or teams. For a small personal wiki, plain Markdown and a few agreed conventions may be sufficient. The important test is whether you can move the pages, links and evidence you actually rely on, not whether the export button produces a zip file.

So Which One Would I Use?#

For an unfamiliar public repository, I would start with a generated repo wiki and follow its citations into the code. When the work moves from understanding the system to changing it, I would add structural analysis and tests. Neither needs to become an organisation-wide knowledge project before it can be useful.

For questions over a maintained document collection, I would start with retrieval. I would add a maintained wiki when the same cross-document reasoning keeps recurring, or when people need a shared explanation they can review and improve. That is the point where writing the answer down becomes part of the system rather than an optional last step.

Back at the payment service, this means the generated overview can show you the retry implementation, the knowledge wiki can preserve the decision behind it, and the agent instructions can tell an automated contributor how to change it responsibly. You do not necessarily need three products. You do need to know which job each document is doing.

The original question was not really about finding a number in the code. It was about understanding enough to decide whether that number should change. That is the standard I would use to judge the wiki: whether the next person can make a better decision without having to reconstruct the whole conversation.

Start With What the Code Can Tell You#

Finding a Document Is Not the Same as Keeping an Explanation#

The Human Wiki Has Not Gone Away#

Where OKF Fits Into This#

So Which One Would I Use?#

Further Reading#