AI models have moved from reliable tool calling to long-running work and orchestration, so engineers need to ask them to handle larger tasks.
2
Many software habits, from terminal-centric workflows to language-based developer identities, persist because they are familiar rather than useful.
3
The practical limit for small teams has shifted toward wider products, since agents can help build missing platform features and let users extend the product themselves.
Summary
Theo Browne argues that software engineers are still building around assumptions from an earlier era. He describes Sonnet 3.5 as the reliable tool-calling era, Opus 4.5 as the point where models could run tasks for hours, and Mythos as a move toward orchestration. That change makes familiar boundaries feel outdated. He compares terminal-heavy workflows and Git conventions with skeuomorphic iPhone design, where digital tools copied physical objects before designers began using the medium more directly. Browne then describes a new project scale: work that once looked like a startup can now be a side project, while some recurring services can be a Markdown file run by cron. He does not know what "too big" means anymore. His advice is to think wider across a product spectrum, rather than only building depth in one area. A small team may not match AWS reliability, but it can cover enough adjacent functions to let users start, then extend the system themselves.
AI models have moved through tool calling, long-running work, and orchestration
Browne frames recent models as separate eras. Sonnet 3.5 made tool calls consistent enough for day-to-day coding inside a codebase. Opus 4.5 could keep track of longer tasks, test its work, and reach a good state over hours instead of minutes. Mythos adds orchestration: Browne says it understands its own role well enough to spawn other models, divide work, and verify the result. He says this can happen from a prompt, without a custom software factory. The change matters because ordinary tickets from his previous job could already be solved by Opus 4.5, while Mythos demands projects that require more than routine implementation.
Engineers need to build larger problems as models improve faster than their habits
Browne says the models are getting better faster than engineers are, so the response cannot be to keep making the same work slightly more efficient. He tells the audience to go bigger and push both the models and their own ideas further. That requires giving up strong opinions formed over years of programming. He recalls learning screen, tmux, SSH, and Git before he even wrote code. Those tools became part of his identity, which makes it difficult to ask whether they still fit the work. His argument is practical: when models can solve routine tickets, building another routine ticket system does not make full use of them.
Software developers are still copying old interfaces and conventions because they feel familiar
Browne uses the change from iOS 6 to iOS 7 to explain what he calls software's current skeuomorphic phase. Earlier iPhone apps copied physical objects, such as compasses and bookshelves, to persuade people that a phone could replace them. iOS 7 stopped trying to convince users and used the interface more directly. Browne says developers have not made that shift. They treat terminals as the ultimate interface even though natural language does not fit well there, and they preserve Git conventions such as excluding environment files because that is how the system was built. He also questions identifying engineers by programming language, and keeping code or merging pull requests simply because someone spent time writing it.
AI has shifted the boundary between a side project, a startup, and an oversized project
Browne compares three things he has built: a Reddit scraper that took two or three days, Ping, a startup for OBS-based collaborations that went through Y Combinator, and a broader full-stack cloud product. A year earlier, he would have classified them as a side project, a startup, and something too big. He says the tiers have now moved down by one level. Work that used to require a startup may fit within a side project, and some products at the event might now be a Markdown file. His example is a PR-triage service. A Markdown instruction reads GitHub repositories, reviews open pull requests, updates a static HTML file, uploads it to S3, and runs each morning from cron.
The unknown size of the next project is a reason to keep testing the boundary
Browne says he no longer knows what belongs above the new Markdown, side-project, and startup tiers. Possibilities such as training a model from scratch, building an operating system, or competing directly with npm and Node do not give him a clear answer. He admits that uncertainty is scary, but also says it creates room to test ideas that previously seemed unreasonable. He then changes his language from "bigger" to "wider." The question is no longer only how many features a product has in one area. It is also how much of the surrounding product spectrum a small team can cover.
Small teams can build across a wider product spectrum and let users fill in the gaps
Browne separates breadth from depth. Vercel has deeper features for front-end-leaning, full-stack servers, while AWS covers a much wider range. That breadth used to be out of reach for a small company because it could not match the engineering staff behind AWS. Browne says agents change the calculation. He is not claiming a small team can build something as reliable as RDS, but says it can add a database platform to a product in a day or two with enough prompting and effort. If the system is designed for extension, users can create missing features for their own needs. He points to Slack as an accidental example, since its bot APIs give people a shape in which to run their own agents and features.
"The fact that you can now execute markdown by just piping it to Codex or Claude is unbelievable and I think most of us haven't fully appreciated how insane that is."11:22
Who should watch
You still design products around terminal workflows, Git conventions, or programming-language identities because those choices are familiar.
Your side project or startup depends on recurring tasks that could be expressed as instructions and run on a schedule.
You are building a narrow feature set and need to decide whether the product should cover more adjacent functions or let users add them themselves.
