Dosu

Documentation has always lost to features, and the reason is not laziness. Writing it is work that benefits somebody else later, which is the least motivating shape a task can have.

Coding agents have changed the arithmetic. An agent with good context is fast and accurate; an agent without it reads half the repository to answer a simple question, gets it wrong, and costs you tokens doing so.

Dosu's proposition is that documentation should be captured rather than written — extracted from the work as it happens, and updated when the code it describes changes.

Dosu: Documentation That Writes Itself

• Automatic knowledge capture from coding agent sessions, so documentation is a by-product rather than a task.
• Self-documenting pull requests — docs update whenever source code changes.
• One source instead of many MCP servers, consolidating GitHub, Confluence, Notion and Slack.
• 827 open-source libraries searchable out of the box, plus your own repositories.
• 50% fewer tokens and 2x faster agents claimed, with 200k+ engineers and SOC 2 Type II certification.

Why Do Coding Agents Need Better Docs?

Dosu positions itself as knowledge infrastructure for agents and humans, stating that automatic knowledge capture accelerates your team and improves agent performance without changing your workflow.

The mechanism is worth spelling out because it explains the token figures. An agent answering a question must first find the relevant context, and if there is no documentation it does that by reading code.

Reading code is expensive in exactly two ways. It consumes tokens proportional to how much has to be read, and it produces an inferred understanding that may be wrong — because code shows what happens, not why, and the why is where the decisions live.

Good documentation short-circuits both. The agent reads a paragraph instead of four files, and the paragraph contains the reasoning that the code cannot express.

This reframes documentation from a courtesy to infrastructure. It was always valuable and always deferrable; with agents in the loop it has a measurable per-query cost, which is the first time the argument has had a number attached to it — much as CodeScene attached a number to technical debt.

Code shows what happens, not why. The why is where the decisions live, and it is exactly what an agent cannot infer by reading more files.

Capturing Knowledge From Agent Sessions

Dosu's terminal output describes automatic knowledge capture as on, documenting useful insights from coding agent sessions.

This is the cleverest idea in the product. When an agent works through a problem, it necessarily reconstructs an understanding of the relevant part of the system — and that understanding is normally discarded when the session ends.

Capturing it converts a by-product into an asset. The expensive part of documentation, which is working out how something actually functions, has already been paid for; writing it down is the cheap part that never happens.

It also aligns the incentive correctly. Nobody has to remember to document anything, and the documentation that gets created is about the parts of the system people are actually working on, which is where it is most needed.

The caveat is that an agent's understanding can be wrong, and captured wrongness is worse than absence because it will be trusted by the next agent and the next person. Any system doing this needs a review path, and that is the thing to check before switching it on across a repository.

Self-Documenting Pull Requests

The second capability is docs updating whenever source code changes, described on the site as self-documenting PRs.

This attacks documentation's real failure, which was never that it did not exist. It was that it existed, described the system as of two years ago, and was therefore worse than nothing because people believed it.

Stale documentation is genuinely dangerous with agents in the loop. A human reading an out-of-date page usually notices the mismatch against the code; an agent may confidently act on the description instead.

Tying updates to the change that caused them is the structurally correct fix, because it removes the gap where documentation drifts. The moment the code changes is the only moment anyone knows what changed and why.

The practical question to ask is what happens when the update is wrong. A documentation change generated alongside a code change should be reviewable in the same pull request, which is where products like GitBook and cubic approach the same review surface from different directions.

• Treat captured documentation as a draft that needs review, not as truth.
• Check that generated doc updates are reviewable in the same pull request.
• Consolidate context sources before adding more MCP servers.
• Measure your own token usage before and after, rather than trusting a published figure.
• Start on one repository where the code is well understood by a human.

One Source Instead Of Many MCP Servers

Dosu makes a pointed argument about replacing a tangle of MCP servers with a single consistent source of knowledge, and lists GitHub, Confluence, Notion and Slack among its connections plus 827 built-in open-source libraries.

The problem it names is real and recent. Connecting an agent to five separate systems means five sets of credentials, five retrieval behaviours, five ways for something to fail, and no coherent notion of what the agent actually knows.

It also means duplication and contradiction. The same fact exists in a Notion page, a Slack thread and a README, in three versions of varying age, and the agent picks whichever it finds first.

A consolidation layer resolves that by deciding what is authoritative, which is a genuinely useful thing to have decided. The trade is that you have added a dependency between your agents and everything they know.

The 827 open-source libraries are the underrated part of the list. Agents routinely get third-party library usage wrong because their training data predates the current version, and a maintained index of library documentation addresses that specific and common failure.

Reading The Published Numbers

Dosu publishes three figures: 50% fewer tokens burned by agents working with accurate documentation, 2x faster agent performance with Dosu-maintained context, and 200k+ engineers already using it.

The first two are vendor benchmarks with no stated methodology on the page, so treat them as directional. The direction, however, is well supported by ordinary reasoning: less reading means fewer tokens, and better context means less trial and error.

What makes them unusually testable is that both are things you can measure yourself. Token usage per task is already visible in your agent tooling, and so is time to a correct answer.

That puts this in a better position than most vendor claims, which rely on effects you cannot isolate. Run twenty representative tasks before and after and you have your own number, on your own codebase, which is the only one that matters.

The 200k+ engineers figure is the vaguest of the three, since it does not distinguish between people who installed it once and teams using it daily — a distinction every developer tool blurs in the same way.

Adding Dosu To An Existing Repository

The risk with automatic documentation is generating a large volume of plausible text about a system nobody has verified, which then becomes the authority.

This sequence starts where a human can check the output and expands only once the captured knowledge has proved accurate.

1. Start with one repository somebody on the team knows thoroughly.
2. Measure current token usage and time-to-answer on twenty representative tasks.
3. Turn on knowledge capture and read the first documents it produces, closely.
4. Correct anything wrong immediately, before it is trusted by later sessions.
5. Enable self-documenting PRs once captured knowledge has proved accurate.
6. Re-run the same twenty tasks and compare against your own baseline.

Agent Knowledge Terms

The vocabulary around agent context, and what each term actually means.

undefined

undefined

undefined

undefined

undefined

undefined

Dosu: Product And Numbers

Does Your Repository Need Dosu?

Connect it when

• Coding agents are a real part of how your team works.
• Your documentation is thin, stale, or spread across four systems.
• Agents keep rediscovering the same things and costing you tokens for it.
• You are running several MCP servers and the tangle has become a maintenance problem.
• Onboarding relies on people asking colleagues rather than reading anything.

Write docs yourself when

• Your codebase is small enough that context is never the constraint.
• You already maintain accurate documentation with real discipline.
• You cannot allow a third party to index your source and internal systems.
• Nobody will review captured documentation, which makes wrongness durable.
• Your problem is code quality rather than code understanding.