Learning systems
I stopped collecting notes. Claude helped me compile knowledge.
How Karpathy’s LLM Wiki pattern, an Obsidian vault, and a small set of maintenance rules made my learning easier to organise, connect, and retrieve.
My personal knowledge base did not become messy because I stopped writing. It became messy because I kept writing—without a reliable way to file new ideas, connect them to old ones, or find the useful thread later.
Articles, videos, technical notes, and half-formed questions accumulated faster than I could maintain a taxonomy for them. Capture felt productive in the moment. A few weeks later, retrieval depended on remembering the title, the folder, or the exact words I had used. The information existed, but the context around it had decayed.
The setup I use now gives the maintenance work to Claude, keeps the resulting knowledge in plain Markdown, and lets me inspect the connections in Obsidian. Git records how the wiki changes. I have not timed this against my previous workflow, so I cannot claim a percentage improvement. What I can say is simpler: returning to something I have already learned feels much faster and less frustrating.
Writing was easy; maintenance was the tax
A new note rarely belongs to only one subject. A lesson about queues might also be about backpressure, failure recovery, and product latency. Putting it into one folder hides the other relationships. Adding every possible tag and link manually turns a short learning session into clerical work.
The difficult jobs begin after capture: decide what the source changes, update an old summary, link related concepts, record a contradiction, and leave enough structure for a future question. Those jobs are small, repetitive, and easy to postpone. Once enough of them are postponed, the knowledge base becomes an archive rather than a working memory.
The bottleneck was never saving information. It was keeping the relationships alive.
This distinction changed what I wanted from the tool. I did not need another place to type. I needed a maintainer that could read the new source in the context of what was already there.
My first design put Claude in front of Notion
My initial plan was reasonable: connect Claude to Notion through MCP, paste in a source, and ask Claude to refine it, place it in the right section, and connect it to related material. Anthropic’s MCP documentation describes this general capability—connected servers let Claude read from and act on external systems instead of depending only on pasted chat context.
I did not abandon that idea because Notion could not support organised knowledge. The boundary simply turned out to be less natural for how I wanted to work. I wanted the durable artifact to be a set of files I could inspect with ordinary tools, diff with Git, edit without an integration, and give directly to a coding agent.
Then Mrityunjoy Das introduced me to a post about using Andrej Karpathy’s LLM Wiki idea with Obsidian. That gave the problem a better shape. Instead of asking the model to tidy a notebook, I could treat the knowledge base as a small codebase: sources go in, a schema governs the work, and linked Markdown pages come out.
The LLM Wiki changes the unit of work
In Karpathy’s LLM Wiki idea file, the model does not rediscover everything from raw documents for every question. It incrementally compiles sources into a persistent, interlinked wiki and maintains that artifact as new material arrives.
The pattern separates three responsibilities:
- 01Raw sources preserve evidence
Articles, notes, transcripts, and other inputs remain unchanged so a generated summary can always be checked against its origin.
- 02The wiki preserves synthesis
Claude creates and updates linked concept pages, summaries, comparisons, indexes, and the other forms that make accumulated knowledge browsable.
- 03The schema preserves discipline
A project instruction file defines where information belongs, how links and citations work, and what Claude must do during ingestion, retrieval, and maintenance.
Obsidian fits this pattern because a vault is a folder of Markdown-formatted plain-text files. Its internal links, backlinks, and graph views expose relationships without turning the underlying notes into a proprietary database. Obsidian is the reading and navigation surface; the files remain usable without it.
The working loop I customised
I kept Karpathy’s core separation, then adapted the routine to the way I learn. The exact folder names matter less than the contract between the layers. A small version might contain immutable source material, generated wiki pages, an index, an append-only activity log, and a CLAUDE.md file describing the rules.
- 01Capture the source
I add the material I learned from rather than saving only my first interpretation of it.
- 02Ask Claude to ingest it
The task is to extract useful ideas, update existing pages, create missing concepts, and preserve references—not merely produce a summary.
- 03Review the connections
I browse the changed pages and their backlinks in Obsidian, where unexpected hubs and isolated notes are easy to notice.
- 04Leave food for thought
I ask Claude to add follow-up questions: uncertainties to resolve, adjacent ideas to explore, and claims that deserve another source.
- 05Commit the artifact
Git gives me a reviewable history of what Claude changed and a recoverable point before the next ingestion.
The follow-up questions are the customization I value most after retrieval. A normal summary tends to close a topic. A good question keeps it active. It turns the wiki from a storage system into a queue of possible learning directions.
My ingestion rule
Do not ask only “What does this source say?” Also ask “Which existing idea does this strengthen, challenge, or leave unresolved?” The first question creates a note. The second improves the knowledge base.
Retrieval is where the system earns its keep
The most useful moment happens later. I ask Claude about something that already exists in the vault. Instead of manually opening folders and reconstructing the trail, Claude can inspect the index, search likely pages, follow their links, read the relevant sources, and bring the context back into one answer.
This is more useful to me than receiving another generic explanation from scratch. The answer can reflect the material I chose to preserve, the connections already made, and the questions I left open. When a query produces a genuinely useful comparison or synthesis, that result can become a candidate page for the wiki rather than disappear into chat history.
I describe this as faster retrieval because that is how it feels in daily use, not because I ran a timed experiment. The deeper improvement is continuity. I spend less effort rebuilding the context of an old learning session before I can ask the next question.
What improved—and what “productivity” means here
This system does not help me learn by consuming more material. It helps by reducing the maintenance and rediscovery surrounding the material I already chose. The benefit appears in several connected places.
- Scattered inputs become organised material: Claude applies the same schema during each ingestion.
- Relationships survive capture: related concept pages and backlinks are updated while the source is still in context.
- The graph exposes structure: Obsidian makes hubs, clusters, and orphan notes visible enough to investigate.
- Old learning becomes easier to resume: Claude can retrieve a small connected slice instead of asking me to reopen everything.
- Changes remain inspectable: Git shows what was added, rewritten, or removed and provides a recovery path.
- Questions accumulate alongside answers: “Food for thought” gives the next learning session a useful starting point.
The graph is not the goal, and a large number of links is not a quality metric. The graph is valuable when it reveals a missing relationship or makes navigation easier. A beautiful hairball of weak connections is still a weak knowledge base.
A generated wiki can compound mistakes too
An LLM-maintained wiki creates a new failure mode: an unsupported synthesis can be written down, linked from several places, and later retrieved as if it were established knowledge. Summaries can remove an important qualification. A stale page can survive after a newer source contradicts it. Automation lowers maintenance cost, but it does not remove the need for provenance.
I use several boundaries to keep the convenience honest:
- Keep raw sources unchanged and link generated claims back to them.
- Review meaningful diffs before treating a new synthesis as durable knowledge.
- Record contradictions instead of asking Claude to silently choose a winner.
- Run periodic maintenance for stale, duplicate, weakly sourced, or orphaned pages.
- Do not file an answer back into the wiki when retrieval found no confident support.
Local Markdown also needs a privacy footnote. The vault lives on my machine, but that does not automatically make every processing step local. If a cloud model reads a note, its content leaves the local editor according to that provider’s data path and settings. MCP connections add another trust boundary, and Anthropic specifically warns that servers fetching external content can introduce prompt-injection risk. Sensitive sources therefore need deliberate model, permission, and connector choices.
Start with one domain and one retrieval question
A useful LLM Wiki does not need a grand taxonomy on day one. Start with a subject you revisit, a small set of real sources, and one question you expect the system to answer later. Define the source boundary, wiki rules, index, and review process before adding automation around everything else.
Ingest a source, inspect the pages, ask a question, and look at what Claude had to guess. Those guesses are feedback for the schema. Add conventions only when a real failure makes them necessary. Karpathy’s idea file is intentionally modular; the useful implementation is the one that evolves around your material and your way of thinking.
A note becomes valuable twice: when it captures an idea, and when it helps answer the next question.
Claude, Obsidian, and Git did not remove the work of learning. They changed where I spend that work. I can focus more on choosing sources, challenging the synthesis, and asking better questions—and less on remembering which folder contains the thought I need.