Karpathy's 'Second Brain' Wiki Pattern Challenges RAG Orthodoxy. 100 Articles, 400K Words, Zero Code Written.

Andrej Karpathy published a GitHub Gist proposing something that made me uncomfortable at first: replace RAG with a persistent, LLM-maintained markdown wiki that compounds over time. No vector database. No embedding pipeline. No chunk-size tuning. Just markdown files that an AI agent maintains, updates, and queries.

His personal wiki has grown to roughly 100 articles and 400,000 words since December, built entirely by AI. Karpathy didn't type code to create any of it. The LLM reads sources, synthesizes information, and maintains a growing knowledge base in plain text.

I built Rayni specifically around pgvector RAG. I've spent weeks tuning chunk sizes, overlap ratios, and reranking strategies. Karpathy's argument isn't that RAG doesn't work. It's that for personal knowledge management and research workflows, a wiki maintained by an AI is simpler, more inspectable, and compounds better. RAG retrieves. A wiki reasons about structure over time. Different tools, different affordances.

The ecosystem is already responding. Apify shipped a "Second Brain Builder" automation tool that implements the pattern. Multiple analysis pieces on Medium and Substack are calling it the future of personal knowledge management. The pattern resonates because it's accessible. You don't need to understand embeddings or vector similarity to maintain a wiki.

The skeptic in me sees limits. A 400K-word wiki fits in a single context window for frontier models. What happens at 4 million words? At 40 million? RAG's advantage is that it scales to corpus sizes that can't fit in context. The wiki pattern works for personal knowledge. I don't think it works for enterprise document stores with millions of pages.

But there's a deeper point. Most developers building RAG systems are over-engineering for their actual scale. If you have under 1,000 documents, you probably don't need vector search. A well-organized collection of markdown files with an AI that can read and update them might genuinely be simpler and more effective.

For builders: before you add a vector database to your next project, ask how many documents you're actually indexing. If the answer is under 500, try the wiki pattern first. You can always add RAG later. Going the other direction, ripping out infrastructure you already built, is much harder.