What do we build now? — Theo Browne, @t3dotgg

At-a-Glance

• Verdict: Watch fully
• Core thesis: AI models now enable developers to build breadth-first products at startup/side-project scale that previously required large teams, so entrepreneurs must abandon legacy developer identity/tooling assumptions and 'think wider' instead of deeper to compete with incumbents.
• Why it matters: This reframes the entire startup/product opportunity space: what was 'too big' a year ago is now feasible for solo builders, and what was a startup is now a side project (or even a markdown file on a cron). If you're not rethinking scope assumptions, you're building at the wrong tier.
• Best use: Internalize the 'tier shift' mental model (side project → markdown file; startup → side project; too big → startup) and apply the breadth vs. depth framework to identify opportunities where AI lets you cover wide feature surfaces competitors can't justify staffing for.

Executive Summary

Theo Browne argues developers are experiencing 'AI psychosis'—a disorienting phase where model capability leaps (Sonnet 3.5 for tool calls, Opus 4.5 for multi-hour tasks, Mythos for orchestration) are outpacing human mental models of what's buildable. He traces his own journey from Sonnet 3.5 enabling reliable tool calls in codebases, to Opus 4.5 completing hours-long tasks autonomously, to Mythos spawning sub-models and orchestrating verification without custom tooling. The key insight: you must 'go bigger' to see new model value, because most legacy Jira tickets are trivially solvable by Opus 4.5, and Mythos unlocks entirely new project scales.

Browne challenges developers to abandon 'skeuomorphic' attachment to legacy tools (terminals, Git, Vim, language identity, sunk-cost code preservation) that made sense when hiring was scarce but now constrain ambition. He draws an analogy to iOS 7's shift from skeuomorphic design (fake leather, bookshelves) to flat interfaces: once adoption was won, Apple stopped 'convincing' and started optimizing utility. Developers are stuck in the 'convince' phase, treating terminals and Git workflows as sacred when natural language interfaces and AI-native patterns (like committing .env files or deleting code guilt-free) are more effective.

The talk's centerpiece is a 'tier shift' framework: Browne's Reddit scraper (side project, 2021), Ping/Zoom-for-streamers (startup, YC 2021), and Pulse.Cloud full-stack platform (too big, current) used to map to three tiers. Now, with models like Mythos, everything drops one tier: startups become side projects, side projects become markdown files on cron (he runs a daily PR triage service as a single markdown prompt), and 'too big' shrinks to startup scale. He doesn't know what 'too big' means anymore—training models? Building an OS?—but that uncertainty is the opportunity.

Browne reframes 'bigger' as 'wider': instead of competing on depth (Vercel's deep front-end features vs. AWS's breadth), AI lets you build breadth-first—cover a wide surface area with 'enough' features in each vertical, then let users build missing depth themselves if you architect for extensibility (like Slack accidentally did with bots). His closing provocation: if your idea doesn't feel stupid, it's not big enough. It's time to compete with Slack, build native operating systems, challenge Salesforce directly—because the models make it feasible and the old gatekeepers (hiring, time, complexity) are gone.

Key Takeaways

• Claim: Model capability is advancing through discrete 'eras': Sonnet 3.5 = tool call era, Opus 4.5 = long-running task era, Mythos = orchestration era where models spawn sub-models and verify work autonomously. | Evidence: Browne tested all three models hands-on. Sonnet 3.5 was first to reliably call tools in codebases for day-to-day work. Opus 4.5 completed multi-hour tasks end-to-end without losing context. Mythos 'understands itself' and will spawn additional models to break up and verify work if you simply prompt it to do so, no custom tooling required. | Caveat: Browne admits he was wrong before about hitting a wall, suggesting his predictions about model pace may still be incomplete. He also notes you won't see Mythos benefits if you're not pushing the model with bigger tasks—most legacy Jira tickets won't showcase its orchestration strengths. | Implication: Entrepreneurs and operators must continually raise their ambition ceiling to match model progress. If your product roadmap is still scoped to what Opus 4.5 could do six months ago, you're already underutilizing current capabilities. The 'go bigger' imperative is literal: start projects you'd have rejected as infeasible last year. | Timestamp: 00:30 - 03:45
• Claim: Developers are in a 'skeuomorphic phase' treating legacy tools (terminals, Git, Vim, language identity) as sacred when they're holdovers from a pre-AI world that optimized for scarcity of engineers, not utility. | Evidence: Browne cites absurd norms: Git can't commit .env files (requires separate secret-sharing systems); developers guilt-merge PRs to avoid conflict despite knowing code is wrong; senior engineers dismiss others based on language (JavaScript devs 'not real'); terminals force natural language through command-line interfaces where it doesn't fit. He parallels this to iOS 6's fake leather/bookshelves—interfaces designed to 'convince' users, not serve them—vs. iOS 7's flat, information-dense redesign once adoption was won. | Caveat: Browne self-identifies as a terminal/Vim lover and notes most audience members have 10+ years of coding muscle memory, so these attachments are deeply ingrained. He doesn't offer a concrete replacement interface, only the call to question assumptions. | Implication: Product builders should audit their own stack and workflows for 'skeuomorphic' decisions—choices made because 'that's how we've always done it' rather than because they optimize for AI-native patterns. For example: why not let agents commit secrets if the repo is private? Why not let agents delete and rewrite code without developer guilt? Why not architect around natural language interfaces instead of CLI emulation? | Timestamp: 04:10 - 07:50
• Claim: The 'tier shift': what was a startup in 2021 is now a side project; what was a side project is now a markdown file on cron; what was 'too big' is now startup-scale. | Evidence: Browne's Reddit scraper (2-3 days, 2021) = side project. Ping/Zoom-for-streamers (YC startup, 2021) = startup tier. Pulse.Cloud (Vercel + auth + databases, in progress) = too big. He now categorizes Ping-level ideas as side projects, and his PR triage service—which he used to run as a multi-component system—is literally a markdown file with a prompt ('go to these four repos, triage PRs, update static HTML, push to S3') running on 9am cron. Output ready by 9:15-9:20 daily. | Caveat: Browne admits he doesn't know what 'too big' means anymore—training models from scratch? Building an OS? Competing with npm/Node directly? The upper bound is undefined, which is both scary and exciting. Also, he's personally building Pulse.Cloud and warns attendees not to compete ('LakeBid coming soon'). | Implication: Operators and founders must re-scope their product ambitions upward by at least one tier. If you're building a feature, ask if it should be a product. If you're building a product, ask if it should be a platform. If you're building a platform, ask if you're thinking wide enough (see next takeaway). For Ken's agent/investing lens: many current 'startups' pitching at events could be automated markdown files, which means the bar for fundable startups has risen dramatically. | Timestamp: 08:00 - 11:30
• Claim: Strategic shift from 'deeper' (Vercel's narrow, deep feature set) to 'wider' (covering broad surface area with extensible architecture so users build missing depth themselves). | Evidence: Vercel beat AWS not by matching AWS breadth but by going deeper in full-stack front-end. That model required sacrificing breadth because you didn't have thousands of engineers. Now, AI lets you build a database platform 'in a day or two of work with enough prompting' (not RDS-reliable, but enough to let users start). If you architect for extensibility (like Slack accidentally did with bots), users will add features you never imagined. Browne: 'Slack sucks. It's not a good product, but it's the right shape' because half of agent workflows now run in Slack due to its bot APIs. | Caveat: Browne clarifies he's not saying you can match RDS reliability in two days—only that you can ship a minimally viable database feature that lets users start and extend it themselves if your architecture is open enough. He also notes 'if you build your stuff right' multiple times, implying non-trivial design choices around extensibility. | Implication: Product strategy should prioritize breadth + extensibility over depth in any one vertical. For agent platforms, this means enabling users to script/automate/extend rather than building every feature yourself. For Ken's operator lens: look for platforms with narrow surfaces trying to go deep (old model) vs. platforms with wide surfaces and extensibility primitives (new model enabled by AI). The latter is the investable architecture. | Timestamp: 12:00 - 14:50
• Claim: If your startup idea doesn't feel stupid, it's not big enough. It's time to compete with Slack, build native operating systems, challenge Salesforce directly. | Evidence: Browne's closing provocation after walking through tier shifts and breadth-first strategy. He acknowledges it 'sounds stupid' to suggest building a Slack competitor or OS or Salesforce alternative, but argues the old gatekeepers (team size, time, hiring constraints) that made these infeasible are gone. The models make it possible; the mental blockers are now the constraint. | Caveat: No concrete playbook provided for how to execute these 'stupid' ideas, only the framing that they're now feasible. Browne's own Pulse.Cloud example is still in progress, so he hasn't validated this thesis with a shipped product yet. | Implication: For founders and operators, this is a litmus test for ambition calibration. If your pitch feels 'reasonable' or 'achievable with current tools,' you may be underindexing on model capability gains. For Ken's investing lens: look for founders pitching ideas that sound absurdly overscoped—those may be the only ones correctly calibrated to the new tier structure. Conversely, 'safe' pitches may be building at the markdown-file tier and not realizing it. | Timestamp: 14:55 - 15:50

Detailed Brief

Model Evolution & the 'Go Bigger' Imperative

• Claims: Three model eras in recent months: Sonnet 3.5 (tool call era), Opus 4.5 (long-running task era), Mythos (orchestration era); Sonnet 3.5 was first to reliably call tools in context of a codebase for daily coding work; Opus 4.5 could complete multi-hour tasks end-to-end without losing track, no longer requiring step-by-step prompting; Mythos understands itself and can spawn additional models, break up work, and verify results autonomously—just prompt it to do so; Most of Browne's previous Jira tickets at his last job could be trivially solved by Opus 4.5; his previous work wouldn't benefit from Mythos; Models are getting better faster than humans are, so humans can't 'get better'—they have to 'go bigger'
• Evidence: Browne's hands-on testing of all three models across his own codebases and projects; Audience poll: majority raised hands for having used Sonnet 3.5; fewer felt a big jump to Opus 4.5 (but most did); substantial number have tried Mythos/Fable; Mythos doesn't just write/test code—it orchestrates sub-tasks without custom software factories or tooling, responding to natural language orchestration prompts
• Caveats: Browne admits he was wrong before when he claimed models were hitting a wall, implying his model capability predictions may still be incomplete; You won't see Mythos benefits if you're not pushing the model with bigger, more complex tasks—incremental work won't showcase orchestration; No specific reliability benchmarks or failure mode discussion for Mythos orchestration in production use cases
• Implications: Product roadmaps scoped to Opus 4.5 capabilities (six months ago) are already obsolete; teams must continuously raise ambition to match model pace; For agent/AI operators: if your automation is still task-by-task prompting (Opus 4.5 era), you're missing Mythos's orchestration leverage—prompt for multi-step breakdowns and verification upfront; For Ken's investing lens: founders still pitching 'AI-assisted' tools rather than 'AI-orchestrated' platforms may be behind the curve; look for pitches that assume orchestration as the baseline

Developer Skeuomorphism & Legacy Tool Attachment

• Claims: Developers are in a 'skeuomorphic phase' treating terminals, Git, Vim, and language identity as sacred when they're legacy interfaces optimized for pre-AI constraints; Absurd norms: Git can't commit .env files (requires separate secret-sharing systems); developers guilt-merge bad PRs to avoid conflict; language identity (e.g., 'JavaScript devs aren't real') persists even among seniors; Terminals are not good interfaces for natural language but devs pretend they are because terminals are familiar and beloved; These choices were defensible when engineers were scarce (companies couldn't say no to developer tool preferences), but that rationale no longer holds; iOS 7 analogy: Apple shifted from skeuomorphic design (convincing users iPhones could replace physical tools) to flat, utility-focused design once adoption was won; developers need the same shift
• Evidence: Browne's personal attachment to terminal/Vim despite recognizing their limits; Audience poll: majority raised hands for 10+ years coding experience; substantial number for aspiring/current Vim users; Specific examples: .env file exclusion from Git; guilt merging PRs; 'he writes JavaScript, not a real developer' dismissals; iOS 6 vs. iOS 7 compass UI comparison: skeuomorphic compass looked like physical compass but conveyed less info; flat iOS 7 compass shows clearer directional data, red lock indicator, current heading
• Caveats: Browne acknowledges these attachments are deeply ingrained (he loves his terminal) and doesn't offer a fully fleshed-out replacement interface; No concrete alternative workflow proposed—only the call to question assumptions and be willing to abandon legacy patterns; Some legacy tools (Git, terminals) have network effects and ecosystem lock-in that make replacement non-trivial even if interfaces are suboptimal
• Implications: Product builders should audit their own stack for 'skeuomorphic' decisions: are you building CLI wrappers for AI because that's familiar, or because it's optimal? Are you preserving Git workflows (no .env commits, branch/PR rituals) because they serve AI agents, or because they served human teams?; For agent operators: rethink interfaces—if agents can read/write natural language and execute across repos, why emulate human Git/CLI patterns? Consider agent-native workflows (e.g., agents commit secrets to private repos, agents delete/rewrite without human approval gates); For Ken's content/AI ops: this is a strong meme/talking point for developer-focused content—'are you building skeuomorphic AI tools?' could resonate as a frame for critiquing overly cautious or legacy-bound AI product design

The Tier Shift: Startups → Side Projects → Markdown Files

• Claims: Three projects Browne built/is building: Reddit scraper (side project, 2-3 days, 2021), Ping/Zoom-for-streamers (YC startup, 2021), Pulse.Cloud full-stack platform (too big, current); A year ago, these mapped to three tiers: side project, startup, too big. Now, everything is one tier lower: markdown file, side project, startup; Many startups at the event could be side projects or even markdown files—'do you know how many companies are at this event where their whole product could just be a markdown file?'; Browne's PR triage service: used to be a multi-component system; now it's a markdown file with a prompt ('go to these four repos, look at open PRs, figure out status, help me prioritize, update static HTML, push to S3, give me URL') running on 9am cron, ready by 9:15-9:20; Executing markdown by piping to Codex/Claude is 'unbelievable' and underappreciated; 'try that if you haven't'; Browne doesn't know what 'too big' means anymore—training your own model? Building an OS? Competing with npm/Node directly?
• Evidence: Browne's three projects with explicit 2021 vs. current timelines; Daily cron markdown file for PR triage running in production for Browne personally; Audience context: event attendees include startup founders pitching ideas Browne considers markdown-file-tier
• Caveats: Pulse.Cloud (the 'too big' → startup example) is still in progress, so Browne hasn't validated the tier shift with a shipped product at the new 'startup' scale yet; Browne's uncertainty about the new 'too big' upper bound suggests the tier framework may be unstable or still evolving as models improve further; Markdown-file-tier projects still require some engineering sophistication (cron setup, S3, GitHub API access)—not literally zero-effort for non-technical users, though Browne implies the delta is small
• Implications: For founders: if your startup pitch could be executed as a markdown file on cron, you're likely building at the wrong tier and won't be fundable. Re-scope upward by at least one tier (side project → startup, startup → platform).; For operators: audit your internal tools and automation—how many multi-component services could collapse into prompted markdown scripts? This is low-hanging fruit for cost reduction and maintenance simplification.; For Ken's investing lens: due diligence should include 'could this be a markdown file?' as a disqualifying question. If yes, the startup is mis-scoped. Conversely, look for founders who are building at the 'sounds too big' tier—those may be the only ones correctly calibrated to current model capabilities.; For content/GTM: the 'markdown file on cron' example is extremely memeable and concrete—strong hook for developer content ('I replaced my SaaS with a markdown file') or for illustrating AI capability to non-technical audiences.

Breadth vs. Depth: Think Wider, Not Deeper

• Claims: 'Bigger' is the wrong framing; the right framing is 'wider'—breadth (range of things software covers) vs. depth (number of features in a given area); Old startup model: compete with AWS by going deeper in a narrow vertical (Vercel's full-stack front-end depth) because you can't match AWS breadth without thousands of engineers; AI changes this: 'all of a sudden, that range is viable in a way that it never was before'—you can build a database platform 'in a day or two of work with enough prompting' (not RDS-reliable, but enough to let users start); If you 'build your stuff right' and 'play your cards correctly,' you can cover a wide spectrum with enough features to let users try the product; when users need features you don't support, 'it's not your problem' if you've architected for extensibility—users can build missing features themselves; Slack example: 'Slack sucks. It's not a good product, but it's the right shape'—Slack accidentally became the platform for running agents because its bot APIs are extensible enough, even though the core product is weak
• Evidence: Vercel vs. AWS comparison: Vercel will never match AWS breadth, but front-end devs feel pain without Vercel because it's deeper in its niche ('even the agents prefer it'); Browne's claim you can build a database platform in 1-2 days with prompting (no reliability comparison to RDS, but functional enough for users to start); Slack is now 'the platform people run their agents in half the time' due to bot APIs, despite Slack itself being a poor product
• Caveats: Browne explicitly clarifies: 'I'm not saying you can build something as reliable as RDS'—the breadth-first approach sacrifices depth/reliability in any one vertical, betting on extensibility to fill gaps; 'If you build your stuff right' is repeated multiple times without specifics on what 'right' means architecturally—implies non-trivial design choices around APIs, modularity, user scripting/extension primitives; Slack's success as an agent platform was accidental, not intentional design, which suggests extensibility architecture is hard to get right even for well-resourced companies
• Implications: Product strategy should prioritize breadth + extensibility over depth in any one vertical: ship a database, auth, file storage, etc. at 'good enough' quality, then expose APIs/scripting so users can extend what you haven't built. The combinatorial surface area is your moat, not the depth of any one feature.; For agent platform builders: extensibility is the unlock—if your platform lets users script/automate/compose features you didn't build, users will tolerate missing depth because they can fill it themselves. This is the inverse of the old SaaS model (deep, opinionated, best-in-class features).; For Ken's investing lens: evaluate platforms on extensibility primitives, not feature completeness. Does the platform expose APIs, allow user scripting, support composability? If yes, breadth-first is viable. If no, the startup is stuck in the old depth-first model and will lose to breadth-first competitors enabled by AI.; For Ken's operator/AI ops work: apply this to internal tooling—instead of building deep, custom tools for each workflow, build a thin extensible layer (like Slack bots) and let teams script their own depth. This is how you scale tooling without scaling headcount.

Closing Provocation: Compete with Slack, Salesforce, Build an OS

• Claims: If your idea doesn't feel stupid, it's not big enough; It's time to compete with Slack, build your own native OS, challenge Salesforce directly; These ideas sound stupid, but the old gatekeepers (hiring, team size, time, complexity) are gone—models make them feasible now; The mental blockers (not the technical ones) are the remaining constraint
• Evidence: Browne's own Pulse.Cloud project (Vercel + auth + databases) as an example of tackling 'too big' scope; Tier shift framework: what was too big a year ago is startup-scale now, so Slack/Salesforce competitors are newly viable; Slack's weakness ('it sucks, it's not a good product') as evidence that incumbent products are vulnerable if you build the right extensible architecture
• Caveats: No concrete playbook for executing these 'stupid' ideas—Browne provides framing and permission, not tactics; Pulse.Cloud is still in progress ('LakeBid coming soon'), so Browne hasn't validated this thesis with a shipped product yet; Competing with Slack/Salesforce involves non-technical moats (network effects, enterprise sales, compliance, integrations) that AI doesn't directly address—Browne focuses on technical feasibility, not GTM
• Implications: For founders: use 'does this feel stupid?' as a calibration check. If your pitch feels achievable/reasonable, you're likely underindexing on model capabilities and building at the wrong tier. Aim for ideas that sound absurdly overscoped by last year's standards.; For Ken's investing lens: 'stupid' ideas may be the only correctly scoped ones. Look for founders pitching Slack/Salesforce/OS competitors who understand the tier shift and breadth-first strategy. Conversely, 'safe' pitches (incremental SaaS features, niche tools) are likely mis-scoped and vulnerable to markdown-file-tier automation.; For operators: challenge your own ambition ceiling. Are you building the biggest thing you can imagine, or the biggest thing you think is 'reasonable'? The gap between those two is where the new opportunity space lives.; For Ken's content/GTM: this is a strong closing hook for developer-focused talks/content—'if your idea doesn't feel stupid, it's not big enough' is memorable and actionable, and frames ambition as the key unlock rather than technical skill or resources.

Notable Concepts & Terms

• AI psychosis: Browne's term for the disorienting state developers are in as model capability leaps outpace mental models of what's buildable. Used as an audience rapport-builder ('who here feels AI psychosis?') and framing device for the talk's central argument that developers must radically re-scope ambitions.
• Tool call era / Long-running task era / Orchestration era: Browne's taxonomy for discrete model capability jumps: Sonnet 3.5 reliably called tools in codebases; Opus 4.5 completed multi-hour tasks end-to-end; Mythos spawns sub-models and orchestrates verification autonomously. Maps to specific model releases and represents qualitative, not just quantitative, capability shifts.
• Skeuomorphism (developer context): Design aesthetic where digital interfaces mimic physical objects to convince users of utility (e.g., iOS 6's leather calendar, bookshelf). Browne argues developers are stuck in this phase, treating terminals/Git/Vim as sacred because they're familiar, not because they're optimal for AI-native workflows. Calls for an 'iOS 7' shift to utility-first design.
• Tier shift: Browne's framework for how AI collapses project scope tiers: what was a startup a year ago is now a side project; what was a side project is now a markdown file on cron; what was 'too big' is now startup-scale. Central to his argument that founders must re-scope ambitions upward by at least one tier to match model capabilities.
• Markdown file on cron (as a product tier): Browne's term for the new bottom tier of software: a single markdown file with a natural language prompt, executed by piping to Claude/Codex, running on a scheduled cron job. His PR triage service is a live example. Represents the collapse of multi-component services into prompted scripts, and a litmus test for whether a 'startup' is mis-scoped.
• Breadth vs. depth: Strategic framing for product scope: breadth = range of things software covers; depth = number of features in a given area. Old startup model was depth-first (Vercel's deep front-end features vs. AWS breadth) because breadth required large teams. AI enables breadth-first strategies: cover wide surface area, let users build missing depth via extensibility. Key to Browne's argument for 'thinking wider' instead of 'bigger.'
• Pulse.Cloud: Browne's in-progress project: 'imagine Vercel, but it goes further each direction—auth built in, databases built in.' Example of tackling 'too big' scope that's now startup-feasible due to AI. Also a stealth flex ('LakeBid coming soon, don't compete with me') signaling Browne is betting his own reputation on the tier shift thesis.
• If your idea doesn't feel stupid, it's not big enough: Browne's closing provocation and litmus test for ambition calibration. Argues founders should aim for ideas that sound absurdly overscoped (Slack competitors, native OS, Salesforce alternatives) because the old gatekeepers (team size, time, hiring) are gone. Mental blockers, not technical ones, are the remaining constraint.

Operator Notes / Why Ken Should Care

• For AI operators: Browne's 'go bigger' imperative applies directly to internal automation—if you're still building task-by-task workflows (Opus 4.5 era), you're missing Mythos's orchestration leverage. Prompt agents to break up multi-step work and verify results upfront, rather than chaining discrete tasks manually.
• For agent system builders: the breadth vs. depth framework is critical for platform strategy. Prioritize breadth (cover wide surface area: DB, auth, storage, etc.) + extensibility (APIs, scripting, composability) over depth in any one feature. Let users build missing depth themselves. This is the moat in the AI era.
• For Ken's investing lens: use 'could this be a markdown file?' as a disqualifying question in due diligence. If yes, the startup is mis-scoped. Look for founders pitching 'stupid' ideas (Slack/Salesforce competitors, OS-level products) who understand tier shifts and breadth-first strategy. These are the only correctly calibrated pitches.
• For content/GTM: Browne's talk is highly memeable—'AI psychosis,' 'markdown file on cron,' 'if it doesn't feel stupid, it's not big enough' are all strong hooks. The skeuomorphism analogy (iOS 6 → iOS 7) is also a powerful frame for critiquing legacy-bound AI tool design. Consider adapting these for developer-focused content or founder education.
• For workflow/ops: audit your own stack for skeuomorphic decisions—are you building CLI wrappers, preserving Git/PR rituals, or avoiding .env commits because that's how humans worked, or because it serves agents? Consider agent-native workflows (e.g., agents commit secrets, delete code without approval gates) where legacy constraints don't apply.
• For business strategy: Browne's breadth-first + extensibility model inverts traditional SaaS (deep, opinionated, best-in-class features). If you're building a platform, ask: are you competing on depth (old model, requires large team) or breadth + extensibility (new model, enabled by AI)? The latter is the only sustainable strategy if models keep improving.
• For Ken's portfolio/founder conversations: Browne's 'tier shift' framework is a strong mental model for calibrating ambition. Many founders are still pitching at the 'safe' tier (side projects, incremental features) when they should be pitching at the 'stupid' tier (platform plays, incumbent displacement). Use this as a coaching framework to push founders to think wider.

Watch Map

• 00:00: Intro: 'AI psychosis' framing, audience poll on who feels it
• 00:30: Model evolution: Sonnet 3.5, Opus 4.5, Mythos—tool call era, long-running task era, orchestration era
• 03:45: 'We need to go bigger'—models are outpacing humans, most previous work trivially solvable by Opus 4.5
• 04:10: Developer skeuomorphism: iOS 6 vs. iOS 7 analogy, terminals/Git/Vim as legacy interfaces
• 06:20: Examples of absurd norms: can't commit .env files, guilt merging PRs, language identity, sunk cost with code
• 08:00: Three projects & tier shift: Reddit scraper (side project), Ping (startup), Pulse.Cloud (too big) → now markdown file, side project, startup
• 10:00: Markdown file on cron: PR triage service as single markdown prompt, runs daily at 9am, ready by 9:15-9:20
• 11:30: Doesn't know what 'too big' means anymore—training models? Building an OS? Competing with npm?
• 12:00: Breadth vs. depth: Vercel vs. AWS, old model was depth-first, AI enables breadth-first + extensibility
• 13:30: Can build a database platform 'in a day or two' with prompting—not RDS-reliable, but enough to start; let users build missing depth
• 14:00: Slack example: 'Slack sucks, not a good product, but right shape'—extensible bot APIs make it the agent platform despite weak core
• 14:55: Closing provocation: compete with Slack, build native OS, challenge Salesforce—'if your idea doesn't feel stupid, it's not big enough'
• 15:50: Wrap-up and thank you

Source/Metadata

• Title: What do we build now? — Theo Browne, @t3dotgg
• Transcript words: 5631
• Duration seconds: 961
• Timestamp note: Timestamps manually inferred from transcript context and typical 16-minute talk pacing; original transcript did not include granular timestamps, so watch_map times are approximate based on content flow and typical speaking pace (~350 words/min).