How to build for the models of tomorrow

1 The bottom line

Build for where models will be in two to three months, and retest every parked idea whenever a new model ships. Capabilities change faster than roadmaps, so features that fail today often work next release.

2 Key takeaways

• Build for the models of two to three months from now. Building for today leaves you behind, and bets on years out are almost always wrong.
  • Tara Seshan and Nan Yu, OpenAI20:00: Tara keeps a document of her own wrong predictions to remind herself how poor long-range ones are.
  • Boris Cherny, Claude Code (Anthropic)1:05:56: Claude Code wrote about 20% of his code in February, 30% in May and 100% by November, and growth went exponential with Opus 4 and Sonnet 4.
• Prototype what fails today, park it, and rerun it on every new model. A failed test often means the model is not ready, not that the idea is bad.
  • Ami Vora and Mike Krieger, Anthropic22:32: a 2024 computer use product was neither good for automation nor education, so it was parked, and a later eval showed it succeeding more often than not.
  • Andrew Ambrosino, OpenAI33:01: the Codex app released in February would have failed if ready in November. Only the models changed.
• Test every idea on the newest model before you rule it out. Capabilities shift in weeks, and old judgments stick.
  • Ami Vora and Mike Krieger, Anthropic23:52: people often judge capabilities with an old model like Sonnet 4.5, and models can improve in ways nobody expected within three months.
  • Boris Cherny, Claude Code (Anthropic)23:00: a newer engineer asked Claude to find a memory leak, and it took the heap snapshot, wrote its own analysis tool and opened a PR faster than Boris could debug by hand.
• Delete the scaffolding when models catch up. Features that patch a weak model become dead weight once it improves.
  • Cat Wu, Anthropic1:01:11: with Opus 4 and later, the model used the to-do list on its own without being forced to.
  • Roman Ugarte, Grok Bot (SpaceXAI)1:13:30: Cursor pulled capabilities from three to six months ahead into the present, then deleted that scaffolding once models handled it.
• Plan the near term in detail and keep long-range plans hazy. Precision far out is false precision.
  • Andrew Ambrosino, OpenAI32:18: anything planned in November may have been true for December but is not what actually happened.
  • Keith Rabois, Khosla Ventures35:50: things impossible in November are easy by March.

we see it as a win in labs if all your project did is show that the models aren't ready for it yet

Ami Vora and Mike Krieger, Anthropic22:32

2.1 Set your horizon

Pick a target a few months past today's models, and check your plans against it.

• Aim at the next model, not the current one and not a distant one Tara Seshan, OpenAI27:27
  • Stay tied to research and know which capabilities the models are being pushed on, such as coding or writing.
  • Design product constructs that get out of the model's way, so the product is right when the next model lands.
  • She says you fail if you build for where models are now, and you fail if you build for where you think they will be in a year.
• Ask what changes if the next model arrives Dianne Penn, Anthropic34:40
  • Ask the team what changes in what users do if, say, Claude 8 shows up, and whether what you build today still works in that world.
  • Hold strong opinions on the theme or area, and loose ones on the exact prototype or approach.
  • Labs prototypes that don't work yet are revisited in one to two model generations.
• Design as if intelligence and tokens are nearly free Mark Pincus, Zynga1:07:00
  • Reimagine consumer services assuming token costs fall sharply in a year or two, instead of designing around today's limits. This opens space for premium apps and games that hit AI limits today.
  • Anish Acharya, a16z27:30 asks founders to assume models are infinitely intelligent and astonishingly cheap, and to ask how they would reorganize the company.
  • Pincus warns that giving away tokens at a loss is not a plan on its own. Unlike dot-com pig ears delivery, token prices will fall.
  • Acharya notes electricity took 40 years to go from swapping out coal to rebuilding factories from scratch. The most ambitious companies rethink everything around the models.
• Expect agents to be your heaviest users Tibo Sottiaux, OpenAI31:02
  • Expect most actions on the internet to be taken by agents, and design for that scale.
  • You can hold back an agent interface for a while, but it is inevitable.
  • When Notion shipped its MCP, agents sent a large amount of traffic. That strained the system and forced the team to work out the economics.

2.2 Find what is almost possible

Keep a list of things AI cannot quite do yet, and watch for the day one crosses over.

• Keep a running list of what is almost possible Josh Woodward, Google Labs8:18
  • Track experiences AI cannot quite do yet.
  • When a model or demo crosses one over, treat it as a phase shift and put a small team on it right away.
  • Pair the new capability with a real user problem people would pay to solve.
  • A demo he saw 48 hours before the interview became a project within those 48 hours.
• Ask what is possible now that was not a few months ago Brett Bauman and Zack Hargett, Coconote48:08
  • Zack uses the question "what's possible today that wasn't possible 3 or 6 months ago" to find new products.
  • Jelte Liebrand, Savvy Navvy11:57 adds a second question: what feels dumb today that seemed fine three years ago? Typing in data or dropping a pin starts to feel clunky.
  • Runna's real-time AI running coach could not have existed six months to a year earlier without a human coach reacting to your metrics.
  • Liebrand notes people now get annoyed when ChatGPT gets something wrong, which shows how fast expectations moved.
• Spot the use case people are already pulling toward Dianne Penn, Anthropic11:45
  • In 2023 she saw people using models for long-form code rather than autocomplete, and pushed to train Opus 3 to be better at it.
  • Boris Cherny, Claude Code (Anthropic)51:00 says to look at what the model is trying to do and make that easier. Claude Code exposes the model with minimal scaffolding and a minimal set of tools.
  • Share prototypes openly, because experimentation is not always an individual sport21:50.
  • The coding change was relatively small in training but became a lasting differentiator for developers.
  • A bash tool alone let the early Claude Code prototype answer what music Boris was listening to, with no instruction on how.
  • Edward Tian, GPTZero45:00 described an AI filter for browsing at seed, but built it only two or three years later when demand appeared.
• Use AI to serve small segments you skipped before Leon Sasson, Rise17:18
  • AI makes it feasible to personalize for small groups, and at scale you can A/B test them too.
  • Examples are night owls aged 25 to 35 or night shift workers, each 10 to 20% of users. Leon says users start churning if the product feels too generic.

2.3 Prototype it and park it

Build the features models cannot do yet, shelve them, and let new models decide when they ship.

• Prototype every model-dependent feature you want Andrew Ambrosino, OpenAI33:01
  • List the features you want over the next year or two and prototype all of them.
  • Ship the ones that are ready, let the others sit and bake, and swap in each new model to retry them.
  • Whether a feature works often depends on model intelligence, not its shape.
• Turn a failure into an eval you can rerun Ami Vora and Mike Krieger, Anthropic22:32
  • Externalize the failure as an eval, ideally in a harness, or hand it to the research team so you can revisit in a few months.
  • Building early is what gives you the intuition to recognize the moment it starts working.
• Build products that do not work yet, so you know what is missing Cat Wu, Anthropic1:04:55
  • When a new model ships, drop it into the existing prototype and test whether it closes the gap.
  • Code review was attempted several times. It became reliable enough to gate merges with Opus 4.5 and 4.6 and Sonnet 4.6, running multiple review agents in parallel.
  • Anthropic's engineering team now relies on Claude code review passing before merging PRs.
• Do not kill a feature that failed because the model was not ready Andrew Ambrosino, OpenAI36:15
  • Treat the old code as an artifact to test against future models, and do not mistake having written it for a reason to ship it.
  • Match the form factor to what models can reliably do. He says37:30 the first Codex web had you delegate and wait, which was too early.
  • Operator, the agent in Atlas, and the in-app browser in Codex are the same idea re-released with better intelligence, and the outcomes were very different.
  • Claude Code launched local, asked questions and did not pretend you could delegate your life to it. That fit the models better.

2.4 Retest on every release

Make a new model launch the trigger to rerun old failures and drop old assumptions.

• Make time at each release to ask what is newly possible Amol Avasare, Anthropic1:18:40
  • Ask "what is the new things you can do with this?" and update your priors, or you may miss capabilities for months.
  • Ian Silber, OpenAI53:40 recommends poking at the edges of each new model and feature. A setup or interaction you needed may no longer need to exist, and a new one may.
  • This also builds product sense for AI products.
  • Ian saw early voice mode and barely working computer use at hiring, and now uses both to build software.
• Revisit what you failed to automate Fiona Fung, Anthropic1:17:00
  • Something Claude could not do before may work with the next model, so periodically revisit it.
  • She noticed engineers resisting AI tools after seeing early mistakes in Sonnet 3.5 or 3.6, without accounting for the rate of improvement.
• Ship something with every new model to build intuition Anish Acharya, a16z27:30
  • Pick a low-stakes project as a chassis and keep adding to it, using the model as a tool rather than a goal.
  • Learn each model's shape. Qwen is creative and strong on long-horizon tasks, while GLM is precise and neurotic, with no vision.
  • Qwen ran 4 to 5 hours to produce a 5-minute documentary, using MiniMax for video and 11 for audio.
• Keep the problem, discard your old solution Ami Vora, Anthropic1:28
  • Hold on to the deep understanding of the human problem, throw away what you knew about how to solve it, then try again with fresh eyes on the technology.
  • She contrasts a technology cycle that used to be 5 to 10 years with one that now feels like every two months.

2.5 Change the product and the team as models change

Remove crutches, reinvent on a schedule, and run a roadmap that bends with each release.

• Read your whole system prompt at each launch and delete what the model no longer needs Cat Wu, Anthropic1:01:11
  • Features added to compensate for model weaknesses, like the to-do list that made Claude fix all 20 call sites in a refactor, become unnecessary as models improve.
  • New models also unlock features that were not accurate enough before.
  • Roman Ugarte, Grok Bot (SpaceXAI)1:13:30 says Cursor's habit of pulling the future into today made users trust it to bring the next frontier. Distribution and data advantages followed, and he argues moats are discovered, not planned.
• Be willing to delete the product and act without asking permission Roman Ugarte, Grok Bot (SpaceXAI)1:11:10
  • His two repeated values are "deleting the product", which means removing scaffolding even if it upsets some users, and "just do the thing".
  • He says the competitors Cursor started against lost ground through cultural inability to move fast, not wrong decisions or lack of resources.
  • Cursor scaled from about 15 people to over 1,000 while keeping a startup pace.
• Replace the year-long roadmap with fast noticing and shipping Keith Rabois, Khosla Ventures35:50
  • Build an organization that changes its roadmap on the fly, where someone notices what is newly possible this week and ships new customer value next week.
  • He says conventional PMs as intermediaries make less sense.
  • Shopify has not allowed PowerPoint or Keynote product presentations for about 2 years. Every presentation must be a working demo.
• Prefer the general model and a smarter single agent over tuned scaffolding Boris Cherny, Claude Code (Anthropic)1:05:10
  • Apply Rich Sutton's bitter lesson: the more general model will always beat the more specific one. Avoid tiny models and fine-tuning unless you have a clear reason.
  • Tibo Sottiaux, OpenAI3:19 says fiddling with loops and graphs is a passing phase. The lasting product is a smart agent that runs 24/7, understands goals and preferences, and learns from feedback.
  • Boris says waiting for the next general model is often better than investing in scaffolding around today's.
  • Tibo's own agent team size expands and shrinks with each model breakthrough, and a bigger single agent can replace a team of agents.

2.6 Turn each model into growth, and protect what lasts

Model releases are your biggest growth moments, so pair them with products and spend design effort on what will not change.

• Treat model releases and the products they enable as your growth lever Mikey Shulman, Suno29:40
  • Track three things in the model: sound quality, song quality (catchy, memorable), and control (how users interact with it). Songs and control can always improve, so the lever never runs out.
  • Pair the model with a product that lets users feel it. Dianne Penn, Anthropic12:58 says you need frontier products for people to feel the magic of frontier models.
  • Mikey says all inflections in users, revenue and subscribers come from making the product better, and model releases are the biggest drivers.
  • Opus 4.5 and Claude Code lifted each other, since the model could run end to end in an agent manner.
  • Connor Zwick, Speak15:30 launched open-ended roleplay once LLMs improved, after years of structured experiences. It completely changed long-term retention and time spent in the app.
• Optimize for what is only possible now, not the old metrics Mikey Shulman, Suno15:30
  • Doing the same application faster misses the beauty of what is only possible today.
  • Time your launch to when open-source tools let you focus on your niche. He says4:55 six months earlier there was not enough open source from the text community, and six months later competition would have crept in.
  • Bark's text-to-speech made some word errors but sounded far more lifelike and emotional than robotic systems tuned for word error rate and speed.
• Spend heavy design effort only where the technology will not change next month Ian Silber, OpenAI33:50
  • For durable pieces like the ChatGPT composer, try 100 things and ship one. For other work, ship quickly, build in public and learn from instant feedback.
  • Amol Avasare, Anthropic16:40 warns against activation flows built around one model's capabilities. Focus on the durable fundamentals of matching the right feature to the right user.
  • Some ChatGPT work goes from idea to ship in about 4 hours, while the "personal life" vision gets whiteboarding, Figma, prototypes and dogfooding first.
  • Amol calls capability overhang a big problem: Opus 4 and Opus 4.5 each unlocked different capabilities, outpacing the test and ship cycle.
• Own something the next general model cannot copy Anada Lakra, BoldVoice53:50
  • BoldVoice has an in-house audio ML team that trains models from scratch on its own data, with expert speech coaches labeling and transcribing.
  • Another route is to build the layer above the models. Weber Wong, FLORA42:59 builds the creative computing layer, as Microsoft built BASIC, then DOS, Windows and Office on top of personal computers.
  • The bet was that non-native English speech is too niche for general models like ChatGPT or Claude, yet still a huge market for one company. ChatGPT or Claude still cannot give the feedback BoldVoice gives.

2.7 Where they disagree

Sources differ on how far ahead to aim, whether to train your own models, and how fast to push users.

• How far ahead to build
  • Boris Cherny, Claude Code (Anthropic)1:05:56 says to design for the model six months out, even though product market fit will be weak for the first six months. The payoff is that the product clicks when the better model ships.
  • Tibo Sottiaux, OpenAI31:28 says to imagine capability, cost and speed roughly 10 times better in a year, and that many builders are not pushing far enough.
  • Yuliya Lennox, Solid Starts38:07 says to position for capabilities that do not exist yet and accept lower margins and higher burn if models will be good and cheap in two years.
  • Adam Turaev, Praktika14:07 built on the edge from 2021 and reached $50M ARR with almost half a million paying subscribers.
  • Cat Wu, Anthropic52:15 says the hard skill is getting maximum capability from today's model, and she sets a direction only a month out.
  • Liebrand says that building anything to launch in 12 months means you have already lost11:57.
• Train your own models or wait for the general one
  • Anada Lakra, BoldVoice53:50 trains from scratch on proprietary data. Boris Cherny, Claude Code (Anthropic)1:05:10 says to avoid fine-tuning and bet on the general model.
  • Eugenia Kuyda, Wabi49:27 says Replika trained its own models but should have gone bigger at moments, investing $10 to $20 million in a new model rather than a million. She concludes fast-moving technology rewards bigger risks.
  • The fit seems to depend on the niche. BoldVoice's data is too narrow for general models, while Boris's advice is for products where the general model will keep improving on your task.
• Whether to push the frontier on users who resist it
  • Tara Seshan and Nan Yu, OpenAI6:28 say to ship frontier features to enterprises even when it breaks their habits, or you get leapfrogged. Build what users need, not what they say they need.
  • OpenAI moved enterprises from chat to agents even though it broke their processes and their expectations for how updates arrive. Most were only using chat while the agent revolution was happening.
  • Avasare points the other way for onramps. By the time you test a new model and ship an activation flow, the next model may make those learnings irrelevant.