Why Your Second Brain is Dead Weight

Your Notes Aren't the Bottleneck

On April 2, 2026, Andrej Karpathy published a GitHub gist called llm-wiki and tweeted about it. Inside 5 days, the tweet had millions of views, and the gist crossed 5,000 stars. Forks multiplied. A dozen Substack writers sketched variations before the weekend was out. It is probably the most-read knowledge management idea of the year.

The idea: instead of feeding an LLM a bundle of raw notes at query time (classic RAG), you give it a schema file and a folder of sources, and let it maintain a wiki as a first-class artifact. The model does all the reading and writes the entries, and keeps the cross-links current. The job (should you choose to accept it) is adding sources and curating the schema. By Karpathy’s count, his own wiki reached about 400,000 words across roughly 100 articles.

The pattern removes the single worst failure mode of a decade of knowledge tooling, which was assuming the human would come back to process the clippings. Humans don’t process them. They clip and move on. The wiki pattern takes the human out of the loop at the step they were always going to fail, and hands that step to a system that doesn’t get tired and doesn’t get bored.

If a company already has a defined corpus, this is (sort of) an upgrade.

A research lab with a subfield, an engineering org with an internal codebase, a legal team with a closed archive of precedent: all of them can deploy the same pattern with a few tweaks.

For most operators in 2026, it imports a bet from 2020 that the world has already outrun.

The caveat: Karpathy is a great deal smarter than most of the people writing about this stuff. Disagreeing with him in print is brave or dumb depending on the replies.

The bet is that value lives inside the archive. This was obviously true in Ye Olden Dayes. Models couldn’t browse the internet, retrieval was brittle and slow, and the public web was outside the model’s reach at query time. If you wanted an LLM to say anything useful about your specific world, you had to dam up a little pond of your own sources so it could swim in it.

Every knowledge tool built before 2023 rests on that bet. Notion AI. Confluence semantic search. The internal wiki line item at every Series B company in a typical portfolio.

But we’re in a world where Claude can read Wikipedia in real time, pull down an arXiv paper in seconds, and summarize any URL thrown at it before the coffee cools. It can weave six disconnected domains into a single answer. The pond is irrelevant when the model is already swimming in the ocean.

So the first question to ask about any new knowledge architecture in 2026, Karpathy’s included, is: what specifically does our archive contain that the open web doesn’t?

The marketing team’s folder of clipped HBR articles? Claude can read HBR. The strategy deck citing Kahneman? The model has read Kahneman multiple times, in translation and out of it. The shared Readwise export from the leadership offsite? 99% of it is other people’s writing that the model has better access to than the team does, with no random paste errors from someone’s phone. The internal best-practices wiki built off public blog posts? Every entry has 40 better-written versions on the open web.

What’s actually proprietary and not in the training set? Customer call transcripts. Contracts and SOWs. Pricing models and the live deal pipeline. Account histories and renewal dates. The decisions leadership made and the reasoning behind them. Working files on current projects. The post-mortems nobody publishes.

This list fits in one folder per business unit. Measured in gigabytes, openable in any plain-text editor. It needs no graph view, no bi-directional links, no AI-powered semantic search plugin, no monthly feature release.

Which is almost certainly why nobody is selling it.

The enterprise knowledge market has done a clever thing with this asymmetry. It takes the one set of materials LLMs can’t help with (the company’s private decision history) and bundles it with the hundred sets they don’t need help on at all (public writing, general knowledge, every Substack the team subscribes to) and then charges per seat for the privilege of confusing the two. A mid-market company’s stack of Notion, Confluence, Glean, Readwise, and a transcription service will run a six-figure annual line item. Most of what those tools hold is content the model could fetch free on demand.

Elegant as it is, Karpathy’s pattern inherits the same problem. Its architecture assumes the company will be feeding it a meaningful corpus. For most operating businesses, where the “knowledge base” is 90% public reference material and 10% real proprietary signal, the pattern gets the ratio backwards. The compute goes to beautifully cross-referenced wiki entries about material the model has already read a hundred times, and almost none of it goes to the handful of decisions leadership needs to get right this quarter.

Which brings me to the test every knowledge tool has to pass in 2026: does it help anyone in the building decide anything Monday morning when the week starts?

The bottleneck for an operating business is judgment plus a willingness to ship without a 40-slide deck. The team has read plenty already, and no internal wiki fixes that. Claude doesn’t fix it either, although Claude at least talks back when the strategy doc is staring at a blank page. A wiki is a read-only companion for work the org is avoiding. With the proprietary folder attached, a model in a browser tab is a working colleague for work the org is in the middle of doing.

The test of any knowledge system has always been retrieval. Capture is the cheap part. Clip and forward, dictate and transcribe.

Capture scales with guilt, and retrieval scales with need.

For most of the companies I’ve watched build these systems, the ratio between capture and consultation is catastrophic. I’ve lost count of how many beautiful internal wikis I’ve sat through where the leadership team can’t point to a single page from the last 6 months that changed what they did next.

We underestimate how much a well-maintained archive reshapes the org’s reading. The team starts reading for what can be filed, and stops reading for what could disturb the strategy. The archive domesticates institutional attention over time, and Karpathy’s wiki pattern will accelerate this, because the feedback loop is tighter. You can watch the model generate an entry and feel the pleasant chemical hit of having “captured” the source.

The obvious counter is that the wiki externalizes the boring parts, freeing leadership to think about the rest. But is externalizing the boring parts, at scale, actually worth the compute and the attention overhead? For a research lab, probably. For a company trying to keep 6 enterprise customers happy and ship a product this quarter, the overhead is larger than the savings, because the private part (the part that actually needs a system) was never the bottleneck.

What does a 2026 setup look like when you take all this seriously? A browser, a folder, a plain-text decision log, and an API key per team.

The browser runs a small number of tabs. One holds the model. One holds the work in progress. One holds whatever source is currently being read. A fourth, if needed, holds a dated decision log. Ask the model when information is needed. Write the decisions and the reasoning behind them in the log. Whoever inherits the seat next year will want to read what the previous occupant was thinking, because decisions compound when you can see them.

The folder holds the proprietary material. Project files. Contracts and SOWs. A running log of customer calls. A scratch document per active deal. A WHAT file for the handful of things the company can’t afford to forget. The whole thing in plain text or markdown, because plain text survives format changes, vendor lock-in, and the next migration.

Much of the enterprise knowledge economy is an insurance policy against regret. The team saves the article because one day someone might want it. The CFO renews the subscription because one day someone might go back. But one day rarely arrives. Meanwhile, the model in the other tab will find that article in 4 seconds and produce a better summary than the one a junior analyst highlighted at 11pm on a flight. The fear of losing access to a version of the company that read something once is a residue from an older world, before models that could fetch anything.

By my observation, the operators who ship the most work in ways that look embarrassingly primitive. Jeff Bezos ran Amazon on six-page narrative memos for twenty years and the format outlasted three CEOs of competitors. Ray Dalio kept Bridgewater’s Principles in a plain-text document long before it became a book. Charlie Munger ran the Berkshire investment thesis on a yellow legal pad and his own working memory.

If you want a small experiment, try this.

For 30 days, audit your knowledge spend. Pause the Notion Enterprise renewal. Archive the Confluence pages nobody opened. Turn off the daily highlight digest. Keep one proprietary folder per team. Keep a dated decision log. When the team needs something, ask the model and read the source. Decide and move on. Write down what got decided and why, and see what (if anything) is missed.

Most folks miss nothing except the ritual of feeling productive.

The ritual is the part that was costing six figures a year.

The org is already swimming in open water. What it needs from a model is not another archive. It needs a colleague who can read anything pointed at it and help leadership decide what to ship, and what to do on a Monday morning.

---

Selfonomics is designed, built, and backed by Studio Self

We make tech legible.

Reach out: hello@thisisstudioself.com