From IDEs to AI Agents with Steve Yegge

Steve Yegge has been a software engineer for 40 years. He spent decades at Amazon and Google, is famous for his brutally honest rants about the industry, and for being right, a lot. He recently built Gastown, an open-source AI agent orchestrator, and co-authored the book Vibe Coding with Gene Kim. In today's conversation, we discuss Steve's 8 levels of AI adoption for engineers, from no AI to running multiple agents in parallel, and why 70% of engineers are still stuck at the bottom levels. Why AI is creating a vampiric burnout effect on developers, where you can be 100 times more productive, but only get 3 good hours a day. His prediction that big tech companies are quietly dying, and that small teams of 2-20 people will rival their output. And many more. If you want to understand what the day-to-day of software engineering looks like in the near future, and how not to get left behind, this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics, experiments, and more. Join us to learn more about them, and our other season sponsors, Sonar and WorkOS. So Steve, really good to have you on the podcast again. What have you been up to? Gergely, great to be back. It's been 10 months now? Closer to a year. Yeah, close to a year. Yeah, boy. Seems like forever. Yeah, sure does. Yeah, there's been a lot going on. I'm unemployed right now, which has been incredibly fun. I am just doing whatever I want with what I'm doing, which is real nice. And I've had a couple software launches, which was nice, I had a book launch last year, which was nice. I've been living the life. Yeah, so for a very long time, you've been known as this kind of truth teller of bringing in sometimes comical, sometimes really uncomfortable facts or observations, should I say, you wrote often in really kind of fun ways with rants. And a lot of them resonated with people. Do you remember what was a rant that really stood out at any point in time that you got some really good feedback, either at that point, or later you felt validated by it? Oh, well, so a lot of people tell me, well, those who know, their favorite Stevie blog is actually Execution in the Kingdom of Nouns. I don't know if you remember that one. Way back in the day. I was at Google, early days Google, and I was trying, I was struggling to sort of like get this idea across to people that Java's growth was super linear with the amount of code. So the amount of code would grow more than the amount of functionality, which is not a good place to be. And Java's gotten a lot better since then, right? But my post raised a lot of eyebrows at Sun because they were like, what is this guy complaining about? Why doesn't he just shut up? You know, but I was like, I want to use a language that has first class functions. And so I wrote a very, very, very unusual blog post called Execution in the Kingdom of Nouns. People really loved it, where it was a story. It's just a fairy tale about a land where there were no verbs. And it was, it was fun. So one of your lesser known blog posts, or for a lot of listeners, it's called a Rich Programmer Food essay, Rich Programmer Food. And this was about compilers. Do you remember what you argued about or what the points you made? Of course. This is the most important blog post ever. I'm going to tell you, I met a guy, okay, who he introduced himself at SWIX's AI engineering conference in New York. And he's like, I've wanted to meet you, Steve. I'm one of your players. Okay. And I'm like, whoa, cause this dude's, you know, in his thirties and you know, you know, he's played my game. You understand the game that I wrote? It's something that most people, most people haven't seen it because I didn't open source it. I will someday. It's just a pain in the butt. It's a really beautiful thing. And it, and it created so much love in the players for decades. They would come back. But this guy was so into it. And he's like, I read your, I read your rich programmer food blog post and decided to become a compiler expert. I became a PhD. He was in high school when he read it, became a PhD, started his own company. He's got a startup that's doing really, really well now. And he said it was all because of that post. And this post talks about, I think you argued that unless you know how compilers work, you're not going to be a good programmer, an efficient programmer. I'm not sure what the phrase was. There's going to be a layer of magic between what you're doing and what the computer is doing that is forever going to be sort of a friction for you. And then I think you even argued that some PhDs don't even understand how compilers work and this will make it really hard for them to be efficient. At the time, that was definitely true, right? How do you think that post has aged? Because at that time, I think it was like 2012 or so, like even then I would assume it was a bit unconventional to say like, you need to understand assembly because it was high level languages, right? Java was in its prime, C-sharp, Ruby was starting to come out. I mean, heck, JavaScript was starting to become big and React was starting in a few years. And most developers would have thought, why would I need to know compilers, assembly? I mean, that's what the compiler is for, right? Yeah. You're asking a really, really, really foundational question. You're asking me what universities should teach is what you're asking me, Gergely, OK? In disguise. And, you know, that those goalposts have moved every few years since I got into this game in the 80s. All right. What you need to know in order to be a software engineer, it used to be assembly language. It used to be like lots of bits and stuff like that. And over time, my buddies and I realized that our favorite bit manipulation questions were starting to bounce off candidates who'd never seen a bit before, right? And we did some soul searching in the 2010s, you know, and we were like, eh. Do you really need to know how to manipulate bits in a byte with XORs and stuff like that anymore? Probably not, right? And that was a depressing realization because we had prided ourselves in knowing how that stuff works, but we just don't need it anymore. And the sad reality is that I had a lot of my own ego and identity wrapped up in my sort of compiler background. It's all it's interesting, right? But it's not useful in any meaningful sense anymore. And is it not useful because the compilers have gotten so good at optimizing, for example? Is it that the problems have moved on to higher layers? Yeah. Why do you think that is? They're just walking up the abstraction ladder, that's all. And we're not even talking about AI just yet. Like this happened even... Didn't say AI, did you say AI? No, not yet. We will say it, but even in the, I remember like, you know, late 2010s, it didn't really come up. Like in my career, I can only remember one time where it would have been nice to know what the compiler did, but even then might've been a red herring, honestly. Look, what you have to know just keeps moving. They just, they keep changing the courses. They keep changing what they teach. Many people don't see this because they're only looking a year or two or three back and, you know, looking a little bit forward, but I've been doing this for 40 years and I can tell you, they teach you very different things now than they used to teach. And it's because you need to know very different things. And nowhere is it more evident than when we saw the exponential curve of the graphics industry, computer graphics. Look at graphics today compared to 19, you know, 92 when I was learning graphics in university and I had to learn how to literally, you know, do the algorithm to figure out where the next pixel goes on a line so I can render it to eventually turn it into a triangle, which is a polygon. Meanwhile, two years later, I took the same course and we were doing animation. I didn't even know what a polygon was. I mean, I did, but not at that level, right? The whole ladder just kept moving up. And the jobs changed. Originally, they needed people that could write device drivers and then they need people. And now they need people who can do game worlds and physics and all this stuff, right? It's just graphics showed us the way. This is what happens. And software engineering jobs have been very stable for, I don't know, since iOS, since mobile and cloud. Those are the last two big innovations, right? Yeah. Steve just made the point that the industry goes through these massive maturity leaps from raw pixels to game engines, from bare metal to cloud. And if you're building software today that needs to make that leap to enterprise grade, there's a tool that handles exactly that. This is our season sponsor, WorkOS. If you're building any SaaS, especially an AI product, authentication, permission, security, and enterprise identity can quietly turn into a long-term investment. SAML edge cases, directory sync, audit logs, and all the things enterprise customers expect. It's a lot of work to build these mission-critical parts and then some more to maintain them. But you don't have to. WorkOS provides these building blocks and infrastructure so your team can stay focused on what actually makes your product unique. That's why companies like Entropic, OpenAI, and Cursor already run on WorkOS. Great engineers know what not to build. If identity is one of those things for you, visit WorkOS.com. With that, let's get back to the question of what the last real innovation in software engineering actually was. And it's been kind of dead since then, actually. Yeah. I don't want to say AI because we're not talking about it yet. But I think we went through a period where people stagnated a little bit, where the courses didn't change very much. And we thought, this is all we're ever going to need to know. I feel the last big innovation, correct me if I'm wrong, was distributed systems. That was the last kind of hard problem, starting from like 2010s, when Uber brought microservices into there, how we scale services, how we store large amounts of data. I feel that was like... I mean, it was a big slope. Yeah, but honestly, I feel there's a lot of migrations happening. New React versions coming up and developers struggling with that. Apple every year throwing in a screwdriver in the wheels with the new breaking version. Android developers needing to retire an Android old version and deciding where to cut it off. So I feel there was that kind of migrations thing. And also business was just good, right? Everyone was growing. Everyone was busy hiring. There's no tomorrow. There was a time in 2021, the market was so hot. A lot of bootcampers with three months experience were getting offers. It's a pretty good company because everyone was so desperate to hire. Yeah. And then came AI in 2022. One thing that always struck me about you, even in those, like, you know, in 2020s and even before, you were always pretty pragmatic. You know, you were, by trade, you were always into compilers, debugger tools. That's where you started. You worked on hard problems at Amazon, at Google. Never shied away to getting into like hard technical problems and, you know, like all these things. And when AI came out, I don't remember you saying, oh, this is amazing. This is going to change the world. How did you feel? What were you kind of like observing, skeptical, like at the very beginning, right? When you first came across LLMs, how was that? I was pretty blown away that they could write fairly coherent Emacs Lisp functions. Like, like ChatGPT, the original one in December 2023. 2022. 2022. Okay, boy, time flies. Could already write code in a weird language, right? Not very much of it. And it was, it was janky, but that was, for me, that was the beginning of, oh, right. You know, cause I've had friends in AI for 20 years saying any minute now, any day now, right? And they'd show us and it would complete better and better and better. And this was the first time it was like, oh, okay. I see now. Right. But I was still skeptical like everybody else. And I can, I can tell you because when, when the rumors came out about cloud code in beginning of last year, right. That Anthropic had a tool internally that was writing code for them. And it was a command line tool. I, along with everyone else went, no, it's not, you know, we were just like, just flat out rejection. Just absolutely not happening. Right. Until I used it. And then I was like, oh, I get it. We're all doomed. Right. And then I wrote Death of the Junior Developer right after that, actually, I think. Gosh, it might've even been after, after 4.0 came out that I did Death of the Junior Developer. But things changed really fast once that came out. But was I a skeptic? Yes. But did I pay attention to the curves from the very beginning? I figured if chat GPT 3.5 can write a coherent Emacs list function, then in a year, let's see how they do. And in a year, 4.0 was writing a thousand lines of code. A thousand lines. Dude, that's most of the world's code is in files of a thousand lines or less. Which means that it can make credible edits. It wasn't able to up until 4.0 came out. Right. And so like, man, it was that point when I was like, okay, we're on a curve. This is a ride. It's not stopping. Let's get on the ride and see where it goes. And I dove in. Right. And I was like, I was behind. I didn't know AI. I didn't know like the fundamentals of the, I didn't know the lingo. You know, everybody knows this stuff now. Right. But I spent a year doing nothing but reading papers and catching up. Right. So in this book, Vibe Coding, I remember last time you were on the podcast, this book was about to come out and I was reading an early version of it or so. But the back cover, I just read the back cover and I realized that you must have written this about a year ago. And it says the days of coding by hand are over. When did you realize this? Because I've realized this recently with Opus 4.5, but this was, this was a lot before, well before that. Yeah, it was a year ago. It was, let's see, what is it right now? January. So it was over a year ago. It was 12, 13 months ago when I first realized. And, and it wasn't, that wasn't even my quote. That was, that was Dr. Eric Meyer, right? The inventor of many, many, many things in the programming world. One of the most important compiler people in the world. That dude, think about it. He spent his life building technology for developers to be able to write code. And he's saying developers aren't going to write code anymore. What would possess somebody to say, well, my life's work isn't really right. And that's what caused actually Gene Kim and I both to go, huh. Right. You know, if the inventor of, you know, you know, he, he made huge contributions to, to, to visual basic and C sharp and, and, and link and, and, and Haskell and P and PHP with a pig, is that what it's called? Right. All him. And he's just like, no, we're done. We're done writing code. I mean, that's, that's, that's, that's pretty big words from a languages person, one of the most famous in the world, right? What does he see that we didn't? And the, he sees the curves, man. It's that simple. It's like exponential curves. They get real steep, real fast. And we're, we're heading into the steep part this year. So the inventor of C sharp and visual basic is saying that we're done writing code, but even if the AI writes all the code, someone has to verify it. And that's where our season sponsor Sonar comes in. Sonar, the makers of Sonar cube has introduced the agent centric development cycle framework, ACDC, a new software development methodology designed for the unique scale and speed of AI generated code. It's a move towards a more intentional four stage loop that gives agents a guard through as they actually need the four paces being. 4.0 comes out. We love 4.0! People loved 4.0. They still do. They can't get rid of it. But they still think that's as good as it gets. You know, Opus 4.5 is out, and most people haven't played with it. Most people don't realize what's there. And that thing is already two months old. The half-life between model drops, as far as I can tell, has gone from about four months at the beginning of last year to two months from Anthropic at the beginning of this year. So any day, we're going to see another model from Anthropic. It will probably be out by the time we have this podcast out, right? And that will be so much further up the curve that people are going to start to be really freaked out by it. It's going to worry people when they see the next model. OK? Because all of the bugs, all the mistakes that they're complaining about right now, get fed right back into its training, and so that it doesn't make them the next time. And this is what people aren't understanding, right? And also, time continues. There will be three and five years from now. The sun's not going to stop, right? And it's coming. So this inevitable, the collision of these curves, man, there will be societal upheaval is what's going to happen. And it's already started. And people are justifiably mad. And I'm mad with them. I'm mad at Amazon for laying off 16,000 people and blaming it on AI without an AI strategy for it. Those people are not going to be able to find jobs, by and large. And they're the first of many to come. And nobody has a plan for this. Why do you think Amazon did that if they don't have an AI strategy? Because, unfortunately, and people are going to hate me for saying this, but me saying it doesn't make it true. It was true already. Everybody has a dial that they get to turn from 0 to 100. And you can keep your hand off the dial, but it just has a default setting of what percentage of your engineers you need to get rid of in order to pay for the rest of them to have AI. Because they're all starting to spend their own salaries in tokens. And so, at least for a while, if you want your engineers to be as productive as possible, you're going to have to get rid of half of them to make the other half maximally productive. And as it happens, half your engineers don't want to prompt anyway, and they're ready to quit. And so what's happening is everybody, on average, is setting that dial to about 50%, and we're going to lose about half the engineers from big companies, which is scary. Yeah, that's wild. That's way bigger than we've seen back at COVID. It's going to be way bigger. It's going to be awful. But at the same time, something else is happening, which is AI is enabling non-programmers to write code, and it's also enabling engineers who have seen the light and believe the curves are going to continue to go up to actually get together in groups of 2 and 5 and 10 and 20 and 30 people and start to do things that rival the output of these big companies that are tripping over themselves. And so we've got this mad rush of innovation coming up from the bottom up, and we've got this mad knowledge workers falling out of the sky as the big companies lay them off, because there's clearly the big company is not the right size anymore. Even Andy Jassy's saying it. We're going to do the same thing with fewer people, right? And so, does this mean we're going to have a million times more companies? Is there going to be a massive explosion of software or are people going to get out of software altogether and we're all going to go do other stuff? I mean, like, I'm very curious where all this goes. Small teams that have the right skill set or see the right business opportunity or have advantages can do way more. So there is something there in that. There is. So there's this land rush starting. I think a lot of the people coming out of knowledge work are just anti-AI. And those people are going to struggle. I'm sorry, but if you're anti-AI at this point, it's like being anti-the sun. You're gonna have to go live underground, right? But the people who are like pro-AI, like, I think we're going to see a big redistribution of who's doing the work and where you get your software from. And it may, we may well wind up from, I could actually see a happy place where Amazon's not even a thing anymore. I really could because software becomes, we don't have the words for what's happening, right? You know, so many things happening this year that we don't have words for. Have you noticed that? But software becomes sort of like a distributed, I don't know. I do see non-technical people getting into software. Could there be a job there for engineers to come and actually take over maintenance? Yeah, I mean, I think there's going to be plenty of opportunity for, there's going to be, there are going to be a lot of engineers doing software engineering. I just think we're all going to be doing it with AI, right? But I think it'll be quite some time before companies are comfortable trusting their code to be written and deployed by AI without any human being involved at all. I think the point that people are missing, the important point that the naysayers and the skeptics are missing, is not that, it's, AI is not coming to replace your job. It's not a replacement function. It's an augmentation function. It's here to make you better at your job, right? And that's not a bad thing, actually. I don't, I don't know why people would fight that, but. Speaking about the job as developers, you've said something that can be triggering for a lot of people. You've said that, I think this was on the AI Engineer Summit, that if you're still using an IDE now, you're, you're a bad engineer. Ah, yeah. Well, you got to be a little provocative. Yeah. You know, I, I, well, let me put it this way, OK? I'm not going to say you're a bad engineer, because I know some very, very good engineers, better than I am, who are still at, like, level 1 or 2 in my chart, right? But I feel profoundly sorry for them. I feel pity for them, like I have never felt in my life for these grown people who are good engineers or used to be, and they're, they're like, yeah, you know, I use Cursor and I, I ask it questions sometimes and I'm really impressed with the answers. And then I review its code really carefully and then I check it in and I'm like, dude, you're going to get fired and you're one of the best engineers I know. Tell me about your chart. Tell me about your levels that you came up with. Yeah, so I was drawing this on the board in Australia for a big group of people trying to show them what happens, because I saw them at all different phases. Some of them had their IDEs open. Some of them had a big wide coding agent. Some of them, the coding agent was really narrow, right? You know, and so I was like, OK, we're going to put you on a spectrum just to show what's going on, right? And level 1, no AI, right? You know, and level 2, it's, it's the, the yes or no. Can I do this thing, you know, in your, in your IDE, right? And then level 3, you're like, YOLO, just do your thing, right? Your trust is going up, right? Level 4, you're like, the code, you're starting to squeeze the code out, right? Because you're like, you want to look at what the agent is doing and not so much at the disk anymore, right? So you're not reviewing as much now. You're not reviewing as much. You're, you're, you're letting more of it through and you're really focused on the conversation with the agent. And then at level 5, you're like, OK, I just want the agent. And, and I'll look at the code in my IDE later, but I'm not coding with my IDE. At level 6, you're bored because you're like, okay, my agent's busy. I got, I got to do something. I'm twiddling my thumbs. And so you fire up another agent and now you're addicted because you will very quickly get into an equilibrium where every agent is waiting. There's always an agent waiting for you because somebody's finished, right? As soon as you spin up enough of them, mathematically, right? And so you find yourself just multiplexing between them, going like this, and you can't leave. Practical question. Assuming I'm working on the same code base, how do you split up the multiple agents so that they don't get in conflict? Is it just, are you going to use like... Yeah, so that takes you to level 7, which is, oh my God, I've made a mess, right? I accidentally texted the wrong agent and didn't realize it. And they did a big project inside of this project because I asked them to, and now [inaudible] this mess, et cetera, right? All that stuff. And that was when I started going, okay, what if we were to like coordinate this? What if Claude code could run Claude code? That's the question everybody wants to know. And everybody was trying all last year. It's going Claude code. Run yourself. It would run for a while and it would stop, right? And, and so it was the whole stopping thing that... So yeah, Drop off in cognition as the tokens go up, right? Yeah, losing their track and stuff. So, so what, which one's right? And we've got people who are like full on in the, in the, in the minimizing and the, and the, from the maxers, And, and I looked at my work workflow and I was like, well, pollcats are the min and crew are the max. I have two fundamental role worker roles in GasTown. You have that, you have a really simple one, which is the small context of the pollcats. Yeah, if you have a really, if you have a really well-specified task, all broken down into subtasks, then you can find, and, and it's like, it's self-contained. It's, it says what to do. Then you can give it to a worker and have it go do it, right? Meanwhile, you have a really difficult design problem. You're gonna have to have a series of conversations about this. I maximize context. I'm like, read all these docs and then we'll talk, right? So it's just two workflows. And like, I, I liked the idea. I mean, it sounds like it's, I think it's so easy to imagine, like, it's a little town, you know, like in this wild, wild west, there's the mayor, like the, the crew, the, the workers, everyone's buzzing and going around and the houses are being built. In practice, how does this work? Like, how has this worked for you? What are you hearing people get projects done versus not getting it done versus turning into absolute chaos? What have you learned with GasTown? It's been a great experiment. I mean, I've, I've really enjoyed it. Well, yeah. I mean, right? I mean, I went out and built something that doesn't, that deliberately doesn't work. It's too hard. It's too hard for the models. Even Opus 4.5 is barely enough. And it's funny because the folks at Anthropic told me they, they like it, that they're kind of embarrassed, some of them, because they feel like I've got all these workarounds for bugs in their model, which it kind of is, right? But it's not a bug. It's that their model was never trained to be a factory worker. And it will be soon. So a lot of GasTown is going to disappear. A lot of the complexity, a lot of the roles that are monitoring, all they're trying to do is tell Opus 4.5 to be smarter. And that's being on the wrong side of the bidder lesson, right? So a lot, GasTown is going to simplify and flatten into just minimax roles. Crew for your max and your pollcats for your mins. And, and I think that's the natural shape. And they'll just scale up. And, and could that be the pollcats, they might just be sub-agents at some point, for example. Well, sub-agent, I mean, pollcats are sub-agents. It's just that they're, they're more, they're first class. They have their own identity inbox. You can talk to them. You, you can actually see how they performed over time by computing skill vectors on their, their work and things like that. So a little, a little bit more than that than sub-agents. I think sub-agents have the problem of being opaque. I'm going to fire off a bunch of sub-agents to go do this work. And then you're like, okay, let me know when you're done. Whereas with GasTown, you can go look at them and be like, dude, your pollcat's not working. I'm gonna poke it. Right? So GasTown gives you a lot of hands-on, I don't know, steering, right? It doesn't try to be, it doesn't try to get out of your way. It's in your way, GasTown. It's really fun though. I miss it. It's been down for a few days for me, and I tell you, man, working with regular Claude just stinks by comparison. Because it's like an idea factory. Once it's actually running and all booted up and everything, you can have so many things going on at once and actually track them reasonably well. Now, it can suck you into a mode where you don't sleep, you don't eat, and you start, it's not good for you. And I actually wanted to talk to you a little bit about what's, what's happening in the industry at some point. But, but GasTown itself, I mean, like it was all calculated, all the characters, you know, the naming. Why did I even do GasTown, right? Why is it? Why? Because I wanted to move the over to the window, right? Because people last year, when I would say orchestration's coming, they'd say, no, agents aren't, no swarms and orchestration, whatever. Everything you're saying is just not true. And now what they're saying is, bro, you're being pretty aggressive, right? Which is a different conversation. They're like, now they're like, whoa, your swarm, I don't know, maybe your swarm can't do bubble, but it's just completely shifted the conversation from the realm of impossibility to the realm of possibility. So is, is it fair to say that you took on more than you, you reasonably thought you could chew? You took on this more ambitious funds because you wanted to both stress test what these models can do. Uh-huh. And find out what's next. See, find out and honestly just have some fun. Have some fun, find out what's next. And I'm continuing to do that. So my next thing is I'm going to string a hundred GasTowns together. We have a community, a discord, and if MoltBook can get people to pitch in tokens for fun, like they paying, they're paying, you're paying for the inference of your, your agent on MoltBook, right? So if I string a hundred GasTowns together and we decide to build something together, we will learn the mechanics of federation. We're probably retracing Ethereum's steps, but we will. And we're going to come up with something remarkable. It's like the people version of MoltHub, right? MoltBook, whatever it is. And what, what are misconceptions about GasTown or what it's trying to do that you feel it's kind of, you know, gone off a little bit of the rails and it's good to clean up? Well, I mean, for starters, I don't think people should be using it. And they are. And I, I really mean it. What you say people should not be using it, like not, should not be using it except if you're doing research or, or if you're like actually understand that this is just a proof of concept. So some, some very, very clever people that I've been talking to have, have been searching their problem spaces for subsets, categories that GasTown could productively use today at a big company, a big Fortune 50 company, say. Wow. And they've, they've identified some problem spaces that you could put GasTown on today. And I was like, oh, that's pretty, pretty clever thinking. One of them was this company I talked to that sets up bespoke data centers for you. Okay? In any region you want, which is something AWS has never been able to do. Google's always tried. And they say it's just three months of miserable button presses to try to install the software and check that it all works. And the acceptance criteria are very clear. It's, you know, it's almost a Routh loop, but they think GasTown could swarm it and eventually converge on a data center that works and, and save all the people the trouble, you know what I mean? And I was like, all right. And this could potentially meaningful move the needle on their ability to open up more of these data, data centers for people, right? Wow. Yeah, go figure. And the same guy was telling me that he's been looking at production incidents and he, and he's realized that their system is already in an indeterminate unknown broken state when they're down. So how much worse can AI actually make it? Now I cautioned him and said, actually, it can make it a lot worse. But he's thinking on the long lines that there are certain categories of outages where you could have them in investigation mode or whatever, right? Where they could speed things up. So people are looking for the fuzzy problems. There was a third one that came along. I forget what it was, but there was, there's a class of problems emerging for which you can swarm them because you, you don't care that the results are messy. It's the cumulative work that, right? But that's actually how I code now. I mean, right? I mean, like I code myself, I mean, I bit off more than I could chew. There's no question about it, man. GasTown is a huge mess right now and everybody's going, he's gonna vibe code himself into a corner and come crying out, you know, they're pretty close to true. Although I did manage just before we got on the plane to get it back on track and it's working again, right? So one interesting thing about GasTown is you said you don't look at the code, you have the agents write the code and which is very, very unlike what your career has been, right? You cared about craft code, elegance. Why did you decide to do it and what are the results? I mean, are the results as bad as I would think they would be? Because this is right, like, like if you imagine we're gonna put like a thousand interns on a project, like we've kind of seen that in the past and the result has been, well, eventually a senior engineer comes in and cleans up the mess and I'm just curious, like, how, how is it better Because you don't want to give a bad experience to people. What changed, though? Just the ability to do an infinite number of prototypes. So instead, you make prototypes until you get a great one, and you're like, let's launch this. And so, apparently, Claude co-work happened in 10 days. Somebody went, hey, I did a prototype, and they were like, we're gonna launch this. And 10 days later, they launched it. So, I mean, it works! But I guess one important context there, when I talked with Boris Cherny about a feature that they did about how they did the tasks in Claude code, the task list of how it completes, he told me that in two days, he built 20 different prototypes that were all working, thanks to AI. I didn't know that, but he's doing what I'm talking about. They call it slot machine programming, right? You do 20 implementations, and is that what he's doing? Something like that. I don't want to put words in his mouth, but I was just floored, because building 20 working prototypes, that would have been two weeks. And you would have stopped at three, right? That's in our book, actually, if I can pitch the book for a moment. FAFO, F-A-A-F-O, is the dimensions of value that you get from vibe coding, and the O is optionality, which is the ability to create lots of prototypes. What it lets you do is defer your decision until you know what the right answer is, which is cheating. So, of course, everybody does it, right? And it's going to fundamentally change the way that companies are run. It's gonna change the way that people organize to create software. And it's going to happen this year. It is just fascinating how these changes are coming, but what enables these changes? Is it the fact that we can iterate faster with these things? Like, I, I, look, I saw a phenomenon happen at Google. This is, this is kind of a big company question. There's kind of two, there's a big company and a small company answering your question, right? So, something happened at Google. I went through the golden age of Google where it was like Anthropic. It was a hive mind. It was nobody was mean. Everybody was innovating, and it was wonderful. Yeah, this was a time where, like, the founders were really close. You could chat down. You'd go to the cafeteria, and Larry and Sergey would be sitting there, and you'd hang out with them and just chat, and it was like, golden age, right? Yeah. And then it changed rather abruptly. We made a few pivots, and it became not that company anymore. And in fact, innovation died on the vine, like, altogether. And since, I don't know, 2008, there has been no innovation from Google. It's all been acquisitions. They have, they've created nothing new. I mean, I mean, they did Gemini a few years, a few years later, right? Gemini, okay, sure. They created LLMs, and they did nothing with them. That's a perfect example of why innovation dies there. Yeah, for five years. Right? Five years, they did nothing. So I don't count Gemini. That's a different Google, okay? We're talking about the Google that screwed up. I don't want Anthropic to screw up this way again, the way that Google did. Google put safeguards in place to try to keep them from turning into the company that they turned into, which was ossified, you know, territorial. Nobody could. I hired a brilliant dude from Microsoft, brought him into Google and said, figure out what you're going to do. Take as long as you need. It took him six months to find something that nobody else had claimed already. People claim work and then never do it at Google. So I'm going to tell you something I've never said before. This is a brand new take. I think what happened at Google was when Larry Page became CEO, and he said, we're going to put more wood behind fewer arrows. That was his motto. And he put a halt to innovation, okay? Before then, there was more work than people. And after that, there were more people than work. And so people started to fight over the work. And that's where people started to do land grabs and backstabbing and territoriality and empire building, and all the bad stuff you see, all the politics that you see is about fighting over work. And going back to Anthropic, they're at a frontier, and there's infinite work. And, like, literally, all of them have too much to do. And a friend of mine, a friend of mine at Amazon once told me that we don't have a lot of the problems that Google has because everyone at Amazon is always slightly oversubscribed. They have too much work. I've, I've heard similar with Apple as well. Yeah. That that's kind of deliberate. Interesting thing, I mean, if we assume, I am seeing productivity gains for myself, so I'm not disputing that agents actually make you more productive, and I think we can agree on by how much, but for me, it's a lot. But if this happens to a lot of companies, people can actually do a lot more work. Do you think a lot of companies that are larger will see politics show up, which typically kind of happens when... If, if, you're right, if, like, the catalyst for the bad stuff beginning is more people than work. Yep. And all of a sudden, people can do all the work. Yep. Then the company's biggest problem is going to be finding more work, or they're gonna have to get rid of people, which is kind of bad, right? But it's not unlike Gastown in the small. My biggest problem with Gastown is feeding it because it works so fast. I have to work really hard to come up with good designs for it, right? That's what I spend all my, which is why I'm taking naps all day long, because I'm trying to come up with difficult work for it, right? Other people have said this too. This is, this is the problem with Gastown. And this is the problem with everybody who's going to use any orchestrator. It doesn't have to be Gastown. That thing will be dead in four months, probably, right? I mean, it's the shape that worked in December 2025. That's not going to be the shape that works in four months, right? I think we're going to see a huge ecosystem of building blocks for people who are non-technical who want to build stuff, and they need those APIs, and, you know what I mean? Like, for storage or for matching or for whatever it is they need to do. So, so I guess if you're in tech and if you're looking for an idea, either because, you know, like your job is looking a bit shaky or you actually just want to do something, like, now could be a great time to start building some of these building blocks that work in any, like, reliable building blocks will probably be in need that are, that have states, that have SLAs, whatever. That have some, some, some importance, right? That's not trivial to do. That's right, because AIs are lazy. And with good reason, they don't want to burn tokens if they don't have to. So if you provide a service that's going to make something convenient for them, they'll absolutely use it. Yeah, especially if it's a service that you, you need to maintain, for example. Like, you need to keep up with, may that be regulation or changes or logging or whatever. You know, that's kind of a lot of work to do even to prompt, like, to, and go back every day to prompt again to, like, update and all that. Also, as humans, we're also lazy. Yeah, I mean, well, Larry Wall called it, right? It's, that's one of the virtues of a programmer. Yeah. I want to go back to one of, another one of your essays from 2012, uh, which was called the Borderlands Gun Collector Club. You're the one that read that one. I got recommended on BlueSky and a lot of people liked it, and I read it and I realized I didn't read it. And this was a really interesting essay because seemingly it has nothing to do with what we're talking about, but you talked about gamification. And you talked about how this Borderlands game, which you played apparently, right? Back in the day, yeah. Back in the day, you mentioned how, after you completed the game, there was this weird thing that the game developers probably accidentally put in there. People kept coming back to have, like, custom guns. And these were like a meta goal that the designers probably never thought of, but it actually made the game pretty kind of addictive. And you called this as a, I think it was like some sort of elder game or something like that. And you were kind of saying that, hey, this is pretty smart. This was accidental from a game designer, but maybe more game designers should do this because it just makes the game addictive and, you know, like not saying that. But since then, that was in 2012, we've seen so many games just have, like, deliberate gamification and not just games, but a lot of other things. Yeah, a lot of them found that mechanic eventually. Who is it, the Borderlands and TakeTwo? Or, I forget. Anyway, they figured it out early, then they didn't capitalize on it. But, yeah. So, interestingly, I think, yeah, gamification, gamification is kind of rearing its head. People have pointed out that, like, people are making game finance to Gastown, right? I mean, why I've also been a vice president at big companies of engineering. And so when I'm working with a team of 80 agents, it's not very different from working with a team of 80 engineers. Any one of them can screw up too, engineers. And you've done that, right? I have. And I'm telling you, they are isomorphic. So what is the bitter lesson? The bitter lesson is, don't try to be smart. Just try to be large. Okay? Now, that's not the only way to make the AI smarter. They can also make them smarter in a couple of other important frontiers that are also getting developed. And so, to tie it full circle to the beginning of our conversation, everyone who believes right now that the curve is S-shaped, they're a hundred percent correct. They are a hundred percent correct. It is S-shaped. Eventually, we will run out of resources. The world will be out of resources, and it will flatten, right? But I can tell you that there are at least two more cycles left in this, and that means there will be at least 16 times smarter than they are today, and that is going to cause all of knowledge work to be subsumed by this stuff. Before we go all the way there, let's talk about how all this, the better models, more productive, could impact personal software, things that people can build themselves. This is what I thought you were asking about earlier when you said you wanted an API from Zendesk. Think about it. Everyone's going to want to build their own software. Oh, I was talking with a business friend, not personal, but... Oh, businesses. But also personal software. Like, what would the future look like when everyone could have OpenCLaw running in their closet or Gowl town, or they don't have to run it on their thing, but they can turn to this agent? How could that change both personal software, but also the software industry as a whole? Because for a long time, personal software was the privilege of us engineers who could build it, and we built our tools and we had open source, and we had some billion dollar companies grow out of some of the cool things. But what do you think could happen now that this will be democratized to some extent? How do you think open source could change? Open source? How would open source change? Because one interesting thing that I'm seeing is a lot of remixing happening. So people, you know, now a lot of open source projects don't really take pull requests because there's a lot of not great ones. But a lot of people are just remixing. They're just taking the open source project, they're telling the AI to make this change and they publish it as open source as well. Often no one looks at it. And now they don't need to ask for permission. A lot of people are like weaving things together. They say, take this project, take this thing. Right. So that's a lot more open source. I see what you're saying. In the old days, the F word fork you used to be like kind of a declaration of war. Like if you forked somebody's project, it meant you had had enough of them. Like Rucode forked Klein, and then somebody else forked Rucode. And it's just like, I think it's now going to be an everyday occurrence, right? Because it used to be that to fork, it would be a lot of time and effort to maintain a fork, to merge back the things. Cursor is a fork, isn't it? It is. Yeah. That's a lot of work. That's a lot of work. Yeah. A lot less work now, right? So yeah, everyone's going to be forking. So yeah, no, I think that that's a natural consequence of everybody writing code. Just like everyone can take a picture now. That didn't used to be true. What are some of your beliefs from early on in your career that held really, really well until recently, and now we just abandoned because of AI? Engineers are special. There's one. Come on. We are special. No, I think we're still special. We can... Yeah, sure. We learned how to do something by hand that computers can do now. Kind of cool, I guess. What about the engineering mindset? We have that. Like, it's not just coding that we do, right? Well, for one thing is I believe that our thirst for new software will never, ever, ever diminish. It will only grow. And so we're at the beginning of software. All the software we have right now is garbage. That right there, OBS especially. And we're going to see a new world over the next 10 years where software is commonplace and good. And you'll have your choice. And it won't be, I have to pick and choose between three really bad OAuth solutions or company HR systems or whatever stupid-ass thing, right? Like today, the selection is terrible. SaaS is awful. The whole, the whole, right? Airline apps. Airline apps, right? I mean, we ran a vibe coding workshop in Sydney where a dude actually wrote an airline check-in app for himself and got it into the Android queue before Southwest realized and shut him down because he was a bot. But that's what people want. They want personal bespoke software. And they're going to get it. And so, yeah, I think you're going to see. That's why when Jeffrey Emanuel forked beads, I was like, you go, you go. He's like, I feel so bad about it. I'm like, dude, this is the new world, man. Fork, fork, fork. Let's have beads in every language. I don't care. Right? In all fairness, like just looking at it from the positive side, like I wouldn't mind just having good software for the stuff that I use day to day. My utility provider is, someone is getting better, the government websites that I have to access, my paying my parking fine the other day. I tried to send a package to Canada from the Netherlands and the post, like the official post has been broken. They cannot send anything for a week. And I see the exception. They cannot fix it. So I had to go DHL and pay a bunch more money. That's right. And like, there's a lot of bad software out there. It is. Now your agent will be dealing with it, not you. Yeah. But I think people who write software that agents like and prefer and choose, and then they find a way to market it and get the agents aware of it, they're going to win big because everyone will use agents. We'll all be dependent on it. Well, plus also, I guess, software or ways of making agents write quality software. Because I have a feeling like you will want to do better stuff that if you do the same, you're not going to have a business, right? Yeah. So, I mean, look, I think businesses will compete on more and more complex software. The ceiling will just keep going. We're building like we're going to, until we build the Death Star or whatever, right? I mean, like, we're building bigger and bigger things. Oddly enough, Sergei, I am an optimist through all of this. That's my first belief, I think, first and foremost, is that it's all going to work out. So, asking the optimist now, I got this question off, I think it was on Blue Sky. This person asked, like, how do you think the software industry will continue to exist if we get to a point that any software could be trivially cloned? Yeah. Where will that leave us? What cannot be cloned? What is the moat? Just, we just jump ahead. We assume that these things actually can do it. Human connections. Human connections are probably the biggest one. As, as, you know, kind of almost counterintuitively, as software does more and more automated for you, people are going to be like, oh, well, yeah, but that's, that's just automated. I want a human to do it. And they will literally want a human to bring their thing instead of a drone. You know, they'll, they'll, they'll, they'll want humans to curate things for them. And I, I think that's going to be, humans will be a moat. Do you think if we look back at some of history, like, like from, you know, the history, the rest of history, like, have we seen some changes that felt a bit like this and then we saw some professions thrive because of either more automation or, you know, like... Stack Overflow? I don't know. I mean, like that one jumped to mind, Mechanical Turk. I mean, like, we've seen a bunch of big step functions. It's just that we're, we're about to see a whole bunch of them at once, right? I mean, look at the news lately. I mean, like, you're like, this is the funny thing is everyone's like, where's all the innovation? And then in the news all day long, they're seeing all this innovation in AI. It's just not coming from, you know, the Walmarts and Microsofts. It's coming from random individuals, right? But the innovation is there. And from the startups that I've been talking to, you know, I've been talking to anywhere from 2, 5 to 20 person startups. I think we're going to see some really impressive stuff launching in the next couple of months. Are you seeing these small startups change how they work? Oh God, it's so different, dude. It's so different. Tell me how. It's so different. Okay, for starters, for starters, I think in the new world, I'm convinced of this, okay? Everything that you do will either have to be fully transparent or you're hiding it for a reason. Tell me more. In other words, if you don't want people to An amazing client in the cloud, high-speed network connection. And what you can do with it... Sid C was the base and then Cider was built way up on a higher layer. But when you get something like that and you're not restrained, especially in the world where you can run unlimited agents based on your pocketbook, people are not going to be wanting to work on their laptops. GasTown is already completely stressed out my laptop to the wire because cloud code actually takes quite a bit of memory. So, yeah, I think we're moving to a world where people will work on servers and on mobile devices, probably less and less on iPads, not on laptops as much. In the past, you've said that one of the most important predictors of the bulk productivity is language design. Well-designed languages are easier to work with. Do you think this has completely erased, or do you think it might come back at some point? Either purpose-built languages? I think there'll probably be purpose-built languages by AIs for AIs, maybe. But right now, we're in a funny place where some languages work better than others still because they have better training data. But in the fullness of time, all languages will work equally well. I'd push back on that. Like, if a new language never has training data, how would it work well? No, I mean, sorry, all the existing ones. TypeScript, it struggles with TypeScript today. It does, but it's not going to in one or two more. So, could we see a stagnation? Just fewer languages or no languages launching because they just get the job done. And launching a new language seems a bit suicidal unless you, like, bring a bunch of, like, training data with it, right? Man, that's a loaded question. I didn't mean to make it loaded. No, it's a good question, right? Part of me says, like, languages just don't matter anymore, right? Any more than assembly languages matter, except for a few people who are trying to optimize really important things. And then everybody else, it just doesn't matter, right? But then part of me says, well, energy is the most constrained and important resource on this planet, and it's only going to get worse. So finding better algorithms, finding better ways to solve problems, is often a language problem. Finding a DSL, you know. So I think from an optimization perspective, an efficiency perspective, the search for new languages will probably continue. But for pragmatic, for everyday, I don't think it doesn't matter what you pick. Now you can ask your agent what language it's using. So as a software professional who, like, loves the craft, is into, you know, languages, debuggers, tooling, etc., a lot of what we talked about is pretty sad because, you know, like, a lot of the beauty, the challenges that we worked, it seems they might be going away if we continue and if this continues as well. How did you work through this yourself? And also, what is the thing that actually excites you looking ahead? Right. So I had the benefit of going through 30 years of graphics evolution. And so I saw the sadness and I saw the resulting much better games we got after all that happy stuff we were doing by hand moved into the hardware. We were sad because we're used to it. Change is part of life. OK. And we're, you know, at one point, I had to say goodbye to assembly language. Right. I was like, let's compiler writers. They finally caught up. Right. And then we were mad. But then we were happier because compilers are obviously way better than writing in assembly language. Anybody would be stupid to say, oh, God, yeah, no, you're not a good engineer if you can't write in assembly language today. But that was actually what we were saying in 1992. And then you had Blockbuster out in 2012 as well. Yeah. No, I'm just saying stuff changes. What you need to know as an engineer will change and you can't rest on your laurels. And we're going through a period of faster change now. But you have helpers called agents that can actually help you through this change. So stop complaining and just go do it. Yeah. And I think just recognize we're in this industry where change is a thing. And that's right. Now, with that said, I did go through the five phases of grief. Right. The five stages of grief. I mean, like, I went through, I don't know if I, I don't know about anger. I was angry, really angry for a lot of reasons two years ago. But no, I mean, like, if you've ever truly grieved, if you've like lost someone, you know that it hits you in a lot of weird ways where you feel reality is disconnected. You feel sick. You feel stunned. You feel all day long. The world goes monochrome. All color disappears. All kind of weird stuff. Right. And I went through that for about, I don't know, six or seven days. It didn't take me that long to get through it, fortunately. Or maybe it was, that was the peak and I was surrounded by a few months of it on either side. But there was a period that I went through it where I was checking off things that no longer mattered that I had really cared about. Like my ability to memorize or my ability to write or my ability to compute or whatever. All those, anything computing related. I was very sad. Right. Because those things made me special somehow. Right. But then to your question, what makes me excited? Like, as soon as I got through that, I was like, but wait, I'm writing 10 times more code than I ever was and I'm having fun. And why should I be sad that this, right? And so I realized it's just, it's just me holding on to the old, just like I did in graphics. And there's no point because the future is actually more fun than the present. It just, it's gonna be. You're known for your predictions and I'd like to put it to a test. Let's give some specific predictions for next year in 2027. Things that you think will happen either with how we develop or how the industry works. I think that my wife is going to be the top contributor to our video game by summer of next year. And she is not a developer, I'm guessing. No. Oh no, no, no. But she loves our game and she has lots of ideas. Right. Amazing. Yeah. In fact, I think my whole family might be in on it. I'm serious, man. Programming is going to be for everybody and it's going to be the most amazing thing because you know how much fun we've been having all those years. And we've been telling people it's really fun, but now they're going to get to experience it. Right. I look at my kids and how they look at AI. They're having so much fun with this creating. They're just prompting Gemini or any of these with their imagination. And they actually have, they don't think it's weird. I think it's weird, so I never would think of it, but they just enhance our photos with like squirrels on my head. And it just made me laugh and fun. And you realize, like, there's just a lot of fun and new things with it when you let go or you never knew what was before. It's given the people the ability to do very sophisticated mashups of anything. And mashups are really where innovation happens. Right. Innovation comes from taking things and putting them together and seeing where it goes. Right. We're going to see everybody innovating, man. And it's going to be the most amazing thing ever. And then we're going to need ecosystems of agents that can go find stuff that you like because there'll be so much content. How are you going to find the stuff that's really like that you like? You're going to have an agent that knows you really well. I think any software engineer who wants to get, go make a big business right now should go start working on agents that know how to go and search the new world, everything that's coming up. I don't know what we call it, right. The work pile for, for software that you like for experiences that you like. If everybody's creating it, think about it. When the internet came out and everybody can make a webpage and upload shit. We needed aggregators. We needed, you know, we needed search engines. We needed ways to organize and find and surface the good stuff, right? None of that exists right now, but everybody's about to start coding. Like, right. You know, and so like you can get ahead of this. This is why I keep saying, just believe the curves, pick a point on the curve and aim for it. And you will land there and you'll be first when it, when the AI is ready for your thing. Yeah. And I think in years, we already can build. We don't need permission. We can use these tools super efficiently. And we are ahead of the rest of the world right now. Right now. Well, it's exciting times. Well, Steve, we'll have to check back on, on how, if that prediction will come through with your wife contributing more, but this has been, I think really eyeopening. And, and it's, you know, sometimes I think it's good to, to go through the has been and the can be. Yeah. Well, thanks. I hope you enjoyed this conversation as much as I did. An interesting thought from Steve is his parallel between the graphics industry and what's happening in software engineering right now. In 1992, Steve was learned to calculate where individual pixels go on a line. Two years later, the same course was teaching animation. The work in graphics went from writing device drivers to build a game world and physics engines. It all just