# Conclusions — Everything we knew about software has changed

**Source:** https://youtu.be/xUnRQ9vLXxo
**Title:** Everything we knew about software has changed — Theo Browne, @t3dotgg
**Duration:** 16:01
**Speaker:** Theo Browne (t3.gg) at AIE

---

## Main thesis

Models are improving faster than developers can. You cannot keep pace by "getting better" at your craft — you have to **go bigger** and, more precisely, **think wider**. That means shedding a whole generation of developer identity (tools, languages, sunk-cost attachment to code) and letting yourself pick ideas that feel embarrassingly ambitious. If your idea doesn't feel stupid, it isn't big enough.

## The three model eras (why capability just jumped again)

Theo frames recent model releases as qualitatively distinct eras rather than incremental upgrades:

| Era | Representative model | What it unlocked |
|---|---|---|
| **Tool-call era** | Sonnet 3.5 | First model to do tool calls consistently and reliably inside a real codebase — good enough for day-to-day coding work. |
| **Long-running-task era** | Opus 4.5 | Multi-hour tasks without losing the plot. Can write code, run it, test it, and drive it to a good state. This is where his "AI psychosis" started (Nov–Dec 2024). |
| **Orchestration era** | Mythos / Fable | Doesn't just understand your codebase — understands **itself**. Spawns sub-models, breaks work up, verifies afterwards. You don't need a "software factory" of custom tooling; a prompt is enough. |

Practical implication: a task that only takes Opus-4.5-shaped work will *not feel any different* on Mythos. You only see the gain if you push scope further. His old Jira tickets could all be trivially solved by Opus 4.5 — none of them would exercise Mythos.

## Get over yourself — the psychological blockers

Long-tenured engineers carry baggage that is now actively holding them back. Theo's iOS analogy: skeuomorphic iOS 6 looked "like a compass" because Apple was still convincing you the iPhone could replace physical objects. iOS 7 dropped that pretense and became more useful precisely because it stopped imitating the past.

Developers are in their skeuomorphic phase right now. Symptoms:

- **Terminal fetishism.** "Natural language has no place in a terminal, but we pretend it does because the terminal's familiar."
- **Language-as-identity.** Both juniors and seniors reduce people to "he writes JavaScript." The framework/language you pick matters far less than it used to, and mattered less than we thought even before.
- **Ceremonial git norms.** Why *can't* we commit `.env` files? Because git was built for one thing and then colonised our brains. Ask whether each convention is right or just old.
- **Sunk-cost merges.** "Guilt-merging" a PR because someone spent a week on it — even when the right answer is to delete and reset. One under-appreciated gift of agents: no guilt when you throw the work away.

## The tier shift — every project category moved down one slot

Theo lays out the tiers he used to think in, and how they've shifted **exactly one level** after the recent model jumps:

| Old category (≈2024) | Example he built | New category (today) |
|---|---|---|
| Side project | Reddit meme scraper | ↓ shifts down |
| Startup | Ping / "Zoom for streamers" (YC) | Side project |
| Too big | Full-stack cloud (Vercel + auth + DB) | Startup |
| — | — | **New "too big" — unknown** |

Below "side project" a new tier appears that didn't exist before:

- **"G-brain tier" = a markdown file.** Executable prose. He replaced a whole PR-triage service with a markdown file piped to Codex / Claude on a 9 AM cron — by 9:15 it has read four repos, prioritised the day's work, and shipped a static HTML file to S3. Many products at AI conferences right now could just be a markdown file.

And the top of the ladder is genuinely open: he admits he no longer knows what "too big" means. Training your own model? Your own OS? Competing head-on with npm? All are on the table. That uncertainty is the point — you find the new ceiling by pushing past what feels reasonable.

## Think **wider**, not just bigger

The reframe: any product has **breadth** (range of areas it covers) and **depth** (features per area). Old rule: you couldn't out-breadth an incumbent, so you picked a vertical and went deep.

- **Vercel vs AWS.** Vercel will never match AWS's breadth; it goes deeper in frontend-leaning full-stack. If you're a frontend dev not on Vercel today, you feel the pain — even the agents prefer it. This was the old, correct playbook.
- **What changed.** Breadth is now viable for small teams. You will not build something as reliable as RDS in a day — but you can bolt a serviceable database platform into your product in a day or two of prompting. Cover enough of the spectrum that users can **start** using it.
- **Let users close the gap.** Architect so users can build the features you don't ship. Slack accidentally became the platform half of everyone's agents run in — not because Slack is good ("Slack sucks") but because its shape lets users extend it via the Slackbot API. Being the right shape beats being feature-complete.

## Actionable takeaways

- **Match your ambition to the model.** If your work would have made sense on Opus 4.5, you are not exercising Mythos. Pick tasks that *require* the new capability — orchestration, multi-agent spawning, self-verifying flows — or you'll conclude the models "aren't that much better."
- **Try replacing a service with a markdown file.** Pick one internal automation, describe it as prose, cron it into Codex/Claude, ship its output somewhere. See how far it goes.
- **Audit your developer identity.** List the tools/rules you cling to (terminal, language, framework, "we don't commit env files"). For each, ask: right, or just habit?
- **Kill code without guilt.** Reset instead of guilt-merging. Especially easier when the author is an agent.
- **Expand breadth deliberately.** Rather than adding the 27th feature to the vertical you own, add a shallow layer in an adjacent vertical. Make it extensible so users fill the gaps.
- **Pick an idea that feels stupid.** Compete with Slack. Build a native OS. Challenge Salesforce. If nothing about the idea makes you flinch, it isn't big enough for the current models.

## Who this is for

Senior developers (10+ years) who feel the models are "impressive but not that useful for what I do" — Theo's argument is that this is a scoping problem on your side, not a capability ceiling on the model's side. Also useful for founders sizing a startup: what looked like a solo-founder impossibility 12 months ago is a plausible side project this quarter.