2026-07-01·2 min read

Writing projects so a different model can pick them up cold

field-notesclaude-codeprocess

Open a project in a new session and the agent knows nothing. Not the branch, not last week’s decision, not why a file is shaped the way it is. If that session happens to be running on a different model than the one that built the thing, it’s worse: no shared instinct to fall back on, just the code as it currently stands. Normally that means re-explaining the project from scratch, again, out loud, to whichever model showed up this time.

The fix I landed on wasn’t a better prompt. It was writing the reasoning down where any session, any model, can find it.

The spec is the memory

Every feature in every project I run starts the same way: a brainstorm that ends in a written design spec, then an implementation plan with checkbox tasks, then execution. All of it gets committed to the repo under docs/superpowers/. The brainstorm and the spec are the record of the why; the plan is the record of the how. Both are files, not messages. Jubileus, a local-first second brain, has 64 of these spec-and-plan documents. Loom, an interactive-fiction editor I built in three days, has 33 pairs.

That volume isn’t ceremony. It’s the difference between a new session reading five lines of code and guessing, or reading the spec and knowing exactly why the thing branches the way it does. Come back two weeks later, or hand the repo to a different model entirely, and the why is sitting in the commit history, not trapped in whatever context window built it.

Reviewed by more than one mind

The other half of this is deliberate: before execution starts, I have models review the architecture itself, and not always the model I built with. Some of that review goes to a bench of non-Anthropic models, so the plan isn’t one model checking its own preferences. A model reviewing its own design smooths in the direction it already built. A differently-trained one has no stake in the assumptions that got baked in, so it flags them faster.

The signal I’m listening for is disagreement. When two models from different labs read the same plan and land on different concerns, that gap is usually where the real problem sits. A design that only makes sense to the model that wrote it is a design with a hidden dependency, and that dependency stays invisible until a different model tries to extend it and stalls on something nobody wrote down. A cross-vendor read surfaces it while I can still fix it cheaply.

What I’m after is narrower than “any model could have built this from zero.” It’s that a model that didn’t build the project can still pick it up, read the plan, and keep going without me standing over its shoulder explaining what I meant.