Karpathy's LLM-Wiki Is a Flawed Architectural Trap


The Great LLM-Wiki Delusion: Why Markdown Sheep Are Building Castles on Sand

A Response to Karpathy’s Gist and the 5,000-Star Stampede

https://gnu.support/images/2026/04/2026-04-15/800/wizard.webp

Introduction: The Pied Piper of Markdown

I have watched this unfold for two weeks. A man who publicly admits to “AI psychosis” and hasn’t written a line of code in months drops a half-baked idea file on GitHub. Within days, it gets 5,000 stars, 4,000 forks, and hundreds of commenters rushing to implement his vision.

The idea? Let an LLM maintain a wiki of markdown files. You never write. The LLM does everything. The wiki “compounds.” Maintenance is “near zero.”

And the sheep are lining up. πŸ‘πŸ‘πŸ‘

But I have been building knowledge systems for 23 years. I have 245,377 people and 95,211 hyperdocuments in my Dynamic Knowledge Repository. I have seen technologies rise and fall. And I am here to tell you: this pattern is a trap.

Not because Karpathy isn’t smart. He is. But because he is not Engelbart. He did not spend decades thinking about Open Hyperdocument Systems, CODIAK, or the nature of knowledge work. He came up with a clever weekend hack, and people are treating it like the next Unix.

Let me explain why.

Part One: The Fundamental Contradiction

The LLM-Wiki pattern claims to solve a real problem. Most RAG systems are stateless. They re-derive knowledge on every query. Nothing accumulates. A wiki that compounds over time β€” that is a genuinely good idea.

But the implementation is where it falls apart.

The pattern says: “You never (or rarely) write the wiki yourself β€” the LLM writes and maintains all of it.”

Yet later, it admits: “You and the LLM co-evolve the schema over time.”

The schema is a file in the wiki. That means the human does write wiki files directly. The pattern contradicts itself within paragraphs.

The pattern says: “The index avoids the need for embedding-based RAG infrastructure.”

Yet later, it recommends qmd β€” a local search engine with BM25, vector search, and LLM re-ranking.

That’s just RAG with extra steps. The index works at 100 files. It dies at 1,000. The pattern doesn’t replace RAG. It postpones it and then adds a brittle markdown middleman.

The pattern says: “Raw sources are immutable.”

Yet it tells you to download images locally, which modifies the markdown source (URLs change). Minor, but symptomatic.

The pattern says: “Linting detects contradictions.”

But who resolves them? The doc is silent. The LLM? By recency or authority? The human? That would require editing β€” which the pattern says you never do.

These are not fatal alone. But they reveal a pattern of hand-waving that the sheep ignore.

Part Two: What the Comments Reveal

The gist has hundreds of comments. Most are praise. But buried in the noise are voices of reason.

User @mpazik (comment 6079689):

“I’ve been doing this for a while now and there are two things that break first. Queries. Once you’re past a few hundred pages you want to ask your wiki things. ‘What did I add last week about X?’ ‘Show me everything tagged unverified.’ You can’t do that by reading files. The index helps early on but it doesn’t scale. Structure. It creeps in whether you plan it or not. Frontmatter, naming conventions, folder rules. The wiki grows a schema on its own. At some point you realize you’re fighting your tools instead of working with them.”

He solved it by flipping the model: start from structured data that renders as markdown. The index is a query, not a file.

User @laphilosophia (comment 6079377):

“I think the hardest part is understated a bit: truth maintenance. The appealing part of the workflow is that the LLM updates summaries, cross-links pages, integrates new sources, and flags contradictions. But that is also exactly where models tend to fail quietly. Bad synthesis, weak generalization, stale claims surviving new evidence, page sprawl, and false consistency can accumulate without being obvious. The risky sentence is effectively ‘the LLM owns this layer entirely.’ That is fine for low-stakes personal use, but it feels too aggressive for team or high-accuracy contexts.”

He calls for a “source-grounded, citation-first, review-gated wiki.” The LLM should propose patches, not finalize them.

User @asong56 (comment 6086671):

“One disadvantage might be that AI hallucinations can become permanently embedded as facts, causing errors to propagate. It also has maintenance burden, you have to check and clean the notes.”

Exactly. The “near zero maintenance” promise becomes a nightmare of verification.

User @YoloFame (comment 6090142):

“LLM-generated intermediate artifacts tend to amplify factual errors, especially for small text details. For project-level wikis where accuracy is mission-critical, these uncaught errors can be catastrophic for the whole team. The only workaround I’ve found so far is pouring tons of time into manual cross-checking of every LLM edit against raw sources, which basically cancels out the time-saving benefit of this pattern.”

The pattern eats its own tail.

User @skpalan (comment 6079055):

“I might being a bit old school here, but isn’t this just re-emphasizing the need of giving an LLM persistent, structured context? If I am being honest, a well-organized, global+local AGENTS.md hierarchy + skills system already serves this purpose pretty well. But I do like the lint passing concept here, which is periodically having the LLM audit its own wiki/AGENTS.md.”

He sees it clearly: this is not new. It’s a rebranding of existing patterns with more hype.

User @gnusupport (comment 6093292):

“Obsidian is proprietary software. You cannot run a true ‘personal knowledge base’ when the viewer itself is closed-source, vendor-controlled code that phones home no telemetry today but could change its license, add tracking, or go subscription at any moment. Your data sits in plain Markdownβ€”goodβ€”but the experience of navigating your wiki, the graph view, the Dataview queries, the backlinks you rely on to see the synthesisβ€”those are mediated by a proprietary client you do not control. A personal knowledge base means you own and control every layer: the data, the rendering, the query engine, the network. Obsidian cedes control of the human-computer interface to a for-profit company.”

This is a crucial point that the hype ignores. You are building your “personal” knowledge base on proprietary foundations.

User @grishasen (comment 6087524):

“The approach resonates deeply and seems very promising. However, after spending two days building the library from documentation and team message threads, it appears too niche compared to building a local RAG system in a single day and using it as a knowledge base. RAG is immediately useful, whereas the wiki build feels far from complete and consumes a significant number of tokens.”

He tried it. He found it inferior to RAG in practice.

User @pssah4 (comment 6084927):

“When an LLM writes my summaries and cross-references, I get a well-organized information store. What I don’t get is the understanding that comes from doing that work. I don’t develop my own structure of thinking, sorting information, connecting insights. And you feel that later. In discussions, in decisions, in the ability to actually defend a position. If all I have are LLM distillates, I can report what the model produced. I can’t argue from something I built myself, because I never did.”

This is the deepest critique. The act of writing is where understanding forms. Outsource that, and you outsource your thinking.

User @iBlinkQ (comment 6101061):

“Raw resources may be better than LLM Wiki for beginners. YouTube videos and PDFs are tutorials that go from shallow to deep, with the authors explaining things step by step. If you’re starting from zero, patiently working through the original materials is the most efficient approach. Once you have a complete understanding of the source materials, then consult the Wiki to find connections β€” that’s the scenario it’s really suited for: review and summary, not getting started.”

“AI-generated content must be validated; don’t hoard it blindly. Hoarding without reviewing is like hiring a robot to work out for you β€” it runs on the treadmill every day, but your body won’t get healthier.”

“The content you create is not just for you to read, it’s also for the AI. The index and log in Karpathy’s system were designed for AI to read. I also add fields like type and summary to my notes β€” the former distinguishes what I wrote from what the AI generated; the latter makes it easier for the AI to retrieve.”

This user gets it. Raw resources first. Validation mandatory. Content optimized for both human and AI β€” but with clear provenance.

Part Three: Why Markdown Is Not a Database

The core architectural flaw is simple: markdown files are not a database.

No foreign keys. Links break silently. When you rename a page, every link to it becomes a 404. There is no referential integrity. The LLM can try to fix them, but it will miss some, and you will not know until you click.

No schema. Duplicate concepts multiply. “Machine Learning” and “ML” become separate pages. The LLM cannot enforce uniqueness across files because there is no central registry.

No permissions. Private information leaks. The LLM needs to read the wiki to answer questions. If the wiki contains your journal entries, client NDAs, or medical records, the LLM sees them. Markdown has no way to say “this is for human eyes only.”

No deterministic metadata. The LLM guesses file sizes, types, dates. It can be wrong. A deterministic program would extract these correctly every time.

No real query language. Every question becomes an expensive probabilistic guess. “Who is the sister of my friend John?” requires the LLM to search, read, synthesize β€” and maybe hallucinate. In a database, it’s a SQL query: sub-second, deterministic, free.

No audit trail beyond git. Git tracks files, not fields. When the LLM changes a fact, why did it change? What source prompted it? Who approved it? In a database, you have triggers and version tables. In markdown, you have a diff that says “line 47 changed from X to Y” with no context.

The LLM-Wiki works at 100 files. It creaks at 1,000. It collapses at 10,000. The “near zero maintenance” promise becomes a nightmare of endless linting, fixing, and verifying.

Part Four: The Engelbart Alternative

Douglas Engelbart spent decades developing a vision for knowledge work. His Open Hyperdocument System (OHS) framework, published in 1998, specifies:

This is what a real Dynamic Knowledge Repository looks like. Not markdown files. Not LLM-generated wikis. A system with referential integrity, permissions, version control, and global addressing.

Engelbart’s CODIAK framework β€” Concurrent Development, Integration, and Application of Knowledge β€” describes a process that is fundamentally human. Each organizational unit is continuously analyzing, digesting, integrating, collaborating, developing, applying, and re-using its knowledge.

These are human actions. A computer can assist. A computer cannot replace.

The LLM-Wiki pattern inverts Engelbart’s vision. It says: the LLM does everything; the human just curates sources. Engelbart said: the human does the thinking; the computer augments.

One is augmentation. The other is abdication.

Part Five: The Shepherd’s Psychosis

Let us not ignore the elephant in the room. The author of this pattern has publicly stated that he is in a “state of psychosis” and hasn’t written code in months.

From Fortune magazine (March 2026):

“OpenAI cofounder Andrej Karpathy says he hasn’t written a line of code in months and is in a ‘state of psychosis’ as he dives deep into AI agents.”

He admits he is talking to LLMs for two-thirds of the day. He is not writing code. He is not thinking deeply. He is vibe-coding his way through a psychological episode.

And people are treating his gist as a technical blueprint.

This is not an ad hominem attack. It is a reality check. When someone admits they are losing grip on reality, perhaps we should not follow their architectural advice blindly.

The sheep follow the shepherd. But what if the shepherd is lost?

Part Six: The Real Solutions Already Exist

You do not need to build a fragile markdown wiki. Proven, open-source knowledge management systems already exist:

These systems have been battle-tested for years. They have communities, contributors, and real users. They do not rely on an LLM to maintain their integrity.

The LLM-Wiki pattern is not innovation. It is a regression to a less capable architecture, wrapped in hype.

Part Seven: The Verdict

The LLM-Wiki pattern is a clever idea for a weekend project. It is not a serious architecture for knowledge management.

It fails on:

The correct architecture is:

The LLM is a refreshener, not the curator. A tool, not the master.

Keep your hands on the wheel.

References

Engelbart, D. C. (1998). Technology Template Project - OHS Framework. Doug Engelbart Institute. https://www.dougengelbart.org/content/view/110/460/

Engelbart, D. C. (1992). Toward High-Performance Organizations: A Strategic Role for Groupware. Doug Engelbart Institute. https://www.dougengelbart.org/content/view/116/

Karpathy, A. (2026). LLM Wiki. GitHub Gist. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Fortune Magazine. (2026, March 21). OpenAI cofounder says he hasn’t written a line of code in months and is in a ‘state of psychosis’. https://fortune.com/2026/03/21/andrej-karpathy-openai-cofounder-ai-agents-coding-state-of-psychosis-openclaw/

Postscript

I have been building my Dynamic Knowledge Repository for 23 years. It has 245,377 people, 95,211 hyperdocuments, and complete referential integrity. I use LLMs to accelerate my work β€” to generate descriptions, to summarize, to answer questions. But I never delegate control. The LLM is a tool. I am the curator.

The sheep can follow the shepherd. I will stay here, building something that actually works.

πŸ‘β†’πŸ’€ Not today. Not ever. πŸ§™πŸ“œ

*Full article and Hyperscope documentation: https://gnu.support/articles/Hyperscope-vs-LLM-Wiki-Why-PostgreSQL-Beats-Markdown-for-Deterministic-Knowledge-Bases-124138.html*

Related pages