OpenWiki – Source Code Docs That Write (and Maintain) Themselves: A Hands-On Look.

⋅

Part 1 of 3— the idea, the background, and how easy it actually is to start.

Every engineer knows the feeling. You open a repo’s docs/ folder, read a confident paragraph about how authentication works, then discover in the code that half of it hasn’t been true for eight months. Documentation doesn’t fail because people can’t write — it fails because keeping it in sync with the code is nobody’s job, and so it rots.

I’ve been trying OpenWiki [1], an open-source tool from LangChain that takes a genuinely different swing at this problem: instead of asking humans to keep docs current, it puts an AI agent in charge of generating and maintaining a wiki straight from your codebase. This post is what it is, where the idea comes from, and how quickly you can get it running. Part 2 covers what actually happened when I pointed it at a real project — including a failure that taught me something useful about model choice.

The idea behind it: Karpathy’s “LLM Wiki”

OpenWiki didn’t appear from nowhere. It’s LangChain’s implementation of a pattern Andrej Karpathy described as the “LLM Wiki” (original gist) [2].

The core insight is a reaction against the usual RAG approach. With RAG, you chunk your documents, embed them, and retrieve fragments at query time. Karpathy’s argument: don’t retrieve fragments on demand — have the LLM build and maintain a persistent, structured wiki that compounds knowledge over time. A wiki gives both humans and agents a real map of the system, and it points them toward the right context instead of stuffing everything into one giant file.

OpenWiki applies that pattern specifically to codebases. It creates a wiki for your repo, wires that wiki into your coding agent, and keeps it updated as the code changes. (It shares this lineage with other tools in the space like DeepWiki and AutoWiki — the “auto-generate a living wiki from a repo” idea is having a moment.)

How it works

OpenWiki operates in three moves:

1. Generate. It reads your repository and produces a structured wiki — an architecture overview, domain concepts, the API surface, a frontend guide, operations/runbook notes. Crucially, this is grounded in the actual source code, not in a human’s fading memory of how the system used to work.

2. Integrate. Rather than dumping the entire wiki into your CLAUDE.md / AGENTS.md instruction file (which would bloat every agent’s context), it adds a lightweight reference pointing at the openwiki/ directory. Agents — and humans — read the quickstart, then follow links to the sections they actually need. This “point, don’t inline” design is the whole philosophy: keep the fixed context small, retrieve detail on demand.

3. Maintain. A CI job (a GitHub Action ships with the repo) re-runs OpenWiki on new commits. It looks at what landed since the last run, uses the git diffs to understand what changed, and updates the affected wiki pages. The docs update themselves as the code evolves, instead of rotting.

That third step is the part that actually matters. Generating docs once is easy — plenty of tools do it. Keeping them current without human discipline is the hard problem, and it’s the one OpenWiki is really built to solve.

How easy is it to start?

Genuinely easy. It’s a CLI:

npm install -g openwiki
openwiki --init          # interactive: pick a model provider, paste an API key

Config lives in ~/.openwiki/.env. On first run it walks you through choosing an inference provider (OpenRouter, Anthropic, OpenAI, and others are supported) and dropping in an API key. Then you generate:

openwiki "Generate documentation for this repository"

It writes everything into an openwiki/ folder and adds the reference to your agent-instruction file. To refresh later:

openwiki --update

That’s the whole loop. No new platform to host, no database to stand up, no service to babysit — just a CLI and whichever LLM you point it at.

Why it’s worth caring about

A few reasons this clicked for me:

  • It fixes the maintenance half, not just the writing half. Most doc generators produce a nice snapshot that’s stale within a sprint. OpenWiki is designed to keep pace with commits.
  • The docs live next to the code. They’re plain markdown in your repo, versioned alongside everything else, and reviewable in a PR.
  • It’s genuinely useful for AI coding assistants. A structured, source-grounded wiki that an agent can navigate is far more valuable than a wall of prose crammed into one context-eating file. This is arguably the strongest use case: your repo becomes legible to the next agent that touches it.
  • It’s open source (MIT) and model-agnostic. No lock-in on the tool itself; you choose the model backend that fits your budget and privacy needs.

The honest caveat

It’s an early-stage tool (v0.x), and — as with anything that hands the wheel to an LLM — output quality tracks the capability of the model you give it. That’s not a footnote; it’s the whole ballgame, and it’s exactly where my first real run went sideways.

In Part 2, I’ll walk through pointing OpenWiki at an actual Spring Boot + Angular project: the run that crashed on one model, the one that sailed through on another, and what a “good quality docs” run actually costs.

This is the first in a three-part series — Part 2 covers the real run and what quality docs cost; Part 3 covers generating diagrams and contributing a feature upstream.

References

[1] LangChain, “OpenWiki — an open-source agent for repo documentation,” GitHub repository. Available: https://github.com/langchain-ai/openwiki

[2] A. Karpathy, “LLM Wiki,” GitHub Gist. Available: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

OpenWiki – Source Code Docs That Write (and Maintain) Themselves: A Hands-On Look. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Liked Liked