Build-and-Bake: Ship the Same Feature Until the Model Catches Up
Prototype ambitious features now, let them sit, and re-release the same shape each time models leap
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 3
- Confidence
- 90%
Because a feature's success often depends on whether the model is smart enough rather than on the feature's shape, Ambrosino advocates building ambitious things before they work, keeping them as testable artifacts, and re-releasing the same shape each time intelligence improves. A feature that fails today may be the same feature that wins in three months with no design change.
Origin
Andrew Ambrosino, drawing on his prior startup and the Codex/Operator/Atlas lineage at OpenAI.
Core principles
- 01Whether a feature is good is often gated by model intelligence, not by its shape
- 02A built-but-failing feature is an artifact you can re-test against future models, not a dead end
- 03Don't be stubborn: 'not working' may mean 'not ready yet'
- 04Being too 'AGI-pilled' — assuming the model can just do it — fails on the product side
How to run it
- 1
List the ambitious features you're interested in and prototype them all
Enumerate everything you might want to build over the next year or two and prototype each, regardless of whether the current model can pull it off.
- 2
Ship what's ready; let the rest bake as artifacts
Release the features the current model can support, and deliberately let the others sit as saved artifacts rather than killing them.
Pro tip Reframe a rough result as 'we now have an artifact to test against future models,' not 'this is a bad feature.'
Watch out Don't let the muscle memory of 'I wrote the code, so we should ship it' force a premature launch.
- 3
Re-try each baked feature on every model leap
When a new model lands, swap it in and re-test the shelved features — the shape may not change at all, only the underlying intelligence.
Pro tip Calibrate ambition to the moment: don't be so AGI-pilled that the form factor is too early for what models can actually do.
Watch out Over-ambition can make a feature too early for the market even when the idea is right.
In the wild
Ambrosino is confident the February Codex app, if released in November, would have failed in the market — the only difference was the model improvement between the two dates. Same product shape, opposite outcome.
→ Timing against model capability, not feature design, determined success.
Operator in ChatGPT didn't work out; the same fundamental browser-agent feature was re-released with different intelligence across Atlas and Codex. The early Codex Web form factor ('give it a task, it goes off') was too early, while Claude Code's more interactive, less-AGI-pilled shape worked because it matched where models were.
→ Re-releasing the same feature with better intelligence changed the outcome; being too AGI-pilled for the moment failed.
Common mistakes
Killing a feature because its first release failed
Concluding a feature is bad when it's merely gated on model intelligence discards an artifact that could win unchanged once models improve.
Being too AGI-pilled for the moment
Designing a form factor around 'at the limit the model can just do this' ships something too early — like the original delegate-everything Codex Web that wrote code but didn't do the task well enough.
Is it for you?
Best for
AI product teams whose feature viability is gated by rapidly improving model capability
Not ideal for
Products in stable domains where capability isn't the bottleneck and shelved prototypes just accrue maintenance debt
From the transcript
“let's list out all of the things that we think we are interested in doing for the next year or two. Let's prototype all of…”
“the whole premise of whether features were good or not were based on whether they were smart enough, not the shape of them”
“we were too agi pilled for the moment”
From the episode
OpenAI Codex lead on the new shape of product work
Andrew Ambrosino