Everything we knew about software has changed — Theo Browne, @t3dotgg ​

Hello, hello. 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, I'm kind of going through some AI psychosis.

Who here would classify how they feelright now as some form of AI psychosis? I want to see some hands. The rep 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 everythingright.

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 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? 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.

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? That's a relief. There were 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. 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. Who here's had a chance to play with Mythos and Fable so far? We agree it's a pretty damn good model,right? 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.

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.

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, OK, build step one, and then it does it. Then you say, OK, 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. 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 can be completed more reliably and then verified afterwards. And if you tell the model to do that, it will just do it.

You don't need some custom tooling, some custom systems, some fancy software factory. You just need to prompt it to go a little further. I think you'll be surprised how far it can go. What I'm trying to say here is we need to go bigger.

You're not going to see the benefits going forward if you're not pushing the model further, and you're not pushing yourself further with what you're building. Most of the jerry tickets, like clothes at my previous job, could be trivially solved with a model like Opus 4.5.

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 they are. 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. 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 10 years? I want to see hands. It's the majority of the people here. 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. 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.

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. How have you guys written code for 10 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. 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.

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. 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. 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. 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. 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. 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.

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 228 at the bottom. 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. 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.

We're doing thisright 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. Natural language has no place in a terminal, but we pretend it does because the terminal's familiar.

It's what we're used to. It's what we love. It's where we like to think of ourselves when we're thinking about coding. Who here is an aspiring Vim user that wishes you could use Vim, or even does? I know we've all had that Vim phase where we all tried.

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. 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? 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 and get just 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.

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'sright? Or is this how we do things because it's just how we've always done it?

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? I used to think this was a junior thing.

Like, I can't tell you how many times I had a junior engineer I was talking to who was like, oh, you're a coder? What languages do you write? I write JavaScript. I thought this was a junior problem. But then you talk to senior engineers, they're like, oh, he writes JavaScript.

He's not a real developer. 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 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.

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.

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 theright solution, but they spent a week or two on it.

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 theright thing, but you merge it anyways because the alternative was a conversation you didn't want to have.

Why do we do this to ourselves? One of the nice things about agents is you don't have to feel bad when you shut down their work. But 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. And I hope we can finally start to challenge some of these. I'm going to 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 that made sense before.

These are three of the things that I have built or are currently working on. I'm going to 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 it went pretty well. It was a side project that took me two to three days. We'd 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.

Zoom for Streamers was the startup I went through at Combinator with. It was called Pang. I wanted to make it easier for live content creators to do high-quality collaborations in the software they already used, OBS. The full stack 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. The bottom two I built in 2021, the top one I'm working onright now.

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."

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. 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. 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.

What's that? It's the G brain tier. It's a Markdown file. Do you know how many companies are at this event where their whole product could just be a Markdown file? It's insane. And like, OK, 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. 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.

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. 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 9:00 a.m., this runs on a cron, and around 9:15 to 9:20, my Markdown file generates me my work for the day. What the hell? How are we actually here now? Try that if you have it, 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. But what about OK, two more things I want to change about this though. First is the full stack cloud.

This is mine. Don't do it. Late bid coming soon. Very excited. I wouldn't want to compete with me on this one. Trust me. It's going to be really cool. But there's still something else. There's a gap here. And I'm going to 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? 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 isright now. And that's scary, but it's also exciting. 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?

I would argue that bigger is probably the wrong word for most of how I'm thinking here. It's time to think wider. 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. 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. Vercel does not offer all of the features that AWS does.

They never will. It doesn't make sense. But Vercel offers deeper features in the space they're in, which is full stack front-end leaning servers. 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.

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 going to have all of the features they have. You're never going to 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. 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. 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 stuffright, if you play your cards correctly, and you think about things theright way, you'll realize that you can build enough across a spectrum of things you 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 itright. 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 you never would have guessed 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 theright shape for people to build the features they want into it through the somewhat functional Slack bot APIs. 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. It sounds stupid, but I'm going to be real. If your idea doesn't feel stupid, it's because your idea is not big enough. Then there's a lot to say.

Thank you so much, AIE.