Karpathy's LLM Wiki and the rise of 'idea files' — why sharing instructions beats sharing code

Andrej Karpathy — former Tesla AI director, OpenAI founding member, the guy whose YouTube lectures have taught half the internet how neural networks work — dropped a tweet on April 2nd that racked up 17,000+ likes and 3 million views in two days. The idea: stop using LLMs as search engines that forget everything between questions. Instead, have them build and maintain a personal wiki for you.

Two days later, he followed up with something even more interesting than the wiki itself. He shared it as an “idea file” — a plain-text gist you hand to your AI agent, which then builds a custom version for you. Not an app. Not a GitHub repo with 47 dependencies. A document.

That second part is worth paying attention to.

The wiki pattern, in 60 seconds

Most people interact with AI and documents through some flavor of upload-and-ask. You dump files into ChatGPT or NotebookLM, ask a question, the AI finds relevant chunks, generates an answer. It works. But the AI rebuilds its understanding from scratch every single time. There’s no accumulation. As Karpathy put it: “the LLM is rediscovering knowledge from scratch on every question.”

His approach flips this. Three layers:

Raw sources — articles, papers, images, data files. You collect them into a folder. The LLM reads from these but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. When you add a new source, the LLM doesn’t just index it for later. It reads it, extracts key information, writes summary pages, creates entity pages, links concepts together, flags where new data contradicts old claims, and maintains an index. A single source might touch 10-15 wiki pages. The cross-references are already there when you ask your next question.

The schema — a config document (like CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured and what workflows to follow. You and the LLM co-evolve this over time.

He uses Obsidian as the viewer and an LLM agent as the writer. You never (or rarely) touch the wiki directly. Your job is sourcing, exploration, and asking the right questions. The LLM does the summarizing, cross-referencing, filing, and bookkeeping.

And critically: your questions get filed back in. A comparison you asked for, an analysis, a connection you discovered — these become new wiki pages. Your explorations compound in the knowledge base just like ingested sources do. Karpathy’s own research wiki grew to ~100 articles and ~400,000 words this way.

The idea has clear roots. Karpathy himself nods to Vannevar Bush’s Memex — the hypothetical device described in Bush’s 1945 Atlantic essay “As We May Think”. Bush envisioned a personal knowledge store with “associative trails” linking documents together, an “enlarged intimate supplement to memory.” His vision was private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn’t solve was who does all the maintenance. Eighty years later, LLMs handle that.

The Hacker News reaction was predictable

The post hit the front page of Hacker News (158 points, 45+ comments) and the debate split into exactly the camps you’d expect.

“This is just RAG.” Several commenters argued this is retrieval-augmented generation with extra steps. One pointed out it’s essentially what GitHub Copilot does with its copilot-instructions.md file. The rebuttal from user darkhanakh was sharp: “the interesting bit here is the write loop — the LLM is authoring and maintaining the wiki itself, building backlinks, filing its own outputs back in. That’s not retrieval, that’s knowledge synthesis. In vanilla RAG your corpus is static, here it isn’t.”

Fair point. The “linting” step is genuinely different too — auditing inconsistencies, imputing missing data, suggesting connections. That’s closer to an assistant maintaining a Zettelkasten than a search engine returning top-k chunks.

“Won’t this lead to model collapse?” One commenter linked a 2024 Nature paper by Shumailov et al. — “AI models collapse when trained on recursively generated data” — which found that training models on their own outputs causes “irreversible defects” where the tails of the original content distribution disappear. The paper has 567 citations and 691,000 accesses; it’s a serious result. But as user gojomo countered: “Here in 2026, many forms of training LLMs on well-chosen outputs of themselves, or other LLMs, have delivered gigantic wins.” And more fundamentally, this wiki pattern isn’t training. It’s using an already-trained LLM to organize information for human consumption. The human stays in the loop, curating and correcting.

“Bigger context windows will make this obsolete.” User Imanari argued that next-gen models with 10M token context will eliminate the need for this kind of intermediate layer. Maybe. But “dump everything in and ask” has never been a great knowledge management strategy, even when you technically can fit it all. Structure helps. An index helps. Cross-references help. The wiki isn’t just a workaround for context limits — it’s a way of thinking.

“I’ve been doing this with Obsidian for months.” The most interesting reply came from SOLAR_FIELDS, who runs a structured Obsidian system with schemas on top and deploys it across multiple teams. Their take:

The intermediate layer is lossy, it’s messy, it goes out of date, but it’s highly effective. The real value is having a system that supports a human coming in and saying “this is how the system should actually behave.”

They also dropped a cold splash of realism: “You will not have the money these frontier providers do… the abstraction you build is gonna be completely irrelevant in two months.” A fair warning about building too much tooling on a moving target.

The actual innovation: idea files

Here’s what I find more significant than the wiki itself.

When Karpathy shared his follow-up, he didn’t post a GitHub repo. He posted a gist — about 2,000 words of plain English describing the pattern, the architecture, the operations, and some tips. His exact words: “In this era of LLM agents, there is less of a point/need of sharing the specific code/app, you just share the idea, then the other person’s agent customizes & builds it for your specific needs.”

Think about what that means. The unit of sharing is shifting from code to intent.

A GitHub repo says: here’s my solution, figure out how to make it work for you. An idea file says: here’s the problem and the approach, let your AI agent build you a version that fits your setup, your tools, your workflow. The gist is intentionally abstract — it describes what the wiki should do, not the exact directory structure or config format. It mentions Obsidian, Marp for slide decks, qmd (a 17,900-star on-device markdown search engine) as optional tooling, but makes clear you can swap any of it. Your agent figures out the specifics.

This is a genuinely different distribution model. Software used to be “download my app.” Then it became “clone my repo and run the install script.” Now it might be “read this document and have your AI build it.”

A cultural moment, not just a technical one

The timing matters. Ezra Klein published “I Saw Something New in San Francisco” in the New York Times just days before Karpathy’s tweet. Klein observed that the people building AI in San Francisco aren’t just using the technology — they’re being changed by it. They’re racing to “make themselves legible to the A.I.” so the AI can be more useful. Klein frames it through McLuhan’s Narcissus myth: we become fascinated by any extension of ourselves in a material other than ourselves.

One HN commenter, sebmellen, linked Klein’s piece as a cautionary counterpoint to Karpathy. Karpathy responding to a critic by copy-pasting a snarky Claude-generated retort (since deleted) was, for sebmellen, a case in point: “If you don’t have something human to say, don’t say it.”

I think both impulses are real. The wiki pattern is genuinely useful — it automates the tedious bookkeeping that kills most personal knowledge bases. But there’s a line between having an AI maintain your notes and having an AI do your thinking. The best version of this keeps humans in the driver’s seat: curating sources, asking questions, deciding what matters. The worst version is just… an AI talking to itself.

What this means if you run a business

You probably don’t need a personal LLM wiki. Most 15-person accounting firms aren’t sitting on hundreds of research papers they need cross-referenced.

But the pattern underneath applies to almost everything I help clients with:

Knowledge that walks out the door. I’ve written about this before — when your best employee quits, their knowledge goes with them. A structured wiki maintained by an AI agent, fed by Slack threads, meeting notes, and process documents, is one way to capture institutional knowledge without asking humans to do the boring documentation work that nobody ever does. Karpathy’s framing is useful here: “the wiki stays maintained because the cost of maintenance is near zero.” The LLM does the filing that no one on the team wants to do.

The idea file model for internal processes. Instead of writing a 40-page SOPs manual that nobody reads, you write a 2-page idea file describing what the process should accomplish, the constraints, and the edge cases. Hand it to an AI agent. It builds the actual workflow, adapted to your tools and your team. When things change, you update the idea file, not 40 pages of documentation. This is what Karpathy means by “the schema” — a living document that tells the AI how your system works.

Compounding knowledge bases for client work. If you’re a law firm, a consulting practice, or any service business that does similar-but-different work for each client — the wiki pattern is a way to build up expertise that compounds. Each engagement adds to the knowledge base. Each new client benefits from everything the AI has already synthesized. This is the Zettelkasten principle applied to business: small atomic notes that link together and grow more valuable over time.

The practical reality check

I don’t want to oversell this. There are real limitations worth naming.

LLMs still hallucinate. A wiki maintained by an AI will contain errors. If nobody reviews the output, those errors get baked into the knowledge base and influence future answers. The “linting” step Karpathy describes — where you periodically ask the AI to check for inconsistencies — helps, but it’s not foolproof. As HN user kwar13 put it bluntly: “It can’t even keep up with a simple claude.md let alone a whole wiki.”

Scale is uncertain. Karpathy says index-based navigation works fine at ~100 sources and ~400,000 words. That’s a solid personal wiki. For anything bigger — thousands of documents, years of Slack history, hundreds of client files — you’d need actual search infrastructure. Tools like qmd (hybrid BM25/vector search, all on-device) or a proper vector database would help. But then you’re building real infrastructure, not just running a script.

The model collapse concern isn’t zero. The Nature paper found that AI models trained on AI-generated data suffer “irreversible defects.” This wiki pattern isn’t training a model, but it is feeding AI-generated summaries back to an AI for further synthesis. Over enough iterations, subtle errors compound. The human in the loop can’t be optional.

The tooling is still janky. Obsidian is a great viewer but wasn’t designed as an AI IDE. The LLM can’t natively read markdown with inline images in one pass — you have to read the text, then view images separately. The gist itself acknowledges: “It’s a bit clunky but works well enough.” That’s an honest description of most LLM workflows right now.

The shift worth watching

Karpathy’s wiki is a useful personal productivity pattern. But the “idea file” concept — sharing intent instead of implementation, and letting each person’s AI agent customize the execution — that’s a bigger deal.

Software distribution has gone from “buy the CD” to “download the app” to “clone the repo” to, possibly, “read this document and have your AI build it.” The last step democratizes building in a way the others didn’t. You don’t need to read code to use an idea file. You need to understand what you want.

For business owners, this is good news. You don’t need to be technical to write an idea file. You need to understand your business — the constraints, the edge cases, the things that break on Fridays. That’s your expertise. The AI handles the rest.