Build for the Exponential (Skate to Where the Puck Is Going)
Build products for the model that arrives in 6-12 months, betting that today's 20%-working features hit 100%
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 85%
In a domain improving exponentially, building for today's capability guarantees obsolescence. Instead, internalize the rate of improvement and build for what the technology will do in six to twelve months. Features that work only 20% of the time now will work 100% of the time soon, so design the product for that future baseline rather than the current one.
Origin
Ben Mann on how Anthropic's Labs (now Frontiers) team operates, citing METR's (Beth Barnes) research on the growing time-horizon of software-engineering tasks AI can complete, and crediting this mindset for Claude Code's success.
Core principles
- 01People are bad at modeling exponential progress; an exponential looks flat and near-zero right before the knee
- 02Don't build for today, build for 6 months and a year from now
- 03Things working 20% of the time will start working 100% of the time
- 04Anchor product bets to the measured rate of capability improvement, not a guess
How to run it
- 1
Internalize the exponential
Study the actual rate of capability improvement (e.g. METR's time-horizon curve for software tasks) so your intuition tracks the curve, not a linear extrapolation.
Pro tip Ask 'are we AGI-pilled enough?' as a forcing question against timid, present-day scoping.
Watch out An exponential looks flat at the start; judging by today's snapshot will make you systematically under-build.
- 2
Target the 6-12 month capability, not today's
Design for the model that will exist in half a year to a year, not the one in your hands now.
- 3
Bet on the 20% features
Identify capabilities that work only ~20% of the time today and build as if they'll soon work 100% of the time.
Pro tip Pick a leverage point that generalizes as capability grows rather than a narrow demo.
- 4
Choose a durable form factor
Pick an interface that stays valuable as capability scales.
Pro tip Claude Code chose the terminal because it lives everywhere: local machine, GitHub Actions, a remote cluster box, giving it leverage as agents got better.
In the wild
The team reasoned that engineers wouldn't stay locked to IDEs or autocomplete forever, so they built for an agent that does everything a software engineer does, in a terminal that can run locally, in CI, or on remote machines, betting on capabilities that were only partly working at the time.
→ Claude Code became a success precisely because it was built for where the puck was going, not for the model's current 2025 ceiling.
Common mistakes
Building for today's capability
Designing around the model you have now ships a product that's obsolete within months because the underlying capability is on an accelerating exponential.
Dismissing features that only work 20% of the time
Judging a nascent capability by its current low success rate misses that the same feature will soon work reliably; the flat-looking start of an exponential fools people into under-investing.
Is it for you?
Best for
Product and engineering leaders building on top of fast-improving AI models who must place bets ahead of current capability
Not ideal for
Stable, slow-moving domains where extrapolating aggressive improvement would be reckless, or products that must ship reliably today
From the transcript
“we think about skating to where the puck is going”
“don't build for today build for 6 months from now build for a year from now and the things that aren't quite working that are…”
“a terminal is a great place to do that because a terminal can live in lots of places”
“Are we AGI pilled enough?”
From the episode
Anthropic co-founder on quitting OpenAI, AGI predictions, $100M talent wars, 20% unemployment, and the nightmare scenarios keeping him up at night
Ben Mann