Build for the Next Model

Sources#

• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Designing with Claude: From prompt to production
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
• Jeff Dean: The 1% Rule for Building in AI
• OpenAI Codex lead on the new shape of product work
• Rewriting Bun in Rust

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."

The OpenAI-side confirmation: same shape, different intelligence (Ambrosino)#

Andrew Ambrosino supplies the second concrete, retrospective case — and the sharpest formulation of the bet. His claim about the Codex app:

"I am very confident that the Codex app we released in February, if it had been ready in November, would have absolutely failed in the market — the only difference was the models between November and February. The exact same shape… its outcomes were totally different depending on just a few months of timing."

He generalizes it into a "same feature, different intelligence, re-release" pattern: Operator (in ChatGPT) → agent mode in Atlas → the in-app browser in Codex are "fundamentally the same feature," and "you might need to release this thing six different times before it works — the shape might not change at all." What changes is the model underneath. So he coaches his team not to be stubborn — "no, this isn't working, so it's a bad feature" is the wrong read; "it might not be ready yet" (the working build is an artifact to test against future models, not a shippable).

The over-shoot he warns about — "too AGI-pilled for the moment." Ambrosino names the failure mode on the other side of the calibration (the AGI-strawman the next section warns against) with an unusually candid cross-vendor example. The original Codex web release "gave the model a task and it went off and did it" — a fully-delegated, AGI-shaped form factor — but "the model didn't do the task that well." Meanwhile Claude Code came out "totally local, not hooked up to the cloud… doesn't pretend to be as AGI-pilled — it asks you questions, you can't just delegate your life to it," and it "worked way better because that's the point the models were at." His lesson: "we were too AGI-pilled for the moment." The bet is calibrated to where the models actually are, and matching the interaction shape to current capability can beat betting on delegation the model can't yet support. (This is the same product-fit gap Interaction Models describes from the interaction-design side.)

The re-throw discipline: the Bun rewrite (Cherny) — and what the first-party account doesn't say#

The third retrospective case, and the first where the "next model" bet paid off on a task rather than a product (YC interview, July 2026, practitioner-opinion): Jared on the Bun team kept the full Zig→Rust rewrite of the Bun runtime as "one of these test problems that he kind of threw at the model with every new model generation." It failed on every model — "even with the steering" — until Fable, then ran as an 11-day dynamic workflow (verified against the existing test suites, now in production under Claude Code). Cherny generalizes it into the standing advice: for any real engineering problem, "just keep throwing the latest model at it to see if it'll just do it. Cuz even if a previous model didn't, the new one might." This is the bet in its purest form — zero engineering spent compensating, the task itself held constant as the eval, the release cadence doing all the work.

The first-party account tells it differently, and the difference matters to this page. Jarred Sumner — the "Jared" in question, and Bun's creator — published the full methodology a month before the interview (Rewriting Bun in Rust, 2026-07-08, case-study; Sumner is an Anthropic employee). It corroborates the outcome and the model attribution: the port ran on a pre-release Fable 5, and Sumner says "at first, I didn't expect it to work." It does not corroborate the re-throw ritual. Sumner nowhere describes having repeatedly thrown the rewrite at earlier generations. His account is a one-time decision made against a different alternative entirely: the team's actual plan was homegrown Zig smart pointers plus a style guide, and the rewrite was proposed as a week-long experiment ("What if, instead, I spend a week testing if Anthropic's new model can rewrite Bun in Rust?") when he "didn't want to do it" the other way.

Three consequences for the bet as this page states it:

• The "held constant as an eval across generations" framing is Cherny's, not the practitioner's. It may still be true and simply unmentioned, but the vault's only first-party telling doesn't support it. Treat the cleanest re-throw case as unconfirmed at the level of ritual while the outcome stands.
• The trigger was economic, not curiosity. Sumner's stated frame is that "until very recently, programming language choice was a one-way decision" — the bet paid off because the cost of a category of work collapsed, not because a periodic probe finally returned true. That is a different (and more forecastable) signal than "try it again each release."
• "Zero engineering spent compensating" is wrong. The run required ~3 hours of pattern-mapping to produce a PORTING.md, a dedicated workflow to derive a LIFETIMES.tsv, a trial run on 3 files, ~50 hand-tuned workflows, a git-command deny-list, cgroup isolation, and continuous human monitoring for 11 days. The harness was large even though the compensating scaffolding was zero — the two are not the same thing (Harness Shrinkage as Models Improve).

Planning under model uncertainty (the corollary)#

The same logic reshapes roadmaps. Ambrosino: "the shorter-term something is, the more detail it needs" — but a 9-month plan "has to stay very hazy, because any precision you add is false precision, and you're just going to waste time." Anything planned in November "may have been true for December but isn't what happened." So planning becomes forecasting model capability on a timeline: at his last company the process became "list everything we're interested in, prototype all of them, decide which are ready now, let the others sit and bake, and every time there's a new leap in models, try that thing again with it swapped out — because whether features were good was based on whether the model was smart enough, not the shape of them." That is planning-minimization driven specifically by capability uncertainty.

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#

A sharper tension, from outside Anthropic: Jeff Dean tells founders to read "the model almost does this" as a reason to avoid the market, not to prototype into it — "look for something where the model succeeds 0% or 1% of the time, not 20%." Same signal, opposite verdict, and the reconciliation turns on who owns the surface the release lifts. Worked through on The 1% Rule for Wedge Selection.

"Prototype the thing that almost works" is also 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"
• Andrew Ambrosino / Codex — the OpenAI-side retrospective (Codex Feb-vs-Nov) and the "same feature, different intelligence, re-release six times" formulation
• Polish No Longer Signals Readiness — "it might not be ready yet" relabels a working build as an artifact-to-test, not a shippable — the same stage-signal correction
• Interaction Models — matching the interaction shape to current capability (Codex-web "too AGI-pilled" vs. Claude Code's local, question-asking form) is this bet made at the interaction-design layer
• Why AI Lags at Design — design as a capability Ambrosino expects the next models to close, the archetypal "wait for the model" gap
• Latent Capability Overhang — the pessimistic twin: "wait for the next model" (a capability's cost drops 10–100× per release, so mine it later and cheaper) is the flip side of "build for the next model"; both bet on the forecastable release cadence
• The 1% Rule for Wedge Selection — the direct contradiction: Dean reads the same "the model gets this ~20% right" signal as a reason not to build there. Reconciled on ownership — this page is about a capability gap inside a product you already own (the release is a subsidy), the 1% rule is about what the company is for (the release is a competitor)
• What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — the stall analysis: the bet is a cheap call option on the release cadence, with the overhang as post-stall hedge and harness re-accretion as the fallback discipline

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. Partially answered: What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — the survivor taxonomy is the classifier: gaps in behavior/capability (task-prior structure) are "wait for the model" gaps; gaps in boundaries, org-specific record, identity, deployment structure, or human-facing legibility are durable-harness gaps that no release will close. The pre-release tell is what the fix would encode.
• 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.

Resolved Questions#

• 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)? Answered: What Scaffolding Survives Model Improvement — and How Do You Know When a Line Turns Harmful? — it degrades gracefully, because correctly practiced it is a cheap call option on the release cadence: a stall costs the premium (the prototype portfolio expires unexercised), not the firm, provided market validation was kept separate from the capability bet. Three cushions: Latent Capability Overhang keeps effective capability rising post-stall (mine the model replaces wait for the model); the previously-wrong move — engineering the compensating crutch — reclassifies as correct ("too AGI-pilled" correction becomes the standing posture); and competition shifts to the durable layers that never migrated inward. The bet only fails hard under miscalibration: shipping products whose core loop depends on absent capability, which is vaporware whether or not the cadence holds.

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"
• OpenAI Codex lead on the new shape of product work — Ambrosino: "the February app would have failed in November — the only difference was the models"; "too AGI-pilled for the moment"
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny, YC interview (2026-07-27, practitioner-opinion): the Bun Zig→Rust re-throw case and "keep throwing the latest model at it"
• Rewriting Bun in Rust — Jarred Sumner, bun.com (2026-07-08, case-study): the first-party telling of the same rewrite — a one-time week-long experiment against a smart-pointer alternative, not a per-generation re-throw, and with a large prep harness
• Jeff Dean: The 1% Rule for Building in AI — Jeff Dean, YC Startup School 2026 (2026-07-30, practitioner-opinion): the contradicting heuristic — build where models succeed 0–1% of the time, not 20%