What do we build now? — Theo Browne, @t3dotgg
Theo Browne's keynote from AIEWF2026 urges software engineers to fundamentally change product development in response to rapidly evolving AI models (Sonnet 3.5 to Mythos). He advocates for rejecting legacy mental models and tools (skeuomorphism), embracing a new "Markdown tier" for projects, and thinking "wider" instead of just "deeper" by building extensible platforms that can challenge industry giants. The core message is to be more ambitious, as AI has drastically lowered the barrier to entry for complex, broad-reaching solutions.
Theo Browne opens by describing his personal experience with “AI psychosis,” detailing the rapid evolution of AI models and their impact on software development. He traces this evolution through three distinct eras:
- Sonnet 3.5 (Tool Calling Era): Marked a significant leap, reliably handling multi-step, end-to-end tasks within a codebase. It was the first model to consistently enable tool calls for day-to-day coding work.
- Opus 4.5 (Long-Running Task Era): Signified a shift where models could handle tasks taking hours instead of minutes, testing their own work and maintaining context over longer durations. This model could often figure out complex tasks with a single, high-level prompt.
- Mythos (Orchestration Era): Represents the latest jump, where the model doesn’t just understand code but also understands itself. It can spawn additional models, break down work, complete it reliably, and verify the output without requiring custom tooling or a “software factory.” Browne emphasizes that simply prompting it to “go further” can yield surprising results.
Browne argues that this rapid advancement necessitates a fundamental change in how software engineers approach product development. He states, “we need to go bigger” because models are improving faster than human engineers can. To achieve this, developers must “get over ourselves” and challenge deeply ingrained legacy constraints and habits.
He draws an analogy to Apple’s shift with iOS 7, moving away from skeuomorphism in design. Just as iOS 6 apps mimicked physical objects (e.g., a compass app looking like a physical compass) to convince users of their utility, current software development is in its own skeuomorphic phase. Browne contends that familiar tools like terminals, Git, and even the mental models around them are no longer optimal. He criticizes conventions like:
- Terminal-centric workflows: Natural language, he argues, has no place in a terminal, yet developers cling to it out of familiarity.
- Git limitations: The inability to commit environment files without additional systems is an example of an outdated practice accepted because “it’s just how Git was built.”
- Developer identity tied to languages: The notion that knowing a specific language defines a “real developer” is dismissed as an outdated and unhelpful construct.
- Fear of deleting code: Developers often suffer from a sunk cost fallacy, leading to “guilt merges” of suboptimal code rather than starting fresh, a problem AI agents don’t share.
The speaker then illustrates how these shifts redefine project scope. What was once categorized as a “side project” (e.g., a simple web scraper), a “startup” (e.g., a complex collaboration tool), or “too big” (e.g., a full-stack cloud platform) has fundamentally changed. He introduces the concept of a “Markdown tier” where entire “startups” can now be reduced to a Markdown file executed by an LLM on a cron job, performing complex tasks like triaging GitHub PRs and generating daily work plans. This highlights the collapse of the barrier to entry for many projects.
This redefines what “too big” means, suggesting the limits are now much further out, potentially involving training bespoke models or building entirely new operating systems. Browne clarifies that “going bigger” isn’t just about building deeper features within a narrow vertical, but thinking wider—expanding the breadth of product functionality. Historically, startups competed with giants like AWS by offering deeper features in a niche. Now, with AI agents, it’s viable to cover a wider spectrum. A small team can integrate a database platform into their product in days, rather than months or years.
The key is to architect products for user-driven extensibility. He cites Slack as an accidental example, where its APIs allowed users to build features (like agent orchestration) that the original developers never envisioned. Browne concludes with a provocative call to action: engineers should aim to build ambitious projects that might initially seem “stupid,” such as competing with Slack, AWS, or Salesforce. If an idea doesn’t feel absurdly large, it’s likely not ambitious enough for the current AI-powered landscape.