Google just announced Code Wiki. The timing of this is kind of personally frustrating, since I was deep into a post about where AI tooling and software documentation is at in the year 2025. Now that post is going to get a couple of extra paragraphs.
The copy is certainly striking, using phrases like, “Stop documenting”, “No more stale docs. Ever.” Understandably, this hits close to home for technical writers. After all, we’re in the business of producing docs.
What the tool does is kind of provide a seemingly “complete” set of documentation in a web interface, along with an instance of Gemini that you can chat with. The main mode is descriptive, explaining the architecture of the repository, which makes sense if you’re trying to understand the project as a codebase. Most of us aren’t working with libraries at that level. It’s impressive, but kind of weird. I really recommend pointing it at a repository you’re familiar with, and comparing the structure of the output to the official docs (a good example is Code Wiki’s approach to Flutter and Flutter’s docs).
Calling it a wiki is particularly strange — wikis center collaboration. The promise is that the service will own documentation. While this is probably a nod to these tools having a superficial appearance to GitHub’s wiki feature, it’s really different in spirit.
Fabrizio Ferri Benedetti has a spirited rejoinder that is really worth reading:
These tools [sic: Code Wiki and DeepWiki] can fulfill the role of project summarization. They’re helpful when trying to explore poorly documented codebases and get a sense of how the pieces fit together, but they stop short of anything that could be called “docs” (and perhaps that’s why they shyly chose “wiki” instead). I would describe their output as byproducts of an LLM digestion process (yes, blergh).
It’s impressive for the first ten seconds, but as you start reading, you begin to notice that for most complex projects, the wiki is at best dry reference, at worst a dumpster fire of hallucinations, Escherian information architecture, and subtly wrong facts and diagrams. This is not a lazy dismissal: read the comments on Hacker News to get an idea of how dismal their results can be.
As is unfortunately common in this moment, the hardest part of our job is aligning with people who don’t understand the function or role of docs:
What makes me furious with the heat of a thousand Suns is the fact that some devs could be lured into thinking that this sort of ersatz manuals can check the docs box at all. That some could find these self-inflicted wikis a valid replacement of human-made docs shows the same kind of ignorance (or cynicism) about technical writing that folks display when praising art made by AI.
Docs are a product. They require sustained and intelligent effort over a long period of time, as well as a strong community ready to contribute. Docs are the mirror and lore of your code and design, instruments that help you think about what you are architecting and developing. Docs serve purposes and needs. Great docs explain, guide, help, and illustrate. They’re deeply flawed and human. They must be.
The whole post is great, but in particular, this conclusion:
Let’s draw the line: docs generated entirely by AI should never ship to users. You can use AI judiciously to audit your docs for gaps, to spot inconsistencies, to generate first drafts that you’ll edit later. But the moment you let any LLM have the final word on what users will read, you’ve abandoned the basic contract of docs: that someone who understands the system has taken responsibility for explaining it truthfully.
This last sentence is a powerful encapsulation of the value of docs, regarding user expectations, responsibility, and serving as an authoritative source of knowledge.