Andrej Karpathy’s post about LLM-maintained knowledge bases hit 20+ million views on X this month. The concept: instead of asking AI to search your documents from scratch every time, have the AI compile and maintain a living wiki from your raw sources. Summaries, cross-references, contradiction flags. All pre-computed. All persistent between sessions.

The idea resonated because it named a problem everyone recognizes. The research you did last quarter is gone. The competitive analysis lives in a deck nobody can find. The stakeholder context that took months to build evaporated when the project ended.

In this post:

1. Three Problems Wearing One Label

2. What Karpathy Got Right

3. What the Critics Got Right

4. The Missing Layer: An Operating Model for Knowledge

5. From Personal Brain to Organizational Nervous System

6. What to Do With This

Then the adaptations started. Aakash Gupta, who writes Product Growth — one of the largest product management newsletters — published a detailed PM guide to Karpathy's system. Six use cases with real workflows: user research that compounds across projects, competitive intelligence you can query in seconds, stakeholder memory that survives team changes, PRD context that doesn't start from zero, team onboarding that retains knowledge when people leave, and meeting prep in five minutes. He even built a Claude Code skill to reduce setup to 60 seconds.

Product Growth

How PMs Can Take Advantage of Karpathy's Second Brain

Karpathy’s most viral post ever (19.7M views) solved a problem every PM has: the research you did last quarter is gone. The user interviews, the competitive teardowns, the stakeholder context. It all lived in your head and disappeared when the project ended…

Read more

9 days ago · 13 likes · 2 comments · Aakash Gupta

Others pointed out the friction problem: terminal, git, Obsidian, browser extensions, manual prompts. Five processes across three windows. Some argued this is Enterprise Content Management in new clothes. The same SharePoint problems wearing a different hat.

All valid points. All talking past each other. Because the discussion conflates three distinct problems that need three distinct solutions.

Three Problems Wearing One Label

Three jobs. One title. The filing clerk captures. The librarian synthesises. The executive operationalises. Knowledge management treats them as the same problem.

Capture is getting information into a system. This is the problem enterprise content management has wrestled with for 30 years. Storage, ingestion, organization. Every wiki, every shared drive, every document management platform has solved this to some degree. The critics are right that Karpathy’s system still faces the same challenge here. Quality in determines quality out. An LLM-maintained wiki built from poorly formatted notes and half-read articles reflects exactly that.

Synthesis is turning captured information into connected understanding. This is what Karpathy actually solved. The standard approach — called RAG, for Retrieval-Augmented Generation — searches your documents when you ask a question, grabs relevant passages, and generates an answer. Tomorrow it starts from scratch. Your AI reads your notes for the first time, every time. There is no accumulated understanding between sessions.

Karpathy replaced this with what amounts to compile-time processing. Each source gets ingested once. The AI builds persistent wiki pages with cross-references, concept maps, and contradiction flags. The wiki grows smarter with every source added. The filing clerk that nobody wanted to be can now be automated. Knowledge maintenance becomes economically viable for the first time.

Operationalization is making understanding drive decisions and actions. This is the layer nobody in the discussion is talking about.

You can have the most thoroughly synthesized knowledge base ever built. If it doesn’t change what you do Monday morning, it is an expensive reference library.

Capture. Synthesis. Operationalization. Three distinct problems. The conversation is stuck on the first two.

What Karpathy Got Right

Credit where it is due: the compile-versus-query distinction is the most important insight in this discussion. Most AI tools people reach for — NotebookLM, ChatGPT uploads, Notion AI, Copilot — retrieve at query time. They read your material from scratch every time you ask a question. No accumulated understanding between sessions.

There is one partial exception worth noting. Persistent instruction files — like Claude’s CLAUDE.md — do carry context across sessions. They remember how to work: your preferences, your frameworks, your mistakes. But they are curated schema, not compiled synthesis. They remember who you are. They do not remember what you read last Tuesday and how it connects to three other sources. That is a different problem.

Karpathy’s system solves that different problem. After ingesting 50 sources, the wiki contains summaries, concept pages, entity pages, and cross-references that reflect everything you have read. Ask a question and the AI synthesizes from compiled knowledge, not raw documents. The quality of answers improves with every source.

Aakash Gupta’s breakdown of Karpathy’s system. Diagram by Aakash Gupta, Product Growth Newsletter.

Two design decisions deserve particular attention. The lint pass — periodic health checks that find contradictions, stale claims, and orphan connections — is the maintenance discipline that separates a living knowledge base from a graveyard. And filing query outputs back into the wiki creates a compounding loop where your own thinking enriches the base alongside your reading. Most second brain systems only compound what you consume. This one also compounds what you think.

Aakash's adaptation deserves closer attention. Where Karpathy described the architecture, Aakash showed what a PM actually does with it. Each of his six use cases follows the same pattern: a real workflow problem, the wiki query that solves it, and the before-and-after difference. The stakeholder memory case is particularly telling — every meeting's context written down automatically, accessible before the next meeting. For PMs who spend hours reconstructing context that existed last quarter, this is not theoretical.

He also built a 60-second setup skill for Claude Code to lower the barrier. And to his credit, he names the limitations honestly: this is early infrastructure, not a finished product. The compounding risk — subtle AI errors accumulating across wiki pages — is real.

The PM adaptation adds practical use cases. But the gold box names the gap: where does this connect to the PM’s actual work rhythm?

The system works. It just stops one layer short of where the value actually lives — the layer that connects what you know to what you do.

What the Critics Got Right

The friction critique is on point. The toolchain requires Claude Code (a terminal-based developer tool), git (version control software), Obsidian (a markdown editor), and a browser extension for clipping sources. This is developer infrastructure. Aakash’s audience is product managers who aspire to become AI Product Managers — already the most technically ambitious segment. The first instruction is ‘install Claude Code.’ If even they hesitate, the rest of the profession is not following.

The AIPM is the industry’s answer to this gap — a Jedi expected to code like a developer, design like a product designer, test like a QA engineer, and still own the product’s value, viability, strategy, and vision. The compensation reflects the expectation. But most product work does not need a Jedi. It needs a system that works without one.

Not everyone needs to be an AIPM. (Though it helps to keep a lightsaber within reach.)

The Enterprise Content Management critique goes deeper. Underneath the AI layer, you still have ingestion quality problems, curation decisions about what is worth processing, and lifecycle questions about when knowledge becomes stale enough to retire. These problems are decades old. The LLM makes maintenance cheaper. It does not make governance automatic.

But the sharpest critique is the one nobody made: the system has no operating rhythm.

When does the PM ingest sources? When do they query the wiki? When do they run lint passes? Aakash suggests “one source before work in the morning.” That is a suggestion. It is not a system. There is no trigger. No integration with the workday. No connection to any existing workflow. The wiki sits in a local folder, disconnected from the tools where product work happens.

Karpathy built a brilliant synthesis engine with no operating model underneath it. It is like handing a team the best strategy document they have ever seen with no process for turning it into weekly decisions.

The Missing Layer: An Operating Model for Knowledge

Capture | Synthesis | Operationalization

The operating model discipline — Vision, Strategy, Bets, Key Results — applies to knowledge systems the same way it applies to products and businesses.

A knowledge base needs purpose. What decisions should it improve? What questions should it answer faster? Without this, you end up ingesting everything and querying nothing.

It needs prioritization. Which sources get processed first? What topics matter now versus six months from now? An undirected knowledge base grows wide and stays shallow.

It needs a rhythm tied to the work itself. Morning briefings that surface relevant knowledge before the day starts. Weekly reflections that check whether knowledge actually influenced a decision. Monthly reviews that audit the base for integrity. The synthesis layer feeds into the rhythm. The rhythm feeds into action. Action generates new signals that feed back into synthesis.

Knowledge → Rhythm → Action → Signals → Knowledge. The loop is the system.

And it needs measurable outcomes — not 'the wiki has more pages' or 'queries are faster,' but whether knowledge actually changed a decision. The system can reduce research time. It can catch contradictions. But without a rhythm that connects those capabilities to the moments where decisions are made, they depend entirely on the user's discipline.

That is the same dependency every knowledge management initiative has relied on since the invention of the corporate intranet.

From Personal Brain to Organizational Nervous System

There is a second dimension worth examining: scale.

Both Karpathy and Aakash mention team use. Karpathy describes “an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls.” Aakash builds a full use case around team onboarding: a new PM joins, reads the wiki, gets 80% of the context that would otherwise take weeks to transfer. They are right to name the team case. It is real and valuable.

But both describe it as scaling the individual pattern. More sources. More people reading the same wiki. The architecture stays the same.

That works up to a point. A three-person startup can share one wiki because three people can share one perspective over lunch. A 200-person product organization cannot. Where it breaks is when organizational knowledge stops being “shared notes” and starts being “shared decisions.”

In a team, multiple people hold different perspectives on the same market, the same customers, the same strategy. The CTO reads competitive data through a technology lens. The head of sales reads the same data through a pipeline lens. The CFO reads it through a financial lens. All three are right. And each one’s interpretation is shaped not just by their role but by every experience, belief, and instinct they have built over a career. A personal wiki produces one synthesis. One perspective. For that to work across an organization, everyone would need to see the data the same way.

I know of exactly three solutions for that. The Vulcan Mind Meld. The Zen Buddhist state of One Mind. Or Elon Musk’s Neuralink shipping its Unity Consciousness feature way ahead of schedule. Unless you are expecting an abduction by Vulcans, have remarkably ambitious meditation goals, or believe Elon’s track record with timelines is about to change dramatically, I would not restructure your knowledge architecture around any of these.

A personal second brain and an organisational nervous system are architecturally different problems. Not bigger — different.

Back in the real world, the answer is structural. What organizations need is not a shared brain. It is a shared evidence base where the facts are common but the interpretation is role-specific. The CTO, the head of sales, and the CFO all see the same evidence. Each reads it through their own lens. The system holds the tension and routes it to a decision process. That is not a wiki. That is a decision-making architecture.

The jump from personal second brain to organizational intelligence is not “give everyone a wiki and merge them.” It is building a layered system where evidence flows up from frontline work, gets interpreted at each level through different lenses, and produces decisions that flow back down as direction. Information up, decisions down. Knowledge at every layer. No telepathy required.

This is the gap in the conversation. Karpathy and Aakash correctly identify that teams benefit from persistent, synthesized knowledge. But they treat the organizational version as a bigger individual wiki. The architectural shift — from shared notes to shared decisions — is a different problem that the current system does not address.

What to Do With This

Three things are true at once.

Karpathy’s compile-versus-query insight is real. If your AI tools are reading your documents from scratch every time, you are leaving compounding value on the table. This alone makes the discussion worth having.

The system as built has real sustainability problems. Developer toolchain. Manual pipeline. No workflow integration. No operating rhythm. These are the same reasons every previous knowledge base initiative failed, and putting an LLM on top does not solve them.

The deepest gap is the one nobody named. Synthesis without an operating model is a library. A library without organizational architecture stays individual. Neither changes what happens Monday morning.

The operating model is not complicated. It has four parts: a purpose that defines which decisions the knowledge should improve, prioritization that focuses ingestion on what matters now, a rhythm that connects synthesis to the moments decisions are made, and measurable outcomes that track whether knowledge changed anything. Without all four, you have a library.

Before you set up any AI knowledge system, answer three questions:

1. How will new knowledge enter the system without depending entirely on your discipline?

2. When in your existing work rhythm will you actually use what the system knows?

3. And how will you know whether the knowledge changed a decision?

If you can answer those three, the tools are ready. If you cannot, the tools are not the bottleneck.