Think Wider, Not (Just) Bigger

#concept

Summary

Theo Browne's core reframe: you can't out-improve the models by "getting better" at your craft, so raise ambition instead — and specifically expand breadth (range of areas a product covers), not only depth (features per area). "If your idea doesn't feel stupid, it isn't big enough."

Current Understanding

Match ambition to the model. New models are qualitative eras (tool-call → long-running → orchestration; see ai-agent-evolution). You only feel the gain if the task requires the new capability. Work that made sense on the prior model won't feel different on the next.
The tier shift. Every project category moved down one slot: yesterday's startup is today's side project; yesterday's "too big" (full-stack cloud) is today's startup; a new bottom tier appeared — a markdown file (see code-as-throwaway). The top ("too big") is genuinely open — train your own model? your own OS? compete with npm?
Breadth is now viable for small teams. Old rule: pick a vertical, go deep (you can't out-breadth an incumbent). New rule: bolt a serviceable adjacent layer into your product in a day or two of prompting — cover enough that users can start, and be the right shape so users extend you (the Slack effect: it became everyone's agent platform not because it's good but because its shape invited extension).

Evidence

Eras, tier-shift table, breadth-vs-depth, Vercel-vs-AWS, Slack-as-accidental-platform, "pick an idea that feels stupid" — 2026-07-14-everything-we-knew-about-software-has-changed.

Concepts: code-as-throwaway, decoupling-identity-from-profession, context-as-scarce-resource
Entity: theo-browne
Timeline: ai-agent-evolution

Contradictions / Uncertainty

"Bolt a database platform in a day or two" is an ambition claim; reliability parity with incumbents (RDS) is explicitly not promised. Status: tentative.
Wide latitude vs tight specs (recorded here 2026-07-28 by lint; previously logged only on the other side). eugene's leave-less-room-for-imagination argues the opposite reflex: every gap you leave gets filled invisibly, so specs should be tightened and frozen into skills. The reconciliation offered there is breadth of attempts vs tightness of each spec — many cheap wide attempts, each individually well-constrained — which preserves both, but neither source addresses the other and the reconciliation is the wiki's synthesis, not either author's. Status: tentative.

Next Questions

Which adjacent breadth layer is highest-leverage to add first for a given product?

2.6 KiB Raw Blame History