Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
In an earlier article, I explained why the second brain — a network of interlinked atomic notes — wasn't suited to product management. Too much error propagation, too much noise, not enough control.
But there's one domain where this approach works: knowledge "by the book." Standards, regulations, domain vocabulary, best practices established over decades. "Factual" information, stable, that doesn't change from one opportunity to the next.
That's exactly what I needed for industrial maintenance (my field). And that's what led me to build an AI Wiki.
The starting problem
What separates good PMs from bad ones is a fine-grained understanding of context. Not generalities. Precise knowledge of customer stakes, of the field, of business rules.
The trouble is that this knowledge is scattered: across books, articles, standards, field feedback, internal documents. You can't remember it all. And you can't re-read all of it every time you need it.
The first instinct is to turn to an LLM. You load documents, you ask questions. Classic RAG — NotebookLM, ChatGPT with uploaded files — works like this: the AI searches for the relevant chunks in your documents, then synthesizes an answer.
The problem: it starts from scratch with every query. No accumulation. No structured memory. A subtle question that requires cross-referencing five documents forces the AI to find and reassemble everything each time. The ideas stay "weak": extracted individually from each document, never consolidated.
The idea comes from Karpathy
Andrej Karpathy is an AI researcher, former Director of AI at Tesla, a founding member of OpenAI, and recently joined Anthropic. He's also one of the field's best teachers — his Stanford courses and YouTube videos are a reference.
In May 2025, he published a gist describing a pattern he calls the "LLM Wiki." The idea is simple but powerful: instead of running RAG over raw documents, you ask the AI to progressively build a persistent wiki.
When a new source arrives, the AI doesn't just index it. It reads it, extracts the key information, updates the wiki's existing pages, creates links between concepts, flags contradictions, enriches the syntheses. Knowledge is compiled once, then kept up to date — not rediscovered with every question.
The difference is fundamental: the wiki is a cumulative artifact. The syntheses, the links, the contradictions already exist before the next question.
What an AI Wiki is
Concretely, an AI Wiki runs on three layers:
- The raw sources: books, articles, PDFs, standards. They are immutable and remain the source of truth.
- The wiki: Markdown files generated by the LLM — atomic notes, glossary, standards sheets, thematic syntheses, index.
- The instructions: a file (something like CLAUDE.md) that tells the agent how to maintain the wiki — how to name files, ingest a source, classify, link concepts.
When you ask a question, the AI doesn't go back to the original PDFs. It reads the wiki first, finds the relevant notes, and produces a sourced answer from knowledge that's already been consolidated.
And when you add a source, a single ingestion can touch 10 to 15 notes in the wiki: updating definitions, adding nuances, creating links, detecting contradictions.
AI Wiki and Zettelkasten: the parallel and the difference
The Zettelkasten — the method invented by the sociologist Niklas Luhmann — rests on the same principle of interlinked atomic notes. One idea per note, links between notes, a network that grows.
The parallel is obvious: the AI Wiki also produces interconnected atomic notes. But their nature is different.
The Zettelkasten / second brain is link-oriented. It reflects your own thinking, your experiences, your intuitions. It forces you to dig your own furrow, to confront ideas, to formulate your own theses. It's a tool for personal reflection.
The AI Wiki is proximity-oriented. The information is "factual," non-oriented. It serves as a structured, "objective" source. It's a knowledge base, not a system of thought.
The two are complementary. The AI Wiki provides the facts; the second brain interprets them. The wiki tells you "here's what standard NF X 60-010 says about preventive maintenance." Your second brain tells you "this standard is poorly applied in such-and-such a context because…"
My experience: industrial maintenance
I applied this pattern to industrial maintenance — the domain of my CMMS product. A "by the book" domain par excellence: standards (NF, ISO, EN), regulations, precise domain vocabulary, processes documented for decades.
From a dozen sources — reference books, standards, technical articles — the AI extracted and structured 950 atomic notes: glossary definitions, standards sheets, notes on processes, certifications, performance indicators.
Calibration: an AI is blunt and literal-minded
The bulk of the work wasn't extraction. It was calibration.
In V0 (the POC), I was too permissive. Detection too broad, too many notes generated, insufficient quality. The AI captured everything — including noise.
In V1, I tightened the filters. The quality became excellent. But some relevant notes (present in the POC) were ignored — too restrictive.
The challenge is to find the tipping point between exhaustiveness and relevance. And that doesn't happen in two lines of prompt. The ingestion instructions run to several dozen lines: a precise definition of each note type, validity criteria, rules for detecting regulatory references, a final terminology pass.
The method I used to iterate: ask V1 to analyze V0's notes. Understand what it had missed, why, and adjust the rules without losing the rigor of the classification. A cross-validation between two versions of the same system.
What for?
Once the wiki is built, the uses are many.
Search and semantic proximity. With a vector database (LanceDB in my case), you can search by concept — not just by keyword. Searching for "regulatory maintenance" also returns the sheets on periodic inspections, certifications and the NF X 60-010 standards, even if none of them contains that exact phrase.
Review and self-learning. I built a flash-card system on top of the wiki. Ten minutes a day to strengthen my grasp of the domain fundamentals. Memorizing the standards, the processes, the definitions — not to recite them, but to have them in mind when a product decision has to be made.
A source for other LLM projects. The wiki becomes a reusable building block. When I study a product opportunity, I can query the wiki alongside my other sources: source code, competitive intelligence, product knowledge. The domain context is already structured and ready to be injected.
The limits
None of this works unless you already have some background in the field.
The AI changes nothing about this reality: you couldn't trust a vendor without knowing the field yourself. It's the same with an AI Wiki. If you don't have the competence to validate what the AI extracts, you're building on sand.
The AI Wiki structures and capitalizes on knowledge. It doesn't replace it.
Further reading
The PM as Architect of Context From the Single File to a System of Contexts: Why an LLM's Memory Won't Fit in One Document Why a single classification isn't enough to structure customer feedback The product question should start from the source code
Sources
- LLM Wiki — Andrej Karpathy: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- Zettelkasten method: https://en.wikipedia.org/wiki/Zettelkasten
- The second brain is a dead end for product management: https://malorean.net/articles/2026-05-03-le-second-cerveau-est-une-impasse-pour-le-product-management.html