(2026-04-22) Jones Karpathys Viral Ai Wiki Has A Flaw

Nate B Jones: Karpathy's viral AI wiki has a flaw most of the 100K people who bookmarked it haven't noticed yet. A few weeks ago, Andrej Karpathy posted an idea that more than a hundred thousand people bookmarked. On the surface it sounded almost too simple: use your AI to build and maintain a personal wiki. (LLM-Wiki)

Since Karpathy’s post went up, I’ve gotten hundreds of messages asking some version of the same question: “Nate, is this the same thing as Open Brain?”

The honest answer is more interesting than any of those questions assume. These two systems solve the same problem from opposite directions, and the difference between them is one of the most consequential design decisions you can make right now if you’re building anything serious with AI.

This piece is the full comparison I wish someone had written before I started building.

LINKS: Grab the prompts + Wiki Compiler (OB1)

Choosing between these architectures is one thing. Actually building one without stalling at the first design decision is another. The prompt kit for this article walks you through that part: a diagnostic that tells you which architecture fits your actual situation, a schema designer that produces the editorial policy your wiki lives or dies by, a synthesis agent you can run every time you ingest a new source, an auditor that catches wiki drift and hidden contradictions before they compound, and a hybrid blueprint if you want both layers working together. Five prompts, each one built around a specific failure mode from the article.

If you already have Open Brain running, the hybrid I describe below isn’t hypothetical anymore. The Wiki Compiler recipe is live in the OB1 repo

Karpathy’s big insight (it’s not the wiki)

the wiki isn’t the insight. The insight is about what the AI is doing.

Here’s how almost everyone uses AI with their documents today. You upload files to ChatGPT, or you use NotebookLM, or you set up some kind of retrieval system. Then you ask a question

what’s actually happening under the hood: the AI is rediscovering your knowledge from scratch every single time you ask.

*This is how ChatGPT file uploads work. This is how NotebookLM works. This is how most retrieval-augmented generation works. The AI is smart in the moment and amnesiac afterward.

Karpathy’s insight is: what if the AI didn’t throw away the work?*

What if every time you added a new source, the AI read it, figured out what mattered, and updated a set of organized notes, notes that already contained everything it had learned from every previous source? What if those notes included cross-references, flagged contradictions, tracked how your understanding evolved?

Karpathy’s wiki is a write-time system.

Open Brain is a query-time system. When new information arrives, it gets stored faithfully — tagged, categorized, made searchable. But nobody synthesizes anything yet.

A folder of text files can’t answer those questions. The understanding is there, but the structured data to act on it isn’t.

When you or your AI agent asks a question, the AI reads the relevant entries, does the thinking fresh, and produces an answer on the fly. The hard work happens at the moment you need it, not before.

Karpathy’s wiki is like a study guide that a really good tutor writes for you as you learn a subject. Every time you cover new material, the tutor updates the guide

You want to pull every deal over $50K from the last quarter?

You’ve probably noticed that your hundredth conversation with an AI doesn’t feel meaningfully different from your tenth. You’re more skilled at prompting, sure. But the AI itself hasn’t gotten any smarter about you, your domain, your accumulated context. No model upgrade will fix it. It’s a storage architecture problem

Open Brain is like a perfectly organized filing cabinet with a brilliant librarian standing next to it.

*The synthesis is already sitting there, the cross-references already built, the contradictions already flagged.

Karpathy’s own words: “The knowledge is compiled once and then kept current, not re-derived on every query.”*

Study guides and filing cabinets are both useful. They’re good at very different things.

This is the same trap as dashboards in analytics: a dashboard is easier to read than a spreadsheet, but it can hide exactly the thing you need to see.

But there’s a catch that almost nobody in those bookmarks is thinking about yet. Every time the AI turns a raw source into a wiki page, it’s making editorial choices. What to include, what to leave out, how to frame the connections between ideas. Those are the AI’s choices, not yours. Important nuance that got dropped might matter six months from now, and you won’t know it’s missing because the wiki reads so cleanly

If you only store stuff, your AI has to figure out what it all means every single time you ask. You’ve been feeding it articles, meeting notes, and research for six months. You ask a question that requires connecting five different sources. The AI has to find those sources, read them, figure out how they relate, and produce a synthesis, from scratch. Every time

Karpathy is honest about this. His architecture keeps all the raw sources untouched in their own folder, so you can always go back to the originals. But most people building on his pattern won’t maintain that discipline.

The fork in every knowledge system

If you only build a wiki, your AI can read the summary but can’t do anything precise with the raw data underneath

Now here’s where Open Brain enters the picture and things get interesting.

Every knowledge system with an AI at its core has to answer one question: when does the AI do the hard thinking — when information comes in, or when you ask about it?
This is the fork. Everything else follows from it.

For a team, the stakes are sharper. Most organizations are generating enormous volumes of AI-touched knowledge right now (meeting summaries, strategy docs, research outputs, Slack threads) and almost all of it is write-once-read-never. Nobody maintains it. Nobody synthesizes across documents. Nobody flags that the Q2 strategy deck contradicts what the CEO said in last week’s all-hands

And here’s a subtlety that matters more for teams than individuals: sometimes contradictions are the most valuable thing in your knowledge base. Engineering thinks the timeline is twelve weeks. Sales promised the client eight. A wiki that resolves that contradiction into one coherent narrative, picking a side or splitting the difference, actually hides the most important strategic signal in the system. The gap between what engineering knows and what sales promised is the problem your leadership needs to see.

The AI’s job description changes

One of the sharpest practical differences between these approaches is what the AI actually spends its time doing.

In Karpathy’s system, the AI is primarily a writer. Its job is to maintain a document

In Open Brain, the AI is primarily a reader. Its job is to answer questions by pulling from structured data

When the AI is a writer, you interact with it intensively when new information comes in. Adding a single research paper might trigger updates across a dozen wiki pages. That’s the heavy operation. But afterward, getting answers is cheap, because the thinking has been done.

When the AI is a reader, adding new information is cheap. Write a row, tag it, done. The heavy operation is every question, because the AI has to reconstruct understanding from data every time. Simple lookups are fast. Deep synthesis questions are expensive. And that cost recurs every time you ask something similar, because nothing was pre-built.

This difference raises a question most people aren’t asking yet: whose understanding is it?

When your AI maintains a wiki, and a colleague asks you about a topic, and you check the wiki before answering, are you sharing your understanding, or the AI’s interpretation of your sources? You’re trusting that the AI’s capture of your thinking is good enough to share with your colleagues as yours. With a database, provenance is different. These are facts, from identified sources, with timestamps. You can trace any claim back to where it came from. You know what you know, and you know why you know it

It also means the instructions you give the AI, the schema file that tells it how to organize your wiki, quietly becomes the highest-leverage document in the whole system. It’s not a configuration file. It’s an editorial policy for your personal knowledge base. The quality of that schema determines the quality of every synthesis the AI produces. Most people will underinvest in it, and the wiki will be worse than it should be as a result.

What each approach is good at

Karpathy’s wiki wins when:

You’re deep in research. When you’re reading ten papers on a topic over two weeks, each one building on or contradicting the last, the wiki approach is dramatically better.

This also wins for personal knowledge that evolves over months (health tracking, self-improvement, competitive analysis), and for any domain where the value is in the connections between sources rather than in any single source alone.

The other place it wins: the wiki still works even without an AI in the loop. It’s human-readable text files. You can open them in any note app, browse the links, follow the connections. If every AI API went down tomorrow, you’d still have organized, useful notes. That’s a real form of durability that a database can’t match.

Open Brain wins when:

You need precise, structured operations across your knowledge. “Show me every meeting note from Q1 where pricing was discussed.” “Pull the three most recent competitor updates and compare them.” “Find all action items assigned to me in the last two weeks.” These are database queries. They return exact, filterable results.

Open Brain also wins for multi-agent access.

two agents editing the same page creates a mess.

And it wins at volume. Open Brain handles thousands of entries across dozens of categories with search, metadata, and relational queries. Karpathy’s own research wiki runs to about a hundred articles. The pattern works well at that scale, maybe into the low thousands with extra search tooling, but it was never designed for the volume an organization generates. When you’re dealing with thousands of contacts, transactions, events, or tasks, structured storage is the only sane option.

Where each one cracks

Karpathy’s wiki cracks at:

Team use. The moment two people (or two agents) try to update the same wiki page, you have a conflict. Not just a technical conflict — a semantic one.

Fast-moving domains. If your knowledge changes daily (project status, competitive positioning, live deal flow) the cost of re-synthesizing the wiki on every update becomes punishing. Every change potentially ripples across multiple pages. Karpathy’s system is optimized for knowledge that moves at “papers and articles” speed, not “Slack messages and ticket updates” speed.

Dangerous when neglected. This is the one that worries me most. A neglected database just has gaps: the old facts are still true, there’s just missing recent stuff. A neglected wiki drifts. Old syntheses become increasingly wrong as new information doesn’t get integrated, but they still read with confidence because they’re well-written prose.

Database staleness looks like ignorance, and you know you’re missing something. Wiki staleness looks like misinformation, and you don’t know you’re wrong,

Precise queries. “How many sources mention transformer attention?” You’d have to read every file. “What percentage of articles were updated in the last 30 days?” There’s no structured metadata to query. “

Open Brain cracks at:

Deep synthesis quality. When a question requires understanding the relationships between fifteen different stored entries, the AI has to discover and reconstruct those relationships on the fly.

Browsability. Open Brain is headless. There’s no artifact you open and wander through. You can build dashboards and briefings on top of it (and the Life Engine extension does exactly that), but the default experience is: ask a question, get an answer. For people who think by reading and exploring, following links, stumbling on unexpected connections, this is a real gap.

Catching contradictions. In the wiki, contradictions surface when new information comes in, because the AI is actively integrating against existing pages. In a database, contradictions sit silently in adjacent rows until someone asks exactly the right question to expose them.

Telling a story. Databases store facts. They don’t tell stories. If you need “give me the overall arc of how my understanding of this topic evolved over six months,” a database hands you timestamped entries. A wiki hands you a narrative with cross-references.

The principles both systems share

What struck me most about these two approaches: they disagree on almost every implementation detail and agree on almost every underlying belief.

You own the artifact, not the tool. Karpathy’s files are text in a folder you control. Open Brain’s data is in a database you own

The AI does the grunt work. You do the judgment work

Memory compounds through structure, not accumulation

The knowledge base should be AI-native. Karpathy designed his wiki to be worked on by Claude Code, Codex, or any AI that can read and write files. Open Brain was designed from day one for MCP — the open protocol that lets any AI tool connect.

The hybrid I’d actually build next

I’ll lay out the specific architecture I’d propose, and what I think should become the next major Open Brain extension.

Keep Open Brain as your permanent store. Everything goes in. Every meeting note, article clip, research finding, task, contact. Tagged, searchable, queryable. This is your durable memory layer. It handles high volumes, precise queries, multi-agent access, and recall across every domain of your life. It’s the source of truth

Add a wiki layer as the compiled view. A new process where a compilation agent runs on a schedule (daily, weekly, or on-demand after major ingest). The agent reads from Open Brain’s structured data, synthesizes across entries, and produces wiki pages: topic summaries, entity profiles, trend analyses, contradiction reports, an index. These pages are generated artifacts. Think of them like a daily briefing that a really good chief of staff writes by reading everything in your files and distilling it into something you can actually browse.

The compilation agent follows Karpathy’s patterns — cross-referencing, linking related topics, flagging contradictions, maintaining an evolving synthesis. But it works from structured data, not raw files.

The wiki pages are the easy-to-read layer.

The database stays the single source of truth. New information always goes into Open Brain first. The wiki is never edited directly.

How to decide what to build right now

What Karpathy got right that everyone should steal

Regardless of which system you build, two ideas from Karpathy’s post are worth adopting immediately.

The idea file as a publishing format. Karpathy didn’t write a tutorial. He didn’t ship a tool. He published a high-level description of an idea, designed to be pasted into an AI agent that would then build the specifics with you.

The AI as maintainer, not oracle. The deepest insight isn’t the wiki structure. It’s the role the AI plays. Most people treat AI as something you ask questions to. Karpathy treats it as something that has an ongoing job — maintaining a knowledge artifact that gets better over time. The AI isn’t here for one-off answers. It’s here for sustained work that compounds. The question is just the interface.

Open Brain embeds the same principle through extensions, recipes, and the Life Engine’s autonomous loop. But Karpathy stated it more cleanly than anyone: you never write the wiki yourself. The AI writes and maintains all of it. You curate, you explore, you ask the right questions. The AI does the grunt work.

That division of labor — human judgment, AI maintenance — is the real pattern underneath both of these systems. And it’s the pattern that makes AI knowledge actually compound instead of just accumulate.

Where this is going

*There’s a deeper question hiding underneath all of this, though, and it’s the one that will determine whether Karpathy’s approach gets more important or less important over the next two years. His entire system is implicitly a bet that context windows (the amount of text an AI can process at once) will stay small relative to the amount of knowledge you accumulate. If you could dump everything into one enormous prompt, you wouldn’t need to pre-compile anything. You’d just let the AI re-derive every time.

Context windows are getting bigger. Gemini can already handle over a million tokens. So is pre-compilation dying?*

No

A massive context window full of raw sources still requires the AI to do the synthesis work live, during your query, under time pressure. Pre-compilation means that work was done deliberately, with your guidance, not rushed

So I built Open Brain to handle this too.