6.6 KiB
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
.envfiles? 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.