How we actually compare
A technical side-by-side of Andrej Karpathy's LLM wiki approach and how I work with AI on this garden. Same tools, different philosophy.
The surface similarity
When Andrej Karpathy published his LLM knowledge base setup earlier this month, I recognised a lot of it. Markdown files. A CLAUDE.md that defines how the system works. Wiki-links and backlinks between related ideas. An evolving, compounding body of connected content. If you squint, his setup and mine look remarkably similar: we’re both using the same tools, the same conventions, the same general instinct: build something that grows.
But the similarity is surface-level. Underneath it, the two systems are built on different assumptions about what a knowledge system is for, who writes, and what gets to be called knowledge at all.
Who writes
In Karpathy’s setup, the LLM is the primary author of the wiki. It reads the raw sources, writes summaries, creates entity pages, maintains backlinks, and keeps everything consistent. The human collects sources, sets the schema, and asks questions. The wiki itself is the LLM’s domain: “I rarely touch it directly,” Karpathy says.
My garden works differently, depending on what you’re looking at. Articles and jottings, the core of the garden, are 100% mine. I write every word of them. Claude doesn’t touch them. Where Claude does contribute is in the derivatives: summaries, metadata, project reports, semantic triples extracted from what I’ve written. The content is mine; the annotation layer is a collaboration.
The divide is about who holds the pen. In Karpathy’s system, the LLM holds it. In mine, I do.
Data, information, knowledge
Karpathy calls what he’s building a “knowledge base.” It’s a fair shorthand, but I’d push back on the word. Knowledge isn’t a file you can write to disk. It becomes knowledge in human embodied experience: in the moment you connect two things you’d never connected before, or the morning you wake up and realise something has shifted. Until that moment, what you have is data, or information. Both useful, but not the same thing.
Karpathy’s wiki is a well-organised, deeply connected information base. Remarkable in scale and structure. But the knowledge it represents still lives in Karpathy’s head, not in the files. The files are a very good externalisation of it.
My garden is also an externalisation, but of something different: of thinking in progress. Not finished information, but ideas at various stages of growth. The distinction matters because it changes what you’re building the system to do.
The architecture
Karpathy’s structural layer lives in one file: CLAUDE.md. It defines the schema, the conventions, the templates the LLM uses to build and maintain the wiki. The backlinks and cross-references inside the wiki are generated by the LLM as it ingests and processes content.
My structural layer is distributed across the whole garden. The Toolshed holds the architectural specs: content model, collection definitions, prose conventions, wiki-link behaviour. On top of that, there’s a semantic layer: triples extracted from articles, a taxonomy, and tags that are themselves first-class content with their own pages. Backlinks are computed at build time. None of this is generated by an LLM; it’s designed.
What strikes me about this difference is that architecture itself becomes content in my system. The Toolshed is not a config file you never visit. It’s part of the garden, readable and tendable like everything else. Architecture as design, not just configuration.
What each system is for
Karpathy’s system is built for retrieval. You accumulate sources, the LLM compiles them into a queryable wiki, and you ask questions. The system gets better as it grows. It answers questions you already know to ask.
Mine is built for serendipity. When I write an article, I’m not trying to file away information I’ve collected. I’m trying to surface connections I haven’t made yet. The triples extracted from my writing, the tags that link unexpected posts together, the backlinks that appear when two ideas share a concept I hadn’t consciously noticed: all of that is the graph picking up on something my writing revealed. I’m hoping for emergence. Unexpected relations between topics that have no obvious reason to be related.
Karpathy’s system is private and closed. Mine is public and transparent. I am my own primary audience, but everything is open. Always in progress, always a little messy.
The weed problem
There’s a tension in my garden that Karpathy’s doesn’t have, and I think it’s worth naming. AI creeps. It creeps into the spaces you leave for it, and then a little further. Working with Claude Code daily, on metadata, triples, architecture, skills: it’s genuinely addictive. Productive, often. But also, if I’m not careful, it starts to fill the space where my own writing should be.
I need to actively engage in my garden and use my own thoughts to keep the weeds out. That’s not a complaint about the tools. It’s a design constraint I’ve built into how I work: articles and jottings stay mine, no exceptions. Claude works on the layer around them.
Karpathy doesn’t have this problem, because in his system the wiki is the LLM’s domain by design. There’s no contested territory. He’s not trying to protect a writing practice inside the same system he’s using for research. That’s not a flaw in his design. It’s the clearest illustration of the difference between them.
Closing
The tools look the same. CLAUDE.md, markdown, backlinks, compounding content, Obsidian. The surface is identical.
But Karpathy is building a research index: an information system that gets smarter as it grows, that answers the questions he brings to it. I’m building a second brain: a place where my own thinking can slow down, compound, and occasionally surprise me.
Both are valid. Both are useful. The question isn’t which one is right. It’s what you’re optimising for. And, maybe more importantly: what you’re trying to protect.