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
- Designing Data-Intensive Applications — chapter 5 (replication)
- The Hacker News thread on "What I learned writing a JIT"
- A Stripe engineering blog post about idempotency keys
- 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 — but in practice high-dimensional sentence embeddings cluster near , 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.