A pattern for building personal knowledge bases using LLMs.

[…]

Most people’s experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There’s no accumulation.

[…]

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources.

As a human reader, I get immense value out of online wikis (like Wikipedia) and will often not even need the actual source material for the vast majority of my searches. When reading fiction, I will frequently use book-specific wikis as supplemental reading when I’m trying to remember certain details (e.g. where else have I seen this character?). My personal knowledge base (and this site, to some degree) is an effort to build a wiki-like system, that I control, to augment my own memory. Wikis save me a lot of time.

Applying this same principle to LLM systems is a fascinating idea. Wikis (theoretically) can save a lot of tokens.

The knowledge is compiled once and then kept current, not re-derived on every query.
[…]
You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You’re in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work

Architecture

There are three layers:

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it’s what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

Operations

Ingest. You drop a new source into the raw collection and tell the LLM to process it. […]

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. […] The important insight: good answers can be filed back into the wiki as new pages. […] This way your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. […]

The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping.

[…]

The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs.

I’ve applied the concepts for this idea to one of my projects. My first attempt was a failure. It generated a wiki, but the instructions written to CLAUDE.md contained a fatal flaw: Claude would greedily consume the wiki on every query. This was filling my context window quickly. I’ve since updated those instructions and seen efficiency improvements. Plenty of room to improve, though. I plan to explore implementing a few of the operations as commands and an agent for coordination.

Another interesting idea I’ve seen around this concept: for software projects, using compiled artifacts like AST to provide the basis for the wiki. See Codesight for more details.

When I was a little boy, my first memory was this dream of falling. […] My whole life, I’ve been obsessed with the dream. But maybe it wasn’t me falling to my death. Maybe it was me flying.

Dean Potter is a near mythical figure in the world of climbing. He was famous for his daring exploits while climbing, BASE jumping, and highlining (often performing multiple at the same time). He was infamous for his disregard for tradition, safety, and the law.

From directors Peter Mortimer and Nick Rosen comes an unflinching portrait of Dean Potter, the world’s most influential and controversial climber, BASE jumper and highline walker.

The two directors behind the series are also responsible for:

• The Alpinist (2021)
• The Dawn Wall (2017)
• Founding Reel Rock (2005)

The Alpinist and The Dawn Wall are both fantastic climbing documentaries. Both are worth your time.

Now that I live in Colorado, it’s an annual tradition to attend the world premiere of Reel Rock in Boulder. The Dark Wizard will also screen at the Boulder International Film Festival on April 10.

The four-part docuseries premieres April 14 on HBO Max .

This looks to be a must-watch for climbers (or climbing enthusiasts).

Everything I do runs through Claude Code. Not just coding. My morning routine, my CRM, my content pipeline, my lead sourcing, my follow-ups. All of it.

I built a system that runs my entire business from the terminal. One command in the morning, and my whole day is laid out. I copy, paste, check boxes, move on.

At some point I stopped thinking of Claude as something I chat with and started treating it as infrastructure. That changed everything.

Don’t get me wrong, I still chat with it, but only on [Claude Code].

Anyone else gone full Claude Code for non-coding work?

I’ll have a lot more to write about this in the future, but I have been using Claude Code to help launch my business . I have a lot of experience building software but I lack experience in the other skills that are required to run your own business: managing infrastructure, product strategy & research, marketing, design, and the day-to-day details of administration. As a solo indie developer, it’s empowering to have a (semi-)reliable personal assistant that can do a little bit of everything.

I even use Claude Code to semi-automate the running of this blog. Claude has helped me:

• Write a custom Hugo theme that I’m more happy with and which allows me to drop an external dependency.
• Automate the boilerplate and grunt work required to manage a static site.
• Audit the site to catch mistakes and inconsistencies.
• Add a new linked list feature to the blog.
• Proofread my writing to catch mistakes before publishing.

Now I get to focus almost entirely on the writing.

New feature at Daring Fireball: the Linked List, a daily list of interesting links and brief commentary on DF-related topics, updated frequently but not frenetically. Call it a “link log”, or “linkblog”, or just “a good way to dick around on the Internet for a few minutes a day”.

I’ve been following Daring Fireball (by John Gruber) since 2008. I remember the days (before I learned how to use RSS) when I would repeatedly refresh the home page as I went about my day at college. In many ways, Daring Fireball is one of the (if not the) reasons I became interested in writing software for Apple platforms.

From Simon Willison’s Weblog :

I started running a basic link blog on this domain back in November 2003—publishing links (which I called “blogmarks”) with a title, URL, short snippet of commentary and a “via” link where appropriate.

[…]

I’m going to describe the informal set of guidelines I’ve set myself for how I link blog, in the hope that it might encourage other people to give this a try themselves.

Willison goes into great detail about his guidelines. My guidelines are basically:

• Something I found interesting
• Something I want to remember
• Something I want to share

Willison closes with:

Sharing interesting links with commentary is a low effort, high value way to contribute to internet life at large.

Willison’s “What to blog about” is also a must read.

Other pioneers in this space:

• Dave Winer (Scripting News , 1994)
• Jason Kottke (kottke.org , 1998)

I went to the New York Times to glimpse at four headlines and was greeted with 422 network requests and 49 megabytes of data. It took two minutes before the page settled. And then you wonder why every sane tech person has an adblocker installed on systems of all their loved ones.

I’ve been a long-time user of 1Blocker , Hush , and Vinegar to help wrangle the madness of today’s internet.

Simplified versions like text.npr.org, lite.cnn.com and www.cbc.ca/lite still exist out there. And RSS feeds do too.

For the record, a typical post on this site (no images) weighs in as follows:

At just 23 KB, that’s roughly 2,000× lighter than the home page of the New York Times. This site is built to be fast and lean.²

Some supplementary (and seething) commentary from Daring Fireball :

Even websites from publishers who care about quality are doing things on the web that they would never do with their print editions.

[…]

The web is the only medium the world has ever seen where its highest-profile decision makers are people who despise the medium and are trying to drive people away from it.

This post from Daring Fireball weighs in at a trim 157 KB, over half of which comes from the screenshot (an extremely rare inclusion on DF).

Back to Shubham Bose to close it out:

They built a system that treats your attention as an extractable resource. The most radical thing you can do is refuse to be extracted.

Let’s tell the truth, then: Nobody reads your blog. […] At least, not as many as you’d like.

This is not meant to be a mass market blog. Thank you for tagging along.

When you write, you think better. When you think better, you create better.

So, who’s there real audience?

You’re not just writing for today’s invisible audience. You’re writing for:

• Future you. Your posts become a time capsule of your evolving mind.
• One right person. Maybe one day, someone stumbles across your words at exactly the right moment. And that changes something for them.
• The work itself. Consistency beats virality. A hundred posts with depth will outlast a single viral hit.

I’ve been thinking about this a lot as I chart this new course in life. I want to document how running a small software company goes.

Whether it goes poorly or well, by writing about it, I’ll (hopefully) learn from my mistakes and understand what actually worked. If you follow along, you may learn something as well.

And honestly, I just want to write more. I find it cathartic. To that end, I’ve added a new “linked list” feature to this blog and streamlined my workflow. My personal essays are sporadic and varied; I’m hoping this will help me move the needle on my writing consistency.

Daniel_Langworthy (April 13, 2025):

@codinghorror do you know what happened to WASDKeyboards? I am so sad, I love my keyboards I got from them but they seem to just be gone

JimPas (April 13, 2025):

Hi Daniel. I checked this out and the last post on their support site was back in Nov 2024. Scrolling down to the bottom of the page shows this, so it doesn’t look good:

It shows a screenshot of a notice that reads: “Service Temporarily Unavailable”.

Glenwing (April 15, 2025):

I stopped by their office address in early January. Their name was still on the sign, but they’re gone. Replaced with some Solar startup.

This is sad news indeed!

After I started my first software engineering job in 2014, one of the first things I purchased was a mechanical keyboard from WASD: a CODE V1 87-Key Mechanical Keyboard with Cherry MX Clear keys.

I felt strongly (and still do) that writing software is a craft and any good craftsperson should invest in quality tools, learn how to use them effectively, and care for them. That keyboard went with me to every new job and moved across the country from Tennessee to California to Colorado. I’ve never had a single issue with it.

In 2022 when I needed both an office and home setup for Apple’s hybrid schedule, I added the CODE V3 (87-Key Mechanical Keyboard - Cherry MX Clear) to my setup. The V3 was for work; the V1 for home.

Now that I work independently , the V3 is my daily driver but the V1 is still alive and well, boxed up in my office awaiting a day when it’s needed again.