The Pragmatic Programmer revisit

Most personal-knowledge tools optimise for input. The friction is on the way in: capture this thought, file it, tag it, link it. But the value lives on the way OUT — when the system surfaces the right note at the right moment without you asking. Capture-heavy products are easier to build; output-heavy ones are what people actually pay for.

Reading other people's code is a higher-leverage activity than writing your own. You learn three things at once: what works, what doesn't, and why someone smart picked the trade-off you'd never have considered. The ratio of read-to-write hours quietly separates the engineers who plateau from the ones who keep compounding.

The interesting thing about long-context models isn't that they can read more — it's that they finally make the retrieval problem optional. When a model can hold the whole repo in context, the question shifts from "what should I fetch?" to "what should I show?". That's a UX question, not an infrastructure one.

Capture-flow check-list

• [x] Pulled from Safari via Share Sheet
• [x] OCR'd a whiteboard photo
• [x] Dictated three voice memos walking to coffee
• [ ] Imported the long PDF I was avoiding
• [ ] Cleaned the inbox folder

sequenceDiagram
  participant U as User
  participant M as Memory.Wiki
  participant A as AI
  U->>M: Save thought / URL / photo
  M-->>U: Permalink
  U->>A: "Use [URL] as my context"
  A-->>U: Answer grounded in the hub

What changed

A good error message answers three questions: what happened, why it happened, and what to try next. Most ship the first, hint at the second, and forget the third. The fix is usually a single sentence longer.