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, 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. The 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 timelines with the models. Who here used Sonnet 3.5 when it was the creme de la creme, 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 35 was a big moment for me because it felt like these models could suddenly complete much more endto-end tasks like actually get real work done that takes multiple steps. And then we got Opus 45. Who felt or I'll go different way differently here. who didn't feel a big jump when they switched over to Opus 45. That's a relief. There were not too many hands because Opus 45 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. Then we got Mythos. Who here's 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 35 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 codebase where you could use this for day-to-day coding work. Then we got Opus 45 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 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. Mythos is another jump to orchestration. It feels to me like it's the first model that doesn't just understand your codebase, 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. 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. You're not pushing yourself further with what you're building. Most of the juror tickets I closed at my previous job could be trivially solved with a model like Opus 45. 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 was using GNU screen and eventually T-Mox back in the day. I learned how to use those tools and 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. You talk about iOS for a second. Who owned an iPhone 6 or 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 reass. 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 walked 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 skumorphic 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 trying to make them digital. We're doing this right now with software. terminal, but we pretend it does because the terminal is familiar. It's what we 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 like wishes you could use Vim or even does 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 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's right 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. I 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 the right 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 the right 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 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. And I hope we can finally start to challenge some of these. 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 currently working on. We're going to go from the bottom updator 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 the full stack cloud is let's just imagine versel but it goes further each direction. They have off built in but they also have databases built in. These are all things that I benefit from existing so that I built in 2021. The top one I'm working on right 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 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-rain 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.

[applause] And like, okay, seriously though, the fact that you can now execute markdown by just piping it to codeex 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. can exist that are literally just a markdown file running on a chrome. But what about Okay, two more things I want to change about this though. First is the full stack cloud. This is mine. Don't do it. Like 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 is right 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 wider spectrum. And I'm sorry I have to do a diagram. If you watch my videos, you understand 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 Versell. Verscell does not offer all of the features that AWS does. They never will. It doesn't make sense. But Versell offers deep but Versel offers deeper features in the space they're in, which is full stack front-endleaning servers. If you're a front-end developer and you're not using Verscell, 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 stuff right, 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 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 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 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 Slackbot API. 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. Not big enough. I think that's all I have to say. Thank you so much. AIE