Why I stopped trusting silent catch blocks

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.

The hardest part of a 1-person startup isn't the work — it's the lack of a forcing function. Without a meeting on Tuesday, nothing has to ship on Monday. The schedule has to come from somewhere, and "because I said so" isn't enough.

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.

Three rules I keep returning to

  • Ship one feature, deeply, before two features shallowly.
  • The interface IS the product. The engine just has to keep up.
  • Anything important should fit on one screen.

"The best note-taking system is the one you already have open." — every productivity post ever, and also true

Provider Strength Weakness
Claude Long context, instruction following Slow for tiny prompts
GPT-4o Multimodal, fast Drifts on long sessions
Cursor Code-aware ranking Locked to editor
flowchart LR
  Capture --> Organize
  Organize --> Use
  Use -.indispensability loop.-> Capture

Recap

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.