> ## Content Index > Fetch the complete content index at: https://www.implicator.ai/llms.txt > Use this file to discover other available public pages before exploring further. # Karpathy Killed His RAG Pipeline for a Folder of Markdown. Here's the Full Build Guide. - URL: https://www.implicator.ai/karpathys-llm-wiki-got-16-million-views-the-code-isnt-the-point-2/ - Published: 2026-04-14T10:00:23.000Z - Updated: 2026-10-21T15:19:12.000Z - Description: Karpathy's LLM Wiki thread drew 16M views. His Gist with zero code got 5,000 stars. The pattern, a hands-on tutorial, the ecosystem, and why the "idea file" may matter more than the wiki. - Author: Marcus Schuler - Tags: Implicator PRO Briefing *Implicator PRO Briefing / 14 Apr 2026* | | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Pro Members Only Andrej Karpathy stopped building RAG pipelines and pointed an LLM at a folder of markdown files instead. The X thread went supernova: 16 million views, 100,000 bookmarks, and a GitHub Gist with zero code that pulled 5,000 stars. This analysis goes beyond the tutorial to examine the three-layer architecture, the open-source ecosystem that materialized within days, the enterprise limitations vendors are already exploiting, and why Karpathy's "idea file" concept may reshape how technical knowledge travels. New to Implicator PRO? [Subscribe for $ 8/month or $ 89/annually](https://www.implicator.ai/become-an-implicator-pro-member/) — new deep dive every Tuesday morning 3am PST. | | | On April 3, 2026, Andrej Karpathy opened X and posted a thread. No product launch. No funding announcement. No repository link. Just a description of how he keeps research notes organized using markdown files and a coding agent. Sixteen million people read it [within 48 hours](https://m.economictimes.com/tech/artificial-intelligence/why-should-you-create-personal-knowledge-bases-for-quicker-responses-to-queries-andrej-karpathy-explains/articleshow/130036489.cms?ref=implicator.ai). A hundred thousand bookmarked it. Jack Dorsey, who co-founded Twitter, called it a "great idea file." Karpathy followed up the next day with a GitHub Gist he titled "LLM Wiki." It contained zero lines of executable code. Five thousand stars. Zero code. Instead, the gist laid out a pattern. Drop research papers, articles, and web clippings into a folder. Point an LLM at that folder. Tell it to compile everything into a structured, interlinked wiki of markdown files. Read the wiki in Obsidian. Ask the LLM questions against it. File the answers back into the system. The knowledge compounds. No vector database. No embeddings. No chunking strategy. No RAG pipeline. Karpathy has been running this system for months. His wiki on a single research domain grew to roughly [100 articles and 400,000 words](https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an?ref=implicator.ai), compiled and maintained entirely by the LLM. He says he rarely edits the wiki by hand. The LLM writes the articles, creates backlinks between related concepts, builds index files listing every page with a one-line summary, and runs periodic health checks to catch contradictions. "[Obsidian is the IDE](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?ref=implicator.ai)," Karpathy wrote. "The LLM is the programmer. The wiki is the codebase." That analogy carries more weight than the tutorial instructions that followed it. Because within a week, developers had launched open-source frameworks built on the same idea. Enterprise vendors published rebuttals and product pitches in the same breath. One developer fed 2,500 diary entries, Apple Notes, and iMessage conversations into an LLM and produced a [400-article personal encyclopedia](https://www.toolmesh.ai/news/karpathy-llm-wiki-personal-knowledge-management?ref=implicator.ai) he calls "Farzapedia." Designed not for human browsing, but for his AI agent to query. Something about the timing was right. And the 16 million views had less to do with Karpathy's personal brand than with a problem millions of knowledge workers recognized the moment someone named it. What You Need to Know - Karpathy's X thread on LLM-maintained markdown wikis drew 16 million views in 48 hours; his follow-up GitHub Gist with zero executable code passed 5,000 stars within days - The three-layer architecture (raw sources, LLM-compiled wiki, schema file) replaces vector databases and RAG pipelines for knowledge bases under roughly 400,000 words - Open-source ecosystem formed within a week: SwarmVault, llm-wiki-agent, obsidian-wiki, COG-second-brain, plus Shopify CEO Tobi Lutke's qmd local search engine - Step-by-step tutorial: how to set up the three-layer vault, configure the schema, run ingestion and compound queries, and maintain the system with health checks - Karpathy's 'idea file' concept shifts how developers share tools, from distributing code repositories to sharing portable concepts that any LLM agent can implement AI-generated summary, reviewed by an editor. [More on our AI guidelines](https://www.implicator.ai/about/). I — CONTEXT ## From vibe coding to knowledge compilation Each phase of Karpathy's public LLM use has expanded what people believe agents can do. He coined "vibe coding" in February 2025, describing a workflow where developers generate code without reviewing every line. By January 2026, he had moved to "agentic engineering," orchestrating multiple agents that write code under human oversight. Now, in April 2026, the entire frame shifts beyond software entirely. "A large fraction of my recent token throughput is going less into manipulating code," [Karpathy wrote](https://antigravity.codes/blog/karpathy-llm-knowledge-bases?ref=implicator.ai), "and more into manipulating knowledge." > Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase. > > Andrej Karpathy That sentence landed differently than the usual AI optimism. The person who coined the term that defined casual AI-assisted programming is saying he has moved past it. Not because vibe coding failed. Because he found something LLMs handle better than writing software: compiling, organizing, and maintaining structured knowledge. The timing intersects with a technical shift most users haven't absorbed yet. Modern LLMs have enormous context windows. Forty-one models now support [1 million or more tokens](https://lmmarketcap.com/reports/llm-knowledge-bases-karpathy?ref=implicator.ai). Claude handles 200,000 tokens natively. Gemini 1.5 Pro goes higher. At those sizes, a personal research project of several hundred articles fits entirely within a single prompt. The retrieval problem that RAG was designed to solve, getting the right information into a small context window, simply doesn't exist at individual scale anymore. And coding agents gained something equally important over the past year: persistent, authorized access to local file systems. Claude Code reads, writes, searches, and moves through a folder of markdown files on your machine. So do OpenAI Codex, Cursor, Windsurf, and a growing list of alternatives. The agent doesn't need a specialized database or API. It just needs a directory. Karpathy connected these two facts in public and articulated the resulting pattern with an engineer's precision. His system works not because of any novel technology, but because context windows and file-system access converged while millions of knowledge workers were drowning in unstructured information with no good tool to organize it. RAG was supposed to be that tool. For three years, it served as the default architecture for giving LLMs access to proprietary data. Documents chopped into arbitrary chunks, converted into mathematical vectors, stored in specialized databases. When a user asks a question, the system performs a similarity search and feeds the closest matches into the LLM. The model answers from fragments. It never builds a picture. Same documents, same questions, same amnesia. Every session starts over. Karpathy looked at that pipeline and [rejected the complexity](https://antigravity.codes/blog/karpathy-llm-wiki-idea-file?ref=implicator.ai) for anything below enterprise scale. "I thought that I had to reach for fancy RAG," he said, "but the LLM has been pretty good about auto-maintaining index files and brief summaries of all documents." II — ARCHITECTURE ## Three layers, zero infrastructure Strip away the commentary and the architecture reduces to three directories. Get the separation right and the tools barely matter. **Layer 1: Raw Sources.** A staging folder for everything you collect. Articles, papers, repo READMEs, dataset descriptions, web clippings, PDFs, screenshots, basically anything you'd throw in a reading queue. One absolute rule applies: the LLM reads from this folder but never modifies it. These files are your evidence base. Every claim in the wiki traces back to a specific document sitting right here, readable by any human with a text editor. **Layer 2: The Wiki.** A separate folder of LLM-generated markdown files. Summaries, concept pages, entity profiles, comparisons, synthesis documents. The LLM owns this layer completely. You browse it. The LLM writes it. "You never (or rarely) write the wiki yourself," Karpathy's gist states. "The LLM does all the grunt work, the summarizing, cross-referencing, filing, and bookkeeping." **Layer 3: The Schema.** A configuration file that tells the agent how everything is structured, what naming conventions to follow, how to format backlinks, and what workflows to run during ingestion, querying, and maintenance. For Claude Code, this file is called CLAUDE.md and lives at the vault root. For OpenAI Codex, it's AGENTS.md. For Cursor, it goes into .cursor/rules/. The format varies by agent. The function is identical: turn a generic coding assistant into a disciplined research librarian. Most people underinvest in the schema. A vague configuration file produces vague output. One ingest creates topic folders. The next dumps articles flat. Naming conventions drift. Index entries get formatted differently each time. Karpathy's gist specifies exact structure: `wiki/[topic]/[concept-name].md`, lowercase, hyphens. Every wiki article must have an H1, a summary, a body, a sources section linking back to raw files, and a "See Also" section with backlinks. Every line in an index file follows a fixed format: `- [[article-name]] -- one-line summary`. Obsidian CEO Steph Ango responded to Karpathy's thread with a recommendation that became the most-cited reaction in the community: keep your personal vault clean. Create a separate space for agent-generated content. He called it [contamination mitigation](https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an?ref=implicator.ai). The term stuck because the risk is real. If an LLM hallucinates a connection between two concepts, that false link persists in your wiki and quietly influences every future query. A handful of Obsidian plugins do most of the heavy lifting on the human side. Web Clipper, a browser extension for Chrome, Firefox, Safari, and Arc, converts articles into clean markdown with locally downloaded images, feeding the raw/ folder without manual copy-paste. Graph View renders the wiki's backlink structure visually, showing which concept pages are hubs and which are orphans waiting for the next lint pass. Dataview lets you query your vault like a database, pulling tables of recently updated articles or unlinked mentions. And community tools like Neural Composer are starting to build LLM-powered graph operations directly into the plugin layer, blurring the line between Obsidian and the agent running underneath it. Three operations cycle continuously and keep the system alive: **Ingest.** Drop a new source into raw/. Tell the LLM to process it. The agent reads the document, identifies concepts, creates or updates wiki articles, adds backlinks, and updates the master index file. A single new source document might touch 10 to 15 wiki pages, updating some, creating others, threading connections throughout. An append-only log file tracks every operation so you can trace how the wiki evolved over time. **Query.** Ask the LLM a question. It reads the master wiki/index.md first, a file listing every article with a one-line summary. Then it opens relevant articles, follows backlinks to related concepts, and synthesizes an answer grounded in compiled knowledge. After a complex query produces useful synthesis, you file that answer back into the wiki as a new article. That is the compounding mechanism. Every exploration adds to the library. **Lint.** Periodic health checks. The LLM scans the entire wiki looking for contradictions between articles, orphan pages nobody links to, concepts that keep appearing but lack their own dedicated page. It catches index entries pointing to files that no longer exist. CI/CD for your knowledge base, essentially. Run it weekly, or after every significant batch of new material. DAIR.AI founder Elvis Saravia [confirmed the pattern works](https://academy.dair.ai/blog/llm-knowledge-bases-karpathy?ref=implicator.ai): "I have also been obsessed with building LLM knowledge bases. LLMs are excellent at curating and searching once data is stored properly." Lex Fridman described going further, adding dynamic HTML visualizations to his wiki and loading focused subsets into an LLM for [voice-mode interaction during long runs](https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an?ref=implicator.ai). He queries his own compiled knowledge base through earbuds while running seven to ten miles. The ephemeral wiki dissolves when the session ends. III — TUTORIAL ## Build it: from architecture to working system The architecture is clear enough to implement in an afternoon. What follows is a step-by-step guide to building the system with Obsidian and Claude Code. You need Obsidian installed with a vault, [Claude Code](https://docs.anthropic.com/en/docs/claude-code/overview?ref=implicator.ai) running, and the [Obsidian Web Clipper](https://obsidian.md/clipper?ref=implicator.ai) browser extension. Pick a topic you are actively researching, with 10-15 source documents worth collecting. Here is how the three layers map to an Obsidian vault: ``` my-research-vault/ ├── CLAUDE.md # Schema: rules, workflows, conventions ├── log.md # Append-only audit trail ├── raw/ # Layer 1: source documents (read-only) │ ├── arxiv-2403.12345.md │ ├── blog-post-react-server-components.md │ ├── github-readme-fastapi.md │ └── ... ├── wiki/ # Layer 2: LLM-compiled knowledge │ ├── index.md # Master index of all topic wikis │ ├── web-frameworks/ │ │ ├── index.md # Topic index with article summaries │ │ ├── server-components.md │ │ ├── hydration-strategies.md │ │ └── ... │ └── ml-inference/ │ ├── index.md │ ├── quantization.md │ └── ... └── .obsidian/ # Obsidian config (auto-generated) ``` ### Setting up the folder structure and schema Start inside your Obsidian vault. You need four things: a raw directory, a wiki directory, a master index, and a CLAUDE.md file. Your raw directory is just a folder. Name it `raw/` or whatever fits your existing vault structure. Everything you collect goes here. Articles, PDFs, screenshots, code snippets. No organization required. The LLM handles that. The wiki directory holds all compiled output. Create subdirectories by topic inside it. Each topic gets its own `index.md` that the LLM maintains with links and summaries of every article in that topic. At `wiki/index.md`, a master index catalogs every topic wiki. When the LLM receives a query, it reads this file first to figure out where to look. Now the part most people skip: the CLAUDE.md file. Your schema needs to specify the exact file structure, naming conventions for wiki articles, how backlinks should be formatted, what an index entry looks like, and the workflows for ingestion and querying. ```markdown # Knowledge Base Schema ## Structure - `raw/` — Source documents. **Read-only. Never modify these files.** - `wiki/` — LLM-compiled articles. You own this directory entirely. - `wiki/index.md` — Master index. Update after every new article. - `log.md` — Append a timestamped entry after every ingest, query, and lint. ## Naming Conventions - Wiki articles: `wiki/[topic]/[concept-name].md` (lowercase, hyphens) - One article per concept. If a concept spans topics, pick the primary topic and add backlinks from the secondary topic's index. ## Wiki Article Format Every wiki article must follow this structure: - **H1**: Concept name - **Summary**: 2-3 sentence overview - **Body**: Detailed explanation with examples - **Sources**: List of `[[raw/filename]]` links to source documents - **See Also**: Backlinks to related wiki articles using `[[wiki/topic/article]]` ## Index Entry Format Each line in an index file: `- [[article-name]] — one-line summary` ## Workflows ### Ingest 1. Read new files in `raw/` 2. For each file: extract key concepts, update existing wiki articles or create new ones, add backlinks 3. Update topic `index.md` files with new/changed articles 4. Update `wiki/index.md` if new topics were created 5. Append to `log.md`: `[YYYY-MM-DD HH:MM] INGEST: [filename] → [N] articles updated` ### Query 1. Read `wiki/index.md` to find relevant topic wikis 2. Read topic index, then read relevant articles 3. Follow backlinks for additional context 4. Synthesize answer with citations to wiki articles 5. If the answer is substantial, save it as a new wiki article 6. Append to `log.md`: `[YYYY-MM-DD HH:MM] QUERY: [question summary]` ### Lint 1. Scan all wiki articles for: contradictions, orphan pages (no inbound links), missing backlinks, concepts mentioned but lacking own page 2. Check all index entries point to existing files 3. Report findings as a numbered list with severity 4. Append to `log.md`: `[YYYY-MM-DD HH:MM] LINT: [N] issues found` ``` Two things matter in this schema. The wiki article format must require a sources section that links back to raw files. Without that traceability, you cannot verify anything the LLM writes. And the workflow instructions should be explicit about when to update the master index. If the LLM creates an article and forgets to register it, that article becomes invisible to future queries. ### Ingesting raw material Data gets into your raw folder through two paths: manual web clipping and LLM-driven research. For manual collection, the Obsidian Web Clipper extension converts any web page into a markdown file. Install it, then configure the default save location to your `raw/` folder. In the extension settings, change the "Note location" from `Clippings` to `raw`. Every page you clip lands in the staging area automatically. One gotcha with the Web Clipper: it handles images as remote links by default, which break when the source page changes. Install the "Local Images Plus" community plugin in Obsidian. It downloads linked images to your vault so the LLM can reference them via vision capabilities, and your clips stay intact even if the original page disappears. For LLM-driven research, point Claude Code at your vault and tell it to research a specific subtopic. It will search the web, fetch relevant content, and save markdown files to `raw/` on its own. Claude Code can also process GitHub repos, pull out README files, parse release notes, and create structured summaries of codebases. Once you have material in raw, trigger the compilation step: ``` I just added 3 new files to raw/. Read each one, extract the key concepts, and compile them into the wiki. For each concept: - Update the existing wiki article if one exists, or create a new one - Add backlinks to related articles in the wiki - Update the relevant topic index.md - If this creates a new topic, add it to wiki/index.md After you're done, show me which articles you created or updated. ``` The ingest process is where the LLM earns its keep. It reads the raw material, identifies core concepts, writes clear explanations, notes contradictions between sources, and builds a web of connections. A single new source document might touch 10 to 15 wiki pages, updating some, creating others, and adding backlinks throughout. After each ingest, verify the master index updated. Open `wiki/index.md` and confirm the new articles appear. If something is missing, the LLM likely created the article but forgot the index entry. A quick prompt fixes it. ### Querying your knowledge base With enough compiled material, roughly 30 or more wiki articles, the system starts producing answers you could not get from searching your notes manually. The LLM reads the master index, identifies relevant topic wikis, opens those index files, reads the articles, follows backlinks to related concepts, and synthesizes an answer grounded in your compiled knowledge. Simple queries work as you would expect. More interesting are compound queries that cross topic boundaries: "How does concept A in my machine learning wiki relate to pattern B in my systems design wiki?" The LLM follows the link structure and finds connections that would take a human researcher hours to piece together. ``` # Simple query — pulls from a single topic wiki What are the main quantization techniques for running LLMs on consumer hardware? # Compound query — crosses topic boundaries How do the caching strategies in my web-frameworks wiki compare to the KV-cache optimizations described in my ml-inference wiki? Are there architectural patterns that apply to both? # Output-format query — generates a file instead of a chat response Create a Marp slide deck summarizing the top 5 findings from my ml-inference wiki. Save it as wiki/ml-inference/slides-overview.md so I can present it in Obsidian. ``` The compounding trick: after the LLM answers a complex query, tell it to file the answer back into the wiki as a new article. That synthesis becomes a permanent, indexed document. Future queries can reference it. Every exploration adds to the knowledge base rather than disappearing into chat history. You can also request non-text output formats. Karpathy mentions generating [Marp](https://marp.app/?ref=implicator.ai) slide decks from wiki content and matplotlib charts for data visualization. Both get saved as files in the vault and viewed directly in Obsidian. ### Running health checks A knowledge base without maintenance rots quickly. Stale claims persist. New articles lack backlinks to related concepts. Contradictions between sources go unnoticed. The solution: periodic LLM health checks that work like linting for knowledge. ``` # Prompt to trigger a health check in Claude Code: Run a full lint pass on the wiki. Check for: 1. Contradictions — two articles claiming different things about the same concept 2. Orphan pages — articles with zero inbound links from other articles 3. Missing backlinks — articles that mention a concept with its own page but don't link to it 4. Stale claims — anything referencing a version number or date that may be outdated (flag for manual review) 5. Data gaps — concepts mentioned 3+ times across articles that don't have their own dedicated page yet 6. Index integrity — every entry in every index.md must point to a file that actually exists For each issue, tell me: the file, the problem, and your suggested fix. Don't fix anything yet — just report. ``` Run health checks after every significant batch of new material and at least weekly for active research topics. The LLM flags orphan pages, identifies contradictions between wiki articles, finds concepts mentioned repeatedly but lacking their own dedicated page, and suggests gaps where a web search could fill in missing information. The lint step also keeps the index files accurate. Over time, article titles change, topics split, and old pages get superseded. The health check catches index entries pointing to moved or deleted files. One pattern worth adopting: create a `log.md` file at the vault root. Have the LLM append a timestamped line after every ingest, query, and lint pass. Three months in, some wiki claim will look wrong, and you will want to know where it came from. Grep through `log.md`, find the ingest date, done. ### Common mistakes and how to avoid them **Skipping the schema file.** Without a CLAUDE.md the LLM freelances every structural decision. One ingest creates topic folders. The next dumps everything flat. Article formats vary. Index entries get written differently each time. Write the schema first, before you ingest a single document. **Letting the LLM modify raw files.** The raw directory is your source of truth. If the LLM "cleans up" a raw file, you lose the original and can no longer verify wiki claims against the source. Your CLAUDE.md must explicitly state that raw files are read-only. ```markdown ## Critical Rule The `raw/` directory is READ-ONLY. Never modify, rename, delete, or "clean up" any file in `raw/`. If you need to annotate a source, create a wiki article that references it with `[[raw/filename]]`. ``` **Building too many small topic wikis.** Splitting "machine learning" into "supervised learning," "unsupervised learning," and "reinforcement learning" as separate top-level wikis creates fragmentation. The model has to search multiple indexes for questions that span categories. One wiki per broad research domain. Use subdirectories within it for narrower topics. Split only when a topic exceeds 80-100 articles. **Not filing query results back into the wiki.** This is the compounding mechanism. If you query and get a great synthesis but do not save it as a wiki article, that work vanishes. Add this instruction to your CLAUDE.md so the LLM does it automatically. **Trusting wiki content without checking sources.** The LLM will sometimes hallucinate connections between concepts or misinterpret a raw source. Every wiki article links back to the raw files it drew from. When a wiki claim matters for a real decision, click through to the source and verify. The system makes verification straightforward. The checking is still on you. ### What to explore from here Three directions. First, [qmd](https://github.com/shopify/qmd?ref=implicator.ai), the local markdown search engine built by Shopify CEO Tobi Lutke, which adds hybrid BM25 and vector search to your vault without cloud dependency. Second, multi-agent setups where separate LLM agents handle ingest, querying, and linting in parallel, useful once your wiki exceeds 50 articles. Third, Karpathy's forward-looking idea: once your wiki is mature and well-linted, use it as training data to fine-tune a smaller model that "knows" your research domain in its weights rather than through the context window. IV — MECHANICS ## The compilation is the product Retrieval and compilation are not synonyms, and the gap between them explains why this pattern produces better answers than RAG for small and medium knowledge bases. In a standard RAG pipeline, you chop documents into chunks. Those chunks get converted to mathematical vectors and parked in a specialized database. Ask a question, and the system runs a similarity search, feeding the closest-matching chunks into the LLM. The model answers from fragments it has never seen in context together. Search "performance optimization in React" and the top chunks might mention those words in a passing sentence rather than the paragraph that actually walks through the fix. That is retrieval noise, and anyone who has built a RAG system has fought it. Karpathy's system inverts the sequence entirely. The LLM reads every source document during compilation, not at query time. It identifies core concepts, writes explanations, notes where sources contradict each other, and builds a web of connections. The result is a compiled knowledge layer sitting between you and the raw material, optimized for the LLM's own future consumption. Summarization loses detail. Compilation restructures information into a consistent format that preserves key specifics while adding cross-references and resolving conflicts. The LLM acts as a knowledge compiler, turning source material into a representation that a future query can consume efficiently. [LM Market Cap's analysis](https://lmmarketcap.com/reports/llm-knowledge-bases-karpathy?ref=implicator.ai) put it precisely: "different representation, same semantics." Like a C compiler transforming source code into machine code. Output shrinks. Density goes up. But the information survives the transformation. Below roughly 400,000 words, full-context querying beats chunk-based retrieval every time. You get perfect recall because the model sees everything simultaneously. Cross-references, contradictions, and implicit connections that RAG would miss become visible. One X user turned 383 scattered files and more than 100 meeting transcripts into a compact wiki and [dropped token usage by 95%](https://www.youtube.com/watch?v=sboNwYmH3AY&ref=implicator.ai) when querying with Claude. The math is persuasive. And the compilation itself becomes a compounding asset. Every new source enriches existing articles. Every query deposits new synthesis. Every lint pass catches decay before it spreads. RAG systems are amnesiac by design: they forget every answer the moment the session ends. The wiki remembers. The system six months from now is categorically richer than the one you build on day one. Karpathy sensed the commercial potential and stated it plainly: "There is room for an incredible new product instead of a hacky collection of scripts." He called his own implementation a "hacky collection of scripts" without irony. The architecture works. The packaging does not yet exist. V — DISTRIBUTION ## The idea file changes how knowledge moves The follow-up gist may prove more significant than the wiki pattern itself. Karpathy introduced a concept he calls an "idea file." 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 and builds it for your specific needs." That is a claim about distribution, not productivity. Traditionally, a developer shares an implementation. A GitHub repo, maybe a Docker image. The recipient uses the code as-is or forks it. Packaging a useful tool for someone else's environment often takes more effort than building the original. So most useful tools never get shared at all. The idea file flips this. You share the concept, specific enough to be actionable, loose enough that any coding agent can fill in the implementation. Karpathy uses Obsidian on macOS with Claude Code. You might run VS Code on Linux with Codex. The idea file gets pasted into your agent, and your agent builds a version customized to your exact setup. 5,000+ GitHub stars on a gist with zero executable code Glen Rhodes, a tech commentator who writes about developer workflows, [called the shift clearly](https://glenrhodes.com/andrej-karpathys-idea-file-concept-shifts-the-shareable-unit-from-code-to-concept-in-the-llm-agent-era/?ref=implicator.ai): "The repo was the right unit for a world where humans did the implementation. If agents are doing more of that work, the idea is the right unit." Five thousand GitHub stars on a gist containing zero executable code. That metric is not a popularity contest. It is evidence that the distribution model for technical knowledge is changing in real time, and the developer community feels emboldened by the shift. Sharing concepts instead of artifacts removes the friction that kept most useful tooling locked inside individual setups. VI — ECOSYSTEM ## Claude Code, Codex, and the ecosystem that formed overnight Karpathy built his system with Claude Code and Obsidian. But his gist was deliberately agent-agnostic. "This is an idea file," it begins, "designed to be copy-pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.)." Two major paths lead to the same result. **Claude Code** runs locally in your terminal with direct file system access. It reads, writes, searches, and traverses markdown files on your machine without an intermediate API. The schema lives in CLAUDE.md at the vault root. Claude Code handles ingestion, compilation, querying, and linting within a single session. Your data stays on your hard drive. No cloud dependency after authentication. **OpenAI Codex** uses a cloud-based execution model with an [AGENTS.md schema file](https://developers.openai.com/codex/skills?ref=implicator.ai) and a skills system where tasks are defined as SKILL.md files in named directories. Codex reads AGENTS.md at the repository root for project context and uses progressive disclosure, loading skill instructions only when it decides to use them. You get lower local resource consumption. You also get network latency and a dependency on OpenAI's infrastructure. Both work with the same three-layer structure. Same inputs, same outputs, same ingest-query-lint cycle. The configuration files differ in format, not function. But the ecosystem response is where the real energy went. Within days: [SwarmVault](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?ref=implicator.ai) launched as an open-source TypeScript CLI implementing the full pattern: persistent markdown wiki, knowledge graph with community detection and confidence-scored edges, local search index. Works across OpenAI, Anthropic, Gemini, and Ollama backends. [llm-wiki-agent](https://github.com/SamurAIGPT/llm-wiki-agent?ref=implicator.ai) added automatic entity and concept page creation. Every person, company, or project mentioned across sources gets its own page, updated with each new ingest. A living overview document revises itself continuously. [obsidian-wiki](https://github.com/Ar9av/obsidian-wiki?ref=implicator.ai) shipped multi-agent support from day one, providing ready-made skill files for Claude Code, Codex, Cursor, and Windsurf. It introduced tiered retrieval: read titles and tags first, only open full page bodies when the cheap pass can't answer. Keeps query cost roughly flat as the wiki grows. [COG-second-brain](https://github.com/huytieu/COG-second-brain?ref=implicator.ai) combined the LLM wiki pattern with Zettelkasten and GTD methodologies. Seventeen Claude Code skills, Kiro powers, Gemini CLI commands, and full Codex support, all shipping in the same repository. "Just .md files that think," the README says. And then there is [qmd](https://github.com/tobi/qmd?ref=implicator.ai). The reason it matters has everything to do with who built it. Tobi Lutke, CEO of Shopify, wrote a local search engine for markdown files. It combines BM25 keyword search, vector embeddings, and LLM re-ranking. All of it runs on-device. It works as a CLI tool or as an MCP server that Claude Code can query natively. Karpathy mentions qmd in his gist as the tool for when your wiki outgrows simple index-file navigation. 95% token usage reduction after compiling 383 files into a wiki When the CEO of Shopify builds a local markdown search engine and publishes it on GitHub, the pattern has crossed from personal hack into something structurally interesting. Lutke and Karpathy are not collaborating. They arrived at the same architectural conclusions independently, from different directions, and published tools that snap together. VII — SOVEREIGNTY ## Markdown as data sovereignty Karpathy chose markdown deliberately. The choice carries an argument most people skip over. Every piece of knowledge in the system lives as a plain text file on the user's own machine. No database queries. No proprietary format. No cloud dependency. Obsidian could vanish tomorrow. The files would still open in VS Code, Vim, or any text editor built in the last four decades. This is not incidental to the design. It is the design. Karpathy's gist draws a line back to 1945 and [Vannevar Bush's essay "As We May Think,"](https://aiia.ro/blog/karpathy-llm-wiki-knowledge-base/?ref=implicator.ai) which described the "Memex": a personal knowledge store with associative trails between documents. Bush imagined a mechanical desk storing microfilm. Eighty-one years later, the LLM wiki is closer to his vision than anything the web actually produced. The web gave us links but not synthesis. Not maintenance. Not the associative trails connecting ideas across documents. Karpathy's system does all three, with the LLM handling the bookkeeping labor that made every previous attempt at manual knowledge bases collapse under its own weight. And here is the line that separates this from the SaaS knowledge management tools: in the Karpathy pattern, the user owns the data. The AI is a skilled editor that visits the files to do work and then leaves. It is not a platform holding your information behind an API and a monthly fee. Sync a markdown vault through Git or Syncthing and you get version history, offline access, zero vendor lock-in. No terms of service can retroactively change what happens to plain text files sitting on a hard drive you own. The "file-over-app" philosophy rattles companies already anxious about AI data handling. It also creates a trust problem that Ango's contamination warning addressed directly. Agent-generated content is a different animal from human-curated content. Mix the two without clear boundaries and confidence in the knowledge base starts to bleed away. The solution is architectural: separate vaults or at minimum separate directories with explicit provenance. Every wiki article links to the raw source files it drew from. When a claim matters for a real decision, you click through and verify. That verification remains a human job. The LLM will sometimes fabricate connections between concepts or misread a source. Community consensus, expressed across dozens of comment threads in the days following Karpathy's post, landed on a single rule: every wiki article must include a Sources section linking to raw files. Without traceability, you are trusting the compiler without checking its output. The system makes checking straightforward. But the checking? Still on you. VIII — LIMITS ## The honest ceiling Karpathy's system does not scale to enterprise use. He acknowledges this openly. Enterprise RAG vendors like [Epsilla published detailed rebuttals](https://www.epsilla.com/blogs/llm-wiki-kills-rag-karpathy-enterprise-semantic-graph?ref=implicator.ai) within 48 hours, and their core argument holds: running a company's collective intelligence on a local folder of markdown files creates operational, security, and governance gaps that no schema file can fix. No role-based access control. No concurrent editing protocols. No audit trail beyond git history. No path to millions of documents. Any mid-sized company's internal knowledge base dwarfs what a solo researcher builds. Honest scale limit: 100 to 400 articles, roughly 400,000 words on a single domain. Push past that and the LLM starts losing threads, especially when index files grow long and backlinks form dense networks that exceed what the model can track in a single session. At that point, proper retrieval infrastructure earns its complexity. But that ceiling covers an enormous amount of real work. Personal research projects. Competitive analysis. Investment due diligence. Course notes. Book companion wikis. Team knowledge bases for groups of five or ten. Health tracking. Trip planning with cross-referenced logistics. For individual knowledge workers, the honest question isn't whether the ceiling applies. It probably doesn't. The question is whether the compounding effect justifies the setup cost, which amounts to roughly one afternoon and zero dollars in infrastructure. Product Peak's Aleksander Dytko [identified the line](https://productpeak.substack.com/p/the-one-line-from-karpathys-post) everyone else scrolled past: "My own explorations and queries always add up in the knowledge base." That is Karpathy's single most important sentence, buried near the end of the original thread. Most AI workflows bleed information. You ask, get an answer, and the answer leaks out through the floor of your chat history. Gone. The LLM wiki is accretive. Every query deposits synthesis. Every source enriches what already exists. The difference compounds over months into a categorical advantage. A hybrid approach makes practical sense for anyone bumping against the ceiling. Use full-context wiki querying for active projects and current research, the "hot" knowledge that changes weekly. Use RAG for cold archives that rarely update. The two architectures serve different segments of the same knowledge pipeline, and switching between them costs nothing when your data is already markdown. ## The library and the librarian Karpathy did not build a tool. He named a workflow that thousands of people had been approximating for months and packaged the concept in a form that any LLM agent can implement in an afternoon. The resonance is not really about Obsidian. Any markdown editor works. It is not about Claude Code specifically. Any file-system-aware agent works. It is not even about Karpathy, though his credibility as the person who coined vibe coding and co-founded OpenAI gave the pattern immediate authority. Three structural shifts converged. Context windows grew large enough to hold personal knowledge bases in a single prompt. Coding agents gained persistent file system access. Markdown solidified as the format both humans and LLMs read natively. Those facts existed separately for months. Karpathy was the person who connected them, named the result, and published an "idea file" that let anyone replicate it within hours. The distinction between a chatbot and a librarian matters for anyone doing sustained intellectual work. A chatbot answers questions and forgets. A librarian builds the collection. Compiles it, cross-references it, maintains it, makes it better over months and years. The collection persists between sessions. The answers feed back. The system grows without manual upkeep, because the LLM handles the bookkeeping that defeated every previous attempt at personal knowledge management. Zettelkasten. Wikis. Notion databases. They all collapsed because the maintenance burden grew faster than the value. LLMs don't get bored. They don't forget to update a cross-reference. They can touch 15 files in a single pass. The "idea file" concept may outlast the wiki pattern itself. Sharing concepts rather than artifacts, intent rather than implementation, changes how technical knowledge moves through communities. And the communities are already moving. The gist with zero code and 5,000 stars proved the model works. Karpathy pointed at a folder of plain text files on a laptop screen and said: that is the product. No servers. No infrastructure bill. Just a directory, an agent, and the discipline to file every answer back where it came from. The compounding starts the day you build it. ## What to watch **Obsidian** Whether the company ships first-party LLM integration before the plugin ecosystem makes it redundant. Ango's contamination mitigation response signals awareness, but Obsidian's local-first philosophy may resist built-in cloud AI features. Watch for announcements at their next product update. **Context window pricing** Full-context wiki queries consume significant tokens each session. If Anthropic or OpenAI introduce tiered pricing for sustained high-token workloads, the cost math shifts toward hybrid wiki-plus-RAG approaches. Current pricing makes sub-500K-word wikis economical. That could change. **qmd and local search tools** Lutke's hybrid search engine bridges the gap between simple index files and full RAG infrastructure. If Claude Code's MCP integration makes qmd a default tool in agent workflows, the wiki's effective scale ceiling rises substantially. **The product gap** Karpathy said the quiet part out loud: "incredible new product." Multiple startups are positioning. First to ship reliable auto-ingestion, scheduled health checks, and a polished query interface captures a market that doesn't have a name yet. **Fine-tuning from wiki data** Karpathy's forward-looking idea of using a mature, well-linted wiki as training data for a personalized model. If this path proves viable, the personal knowledge base becomes a training dataset, and the LLM stops reading your wiki from context and starts knowing it in its weights. ### Key Takeaways - **Compilation over retrieval:** The LLM reads sources during ingestion and writes structured wiki articles, producing perfect recall at query time without vector databases or embedding pipelines. - **Schema is the real product:** A well-specified CLAUDE.md or AGENTS.md file turns a generic agent into a disciplined librarian. Vague schemas produce inconsistent, fragmented wikis. - **Compounding beats searching:** Every query, every new source, and every lint pass makes the wiki richer. RAG systems forget between sessions. The wiki remembers and grows. - **Ecosystem velocity signals real demand:** Five major open-source implementations launched within a week. Shopify's CEO independently built the complementary search tool. This pattern has legs. - **Enterprise ceiling is real but irrelevant for most:** The 400K-word limit excludes Fortune 500 knowledge bases. It covers essentially every solo researcher, analyst, and small team. - **Ideas as distribution format:** The "idea file" concept, sharing portable concepts instead of code repositories, may prove more disruptive than the wiki pattern itself. - **Data sovereignty by default:** Plain markdown files on local storage, synced via Git, with zero vendor lock-in. The user owns every byte. ### Sources & Further Reading #### Primary Sources - [LLM Wiki (idea file)](https://impli.me/BV2IrP?ref=implicator.ai) \-- Andrej Karpathy, GitHub Gist, April 2026 - [Karpathy shares 'LLM Knowledge Base' architecture](https://impli.me/oGFuld?ref=implicator.ai) \-- VentureBeat, April 2026 - [Why should you create personal knowledge bases?](https://impli.me/WgmTDg?ref=implicator.ai) \-- The Economic Times, April 2026 #### Analysis & Commentary - [Karpathy's LLM Knowledge Bases: The Post-Code AI Workflow](https://impli.me/j1j3Aa?ref=implicator.ai) \-- Antigravity.codes, April 2026 - [The Complete Guide to Karpathy's Idea File](https://impli.me/v6l88P?ref=implicator.ai) \-- Antigravity.codes, April 2026 - [LLM Knowledge Bases: Karpathy's Self-Improving Second Brain](https://impli.me/utUfsW?ref=implicator.ai) \-- LM Market Cap, April 2026 - [The Shareable Unit Just Changed](https://impli.me/z8TVXz?ref=implicator.ai) \-- Glen Rhodes, April 2026 - [Did Karpathy's LLM Wiki Kill RAG? The Enterprise Verdict](https://impli.me/cpZQil?ref=implicator.ai) \-- Epsilla, April 2026 - [The One Line from Karpathy's Post That Actually Matters](https://impli.me/sCdZqK?ref=implicator.ai) \-- Product Peak, April 2026 - [LLM Knowledge Bases](https://impli.me/dYGyvS?ref=implicator.ai) \-- DAIR.AI Academy, April 2026 #### Tools & Implementations - [qmd: Local search engine for markdown](https://impli.me/9K3Xqg?ref=implicator.ai) \-- Tobi Lutke, GitHub - [llm-wiki-agent](https://impli.me/KmFjnH?ref=implicator.ai) \-- SamurAIGPT, GitHub - [obsidian-wiki: Multi-agent wiki framework](https://impli.me/K2b6Ps?ref=implicator.ai) \-- Ar9av, GitHub - [Codex Agent Skills](https://impli.me/5ClX8B?ref=implicator.ai) \-- OpenAI Developers Frequently Asked Questions How many documents can the LLM wiki handle before performance degrades? Karpathy reports roughly 100 to 400 articles, about 400,000 words on a single domain. Beyond that, the LLM loses its ability to track connections reliably through index files and backlinks. At that scale, proper retrieval infrastructure like vector search becomes necessary. Does this only work with Claude Code, or can I use other coding agents? The architecture is agent-agnostic. Karpathy's gist explicitly supports Claude Code (CLAUDE.md), OpenAI Codex (AGENTS.md), OpenCode, and others. The obsidian-wiki framework ships ready-made skill files for Claude Code, Codex, Cursor, and Windsurf. What is the difference between this and traditional RAG? RAG chops documents into chunks and retrieves fragments at query time. The LLM wiki compiles raw sources into structured articles during an ingestion step, creating a persistent knowledge layer the model can query with perfect recall. RAG forgets between sessions. The wiki compounds. Do I need Obsidian specifically, or will any markdown editor work? Any markdown editor works. Obsidian is popular because of its graph view, backlink support, and Web Clipper extension for easy ingestion. But VS Code, Typora, iA Writer, Logseq, or even Vim handle the same files. The wiki is just a folder of .md files. What is an 'idea file' and why does it matter? Karpathy published his LLM Wiki pattern as a concept description rather than working code. The idea is that in the agent era, you share the concept and the recipient's LLM agent builds a customized implementation. Five thousand GitHub stars on a gist with zero code suggests this distribution model is gaining traction. AI-generated summary, reviewed by an editor. [More on our AI guidelines](https://www.implicator.ai/about/). [Karpathy Says AI Coding Agents Made Programming 'Unrecognizable' Since DecemberAndrej Karpathy, the former Tesla AI chief and OpenAI co-founder, said Wednesday that programming has changed more in the last two months than in decades, arguing that AI coding agents "basically didnThe Implicator![](https://www.implicator.ai/content/images/2026/02/2026-02-26-07.02.24-empty_chair_code@2x.webp)](https://www.implicator.ai/karpathy-says-ai-coding-agents-made-programming-unrecognizable-since-december/) [Anthropic's Cowork Strips the Developer Costume Off Claude CodeSimon Willison has been saying it for months. Claude Code, the terminal-based agent that Anthropic marketed to programmers, was never really a coding tool. It was a general-purpose agent that happenedThe Implicator![](https://www.implicator.ai/content/images/2026/01/2026-01-12-16.54.20-claude_cowork_anthropic@2x.webp)](https://www.implicator.ai/anthropics-cowork-strips-the-developer-costume-off-claude-code/) [GitHub won't compete on agent quality. It's building the layer beneath all of themAt Universe 2025, the Microsoft-owned platform announced Agent HQ—a unified control plane for managing coding agents from Anthropic, OpenAI, Google, Cognition, and xAI alongside its own Copilot. The aThe Implicator![](https://www.implicator.ai/content/images/2025/10/2025-10-29-05.17.49-github_1@2x.webp)](https://www.implicator.ai/github-wont-compete-on-agent-quality-its-building-the-layer-beneath-all-of-them/)