From IDEs to AI Agents with Steve Yegge

Steve Yegge has been a software engineer for 40 years. He spent decades as an Amazon and Google, his famous restaurant is really on his rant about the industry and for being right a lot. He recently built Gas Town and open source AI agent orchestrator and co-authored the book Vibcoating 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 peril and why 70% of engineers are still stuck at the bottom levels. While AI is creating a vampire 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 and during look-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. The show will learn more about them and our other seasons sponsors, Sonar and Work OS. So Steve, really good to have you on the podcast again. What have you been up to? Greg A, great to be back. It's been 10 months now. Close to a year. Yeah. Close to a year, yeah boy. Seems like forever. Yeah sure it is. Yeah, there's been a lot going on. I'm unemployed right now which has been incredibly fine. Unemployed or unemployed. I am just doing whatever I want. That's what I'm doing. Just real nice. And I got a couple of software launches which was nice. I had a book launch last year which was nice. I've been living 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 fun ways with RANs and a lot of them resonated with people. Do you remember what was a RAN that really stood out at any point in time that you got some really good feedback either at that point or later you felt that way to buy it? Oh, well, so a lot of people tell me, well those who know your 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 struggling to sort of like get this idea across to people that Java's growth was super linear with the amount of code. The amount of code would grow more than the amount of functionality, which is not a good place to be. And God job has 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 does it 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 the execution in the kingdom of nouns. People really loved it where it was a story. It was 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 point you made? Of course, that's one of the most important blog posts ever. I'm going to tell you, I'm that a guy 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, because this dude's in his 30s. And he's played my game. You understand the game that I wrote? It's something that these people, why are in 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 created so much love in the players for decades they would come back, right? But this guy was so into it and he's like, 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 you read it. He 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? At that time, I think it was a 2012 or so, even then I would assume it was a bit unconventional to say you need to understand assembly because it was high level language. Right? Java was in its prime C sharp. Ruby was starting to come out. I mean, JavaScript was starting to become big and react to it. We'll start in a few years. And most developers would have felt 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 what university should teach is what you're asking me, Gary Gay, okay, in disguise. And you know, that those goal posts 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 had never seen a bit before, right? And we realized, we did some soul searching in the 2010s, you know, and we were like, "Yeah, do you really need to know how to manipulate bits in a biote with XORs and stuff like that anymore?" Probably not, right? And that was a depressing realization because we had tried it 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? This is 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? And this is. We're not even talking about AI, I just see. I'm like, this happened even. It's AI, did you see AI? No, not yet. We will say it. But this, but even in the air, remember, like, you know, late 2010s, it didn't really come up like. Like, career, I can only remember one time where it would have been nice to know what the compiler did, but even then might have 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, the graphics. Look at graphics today compared to 1992 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 online so I can render it. So eventually turned into a triangle, which is a polygon. Meanwhile, two years later, I took the same course and we were doing animation. And you didn't know what a polygon was. I mean, I did, but not at that level, right? The whole latter just kept moving up. And the jobs changed. Originally, they needed people to look at right device drivers. And now they need people who can do game worlds and physics and all this stuff, right? They 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? Yep. Steve just made the point that the industry goes through these massive maturity leaps from Robbix, Solstice, 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, WorkWaz. If you're building any SaaS, especially an AI product, authentication, permission, security, and enterprise identity can quietly turn into a long-term investment, sample 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. WorkWaz provides these building blocks and infrastructure so your team can stay focused on what actually makes your product unique. That's why companies like Entrothic, OpenAI, and Cursor are ready to run on WorkWaz. Great engineers know what not to build. If identity is one of those things for you, visit WorkWaz.com. With that, let's get back to the question of what the last real innovation 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. In fact, 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 you Uber brought micro services into there, how you scale services, how you store large amounts of data. I feel that was a big, it was a big slow. Yeah, but honestly, I feel there's a lot of migrations happening. New react versions coming up and developer struggling with that. Apple every year throwing in a screwdriver in the wheels with the new braking 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 boot campers with three months experience were getting offers. Pretty good company because it 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're always pretty pragmatic. You know, you're by trade, you are always into compilers, debugger tools, that's where you started, you worked on hard problems at Amazon, at Google, never shy to wait to get 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? 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 EMAX list functions, like chat GPT, the original one in December 20, 20, 30, 20, 22, or, 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, because I've had friends in AI for 20 years, saying any minute now, any day now, right? And they'd show us and they 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 tell you because when, when the rumors came out about cloud code in beginning of last year, right? And then I wrote death of the junior developer right after that, actually, I think gosh, it might have even been after after a 40 came out, but 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 code here in EMAX list function, then in a year, let's see how they do. And in a year, 4,000 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 have until 4,000 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? 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 risen 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 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 those important pilot 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, my life's work isn't really right. And that's what caused actually Jean Kim and I both to go, right, you know, if the inventor of, you know, he made huge contributions to visual basic and C# and link and and and and Haskell and PHP with a pig. 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 pretty big words from a language is person one of the most famous in the world. Right. What is he see that we didn't. And 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# 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 season sponsor sonar comes in sonar, the makers of sonar cube has introduced the agent centric development cycle framework, a CDC, a new software development, metallurgy designed for the unique scale and speed of AI generated code. It's a move towards a more intentional for stage loop that gives agents a culture is a actual need. The four paces being guide first agents need to understand that canvas on which you're being asked to create so that the output fits with what the developer and organization require generate the LM based tool generates the coded beliefs will achieve the desired outcome within the right context. Verify. Next, the agent is deliberately required to check its work, ensuring it actually achieves the desired outcomes and is reliable, maintainable and secure. Solve. Finally, any issues identified are provided to a code repair agent to fix to power this sonar has significantly strengthened this offering introducing products and capabilities like sonar context augmentation, sonar cube, agent analysis, sonar cube architecture and sonar cube remediation agent. This sonar source of calm sash pragmatic to learn more about the latest with sonar and how it's empowering organizations to embrace the agentic era with this let's get back to Steve's exponential curves of AI improvement. Playing doubles advocate, you know, like one thing about being an engineer is like you you can draw curves, but you know, like you never know when they end or if they flatten what not we can see where has come what made you believe that this curve would keep going, especially that with LMS, the fact that it even kind of works was a bit of a I guess surprise for a lot of people in the fact that it kept scaling is a surprise and there's this question of like how long they will scale. Yeah, so the world is filled with unbelievers. A people who specifically who believe the curve looks like this an s it goes up and then it flattens. Okay, and they actually think we're at the hump right now and they have thought that ever since the GPT through five came up they're like yeah it's not going to get you better. For all comes out we love for people love for all they still do they can't get rid of it, but they still think that this is a good is against you know, almost 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 it's gone from about four months beginning 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 the people are going to start to be really freaked out by it. It's going to it's going to worry people when they see the next model. Okay, because all of the bugs all the mistakes that they're complaining about right now get fed right back in his 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 in five years from now the sun's not going to stop right and it's coming. So this inevitable the collision of these curves men it's 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. Gary gay, okay, I'm mad at Amazon for layin off 16,000 people in blame and I without an AI strategy for those people are not going to be able to find jobs my enlarge and they're the first of many to come and nobody has a plan for this. What what 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 zero 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 out about 50% and we're going to lose about half the engineers from big companies which is scary. Yeah, that's wild. It's way that's way way bigger than we've seen back at COVID and 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 two and five 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 bottom up and we've got this mad knowledge workers falling out of the sky as big companies lay them off because there's clearly the big company is not the right size anymore it's not even anti jacy saying it we're going to do the same thing for your 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 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 and that there is so there's this land rush starting I think a lot of 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 going to 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 this. And where you get your software from and it may we may well wind up from I could actually see a happy place where I'm going to go. is 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 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 our 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? No. 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 skeptics are missing is not that 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 know why people would fight that, but speaking about the job as a developer, you've set something that can be triggering for a lot of people. You've said that, I think this is on the AI engineer summit that if you're still using an IDE now, you're a bad engineer. Yeah. Well, you got to be a little provocative. Yeah. You know, I, I, let me put it this way. Okay, 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 one or two in my chart, right? But I feel profoundly sorry for them. I feel pity for them. Like I've never felt in my life for these grown people who are good engineers or used to be. And they, they're like, yeah, you know, I use cursor and 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 drawn us 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 have their IDs open. Some of them have a big wide coding agent. Some of them, the code agent was really narrow, right? You know, and so I was like, okay, we're going to put you all in a spectrum just to show what's going on, right? And level one, no AI, right? You know, and level two, it's the yes or no. Can I do this thing? You know, in your IDE, right? Yeah. And then level three, you're like, yo, just do your thing, right? Your trust is going up. Right? And then level four, 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 diffs anymore, right? So you're not proving as much now? You're not proving as much. You're letting more of it through and you're really focused on the conversation with the agent. And then at level five, you're like, okay, I just want the agent. And I'll look at the code in my IDE later, but I'm not coding with my ID. At level six, you're bored because you're like, okay, my agent's busy. I got to do something. I'm totally in 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 spin up the multiple agents so that they don't get in conflict? Is it your, are you going to use like, yeah, so that takes you to level seven, 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 I got to clean up 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 cloud code could run cloud code? That's the question everybody wants to know. And everyone was trying all last year, it's going cloud code, run yourself. It would run for a while and it would stop, right? And so it was the whole stopping thing that, so yeah, I pushed on that really, really, really hard and wound up building some stuff to help with it. But, yeah, boy, it's changed a lot. It's changed so much. Going back to the ID, you had a really good live debate with Natanssobo from Zed and the title was a death of the ID and both of you argued your view. What is your view about the ID and also what did you learn from Nathan on like his take of, he was a bit more pro ID and you were a bit more like, maybe this is not going to be around forever. Yeah, I mean, I am where I am in my journey, which is I think that, hey, I will do it all for us eventually. And so the way I see ID is, what do they really do and what are they really for? It's not really for writing code, it's for bringing tools together, for making a big tool, right? Yep. And yeah, I'm going to see for that or whatever, right? So I see ID is returning and I think cloud co work is a return to the ID form. It's a cloud code going, oh, I need to be for real people, right? But I think cloud co work's form factor probably works better for the average developer than cloud code does, right? So I see ID, I see it's coming back into the world where it's ID is except it's all conversations and you know, monitoring. And this is a really good point. My brother built a thing called craft agents, which is pretty similar to cloud code work, except they connected in their company, their own data sources. And he said that some developer starts to prefer that because it's a visual that's easier to see parallel agents. For example, if you're not a power user, it's easier to scroll. It's just a nicer UI. So your point on maybe some developer should try out like if you're not sold on cloud code, like try, cloud, or any other similar or more visual thing, it might be more, you are thinking, but like you know, get some people love the command line. I actually just use the UI because I just don't like memorizing the commands is embarrassing. It is to admit or maybe these days is not as embarrassing. Not yeah. The key was try as long as you're trying something. Yeah. What probably the single most important proxy metric that you can have it in a company today is token burn because what token burn says is your engineers are trying to do stuff or you're non engineers. And when they're trying, they're failing and they're learning. So if you want to get those organizational bottlenecks discovered early on and you want to get your engineers leveled up on my eight level spectrum early on and you want to solve your business processes ahead, you need to start now, which means try. It doesn't matter what you try. It doesn't matter which tool you use as long as you're using AI and you're trying to get it to do the work, you're doing the right thing. Yeah. And I think as professionals like we really ought to just at least try. Like you get for a sound experience and then you can make your decision. Steve's point about token burn is really interesting. The companies that win are the ones that experiment the most. And if you want to bring that same experimental mindset to your product, not just your AI usage, that's exactly what our presenting sponsor static is built for. Static gives you the complete toolkit without building it yourself. You get feature flags, experimentation and product analytics, all in one platform and tied to the same underlying user assignments and data. In practice, it looks like this. You roll out change to 1% of users at first. You see how it moves the top line metrics you care about, conversion, retention, whatever is relevant for that release. If something was wrong, instant rollback. If it's working, you can confidently scale it up. Companies like Notion won from single digital experiments per quarter to over 300 experiments with Static. They shipped over 600 features behind feature flags, moving fast while protecting against metric regression. Microsoft, et al. and Brex use Static for the same reason. It's the infrastructure that enables both speed and reliability at scale. It has a general free tier to get started and pro pricing for teams starts at $150 per month. To learn more and get a 30 day enterprise trial, go to statc.com/pregmatic. With that, let's get back to Steve's take on the state of gas town. Now, there's a huge problem with people not knowing how to try and they say, "Oh, let me do something." And then it does the wrong thing because they always do and then they're like, "Well, this is garbage." So you have to teach them that it's a shovel and you don't go shovel dig like in Fantasia, right? Like make the brooms walk around. No, you pick up the shovel and you dig with it, but it's a shovel that you didn't have before you were using your hands. It's a really, really simple analogy, but people just don't get it. They don't get it. And I think, and I'm going to say something that's contentious, but it's just the reality of the world. Most people can't read. I've ruined much of my work in my life. I've just completely gone down wrong path by overestimating people's ability to read. And I think that reading is, if anything, getting harder to come by as a skill these days, and this is the situation that we're in right now is that Cloud Code makes you read a lot. So I think we're in a weird limbo for the rest of this year, okay? We're until the UI's arrived that are good enough for everyone who can't read. Everybody who can't read is going to be a severe disadvantage. Tell me a little bit more about your observation of a lot of people or a lot of developers cannot read because you were at Amazon. That place supposedly is running on six pages and people actually reading, does it? I mean, most people can't read. I don't know if you know this, man. Like, they read really slow, okay? And the AI is, I mean, come on, to most people, five paragraphs as an essay. Remember, five paragraphs in the high school is a thing we have in America, I guess. Maybe years were 100 paragraphs in the answer, man. But to us, five paragraphs is a lot. And that's like, that's the AI just clearing its throat, right? Yeah. You know, you've got to be able to read waterfalls of text. And so we're looking at a world where that won't work. And so you're going to need recursive summarization. You're going to need a factory. And it's funny because like, this is why, I mean, trying UI is so important because Gaston right now, the reason I say you can't use it is that it's a factory filled with workers and you're talking to it through a telephone. You can also go and look through the window and count on it and talk to the workers. But it's not like you're in it, right? With a UI, you're in it. And you can see what's going on, right? It's all invisible and yes, to buy in large, right? You know, hard to see. And so I really do think, and I'm just going to make a bold prediction. I think that by the end of this year, and we'll see demos of it, like right away, but by At the end of this year, most people will be programming by talking to a face. A face as in a face on the screen. A face. Your AI like the gas town mayor will be a fox talking to you and you'll say, why doesn't it work? And you'll say, I'll go look at it and it'll go spin off its workers just like it's doing that you're talking to a face. And it will talk about it. Yeah. I think that's the only thing that's going to work for most people. Fascinating. Let's write this down to prediction. Why do you go build it? I'm not going to. Let's talk about gas town. You mentioned gas town. For those, a lot of people have heard about what is gas town. Gas town is an orchestrator. So 2023 was completions. Code completions. Yeah, autocomplete. Yeah. That's when we said this in fact completion acceptance rate card. Remember that? Yeah. People are measuring it. Stupid metric, by the way. Second one was, but it was close. It was a proxy for are they trying? Right? Then there was chat. That was 2024. Right? Agents was 2025. We knew you could just look at that curve and go, okay, well, if chat is completions in a loop basically, and agents are basically chatting a loop, well, then we're going to put agents in a loop. And that'll be an orchestrator, right? And a bunch of them started coming out and I built one of my own. Yeah. My own vision. But that's all it is. It's agents running agents. And can you talk through and a software engineer to this architecture? Like how is it organized? How can I imagine you'll just set up? Yeah. Sure. And the Gas Town is really complicated and it's been really broken all week because I'm migrating into Dolt. And that's where I actually learned how complicated it was. It has a lot of features. You're migrating to Dolt. To Dolt. It's a new database. Oh, okay. Yeah. Dolt is amazing. Dolt is a get back to database. It's a get database. It's beads is just get plus database crammed together badly. And there's actually a database that does this. So I'm migrating to it. But yeah, anyway, Gas Town is what it should be is one mayor that you talk to. That's your person. And then what else needs to get done? They're just going to fire off workers. Okay. It's a little a little bit more complicated than that because there are really, I think there are two kinds of work that people go back and forth on and people are arguing about whether they're the right one. Some people that anthropic told me it's the minimaxing context argument. Okay. And then people who believe that you should maximize your context window and fill it with rich, juicy context so that the AI is wise and all knowing when it's talking to you. They want to like, you know, just write at the edge of the context. And then there are others who are like task, kill it, task, kill it. I want the shortest window. We need a short window because of the quadratic increase in cost. Combined with the dramatic drop off in cognition as a tokens go up, right? Yeah. Losing their track and stuff. So what's one's right? And we've got people who are like, full on in the minimizing and the, the, the macsures. And I looked at my work workflow and I was like, well, poll cats are the min and crew are the max. I have two fundamental role worker roles in gas town. So you have to do a really simple one, which is the small concept of the poll. Yeah. If you have a really well specified task, I'll bring them down into some tasks. Then you can find, 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 going to have to have a series of conversations about this. I maximize contacts. I'm like, read all these docs and then we'll talk, right? So it's just too workflows. And like I like to do. I mean, it sounds like it's, I think it's so easy to imagine. Like it's a little town, you know, like it was wild wild was there's the mayor, like the crew, the, the workers, everyone's buzzing and going around in the house, so being built in practice, how does this work? Like how has this worked for you? How, 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 really, it's an experiment, right? 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 Anthrophic told me they, they like it that they're kind of embarrassed some of them because they feel like I've got all these work rounds for bugs in their model, which it kind of is, right? But it's not a bug. It's so 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 bitter lesson, right? So a lot of Gastown is going to simplify and flatten into just minute, minute max rolls through, free max and your Polk has free minz and, and I think that's the natural shape and they'll just scale up. And could that be the Polk as they might just be sub agents at top point, for example? Like, well, sub agent, I mean, Polk has our sub agents. It's just that they're more their first class. They have their own identity inbox. You can talk to them. You can actually see how they performed over time by computing skill vectors on their work and things like that. So 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 it and be like, dude, your Polk hat's not working. I'm going to 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 cloud 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 happening in the industry at some point. But Gastown itself, I mean, it was all calculated, all the characters, the naming, why did I even do Gastown? Right? Why is it like? 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 are no swarms, no 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, well, you're 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 or the realm of possibility. So is it fair to say that you took on more than you, you'd reason when we thought you could chew? Like on this more ambitious ones, because you wanted to both stress tests, what these models can do. Uh-huh. And find out what you can 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 100 Gastowns together. We have a community, a discord. And if Malt book can get people to pitch in tokens for fun, like they're paying, they're paying for the inference of your agent on Malt book, right? So if I string 100 Gastowns together and we decide to build something together, we will learn the mechanics of Federation. We're probably retracing Ethereum steps, but we will. And we're going to come up with something remarkable. It's like the people version of Malt book, whatever it is. And what are misconceptions about Gastown or what is trying to do that you feel it's kind of gone off a little bit of rails and is it good to clean up? Well, I mean, for starters, I don't think people should be using it and they are. And I really mean it. Well, I'm the one who people should not be using it, like not should not be using it, except you for doing research or if you're like actually understanding this is just a proof of concept. So some very, very clever people that I've been talking to have been searching their problems faces for subsets, categories that Gastown could productably use today at a big company, a big fortune 50 companies say. Wow. And they've identified some problem spaces that you could put Gastown on today. And I was like, oh, it's 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 almost a Ralph loop, but they think Gastown could swarm it and eventually converge on a data center that works. And save all the people the trouble, you know what I mean? And I was like, oh, I ate. And this could potentially meaningful move the needle on their ability to open up more of these data centers for people, right? Oh. Yeah, go figure. And the same guy was telling me that he's been looking at production incidents and he's realized their system is already in an indeterminate, unknown, broken state when they're down. So how much worse can I actually make it? Now I caution him and said, actually, it can make it a lot worse. But he's thinking on the long lines that there are certain categories about it, just where you could have them in investigation mode or whatever, right? Or 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's a class as a problem is emerging for which you can swarm them because 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 bid off more than I could chew. There's no question about it. And Gastown is a huge mess right now and everybody's going, he's going to ride 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 that 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 there results as bad as I would think they would be? Because this isn't right. Like, if you imagine we're going to 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 injury comes in and cleans up the mess. And I'm just curious like how, how is it better or worse? Well, so the ceiling of what it can actually build, production. before it just dissolves into a mess is going up. But right now, I think it's sitting somewhere between a half million and five million lines of code, somewhere in there, probably more on the half million side right now, and with the next drop of an anthropic model, we're probably going to see it jump up to a few million lines, just pretty good size, but it's nothing compared to what enterprises have, right? Nothing. Enterprises are very, very, very, very, very, they have hundreds of millions to billions of lines. Yeah, but not in one code base. Like having a few million lines of code is already a bit code base, and you'll typically have 50 plus people, sometimes 100 plus people. 200 plus working on it. Right. What it really comes down to, just to summarize this conversation, get to the end, is how well you're going to be able to take advantage of AI, totally depends on whether you're monolith or not. If you're a monolith, which almost every company is a monolith, they have one monolith and then a bunch of microservices, right? If you're a monolith, you're kind of host, because I told you the ceilings going up for what they can do, but it ain't ever going to hit your monolith. That will never fit in the context window, and you're never going to be able to, never in the next 18 months be able to tell a model, go fix my monolith, you have to break it up. Okay. If you want to take advantage of AI, or rewrite it from scratch, it's starting to get faster at this point to think about rewriting your stack. One thing you mentioned, even before we started that, AI can really drain you, it can drain your energy, it can pull you, and it can suck you, and can you tell me about it? Dude, there is something happening that we need to start talking about as a community, as an industry. Okay. There's a vampiric effect happening with AI, where it gets you excited, and you work really, really hard, and you're capturing a ton of value. For me, I'm doing it off for myself, and it's still kind of like pushing me to my ragged edge. I find myself napping during the day, but I'm talking to friends at startups, and they're finding themselves napping during the day. It's funny, they literally try to load each other up with enough context to force the other one into a nap, almost like a compaction event. It's so weird, and we're starting to get tired, and we're starting to get, crank, and I started talking to people in the industry, and they're starting to get tired and crank. What's happening is, see, companies are set up to extract value from you, and then pay you for it, right? But the way all companies have always been set up is that they will give you more work until you break. If you can do it, they'll just happily just say, "Give you more, give you more, until you're plate flows over and you die." People have to learn the art of pushing back, right? That's been a thing for a long time, but it's changed the equation, the way you push back, the reasons to push back, and all that have changed very dramatically and are changing right now, because you've got all these people now who can be super productive, and it's like, let's say an engineer can be 100 times as productive, just for sake of argument. Who captures that value? If the engineer goes to work and works for eight hours a day and produces 100 times as much, the company captured all of that value, and that is not a fair capture exchange. I think we can argue unless if they have early say sharp and they have a meaningful equity, that's a bit different than it grows with a lot of people. But that's not the majority of people, right? It's a minority. Yeah. We're probably getting there pretty quickly. I didn't, you know, we did notice one thing. Like, and you probably saw this as well, about six months ago, we talked about a lot, the 996 problem at AI startups, and we were like, "Oh, it's interesting. AI startups, people are working really freaking long hours and they're posting that they're in the office at 3 a.m. and you could tell. I'll share with people what 996 is, who don't know. 996 is 9 a.m. to 9 p.m. six days a week, if I'm not mistaken. Which is 996 is, it's the standard you're expected to work in most of Southeast Asia, as far as I know. I haven't been to China, India, but I assume it's pretty much similar there too, right? There's another group of people who are capturing all of the value for themselves. They go in and they work for 10 minutes a day and they get 100 times as much done, and they don't tell anyone and they've captured all the value. And that's not really ideal either, right? So, at least in terms of, if you're thinking in terms of how can groups of people be successful, it's best if they're all contributing, right? So what do you do? And I think that the answer is, each and every one of this has to learn how to say no real fast and get real good at it. And we need to learn how to start capturing, and the correct, this is the new work-life balance. It's how much of the value you're going to capture from being 100 times as productive and how much of it you're going to pass along to your employer. And this is a really difficult place to be, because we don't have any cultural. All our cultural expectations are pointed in the wrong way for us to work harder. And they want us to, right? Everyone wants to extract, extract, extract. And so I seriously think founders and company leaders and engineering leaders at all levels, all the way down to line managers, you're going to have to be aware of this and realize that getting engineers onto this treadmill is pulling them into they're using much, much more of their system too. You know, they're doing much, much more of that hard thinking now. The easy stuff is getting automated, so you're actually draining them at a higher rate. Their batteries are draining at a higher rate. You might only get three productive hours out of a person at max vibe coding speed. And yet there's still 100 times as productive as they would have been without AI. So do you let them work for three hours a day? And the answer is, yeah, you better or your company's going to break. It's very interesting. It's also like the value extraction, I think. I can see us beating up and we see it with a few prominent people. Peter Steinberger single handedly pushes out so much more value output. You name it, commit in any way. That would have been a team of 10 pretty good engineers before. And he, you know, like in all fairness, he is capturing it in the sense that he's, it's his, is his project, his baby. He does not sleep much. So that's definitely showing. But the value capture there is kind of OK. But I agree with you that this could be something like in the past, whenever there was a technology shift where people were more efficient in your lifetime. Have you seen this where engineers became more efficient? And suddenly you could do a lot more with a lot less. And what happened at that time? People got mad. Yeah. I think the example, Pearl, the pro programming language was a massive accelerator. Amazon's website was built in Pearl. Probably still is. I think Facebook's technically is too. PHP is a fake pearl. And you can quote me on that. So in both of them, we're incredible productivity accelerators. And everybody just could see it. You don't want to build web sites and see. You just don't Amazon tried it and they gave up. Right? So that caused a huge rift to huge schism. There were second-class citizens. All kinds of cultural dynamics happen there, right? I'm curious about how some AI companies deal with this. Can we talk about how anthropic works? Yeah. Yeah. What I know from what you know from the outside. I know that you talk with people across the industry. But anthropic is a very interesting place. One interesting thing that Dario recently said is he thinks. Compensation specifically for their staff, the people who are building all these things. And they're actually using the models and doing. He says something interesting that maybe we should have compensation where people are compensated even after they leave the company. For the value that they created, which is just something completely unheard of. But it's clear that he's thinking about this. This thing that is changing where you can't. Individuals can create massive value in a relatively short amount of time. Google, you can send me a check for all that stuff you never paid me for. Okay. Just got to get that out of the way. I like that idea. Anthropic is unlike any company on earth. Right now. They're operating in a space that is really fragile and they're very protective of it. And they need to be. Because they've created a hive mind. They're running the company as far as I can tell, like a pure functional data structure. Remember Crystal Cassakie's book? That was such a mind-blowing. You can make data structures that never mutate. Then how do you mutate them? Right? And the answer is you just keep adding. You'd improv. Yes and. Yes and. Right? And that's how they operate. And when you say hive mind, what do you mean by that? It's a lot of it. It's like the markets today. Vibes. Every time you're doing it, you're doing it. Like the markets today, vibes, everything's vibes. It just shifts. It's just. Right? It's it's it's vibing. It's it's kind of hard to explain. But you see here's a thing, right? We used to build products by like making spec and then implementing it and then complaining about it and then shipping it. We're going to have a rope map and planning for it and. Waterfall. And timing it for the company annual events. Right. But the. Apple, right ones a year. The way you work with like systems like Gas Town and they've got their own internal orchestrators is you create it. And your founders, the one like the co-founder that was non-technical, you create the prototype and that's your product and you start building it and you just make it the product until it's right. So everybody just gathers around the prototype like a campfire and builds it. And that is what anthropics doing at scale with thousands of people. So you're saying that the playbook of a successful tech product might have changed because the traditional wisdom since the lean startup in like 2010 or so was. And then you use your prototype to get signal that you throw it away and then you build a lot more polish stuff right. And we used to I think every software engine has been around. You don't ship a prototype. You tell people it's a throw away. You start again. You make it production rate scalable. That kind of stuff because you don't want to give a bad experience to people. Yeah. What change though? Just the ability to do 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 cloud co-work happened in 10 days. Somebody went, hey, I did a prototype and they were like, we're going to launch this in 10 days later. They launched it. So I mean, it works. But I guess one important context there when I talk with Boris Cherny about a feature that they did about how they did the tasks in the cloud and cloud code the task list of how it completes. He told me that in two days he built 20 different prototypes that are 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. I 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. I 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, Fafu. FAAFO is the dimensions of value that you get from ride 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 going to change the way that people are organized to create software. And it's going to happen this year. It's just fascinating how these changes are coming. And what enables these changes? Is it the fact that we can iterate faster with these things? I look, I saw a phenomenon happen at Google. This is kind of a big company question. There's kind of, there's a big company and a small company answer your question, right? So something happened at Google. I went through the golden age at Google where it was like anthropic. It was a hive mind. Nobody was mean. Everybody was innovating and it was wonderful. Yeah, this was time where the founders were pretty close. You go to the shop and tell. And Larry and Sergei be sitting there and he'd hang out with him and just chat. And it was like golden age, right? 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 all together. And since, I don't know, 2008, there has been no innovation from Google. It's all the acquisitions. They've created nothing new. I mean, I mean, they did Gemini a few years later, right? Gem, Gem, yeah. Okay, sure. They created all of them. That's a perfect example of why innovation dies there for five years, right? Five years they did nothing. So I don't count Gemini. That's a different Google. Yeah. 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 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 a 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 rabs 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. 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 in Amazon once told me that we don't have a lot of the problems that Google has because everyone at Amazon is always slightly over subscribed. They have too much work. I've heard similar with Apple as well. That's kind of the little bit 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 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 happens when. Right. Like the catalyst for the bad stuff beginning is more people than work. And all of a sudden, people can do all the work. Then the company's biggest problem is going to be finding more work or they're going to have to get rid of people, which is kind of bad, right? But it's not unlike Gas Town in the small. My biggest problem with Gas Town 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 on 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 the problem with gas. And this is the problem with everybody who's going to use any orchestrator. Doesn't have to be Gas Town. 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? One thing that I think, you know, where it might sound like we're talking really abstract, especially for people who have not done this type of work in this self is like, well, we're talking about orchestrators. They're like all productive. Can you point to something that has been built with an orchestrator with this higher productivity that is a production software? Are you built it or you've observed someone build it that could show like actually, this is way more productive and we can actually see the output or turning it the other way around. Like we're still not seeing that much more output from companies, teams that you would expect. Okay. Like a lot of them are having more productivity, but like from the outside, it's easy to be skeptical when we're seeing not much has changed in terms of our data. Live the apps. So, you know, we're seeing signals here and there, but nothing major. Why might that be? Yeah. That's fair. My feeling is that probably people have a low tolerance for non-determinism and these things are fundamentally non-deterministic. So, they can't just go replace customer call center software because they could be wrong. And it doesn't seem to matter that humans are also wrong very often and AI's can, these days, can very easily get to the same level as a human as an average human in the job. But I think there's still still a lot of risk aversion. Right? So I think that the companies that are actually running with this are actually starting to see the results and it's going to be reflected in their quarterly earnings and visibly in another ways at first. Could it be that we're focusing on building its tools? I'll turn it around and I'll say what if what we're actually observing is that innovation at large companies is now dead and we are only going to see innovation from small places, which is kind of what happened when Cloud came out. And Facebook was a college kid at one point. Facebook feels like the biggest company in the world right now, but it was one dude. Okay? And so when a new enabling platform technology substrate appears, you're going to see innovation at the fringes because of the innovators Deloma. The companies can't innovate. They're all running into this problem. They may have hyper productive engineers who are producing at a very, very high rate, but the company itself can't absorb that work downstream. They're just hitting bottlenecks and these engineers are getting shut down and are quitting. Right? I think what's happening is we're all looking at the big companies going, why are you going to give us something? And the answer is we're looking at the big dead companies. We just don't know they're dead yet. Do you think they're dead because for example, it can now be cheaper to do something like we can just say the external punching bags and as customer support, they have been the de facto place to do your customer support because your agent can sign up. They get this UI, they get this workflow, etc. And for AI native companies that are using MCPs who have not, it makes no sense for them because they just want an API which then does not want you to give to you because they want to charge extraordinary amounts for you to come to their platform and buy their AI for 10 times the cost. That model is going to struggle a lot in coming years because people will build their own stuff, but spoke with APIs. This is my platform rant in real life. If Sendesk doesn't make themselves a platform, then they're going to build product themselves out of existence. I think. And the platform for looking ahead, is it APIs? Is it the M&M CPUs? I mean, as far as we can know, maybe not MCP, right? What did Anthropics found that what works better than MCP is having the AI write its own API to call the MCP because they're so good at writing code? But then nothing really changes because platforms always APIs from the beginning. Yeah, so why do we need MCP? Well, we needed some way to declare what the tool does in an AI way, but I mean, like, I just, it's so loose and so flexible. Integration's going to be really easy. I don't know. I'm not following that space well enough to know if MCP is going to continue to be an important dominant player or if the AI is just used stuff directly like the command line tools, right or APIs. But either way, we're moving into this world where the innovation is coming out of new shops who have adopted and adapted. And I see big companies struggling really bad right now with this. I wonder if we will see a lot more of these building blocks that we didn't know we needed. 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, they're storage or for matching or for whatever it is they need to do. 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 somebody's building blocks that work in a reliable building blocks will probably in need that are that have states that have SLAs, whatever have some some some importance, right. That's not trivial to do. That's right because AI is your lazy 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 need to maintain for example, like you need to keep up with. May that be regulation or changes or logging or whatever. Yeah, that's going to 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 were also lazy. Yeah, I mean, well, Larry law call 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, which was called the Borderlands Gun Collector Club. You're the one that read that one. I got recommended on Blue Sky and a lot of people liked it and I read it and I realized it didn't read it. This was a really interesting essay because seemingly it has nothing to do what we're talking about, but you talked about gamification and you talked about how this borderlines 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 medical that the designers probably never thought of, but it actually made the game pretty kind of addictive. 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." There was accident-formed game designers, but maybe more game designers should do this because it just makes the game addictive. And, you know, like not saying that. But since that, it 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. Whether or who is it did the Borderlands, take two or I forget. Anyway, they figured it out early and then they didn't capitalize on it. But yeah, so interestingly, I think yeah, gamification, gamification's kind of rearing its head. People pointed out that, like, people are making game frontends to Gas Town, right? I mean, why am I making a game? Like, come on, man, I mean, like, look, we have literally, we have games for running factories. Imagine you're running an actual factory. How cool is that, right? That's what Gas Town is. That's why it's so fun, actually. - Do you think that one of the reason that some of the agents are more successful than others, looking at specifically Cloud Code is, they also, this is gamification, where there's always something showing there, right? There's a tanker ring, there's the different things that keeps talking to you. There's always, is some of maybe accidentally or maybe deliberately? - Oh, they have the best product managers in the world and they have, they've done absolute magic with command line UIs, stuff that they've done, it's wild. But, look, I mean, come on, right? That's not gonna work for most devs. So, that's why Cloud Code work is so cool, right? 'Cause it's showing you the direction that things are gonna evolve, I think. - Yeah, so I think developers will use Cloud Code work or something more like it. - With traditional software, we have Tech Dept and we know how to deal with it and we've talked so much of this in fact, if we think about what we spent, we're very busy with the 2010s, Tech Dept, collecting it, paying it off, migrations, yada, yada, yada. Now that we're doing a lot of byte coding or you call it byte coding, but the agent again, engineering, just turning out a lot of code. How do you think we will recognize or deal with or do it and need to deal with this like byte coding depth or agent dig depth? - You do, you do. One of my upcoming blog posts is about this actually. I've discovered that there's a thing, I've given it the name of, it's called a heresy, okay? That happens in byte coded code bases that you're not looking at. Where an idea can take root among the agents that's incorrect. It's a wrong architecture or a wrong data flow or whatever that's causing an impedance mismatch for the rest of your code. And what happens is I call it a heresy because they have a tendency to grow and to come back and they're really hard to weed out, okay? I had a bunch of them in gas dump. There was a Polk Hat heresy that kept coming back. And so what would happen was it's invisible and your product stops working properly along the edges and you don't know why and you start having the agents dig into it and you realize you've got a fracture, you've got a fault line. You have like say two complete databases that are both alive and operational and you're randomly choosing between the two of them, right? And you didn't realize this until just now, right? - Okay. - You find terrible things in your code, right? And you try to get them all out but there'll be one reference to it and some docs somewhere that an agent picks up on and goes, oh, that makes sense. It's the heresy and it returns. And the agent does the wrong thing and goes off and rebuild the heresy and it starts to spread again. It comes back, right? It's like the agents want the system to work this certain way and you're telling them, no, I want it to work this other way and you're fighting with them and what you have to do is you have to actually document the heresy in the beginning of your prompting and say this is one of the ways that you can go wrong on my project, don't do that, right? And then you have to remind it periodically or even put in tooling to keep it from doing that. Another heresy is that my agents all think they should be doing PRs. It's like I'm the maintainer of this code man, just push domain, right? Or a branch or something, don't make a PR. It's just polluting the PR space. That's for contributors. They can't get this today. Now, I could put a bunch of hacks in, but that's fighting the bitter lesson. Opus five will be fine. Opus five will be, oh, you don't want PRs, I want new PRs. - What is the bitter lesson in the start? - Oh, the bitter lesson. Richard Sutton wrote a very, very short essay. It's like 800 words. It's one of the best essays ever. What I call the bitter lesson where he's like, yeah, we're AI researchers and we learned a bitter lesson and you need to learn this lesson. The bitter lesson is don't try to be smarter than the AI. You think that you've got special knowledge, the human spring special domain knowledge to this problem and we're gonna teach it so that the AI will be smarter. What we found was bigger is smarter, always. - That's what I said. - And this is a little more data, right? - Yeah, and so like when they're going into Australia right now, you've seen the drawings, how big open AI's training center was, how big anthropics training center was and now the training centers are big, are 10 times larger, they're massive. They're in Australia because they have all the energy in the land and everything but they are going to make models that are 10 times or more smarter than the ones we have today, right? - We talked about the vibe that but does it not pain you? I mean, as someone who has built software, you know how to build a good software, you went in there to clean up the mess of junior teams or like messes, you could clean it up in but your eyes closed or maybe you had to keep it open. Does it not pain you that when you describe oh the AI going off-shore and doing it, if you scaled it back and said like, hang on, like let me step in, let me make these decisions, let me do the architect, it would not happen. - Yeah, well see the thing is, I've also been a vice president at big companies of engineering. - True. - 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. - Oh, so then 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 a beginning of our conversation, everyone who believes right now that the curve is s-shaped, they are 100% correct, they are 100% correct, it is s-shaped. Eventually we will run out of resources. The world will be out of resources and it will fly, right? But I can tell you that there are at least two more cycles left in this and that means they will be at least 16 times smarter than they are today and that is gonna 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 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 is gonna wanna build their own software. - Oh, I was talking about a business, for a part, not not personal, but- - All businesses, yeah. - But yeah, but also personal software, what would the future look like when everyone could have open claw running in their closet or gas town or they can just, they don't have to run it on their thing, but they can turn to this agent? - Yeah. - How could that change, like both personal software, but also the software industry as a whole? 'Cause 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? - Could have could have changed, 'cause 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 poor 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, make this change, and they publish it in open source as well, often no one looks at it, but 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, and it's actually so there'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, right? If you fork somebody's project, it meant you had had enough of them, like root code forked client, and then somebody else forked root code, and it's just like, I think it's now gonna be an everyday occurrence, right? It used to be that to fork, it would be a lot of time and effort to maintain a fork, to merge back the thing. - Sure, sure is a fork, isn't it? - It is. - Yeah, man, that's a lot of work, that's a lot of work. It's a lot less work now, right? So yeah, everyone's gonna be forking. So yeah, no, I think that's a natural consequence of everybody writing code. - Yeah. - Just like everyone can take a picture now, that didn't used to be true. - Yeah, what are some of your beliefs from early on on your career that held really well until recently, and now you just abandoned because of AI? - Engineers are special, there's one. - Come on, we are special, no? Are we still special? - Yeah, sure, we learned how to do something by hand that computers can do now. Kind of cool, I guess. - What about the injury mindset? We have that, it's not just coding that with you, 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, it will be us especially. And we're gonna 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. SAS is awful. The whole, the whole, right? - Air line apps. - Air line apps, right? I mean, we ran a vibe coding workshop in Sydney where a dude actually rode an airline checking app for himself and got it into the Android queue before Southwest realized, and shut him down 'cause he was a bot. But that's what people want, they want personal books software. And they're gonna get it. And so yeah, I think you're gonna see, that's why when Jeffrey manual forked beads, I was like, you go. He's, 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, 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, so someone is getting better, the government website 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 have to go DHL and pay a bunch more money. - That's right. - And like, there's a lot of bad software out there. - Yes. And there's an agent will be dealing with it, not you. 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 gonna win big because everyone will use agents while they depend on it. - Well, it's also, I guess software or ways of making agents write quality software, 'cause I have a feeling like you will want to do better stuff that if you do the same, you're not gonna 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 gonna, until we build the Death Star or whatever, right? I mean, like, we're building bigger and bigger things. Oddly enough, you're okay, I am an optimist through all of this. That's my first belief, I think, first and foremost, is that it's all gonna work out. - So asking the optimist, now I got this question off, I think it was on Blue Sky. This person asks, like, how do you think the software industry will continue to exist if we get something 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 and we assume that these things actually can do it. - Connections, human connections are probably the biggest one. As, I kind of almost counterintuitively, as software does more and more automated for you, people are gonna be like, oh, well, yeah, but that's just automated. I wanna human to do it. And they will literally want a human to bring their thing instead of a drone. You know, they'll want humans to curate things for them. And I think that's gonna be, humans will be a moat. - Do you think if you look back at some history, like from the history of the research history, like have we seen some changes that felt a bit like this? And then we saw some professions stride because of either more automation or, you know, like, - Stack overflow? I don't know. I mean, 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 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, 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 Walmart's and Microsoft's coming from random visuals. Right? But the innovation's there. And from the startups that I've been talking to, you know, I've been talking to anywhere from two, five to 20 person startups, I think we're gonna 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, 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 see what you're doing, just don't show it to them and they will never see it. And if you do want them to see what you're doing, then you had better get it out in front of them as you do it instantly or else the train will pass you by. So like what they're saying is like, so I told the story of my blog, people have heard it, but they like yelled at a teammate, they were mad because he implemented a feature that they'd asked for two hours before. And they were like two hours ago, it's changed too much since then, right? And he's like, what do I do? You know, what's happening is they're getting into this mode where they realize that stuff moves so fast that everything is invisible effectively from the volume. And so you have to be extremely loud and transparent and intentional about saying everything that you're doing. So that if anybody else is doing it, they can stop you right then. And if they need to integrate with you, they can start right there. - And we're talking with startups that are looking for product for customers. They actually just want to get what we call product market fit where the traditional wisdom was built something amazing and then it really sits at a world. - That's right, that's right. Try to find product market fit and secret as much as you can and then launch it. And then tune, right? That's the formula and many people feel that it. It used to be. Now like you say, and with Gastown, I realized I'm not gonna find product for a market fit by myself. So I launched it as soon as it kind of worked and was like, help me. And that's how I found out about the build database, which was a big change and people fixed a bunch of bugs. I got 100 plus PRs the first couple days and, right? And so it found its way closer to product market fit just by me getting it out there. And would you say that is brought to, like on one end people look at you, well, yeah, it's just one other open source project, but is it bringing actually opportunity if you wanted to, could you turn this into a business? Has it brought you the things where I'm getting at is, is these things that take off either open source projects? Like can they actually turn into actual businesses? Or with that stage? - I promise you, if you would make Gastown, you would be shaking venture capitalists off you like ticks right now. - I am, they're finding me everywhere, okay? And I tell you, it's because there's a lot of money out there right now, sniffing, wanting to find its way and I know something big's gonna happen, right? And it's looking and you can see it and all these different micro economies that are springing up, but nowhere can you see it more clearly than when you launch something cool, like Jeff Huntly did Ralph Wiggum, VCs, right? Everyone wanna talk to him. You just gotta be real careful because anything you build probably is a real short shelf life at this point, right? A real short one. I don't, I'm not attached to Gastown anyway because I think it'll be supplanted by something better within six months if not sooner, right? So to attach to. - So let's assume that staff engineer is listening to this podcast or watching it on their commute and they're at the type of company where they have co-pilot still. There's people like this and they're using it and they wanna believe you, but they're not sure they can. What would you tell them? What is the thing that they can do to get proof that you're actually right and this thing is working? We're not at 100%, we're not even at 50% for people like a lot of people who are in the field I'll have tried it out, but there's a lot of people who are. - Oh yeah, no, they probably still 70% aren't doing it. Yeah, so what would I say? I had a really good message for them. Oh yeah, get out, get out. So here's the thing, right? Co-pilot is, if you were to wind up all the tools from best to worst, co-pilot is like, "You're a wine!" Right, it doesn't even know about the wine, right? But it used to be the best four years ago in 2020, right? - Yeah, yeah. - Which tires. - It was the first competition. - Even maybe two and a half years ago, I was quite stunned that somebody asked does anybody use co-pilot at an AI tinkerous meeting and somebody raised their hand, he goes, "Do you have to?" And everyone laughed and I was like, "What happened?" The brand just tanked. But I'm serious, if you're working at a company that gave you co-pilot, they think that they're starting to move faster and there's a barbarian whore of people using Opus 4.5 that are done. Destroy your company sooner or later. So what you need to do is go into the crazy part of crazy town and figure the stuff out and start building and because we are moving into a world very quickly. This year, where proof of work is so important and I mean proof of work, not the Bitcoin sense, but you are proof of what you have done your resume. And I don't mean your resume because nobody's gonna believe that. I mean the actual work that you did, which has to be visible back to our transparency, right? I think everyone's gonna be bringing their work with them. I mean, the notion of proprietary work is starting to, like, de-threatened, I think, because it's so easy to fork, it's so easy to clone, it's so easy to round around. If you have anything proprietary, you become this thing that everybody just wants to run around you. And so, right, so big, big changes are aflit. But man, if you're working with co-pilot right now, you are going to get left behind. And so, what you need to do is get your sub, find an a half an hour a day to go play with, with cloud code, right? And so, like I said, or if you're a company, make your token burn as high as your investors will let you go, right? Because that token burn is your practice. It's your sorting things out. - So, I wanna ask you the other way around. Let's assume you're just wrong in terms of the curve and we're right at the peak and it will not be 10x, it will plus 2x, - Absolutely. - Reacts, let's just say the next model is inexplicably dumber than Opus 5. - Yeah, let's repeat. - What would happen to the person who takes your advice and they go all in any learning of things? What's the worst thing that could happen to them? If these things take off, it's a great investment, right? But what would happen to them if they followed your advice and the models didn't follow? Where would that lead them? - Exactly where they need to go because the damage is done. Opus 4.5 made this officially an engineering problem. We don't need you AI researchers anymore, thank you. You can make smarter models, I guess, but we don't need them because we have something you can take a bite size chunk out of a mountain and it's a bite size about town size now and so we can eat mountains, okay? It's purely an engineering problem at this point. It's like fire or steam, it's a force, it's a power. And we wrap layer, layer, layer, layer, I worked on a nuclear reactor. I wasn't the Navy, I know how these things work, okay? - I thought so, we are going to put, all right? Layers around Opus 4.5, if that's the smartest model ever and that will do all of the engineering from now on. So it's done, so it's okay to jump into the pool now. - Your first job was about debuggers or not debuggers, but you worked at this amazing company. You told me they had the best debuggers tools. What was the name? - It was GeoWorks and the debugger was called SWAT and it was amazing, time machine and all that. - And on the first pragmatic engineering, when we talked this is in the newsletter, you actually saying? that you to this date you've not seen as good of a debugger but you're kind of determined to like build at some point and help build that. I did build a little debugging closure for the JVM called gonja. It was actually pretty cool but then I got an argument with Rich Hickey about how well he wanted to support the JVM and he doesn't so. Yeah but anyway you're a guy who is passionate about about. I'm sorry somewhere though. You're passionate about debugging. What will happen with debugging? What will happen with debugging tooling? What do you think the future of debugging is? With agents. When I see agents say I'm going to debug this they all use pre-nefs so I'm curious. It could very well be that they just haven't been trained on debuggers yet and that they'll all wake up in six months and go oh I should have been using this but it could also be that you may not need them anymore I don't know. And another step further what do you think the future of the developer workstation like our rigs, our machines will be right? Like do you think that a phone? I want gas down on my phone. I almost have it but I just haven't worked on it. Peter Stamberger told me that he had viped tunnel where he could do it from my phone. He said he stopped it because it became too addictive. Oh yeah. No tailscale and yeah actually the only thing that's keeping me from just being addicted to it all day long is it's too hard to enter control characters in. But that's going to get fixed at some point. Programming on your phone will be a thing. But so do you think that developer workstation can be just like with Chromebook what not or we actually want beefy ones which can run our local agents what not like what do you think of the head on the short term and then maybe on the longer term. Yeah. See what I mean local models. Yeah no I look I love my laptop. I've been programming 40 years. I get the local thing but I've been saying for at least 15 years that we don't need this stuff locally right. Google had an amazing client in the cloud high speed network connection and you can do this. Sitsy 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 by that especially in the world where you can run kind of unlimited agents based on your pocketbook. Yeah people are not going to be wanting to work in laptops and I've already. Gas town has already completely stressed out my laptop to the where you know 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 less and I've had not on laptops as much. In the past you've said that one of the most important kind of predictors of the bulk productivity is language design well design languages are easier to work with. You think this has completely erased or do you think it might come back at some point either purpose of languages. I think there will probably be purpose built languages by a eyes for you eyes maybe but right now we're in a funny place where the some languages work better than others still because they have better training data but in the fullness of time all the languages will work equally well. I push back on that like if if a new language never has training there how would it work I mean I start all the existing ones. The typescript it struggles with types today. It does but it's not going to in one or two months. So could we see a stagnation just fewer languages or no language that's launching because they just get the job done and launching a new language seems a bit suicidal unless you like being a bunch of like training data with it right. Man it's a loaded question. I mean I had a hard time. I didn't mean to make it a load of. 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 it really important things and then everybody else it doesn't 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 for an opt from an optimization perspective and efficiency perspective the search for new languages will probably continue. So for pragmatic for every day. I don't think it doesn't matter what you pick. Now you can ask your agent what language is using. So as a software professional who like loves the crafts is into you know languages, deep augurs, tooling, etc. A lot of what we talked about is pretty 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 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're sad because we're used to it. Change is part of life. And we're at one point I had to say goodbye to assembly language. Right. I was like, let's compile the writers. They finally caught up. Right. And then we were mad. But then we were happier because compilers are obviously way better than writing it assembly language. Anybody would be stupid to say, oh god, yeah, no, you're not a good engineer if you can't write the assembly language today. But that was actually what we were saying in 1992. And then you have the blog post out in 2012 as well. Yeah. No, I'm just saying stuff. Change is 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 where in this industry were change is a thing. And it's right. Now that's a bunch of opportunities. Now with that said, do you 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 realities 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, book, wait, I'm writing ten times more code than I ever was. And I'm having fun. And why should I be sad? And so I realized 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's just going to be. You're known for your predictions. And I'd like to put it to its 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. Oh, bold way. And she is not a little bit of her, 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 it, 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 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 waking on agents that know how to go and search the new world. Everything's coming out. I don't know what we call it, right? The work pile for software that you like, for experiences that you like. If everybody's creating it, think about it. When when you didn't it came out and everybody can make a web page 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, right? And so 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 the AI is ready for your thing. Yeah, I think as engineers, we already can build. We don't need permission. We can use this whole super efficiently. Right now. 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 web conti reading more, but this has been I think really eye opening and it's, you know, sometimes I think it's good 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 lie. Two years later, the same course was teaching animation. The working graphics went from writing device drivers to building game worlds and physics engines. It all just moved up the abstraction layer. Steve's argument is that software engineering is going through exactly that same shift right now, except it's faster. Instead of asking, Will and years have jobs at all? A better question might be, what will the new jobs we do as software engineers look like? Another thing was the grief of this change. Steve is someone who spent 40 years building his identity around compilers, debuggers, elegant code, and then one day he sat down and started checking off one by one the things that made him special that no longer mattered. His world won Monochrome, as he said. Within a week or so he came out from the other side and realized he was writing 10 times more code and that he was having more fun doing it. Still, I think a lot of engineers are quietly going through this something similar right now and it's usually taking longer than a week to digest all of this. Finally, one thing I found really honest from Steve was his point about value capture. If you become 100 times more productive with AI, who benefits? If you work 8 hours and produce 100 times the output, the company captured all of that. But if you just work 10 minutes in a day and produce the same values before, you technically capture it all of it and your company captured none of it. Now, neither extremist sustainable. Steve is saying that this new work like balance is a question that will need to figure out. We don't have the cultural norms for any of this and it's going to be best see as we figure it out. If you've enjoyed this podcast, please use this private on your favorite podcast platform and on YouTube. A special thank you if you also leave a rating for the show. Thanks and see you in the next one.