The Saturday review ritual

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.

ㅁㄴㅇㄹ ㅁㅇㄴ ㅁㄴㅇㄹ
ㅁㅇㄴㄹ ㅁㄴㅇㄹ ㅁㄴㅇㄹ

Cross-AI portability is the structural moat OpenAI and Anthropic can't build for themselves. The user's context, exported as a public URL, becomes infrastructure that survives any single vendor's pivot. That's why the right primitive isn't an API key — it's a permalink.

Markdown won because it was always good enough. Not the best at any one thing — never the fastest editor, never the prettiest output, never the most semantically rich. But always close enough that the switching cost killed every alternative.

Today's reading list

  1. Designing Data-Intensive Applications — chapter 5 (replication)
  2. The Hacker News thread on "What I learned writing a JIT"
  3. A Stripe engineering blog post about idempotency keys
  4. Karpathy's tweet thread about LLM evals

"Make the easy thing the default and the hard thing possible." — design rule I keep stealing from Linear

  • Surface Latency goal Notes

Capture <1s tap → toast local-first, server is best-effort

Open <500ms URL → LCP edge cache for public URLs

Search <250ms keystroke → results semantic + lexical merged

When the embedding similarity is

sim(a,b)=a⃗⋅b⃗∣a⃗∣,∣b⃗∣\text{sim}(a, b) = \frac{\vec{a} \cdot \vec{b}}{|\vec{a}| , |\vec{b}|}sim(a,b)=∣a∣,∣b∣a⋅b​

we expect cosine values between −1-1−1 and 11 — but in practice high-dimensional sentence embeddings cluster near 0.30.3, which is what makes nearest-neighbour search noisy.

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

Whiteboard sketch

Next steps

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.