Build for the Next Model

Sources#

Summary#

A product-strategy corollary of Harness Shrinkage as Models Improve, now stated independently by three Anthropic voices: don't build the thing that already works — prototype the thing that almost works, and bet that the next model release closes the gap. Dan Carey gives it the cleanest case: Claude Design shipped with a list of problems the team "did not fix with clever engineering… we fixed them with Opus 4.7 coming out." Boris Cherny built Claude Code knowing "it wouldn't have PMF for 6 months because we were building for the next model." Cat Wu frames the discipline as "build products that don't necessarily work yet so that you know what is missing… and then with the newest model you can just swap it in." Because models improve rapidly, engineering effort spent forcing today's model to do what next quarter's model will do for free is wasted — "the model releases are a tide that lifts all boats."

The Carey statement (and why it's the clearest)#

"You do not want to work on the thing that already works. You often want to prototype the thing that almost works… The next model may just fix the issues that you cannot solve via engineering. We had this with Claude Design… We fixed them with Opus 4.7 coming out."

This is the rare retrospective, concrete confirmation of the bet: a named product (Claude Design), a named model (Claude Opus 4.7), and a specific outcome (unsolved prototype gaps closed by the release rather than by engineering). Boris and Cat state the strategy prospectively; Carey shows it paying off.

The crucial calibration: next model, not a strawman AGI#

The bet is easy to misread as "build for some imagined super-AI." Cat Wu guards exactly against that — her stance recorded on her entity page is "build for the current model": "It's very easy to build the product for the super-AGI strong model. The hard thing is figuring out for the current model, how do you elicit the maximum capability?" These reconcile into one rule:

Don't build for today's model only → you under-shoot, and ship something that's obsolete the moment the next release lands.
Don't build for a far-future AGI strawman → you over-shoot, and ship vaporware that depends on capability nobody has.
Build for the next concrete release (~the model ~6 months out) → you prototype "the thing that almost works," ship it as a research preview, and let the next release — which you can reasonably forecast — close the gap.

Carey names the target the prototype is reaching for: not completeness but "that hint of magic… something that could become [complete] in the future."

Why this follows from the bitter lesson#

This is the product-side expression of The Bitter Lesson and Harness Shrinkage as Models Improve: capability migrates into the model over releases, so scaffolding built to compensate for a current limitation is a depreciating asset. If a gap is the kind that scales away (reasoning, instruction-following, multimodal fidelity), patching it with engineering is building a crutch you'll soon delete. The discipline is to identify which gaps are "wait for the model" gaps versus which are durable harness work (Harness Shrinkage as Models Improve's caveat: mechanical verification, security, brand/character don't migrate inward).

The tension to hold#

"Prototype the thing that almost works" is in direct tension with Problem-Solution Fit Discipline's prototype-as-evidence trap: a fast prototype proves the build was tractable, not that the problem is real. The reconciliation: build-for-the-next-model is about capability risk (will the tech get there? — yes, wait for it), not market risk (does anyone want this? — the prototype doesn't answer that). You still validate demand through users; you just don't burn engineering forcing a capability the next model will hand you. Carey's own safeguard is that the bet rides on top of Compounding Loop Optimization and daily user contact — the "shape of the product" is validated continuously even while specific capability gaps are left for the model to close.

Connections#

Harness Shrinkage as Models Improve — the parent thesis; this is its product-strategy corollary, and that page's "Build for the next model" section points here
The Bitter Lesson — the root principle: capability migrates inward, so compensating scaffolding depreciates
Claude Opus 4.7 — the concrete model release that closed Claude Design's unsolved gaps
Claude Design — the case study product
Dan Carey — the retrospective statement; Boris Cherny and Cat Wu state it prospectively
Prototype Over PRD — how you author the "almost works" bet quickly
Compounding Loop Optimization — the loop that validates product shape while capability gaps wait for the model
Problem-Solution Fit Discipline — the counter-discipline: don't let "it almost works" become "the prototype validates the idea"
The Verifiability Thesis — what the next model reliably improves are verifiable-reward capabilities; gaps in non-verifiable taste are the riskier ones to "wait out"

Open Questions#

How do you tell a "wait for the model" gap from a durable-harness gap before the next release? Get it wrong and you either ship vaporware or build a crutch you'll delete.
The bet depends on a reliable release cadence and a forecastable capability curve (Task Time-Horizon Scaling). What happens to "build for the next model" if model improvement stalls (the stalled-but-diffused future)?
Does the strategy generalize outside frontier labs, who have privileged visibility into the next model? An external team is betting on a release it can't see.

Sources#

Designing with Claude: From prompt to production — Carey: "we fixed them with Opus 4.7 coming out"
Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next — Boris: "building for the next model"
How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — Cat: "build products that don't necessarily work yet"