Hello Subscriber

this newsletter is a bit different, Instead of presenting what’s new in the world of DokuWiki, this more of a think piece. What does the advent of AI agents mean for the future of wikis and knowledge management?

We’d love to hear your thoughts on the topic.

Andreas Gohr

BTW: if you haven’t seen what an AI agent integration already can look like, have a look at our video showing the AI Agent plugin in action.

Thoughts on LLM Wikis

The idea of an LLM Wiki as postulated by Andrej Karpathy is currently making the rounds on LinkedIn and in other circles.

The idea is simple: instead of manually managing your wiki, creating pages, interlinking them, making sure the documentation is up-to-date and consistent, you just let an AI agent handle it. The “wiki” becomes a bunch of interlinked pages, read and written primarily by the agent. The interface to the information is the agent itself.

To add information, you dump documents, emails, or snippets into an “ingest” agent. A periodic “lint” agent takes on the role of the wiki gardener, and to get information from the system you talk to the “query” agent.

It sounds magical. Finally, the largest hurdle of wiki adoption is solved: nobody has to write anything down anymore.

When I presented the DokuWiki AI Agent plugin (see last newsletter) to my colleagues, their thinking went in the same direction. But I think the idea rests on a misunderstanding: collecting information is not the same as creating knowledge. A useful wiki is not just a storage layer an agent can read and write, but a shared, collaborative structure that humans can understand, navigate, and trust.

Information is not Knowledge

The goal of a wiki is to aggregate and synthesize knowledge from information. Karpathy hints at the issue when he describes how he runs the “ingest” phase:

Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize.

Without this close supervision and guidance, you’re basically “vibe coding” your knowledge base. In case you’re not familiar with the term, “vibe coding” refers to the process of creating software using an AI coding agent without ever looking at the created code (sometimes not even knowing how to program). The results can be impressive for a short time, but the larger the scope and the longer the project development, the more vibe-coded software turns into unmaintainable spaghetti code with lots of duplicate code, unexpected bugs, and side effects.

It’s the same with knowledge management: dump ten years of project emails into an ingest pipeline and you’ll get summaries of conversations, but not institutional know-how. Knowledge requires human synthesis and perspective, the LLM can’t do that alone.

What Karpathy actually hints at, when describing how he uses the ingest phase, is not automation without oversight. His approach is less “vibe coding” and more “vibe engineering”. In software development, this describes working with an AI agent where every output is reviewed, refined, and iterated until approved by an experienced human software engineer. It is a different kind of software development, but it is not necessarily faster or easier than traditional development. The human’s role shifts from developer towards architect and QA manager.

In the case of an “LLM Wiki”, it means that unless you want your knowledge base turning into an unknowable black box, you need to keep a very close eye on how the agent organizes the information and what knowledge is synthesized from it, and permanently steer and correct it.

Opaque Storage is not Navigation

As explained above, you want to keep an eye on what the agents do with the information you feed them. This is made difficult by the system Karpathy suggests. His “wiki” consists of hundreds of markdown files sitting side by side in one directory, with a single index.md providing one-line descriptions and optional categories. He’s explicit: you’re not meant to touch anything here: “The LLM owns this [storage] layer entirely”.

The result is a kind of digital dumping ground: technically searchable, but cognitively opaque. Even with Obsidian providing a graph view or backlink visualization, there’s no real overview, no curated entry points, no intentional hierarchy. Once the number of files crosses a certain threshold, orientation becomes difficult - you can’t easily tell what’s missing, what’s redundant, or where to start exploring.

Traditional wiki gardening solves this by emphasizing human navigation design: choosing page titles, linking paths, organizing namespaces, and summaries that guide the reader. It’s less about storage and more about providing a common thread. Without that human editorial layer, the “wiki” devolves into a bag of loosely connected text fragments - accessible to the LLM perhaps, but exhausting for people to read and trust.

Personal Systems are not Collaborative Wikis

What most people seem to miss in their excitement is the very first sentence of Karpathy’s article: “A pattern for building personal knowledge bases using LLMs.” (emphasis mine).

I have no doubt this system is working great for him. He seems to invest a lot of time into maintaining and refining the data in it. I feel like he’d be great at using a traditional wiki as well.

What his “pattern” is lacking, though, is any notion of how it would work with multiple users. How would the system evolve when prompted by different users with different needs? How can anyone trust the information in the wiki? Who are edits attributed to when agents potentially edit and rewrite whole sections of the wiki at any time? Hallucinations have become rarer with modern models, but they still exist.

Use in a corporate context is even more questionable. There is no notion of ownership, permissions, or approvals at all. While I personally would celebrate the adoption of the “wiki way” where everyone is allowed to see and edit everything, it is very rare for enterprises to adopt that mindset fully.

AI can help, but not Replace Stewardship

The recent hype around OpenClaw illustrates a similar dynamic. OpenClaw promises a personal assistant that manages your email, files, and workflows across every messaging platform you use. And for technically savvy users who take the time to isolate it, restrict its permissions, and audit third-party skills, it delivers. But the vast majority of adopters don’t do any of that. The result: tens of thousands of misconfigured instances exposed to the internet, a skills marketplace flooded with malicious plugins, and critical vulnerabilities that allowed entire agent takeovers from a single website visit.

I fear the pattern will be similar with LLM Wikis: agentic systems promise to remove the hard, tedious parts of a task - but that tedious work is what makes the result useful. Take away the expert supervision and you don’t get magic, you get a mess that’s harder to clean up than what you started with.

I think there are many interesting aspects in Karpathy’s pattern, and I am sure we will see many of them implemented in future wikis, but I don’t think it will magically solve the “issue” of knowledge management being work. Wikis rise and fall with people participating and shaping the information stored in them into knowledge. AI agents can help a lot with that, but they can’t (and shouldn’t) think for you.