Everything we knew about software has changed — Theo Browne

What changes when a coding model can finish a multistep task, then handle implementation and testing, then delegate work to other models? Theo Browne opens with the disorientation of experiencing those changes in quick succession, jokingly calling it “AI psychosis.” His starting point is Sonnet 3.5: a model that made end-to-end coding tasks feel practical because it could carry out several steps of real work.

Opus 4.5 extended that experience beyond writing code and calling tools. Browne describes it testing its work, bringing an implementation into a usable state, and completing tasks that took hours rather than minutes. He then introduces Mythos and asks who has tried it and Fable. But a stronger model given the same small prompt may not feel substantially different. The capability change becomes visible only when the assignment demands more.

Browne organizes that progression into three eras. These are his assessments of working with the models, rather than comparative benchmark results.

Sonnet was not the first model with tool calls; the distinction was sufficient reliability inside a codebase. Opus could retain the task well enough to work toward an outcome without repeated instructions for each next step. With Mythos, Browne sees a further ability to organize additional model workers and check their contributions.

In his experience, prompting for that delegation and verification can be enough; a bespoke software factory is not a prerequisite. Larger assignments reveal capabilities that familiar tickets may never exercise. Most of the Jira tickets from his previous job, he says, were already within Opus 4.5’s reach, leaving little extra benefit for Mythos to demonstrate. Having previously predicted a capability wall, he now retracts that position: if models keep improving faster than developers adapt, the response is to expand the scope of what they attempt.

Expanding scope also means questioning habits acquired over years of development. Browne’s own attachments run deep: GNU Screen, then tmux, along with SSH and Git, entered his workflow before he began writing code. To explain why familiarity can outlast its usefulness, he turns to the iPhone compass from iOS 6 and earlier. Its interface resembles a photograph of a physical instrument placed inside a phone.

The move to iOS 7 can look like a loss of craft if the comparison stops at visual resemblance. Browne offers another interpretation: the earlier compass needed to convince people that a phone could replace a real compass. A bookshelf interface and animated page turns similarly made digital books feel like credible substitutes for paper. Once users accepted those substitutions, the interface could concentrate on usefulness instead of reassurance.

His concrete example is the newer compass’s separation of the direction a user has locked onto from the direction the phone currently faces. He points to a red block indicating deviation and a large 228 heading that makes the current direction easier to read. The gain is more legible information about the task, even if the presentation initially feels less familiar.

Browne sees software development in a similar skeuomorphic phase: new capabilities are being fitted into interfaces developers already identify with. He loves his terminal, yet argues that natural-language interaction belongs elsewhere. The attraction of the terminal—and the recurring aspiration to become a Vim user—can reflect a preferred image of being a programmer as much as suitability for the current task.

That attachment extends to frameworks, languages, and the boundaries imposed by existing tools. Consider his question about environment files: why does a team need a separate sharing system for this particular file when the rest of the project travels through Git? The useful challenge concerns the fragmented workflow, not permission to commit plaintext credentials. A better way to share configuration still needs to protect secrets. Browne’s broader test is whether a convention serves the work or survives because developers have stopped questioning how their tools divide it up.

Language identity produces the same problem at different experience levels. A junior engineer introduces themselves through JavaScript; a senior engineer dismisses someone for writing it. Both make a tool choice stand in for engineering ability. Browne connects the persistence of those preferences to historical hiring scarcity: a company might accept an engineer’s choices rather than face a lengthy search for a replacement. His illustrative six-month hiring scenario describes bargaining power, not a measured hiring average.

Attachment to an implementation can be just as costly as attachment to a tool. Sometimes the appropriate solution is to delete code and restart. Yet when a teammate has spent a week or two on a pull request, rejecting an unsuitable solution means having an uncomfortable conversation. Browne calls the alternative “guilt-merged”: accepting the work because of the effort invested rather than because it solves the problem well.

Agent work removes that particular interpersonal pressure. Stopping an agent or discarding its implementation does not hurt its feelings. The opportunity is to judge the result with less sunk-cost attachment—and then apply the same willingness to reconsider assumptions when choosing what to build next.

Three projects make the change in ambition concrete. Browne’s Reddit scraper collected top programming-humor posts and formatted them for copying to Twitter. He reports building it in two to three days. Ping, the startup he took through Y Combinator, tackled a larger problem: high-quality collaboration for live creators inside OBS, the software they already used. His third project, a fullstack cloud, extends the Vercel concept in both directions, with authentication and databases built in. He built the scraper and Ping in 2021; the cloud project was underway at the time of the talk.

Before the latest model improvements, he would have classified those projects as follows:

The downward shift is a heuristic for changing development economics, not a claim that every product’s operating demands shrink equally. Its immediate consequence is uncomfortable: some ideas that still look like startups may now fit within the scope of a side project.

The new category below a side project is what Browne jokingly calls the “GBrain tier”: a Markdown file. The mechanism is that Codex or Claude can receive written instructions and act on them. Markdown supplies the task description; the agent runtime supplies interpretation, tools, and execution. The file is not itself an execution engine.

His example is a service that previously triaged pull requests, arranged AI reviews, and helped him prioritize work. He replaced it with instructions describing the desired result:

1. Visit four GitHub repositories and inspect their open pull requests.
2. Determine the current status of the work and help prioritize it.
3. Update a static HTML file with the resulting overview.
4. Upload that file to S3 and return its URL.

Browne reports that a daily 9 AM cron run produces his work overview around 9:15–9:20. That schedule describes his own workflow, not a general completion-time guarantee.

The distinctive change is how little dedicated application logic he needs to express the workflow. Repository inspection, prioritization, report generation, and publication are described as a goal for an agent rather than maintained as an entire bespoke service. A recurring task can therefore be small enough to live as an instruction file invoked by cron.

Browne names his forthcoming fullstack cloud Lakebed, announced here as coming soon, and jokes that the audience should leave that particular opportunity to him. But moving a cloud platform into the startup tier leaves an empty category above it. He no longer knows what belongs under too big.

Training a model from scratch, building an operating system, or competing directly with npm and Node are possible boundary tests, not accomplishments he claims or projects whose feasibility he establishes. Finding the new limit requires attempting work beyond what previously seemed sensible. That leads him to refine the direction of ambition: think wider, not merely bigger.

Every product has breadth, the range of areas it covers, and depth, the features it provides within an area. Browne compares AWS’s broad range with Vercel’s deeper attention to frontend-oriented fullstack hosting. Vercel does not need every AWS feature to offer a better experience for that particular kind of development. He considers that experience strong enough to attract both developers and agents.

Specialization was also a practical constraint. A startup could not reproduce the range of services supported by an incumbent’s thousands of engineers, so it competed through depth in a narrower area. Browne now sees more of that horizontal range becoming viable for smaller teams. His qualification is explicit: broader implementation capacity does not mean matching the reliability of RDS.

Browne claims that, with enough prompting and effort, a database platform can be added to a product in a day or two. The strategic target is enough functionality across relevant areas for users to start trying the product. It does not require every vertical to begin with a mature platform’s full feature set. What happens when users reach those missing features depends on how the product is architected.

Breadth becomes more useful when users can supply depth themselves. An extensible product lets them implement missing features and workflows the original developers would never have anticipated. Slack is Browne’s example: despite his criticism of the product, its bot APIs give people a place to build and run agent workflows. The enabling property is the platform’s shape—its capacity to accept new behavior—not the vendor anticipating every use case.

That combination changes which competitors a small team might consider challenging. Browne ends by naming Slack, AWS, and Salesforce: established platforms whose scope once made direct competition seem absurd. The invitation is to test that assumption with broader products that users can extend. An idea that still feels entirely reasonable, he suggests, may be constrained by an outdated sense of what is possible.