Corinna Cohn

A sequel to the architecture guide. Part 1 explained how the search engine was built. This one explains how we found out whether it was any good, tried four ideas to improve it, and shipped the two that actually worked. If you read Part 1, you know the setup: I'd been collecting technical books for years — mostly Humble Bundle hauls — and had over 100 of them sitting on a hard drive, mostly unread. So I built a semantic search engine over the whole library, exposed as an MCP server Claude could query. Ask a question, get back real passages from Neal Ford or Vaughn Vernon, instead of an AI's vague recollection of them. By the end of Part 1, it worked. But "it worked" and "it's good" are different claims, and I'd only ever checked the first one. This post is the story of taking the second one seriously. The whole thing follows from one sentence, taken literally: You cannot improve what you cannot measure. The question that started this Whe...

What do you do with 100 technical books you'll never finish reading? I built an MCP. I've been collecting high-quality technical books for years, mostly from Humble Bundle sales (IYKYK). Some I've read. Some I keep meaning to. But they're all sitting right there on my hard drive, over 100 of them, so the question became: how do I get more value out of what I already own? Keyword search doesn't cut it. If I want to answer "how do I justify decoupling to a skeptical executive?", the relevant passages say things like "selling architecture" or "business risk." You'd have to already know the answer to find it. And there was a second motivation: I'd been circling RAG at a theoretical distance for a while. I wanted to understand the patterns firsthand, not from diagrams. So I built a semantic search engine over my own library, exposed as an MCP server that Claude can query. Everything runs locally: embedding, vector storage, retrieval....