AI Engineer World's Fair 2026
Everything we knew about software has changed — Theo Browne
Read the talk
When agents can do more, build wider
Reliable tool use, longer tasks, and agent orchestration change more than coding speed: they change which projects are worth attempting and how products should let users extend them.
From a talk by Theo Browne
Before you start: Familiarity with Git, pull requests, and coding agents will help with the examples; no model-training background is required.
From completing steps to orchestrating work
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.
| Model | Capability shift | What changes in the workflow |
|---|---|---|
| Sonnet 3.5 | Reliable tool calls | Multistep coding becomes useful day to day. |
| Opus 4.5 | Sustained work | State the goal instead of directing each successive step. |
| Mythos | Orchestration | Decompose work, spawn additional models, and verify 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The compass does not have to look like a compass
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Familiar tools can become inherited constraints
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Rejecting work without guilt
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Yesterday’s startup becomes a side project
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:
| Project | Former category | Revised category |
|---|---|---|
| Reddit scraper | Side project | A smaller category, introduced next |
| Ping | Startup | Side project |
| Fullstack cloud | Too big | Startup |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A scheduled service becomes a Markdown file
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:
- Visit four GitHub repositories and inspect their open pull requests.
- Determine the current status of the work and help prioritize it.
- Update a static HTML file with the resulting overview.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What still counts as too big?
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Breadth becomes a product strategy
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let users build the missing depth
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Anthropic’s original account of Sonnet 3.5’s coding capabilities and internal evaluation.
The Opus 4.5 release announcement, covering coding, agents and computer use.
Further reading
Anthropic explains the relationship between Fable 5 and Mythos 5, their safeguards and release history.
Run prompts noninteractively and integrate Claude Code into scripts with explicit tool permissions.
GitHub’s guidance on credential rotation and the limits of removing secrets from Git history.
Updates since the talk
Build and deploy TypeScript capsules with Lakebed’s database, authentication and runtime tools.
Read the complete timestamped transcript
- 0:00
[upbeat music] Hello, hello.
- 0:18
Fantastic to see you guys here. I still can't believe they're letting me take a stage at something like this, a YouTuber apparently, but can't wait to share a bit about how I've been thinking because if I'm being real,
- 0:31
kind of going through some AI psychosis. Who here would classify how they feel right now as some form of AI psychosis? I want to see some hands.
- 0:39
The re-- those who don't have their hands up yet, don't worry. We'll get you there by the end of this talk if I do everything right. In order to talk about this, I want to start with a bit of a personal journey of my own, and I'm going to go through this the way anybody does in modern
- 0:52
timelines, with the models. Who here used Sonnet 3.5 when it was the crème de la crème, the cream of the crop model available to us? It was unbelievably better than what we had used before, right?
- 1:05
Like, having used all of these different models and trying them in tools, Sonnet 3.5 was a big moment for me because it felt like these models could suddenly complete much more end-to-end tasks, like actually get real work done that takes multiple steps.
- 1:18
And then we got Opus 4.5. Who felt-- Or I'll go different way, differently here. Who didn't feel a big jump when they switched over to Opus 4.5?
- 1:28
That's a relief. There are not too many hands because Opus 4.5 is probably when my psychosis started in November and December of last year. Having a model that couldn't just write the code and call tools, but could go way further.
- 1:39
A model that could test the work and actually get it into a good state and complete tasks that take hours instead of minutes. It was unbelievable. And then we got Mythos.
- 1:50
Who here has had a chance to play with Mythos and Fable so far?
- 1:54
We agree it's a pretty damn good model, right?
- 1:57
But why? It's not just better at coding. If you handed a prompt that you would have handed to these other models before, it's not going to feel that different.
- 2:05
I think of these almost as eras now, where Sonnet 3.5 is the tool call era. Not that it was the first model that could do tool calls. Rather, it was the first one that did them consistently and reliably enough in context of a code base where you could use this for day-to-day coding work.
- 2:21
Then we got Opus 4.5, which was able to do much longer running tasks without losing track of what it's working on. It's no longer, okay, build step one, and then it does it.
- 2:28
Then you say, "Okay, can you build this next part, and then the next part?" You can just tell it what you want, and it could figure it out a lot of the time.
- 2:35
Mythos is another jump to orchestration. It feels to me like it's the first model that doesn't just understand your code base, but it understands itself, and it knows how to spawn additional models and break up work in a way where it could be completed more reliably and then verified afterwards.
- 2:51
And if you tell the model to do that, it will just do it. You don't need some custom tooling, some custom system, some fancy software factory. You just need to prompt it to go a little further.
- 3:00
I think you'll be surprised how far it can go. What I'm trying to say here is we need to go bigger.
- 3:06
You're not going to see the benefits going forward if you're not pushing the model further, you're not pushing yourself further with what you're building. Most of the Jira tickets I closed at my previous job could be trivially solved with a model like Opus 4.5.
- 3:18
My previous work would not benefit from a model like Mythos. If the models are going to keep getting better, and at this point, I'm confident saying we-- they are.
- 3:26
I was wrong when I claimed that we were hitting a wall before. The models are getting better faster than we are. So we can't necessarily get better, so instead, we have to go bigger.
- 3:35
But in order to do that, we have to get over ourselves. This was really hard for me as someone who spent a long time writing software. Who here has written code for more than ten years?
- 3:45
I want to see hands. That's the majority of the people here.
- 3:49
I don't even want to think about how long I've been writing code for, but I have been building up all of these strong opinions since I started. I was using GNU Screen and eventually tmux back in the day.
- 3:59
I learned how to use those tools in SSH and Git before I even wrote code. And those have all been really ingrained in my workflow. I think back to the old days in a weird way.
- 4:09
Hear me out. Let me talk about iOS for a second. Who owned an iPhone back when they looked like this? iOS 6 or earlier.
- 4:17
How have you guys written code for ten years when a fourth of you are that old? I'm confused. Hopefully, you're all Android people or something. This is how iPhone apps used to look.
- 4:28
You might notice it's different from how they look now. It looks less like an app and more like somebody took a picture of a compass and put it in the phone.
- 4:35
This is how apps used to look. But now they look like this. And most people look at that and they're like, "Oh, that's an obvious downgrade. That's so much worse.
- 4:45
Why would Apple ever do that? This is the downfall of Apple and the beauty of their design." I'm going to fight you guys on that. iOS 7 was Apple moving away from trying to convince you that these devices can replace the old tools we used to rely on.
- 5:00
The compass had to look like a compass because the compass had to replace the physical compass that you relied on. The Books app had to look like a bookshelf with real pages that turned because it had to convince you it was a reasonable alternative to buying a book and reading the paper version.
- 5:17
Apps had to be designed to convince you to use them, not to be useful. And iOS 7 represents the shift to not focusing on convincing you anymore. Apple won.
- 5:29
By that point, everyone knew their iPhone could do all of these different things. The point of iOS 7 was to stop convincing and start embracing, start making a better interface.
- 5:38
And this interface, as much as we might not like how it looks, it's so much more useful. You have clear indications of the difference between what direction you're locked on and where you're currently pointing.
- 5:46
That red block is a super nice way to know that you're not in the direction you intend. The current direction you're facing is way clearer too, with the giant two twenty-eight at the bottom.
- 5:56
You just get way more info here than you did before. It's so much clearer. Even if we don't like it because it's not the thing we're used to, we got over it.
- 6:08
We're currently in our skeuomorphic phase as software developers. Skeuomorphism is this design aesthetic trying to represent the way things used to look, the physical goods that we relied on, and try to make them digital.
- 6:21
We're doing this right now with software. We're pretending our terminals are the ultimate interface when they're not even good interfaces, and I'm saying this as someone who loves their terminal deeply.
- 6:31
Natural language has no place in a terminal, but we pretend it does because the terminal's familiar. It's what we u- It's what we're used to. It's what we love.
- 6:37
It's where we like to think of ourselves when we're thinking about coding. Who here is an aspiring Vim user that, like, wishes you could use Vim or even does?
- 6:47
I know we've all had that Vim phase where we all tried.
- 6:51
This is just how we are as devs. We care so deeply about these things. We care so deeply about our tools, the systems we pick, the frameworks, the languages.
- 6:58
We like to think it all matters, and we've blinded ourselves in this. We think things that just don't make sense when you take one step back, like why can't we commit our environment files?
- 7:10
It sounds stupid when I put it on a slide like this, but I want you to really think about this for a second. When I have a team of engineers that are working on a project, why do I have to build another system to share this specific file, but all the other files can go in Git just
- 7:23
fine? It's dumb. It's just how Git was built, because it was built for a very specific thing, and then it took over our industry, and it took over our brains, and we aren't letting go of that.
- 7:33
There's a lot of these things in our heads that we have to start fighting. We have to take the step back and think, is this how we do things because it's right, or is this how we do things because it's just how we've always done it?
- 7:46
And as you start to think more about this, you'll realize there are so many things that we do this with. Like, why do we qualify ourselves by the languages we know?
- 7:55
I used to think this was a junior thing. Like, I could-- can't tell you how many times I had a junior engineer I was talking to who was like, "Oh, you're a coder?
- 8:00
What languages do you write? I write JavaScript." I thought this was a junior problem, but then you talk to senior engineers who are like, "Oh, he writes JavaScript. He's not a real developer."
- 8:08
We care too much. We pride ourselves in these things. They're our identity. These weird facts, these weird choices, these things that feel essential
- 8:18
just don't matter that much anymore. And they didn't then, and they matter less now. We got away with it because it was so hard to find engineers that we could just tell the company what we were doing, and they couldn't really say no because the alternative is spend six months trying to hire someone else.
- 8:31
They're not going to do that. And along that note, why are we so scared of deleting code? I cannot tell you how many times I've been in a conversation with someone where the solution is to just delete it and reset.
- 8:44
But we have such a bad sunk cost mindset in this industry. We care so much about the code we wrote, and we care so much about it still being there that I feel bad working with my team sometimes when somebody files a PR that isn't quite the right solution, but they spent a week or two on it.
- 9:00
Like, who here has guilt-merged a PR before, where you just felt bad because somebody put a lot of work in, it's not quite the right thing, but you merge it anyways because the alternative was a conversation you didn't want to have? [audience laughing]
- 9:12
Why do we do this to ourselves? One of the nice things about agents, you don't have to feel bad when you shut down their work. But we, we just care too much is the point I'm trying to make, and the things we care about are not necessarily the things that matter anymore.
- 9:25
And I hope we can finally start to challenge some of these. I'm gonna get a little more personal here by showing some of the ideas I've built, because the goal here is that when you guys go out of this talk, you have a better mindset for coming up with ideas that make sense now by rejecting the things
- 9:42
that made sense before. These are three of the things that I have built or are currently working on. We're gonna go from the bottom up. I built a Reddit scraper because making good memes is hard, and I would rather just steal them from Reddit, and went pretty well.
- 9:55
It was a side project, took me two to three days. Would just scrape Reddit, top posts on programming humor, put them in a nice format for me so I could go copy/paste them onto Twitter.
- 10:04
Zoom for Streamers was the startup I went through Y Combinator with. It was called Ping. I wanted to make it easier for live content creators to do high-quality collaborations in the software they already used, OBS.
- 10:16
The Fullstack Cloud is, let's just imagine Vercel, but it goes further each direction. They have auth built in, but they also have databases built in. These are all things I've wanted that I benefit from existing, enough so that I tried to build all of them.
- 10:29
The bottom two I built in twenty twenty-one, the top one I'm working on right now.
- 10:33
These are also kind of tiers, different levels that we can build at. If I was to try and categorize them, I would call the bottom one side project, call the middle one startup, and call the top one too big.
- 10:46
It just doesn't make sense. Well, this is how I would have categorized this even just a year ago. But things have changed. Now that the models are bigger, the tiers have shifted.
- 10:58
Everything is now one tier lower. And this is a crazy thing for me to process. The fact that what used to be a startup is now a side project.
- 11:08
In fact, some of the startups I've talked to, even at an event like this, their whole startup could have arguably been a side project or this bottom tier, which there's a weird gap there.
- 11:17
What's that? It's the GBrain tier. It's a Markdown file. [audience laughing] Do you know how many companies are at this event where their whole product could just be a Markdown file? [audience applauding]
- 11:27
It's insane. [audience cheering] And, like... Okay, seriously, though, 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:41
I had a service that would triage all of my PRs, have them all get reviewed with AI, and then help me prioritize. That service is a Markdown file now.
- 11:49
I just literally wrote, like, go to these four GitHub repos, look at all the open PRs, figure out what the current status of the work is, and then help me prioritize it.
- 11:57
And then when you're done, go update the static HTML file and send it to S3 and give me the URL. And every morning at nine AM, this runs on a cron, and around nine fifteen to nine twenty, my Markdown file generates me my work for the day.
- 12:09
What the hell? [laughs] How are we actually here now? I-- Try that if you haven't, by the way. You'd be amazed how many of these types of things can exist that are literally just a Markdown file running on a cron.
- 12:22
But what about... Okay, two more things I wanna change about this, though. First is the full stack cloud. This is mine. Don't do it. Lakebed coming soon. Very excited.
- 12:32
I wouldn't wanna compete with me on this one. Trust me, it's gonna be really cool. [laughs] But there's still something else. There's a gap here,
- 12:40
and I'm gonna be real with you guys. I don't know what goes in this gap. I don't know what too big means anymore. Is it training your own model from scratch?
- 12:48
Is it building your own operating system? Is it trying to compete with NPM and Node directly? I don't know. I don't know what too big is right now, and that's scary, but it's also exciting.
- 12:59
It means I need to keep pushing myself to go bigger than makes sense in order to find these limits. But what does that even mean? What does it mean to think bigger in this scenario?
- 13:13
I would argue that bigger is probably the wrong word for most of how I'm thinking here. It's time to think wider.
- 13:20
What I mean by this is a spectrum, and I'm sorry, I have to do a diagram. If you watch my videos, you understand. There's breadth and depth to any piece of software.
- 13:30
The breadth is the range of things that your software covers, and the depth is the number of features in a given area. Let's look at a company like Vercel.
- 13:39
Vercel does not offer all of the features that AWS does. They never will. It doesn't make sense. But Vercel offers deeper, but Vercel offers deeper features in the space they're in, which is full stack front-end leaning servers.
- 13:52
If you're a front-end developer and you're not using Vercel, you're feeling some amount of pain because they're just further ahead with this, so much so that even the agents prefer it.
- 14:00
And this was kind of how you had to build your startups, because if you were competing with a company like AWS, you're never gonna have all of the features they have.
- 14:08
You're never gonna cover the range that they cover, and it made no sense to try because you don't have the thousands of engineers they do doing that.
- 14:18
At least you didn't. But now things have changed. All of a sudden, that range is viable in a way that it never was before. I'm not saying you can build something as reliable as RDS.
- 14:31
I'm saying that you can build a database platform into your product in a day or two of work with enough prompting and enough effort. And if you build your stuff right, and if you play your cards correctly, and you think about things the right way, you'll realize that you can build enough across a spectrum of things you
- 14:46
care about to enable most users to at least start trying the thing. And when they have features they need in a given vertical that you don't support, it's not your problem, as long as you build it right.
- 14:58
Because they can build the features that are missing themselves. If you architect your systems and you architect your products in such a way that users can do things that they-- you never would have guessed.
- 15:08
Like, Slack accidentally did this because Slack is now the platform people run their agents in half the time, which is crazy. Slack sucks. It's not a good product, but it's the right shape for people to build the features they want into it through the somewhat functional Slack bot APIs.
- 15:24
This is all crazy because I'm basically sitting here telling you, like, it's time to compete with Slack. It's time to build your own AWS. It's time to challenge Salesforce directly.
- 15:32
It sounds stupid, but I'm gonna be real. If your idea doesn't feel stupid, it's because your idea is not big enough.
- 15:40
I think that's all I have to say. Thank you so much, AIE. [audience applauding] [upbeat music]