Build for the next AI model, not this one

A few hours before Anthropic opened Code with Claude in Tokyo, the company shipped the fifth generation of Claude: Fable 5, now the most capable model it offers to everyone, and Mythos 5, a locked-down sibling for vetted research partners. The models are a big deal. But the most useful thing on that stage for founders was not a benchmark. It was a line from Dianne Na Penn, who leads research product management: build for the next model, not the one you have today.

That sounds abstract. It is not. It changes what you build this quarter. Here is the keynote distilled into a plan a founder can act on.

The gap is the opportunity

Penn framed the moment with one line: model capability is on an exponential, but most business capability is still on a linear. Anthropic showed the curve. Two years ago the frontier was drafting a commit message. A year ago a model could build a whole feature. Six months ago agents ran overnight. Now Fable 5 can run for days on a single goal and stay coherent across millions of tokens.

Meanwhile, what most companies actually do with AI creeps up slowly. That gap, between what AI can do and what it is doing for you, is the whole opportunity. Closing it is the job.

Anthropic's own numbers make the point. It said API volume on the platform is up nearly 17 times year over year, and that its engineers now ship roughly 8 times more code than in past years even as the team grew. Rakuten, one of its customers, has a product manager who coordinates teams of agents the way a manager runs teams of people, and now ships major releases every two weeks instead of once a quarter.

Build for the next AI model, not this one

Here is the core idea, in Penn's words: the developers who win are the ones whose architectures, harnesses, and product experiences are ready to absorb the next jump in intelligence.

In practice that means designing so a better model is a drop-in, not a rewrite. If your product only works because you hand-tuned prompts and bolted on scaffolding to paper over today's model's weak spots, you have built a cage. The next model breaks out of it, and the competitor who built for the upgrade ships the better experience first.

A few concrete moves:

• Keep the model behind a thin seam. Swapping models should be a config change you run on a Tuesday, not a quarter of refactoring.
• Lean on simple primitives. Penn's point: as models get smarter, they do more with basic tools like a file system or a sandbox, and need less elaborate hand-holding. Bet on the model, not on your scaffolding.
• Write down what the model cannot do yet. Those assumptions are the walls that move.

This is the same instinct behind building software with AI agents like a team: give the system room and structure, and let the intelligence fill it.

Keep a list of what does not work yet

This was the sharpest tactic in the talk. Penn said you should build harder eval prototypes for experiences that may not work yet, then watch them. When a prototype that was failing starts passing, that is the exponential moving under your feet, and that is your signal to ship something you could not ship last month.

Most teams only test what already works. Flip it. Keep a running set of "almost" features: the demo that is 60 percent there, the workflow the model fumbles, the task that needs one more level of reasoning. Re-run them on every model release. The day one crosses the line, you have a product nobody else noticed was possible.

That is how you turn an unpredictable capability curve into a roadmap.

Treat every model upgrade as a business event

If new models arrive every few months and each one opens new revenue, then upgrading is not maintenance, it is growth. The teams that win, Penn said, are the ones that get the most out of each upgrade and treat it as a business opportunity.

Make upgrades cheap and routine:

• Automate your evals so you can grade a new model against your real tasks in hours, not weeks.
• Stay hands-on. Put the new model in front of your hardest prompts the day it lands.
• Keep a fast path to production so the moment a model wins, it ships.

The slow part is never the model anymore. It is how quickly you can put a better one to work.

The AI-native company: people set outcomes, agents do the work

Angela Jiang, who leads product for the Claude platform, described what this looks like at full strength with a small story. Overnight, a product noticed it was broken, read its own error reports, wrote the fix, and shipped it. No standup. No ticket. By morning the changelog was already written.

That is an AI-native company. Not a company where people use AI to do their work, but one where the work runs on AI and people decide what the outcome should be. Jiang named three ingredients that turn raw intelligence into that outcome: a harness (the tools and the permission to actually act, not just suggest), context (memory, skills the agent can write for itself, and a window large enough to hold the whole problem), and infrastructure (the unglamorous job of running long agents reliably at scale).

This is the same shift we wrote about in how to build an AI-native company: your job moves from doing the work to setting the outcome and the guardrails. Fable 5 is built for exactly this, long-horizon agents that own a goal for a week, dispatch sub-agents, and keep them on track.

Safety is what lets you ship the strongest model

Here is where this gets interesting for anyone responsible for security. The reason Fable 5 could ship to everyone is a safeguard, not the absence of one.

Anthropic held the most capable version of this model, Mythos, back from general release because its cybersecurity and biology skills were strong enough to be misused. Earlier this year it reported that a Mythos preview, run through a vulnerability-research harness, autonomously surfaced a 27-year-old flaw in OpenBSD's networking code that had gone unnoticed for decades. Capability that sharp cuts both ways.

So Anthropic built a routing safeguard: when a request touches cybersecurity, biology, or chemistry, Fable 5 hands it to a more guarded model, Opus 4.8, and labels the response. That one control is what let the strongest model go out to everyone now instead of months from now.

The lesson for founders, and this is the CISSP in me talking: do not treat safety as a feature you add later. The guardrail is the thing that lets you put the most capable model in front of customers at all. Build the controls (clear boundaries on what agents can touch, labeled and logged actions, least-privilege access to keys and data) and you get to move faster, not slower. We unpack more of this in Anthropic's lessons for founders.

What to do this week

• Put a thin seam between your product and the model, so the next one is a config change instead of a rewrite.
• Start a "does not work yet" list: three features the current model almost handles. Re-test them on the next release.
• Automate one eval that grades a model against a real task of yours, end to end.
• Pick one workflow and redesign it so a person sets the outcome and an agent does the work, with clear limits on what it can touch.
• Write down the two riskiest things your agents can do, and add a guardrail to each before you scale them.

The models will keep getting better whether or not you are ready. The founders who build for the next one, safely, are the ones who get to ship what nobody else can yet.

Ready to build your company around this? That is exactly what we teach in the AI Operating System for Startups.

Sources

• Code with Claude Tokyo 2026: opening keynote. The talk this article distills, featuring Dianne Na Penn and Angela Jiang.
• Claude Fable 5 and Claude Mythos 5. Anthropic's announcement of both models, including the Fable-to-Opus 4.8 safety routing.
• Anthropic's Mythos preview report. The source for the 27-year-old OpenBSD finding.
• Profiles: Dianne Na Penn and Angela Jiang, who lead research product and the Claude platform at Anthropic.