Notes on Karpathy LLM Wiki

Andrej Karpathy published a gist yesterday called "LLM Wiki." If you haven't read it, I'd recommend doing that first — it's short and well-written.

I've been experimenting with something similar for a few months. Here's what clicked, where I diverge, and what I think the gist doesn't cover yet.

Karpathy's core idea

Stop re-deriving knowledge on every question. Instead, have the AI build and maintain a persistent wiki that compounds over time.

His key insight: the bottleneck for personal knowledge systems was never the reading or thinking — it was the maintenance. Cross-references, consistency, freshness. Humans abandon wikis because upkeep grows faster than value.

LLMs don't get bored. Maintenance cost drops to near zero. Problem solved.

My context

I've been building the same idea from a different angle. I run a small POS business, journal a lot, and use AI tools across both work and personal life. I wanted knowledge from one area to stop vanishing when I switch to another.

Same goal as Karpathy's. Messier inputs.

Three things I'm stealing from the gist

File good answers back. When you ask your wiki a question and get a useful synthesis — save it as a new page. Explorations compound, not just sources. My AI discussions produce useful thinking all the time, and it all disappears into chat history. Obvious fix I'd overlooked.

A knowledge index. One file listing every wiki page with a one-liner. AI reads this first to know what exists. I've had a knowledge base sitting there for months that my AI tools rarely check — because there's no quick way to browse it. Embarrassingly simple solution.

Knowledge lint. Periodic checks for stale facts, contradictions, orphan pages. I already do this for system docs but never applied it to the knowledge itself. Facts change. How I think changes. Same maintenance discipline, different layer.

Where I diverge

Two quick observations from using this pattern in practice:

Content types need different handling. A todo item becomes a task, not a wiki page. A journal entry gets distilled into principles. A coding session updates the AI's memory. One ingest pipeline doesn't fit all of these — I ended up with three.

Knowledge has more than one home. A single journal entry might produce a personal principle, a business fact, two action items, and three vague ideas. Each needs a different destination. The routing question — where does each piece go? — turned out to be harder than the processing question.

What I think the gist misses

Karpathy solves the maintenance bottleneck. That's real and valuable — probably the biggest unlock.

But once maintenance is handled, a subtler problem surfaces: not everything is ready to be knowledge.

Karpathy's model has two states: raw (unprocessed) and wiki page (processed). In practice, a lot of what I encounter fits neither. Customer feedback. Half-formed product ideas. Vague patterns I'm noticing but can't articulate yet.

These aren't ready to be wiki pages. Individually, they're noise. But ten related signals? Now there's a shape.

I think of it as fog-clearing — signals accumulate passively until something crystallizes on its own. You can't rush it. You can't file it. You just have to let it sit.

A knowledge system that only handles the clear and structured will miss the most interesting signals — the ones still forming. The hard part isn't building the wiki. It's knowing what's ready to be in it, and having the patience to let the rest sit.

If you want to try this

Start simple:

Create a folder
Open Karpathy's gist with any AI tool — Claude, ChatGPT, Gemini
Ask it to set up a wiki for a topic you care about
Feed it one source. Ask questions. See how it feels.

You can always add complexity later — and if you're anything like me, you won't be able to stop yourself. (I'm an engineer. This is a known failure mode.)

Adrian Gan builds POS systems at Mipos and tinkers with AI workflows in his spare time.

Written with Claude Opus 4, edited by Adrian.