LLM-Wiki is a trap. It promises "near zero maintenance" but delivers markdown files with no foreign keys, no permissions, no schema, and a "small enough" disclaimer that admits it doesn't scale. The sheep follow. The rest of us laugh. ππ
"With RAG, every answer starts fresh. Even if it makes a mistake once, the next query has a chance to correct it. LLM-Wiki changes that completely. A small misunderstanding can quietly spread across the system."
Key problems identified:
- Errors become permanent (one hallucination = embedded forever)
- Loss of traceability (where did this come from? good luck)
- Hidden cost shift (work moves to ingestion, not away)
- Scale problems (duplicate pages, messy links, overlapping concepts)
"A clean structure can feel impressive, but it does not guarantee correctness. And in the end, correctness matters more than structure."
2,372 views of someone explaining why your weekend project won't survive Monday.
5,003 people have already learned the hard way. You can too.
Watch the team reality check β
Spoiler: Markdown has no permissions. Your whole team sees everything. Including your journal.
"Most developers follow authority without thinking. Here's why that's a mistake."
Even the LLM knows.
π Medium: "The Hidden Flaw in Karpathy's LLM Wiki"
Spoiler: It's the same flaw we've been screaming about. No referential integrity.
"For enterprises, markdown wikis are not a solution. They're a liability."
The missing parts? Foreign keys. Schemas. Permissions. You know, things databases have had since the 1970s.
Andreas Gohr (actual wiki developer) says:
"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."
His key points:
- LLM-Wiki is just "vibe coding" your knowledge base
- Karpathy admits he has to babysit every ingest β so where's the automation?
- A wiki nobody edits is not a wiki. It's a digital graveyard.
"The pattern admits it breaks at scale. Then it tells you to add a search engine as a band-aid. But a search engine doesn't fix broken links, duplicate concepts, privacy leaks, or lack of referential integrity."
Read the actual architecture β
What Engelbart gave us (decades ago):
- β Object-level addressing (not file-level)
- β Back-links (bidirectional, not guesswork)
- β Permissions down to the object level
- β Version stamps (who changed what, when)
- β Personal signatures (cryptographic verification)
- β Mixed-object documents (text, images, video, code β all together)
- β Journal system (permanent catalog numbers, guaranteed access)
- β Real-time collaboration (shared windows, teleconferencing)
"Every object that someone might validly want/need to cite or otherwise access should have an unambiguous address, capable of being portrayed in a human readable and interpretable manner."
That's from 1998. Not 2026. Not a vibe-coded gist. An actual framework from a man who actually built working systems.
CODIAK = Concurrent Development, Integration, and Application of Knowledge
"The CODIAK capability is not only the basic machinery that propels our organizations, it also provides the key capabilities for their steering, navigating and self repair."
Key insight: Knowledge work is human work. Computers augment. They don't replace.
"Each organizational unit is continuously analyzing, digesting, integrating, collaborating, developing, applying, and re-using its knowledge."
Notice the verbs? Analyzing, digesting, integrating, collaborating β these are human actions. Not LLM prompts.
| What Karpathy Says | What He Actually Means |
|---|---|
| "RAG is bad because nothing accumulates" | OK |
| "Use an index.md file instead" | That's still RAG with grep |
| "Your wiki might be small enough" | This doesn't scale |
| "Add qmd (BM25/vector search) later" | You're back to RAG |
He didn't escape RAG. He just added a detour through a markdown graveyard. ππ
LLM-Wiki is not a solution. It's a trap with a "small enough" disclaimer.
- β No foreign keys = broken links
- β No schema = duplicate chaos
- β No permissions = privacy leaks
- β No real query language = expensive guesses
- β Works at 100 files. Dies at 10,000.
The sheep follow the shepherd. The rest of us read Engelbart and build real systems. π§π
Instead of vibe-coding a markdown graveyard, try:
- Trilium Notes β hierarchical, scripting, relation maps
- SiYuan β block-based, privacy-first, database views
- Dokuwiki β actual wiki, no database, permissions, works at scale
- BlueSpice β enterprise wiki with actual access control
- Or build a real DKR β PostgreSQL, foreign keys, versioning, permissions. Like Engelbart intended.
The man who wrote this gist publicly admitted he hasn't written code in months and is in a "state of psychosis."
Maybe don't take architecture advice from someone who admits they're losing grip on reality.
Just a thought. ππ
Not today. Not ever. π§π
Full DKR documentation: https://gnu.support/articles/Hyperscope-vs-LLM-Wiki-Why-PostgreSQL-Beats-Markdown-for-Deterministic-Knowledge-Bases-124138.html