Latest / The MonkCast / "Absolute AI Maximalist" Adam Jacob on Building Software That Builds Software

Transcript

"Absolute AI Maximalist" Adam Jacob on Building Software That Builds Software · The MonkCast

• speaker-0: Good morning, good afternoon, good evening. I am Steve Algrady. I'm a co-founder of Redmonk. And I'm here today with Adam Jacob. Adam, would you like to introduce yourself? speaker-1: Yeah, I'm Adam Jacob. I'm the CEO of System Initiative, now building a product called Swamp. In a previous life, I was the CTO of a company called Chef that did infrastructure automation. Yeah, a good way to think about me is I'm like a systems administrator who turned into ⁓ a pretty good software developer who's turned into a pretty good CEO. I suppose it depends on how you measure, you know? Yeah, right? Am I good? I don't know. speaker-0: This is why I always have guests introduce themselves. They do much better jobs than I would ever do. anyhow, as we were talking about before we started rolling, ⁓ for the audience, one of the reasons I wanted to have Adam on the podcast is essentially just to talk about, I don't know, sort of where reality and AI intersect. Because I won't put words in Adam's mouth, but certainly the commentary that I see for AI in general is either people who are dismissive of the technology as sort of a toy and sort of something not real and won't work, which I very much don't agree with. But then there's other people at the end of the spectrum who are, know, the singularity has arrived and, you know, AGI is here and so on. it's so, Adam has been sort of commenting on a variety of places, but LinkedIn is certainly one of the places, which is not something I would have expected to say a couple years ago. speaker-1: Here we are, Rest in peace Twitter. speaker-0: I know. ⁓ Anyhow, so Adam's been saying some interesting things about AI, and more importantly, sort of in a practical sense in terms of its actual usage and actual impact. Yeah. So Adam, sort of just as an intro, do you want to give us some context in terms of, I don't know, your journey with AI, like how you came to it and sort of where you sit now? speaker-1: Yeah. So, ⁓ yeah, I think of myself largely as a, as a practical technologist more than anything else. know, like I have heroes that like Mark Burgess is one of my heroes. Mark Burgess for people who don't know who he is, is a, is a, is a scientist and a philosopher. And he creates incredibly deep, dense. He's a physicist and he writes these incredibly dense books, proving the theory of what we all practically learned. to understand about how large-scale computer systems works, promise theory, those sorts of things. I'm not Mark, you know? Like, I can read Mark's books and be like, that's what's been happening to me. know? That explains my experience. But I can't write it myself. You know? I'm not that one. Once she was not being... speaker-0: C-Man's technologist. speaker-1: kind in the moment she did it. We're friends, still are, but she called me the Malcolm Gladwell of DevOps once, a friend of mine did. It was not a compliment. ⁓ but, but, know, it burned a little cause it's a little true, you know? Like I'm, I'm good at distilling. I'm good at distilling theory into practice. And then I'm good at that sort of reporting back my experience of that practice. think. You know, in terms of my own journey, you know, the place I live and hang out is in automation. That's what I have loved to do. It's what I still love to do. It's the stuff that I love to build. It's the people I love to build it for. ⁓ I started a company called System Initiative that was trying to sort of push the boundary of how we would think about doing that work. ⁓ First through like a visual paradigm, and then later on by discovering that we had sort of built a really great engine that we put some AI on top of, which in the end, nobody liked. It was just too weird. It was too complicated. It ⁓ was a bummer. But, ⁓ one of the things we learned toward the end there was that we started building some agents that sat on top of that data structure and they started to be able to do wild things. Like for example, we had modeled all of AWS and all of Azure and we started asking it to do stuff like analyze my existing AWS infrastructure and propose me what a similar one would look like in Azure. and a migration strategy and the agent would just, would, it was like kind of slow and it a little awkward, but it, you know, but it was magic. um, and so from that point of view, that led us to, to what is now Swamp, which is more, uh, Swamp is about basically taking the idea that the agent itself can adapt to different patterns. And what it knows how to do is extend itself to solve your problem. So. You can say things to Swamp, like, ⁓ like you fire up cloud code and if Swamp's installed and you're in a directory, you can say like, ⁓ my wifi is slow in my house. Could you connect to all of my devices and figure out why it's slow and write me a report and it will build you repeatable automation to do that. Knowing nothing about what, wifi gear you have in the house or a model for, or anything to just do it all for you, which is awesome. ⁓ That, that journey. Sorry, if that sounded sales pitchy, I apologize podcast people, but it's worthy background because, ⁓ you know, the other thing that happened was my team really shrank from, the one that was building system initiative to the one that's building swamp, which is like five people. And we decided that we were just going to try being absolute AI maximalists. So we were like, we're going to try building this new thing and we're going to just, we're not going to look at the code. You know, and our answer to every problem is just going to be more AI and, and wow, did that work? I mean, crazy good, you know, ⁓ it also broke every social more we had, you know, I don't know how to estimate the complexity of a problem anymore. I don't know how to estimate how long something takes. don't know how to estimate risk. I don't know the way you trust each other is different. You know, can't, if, if a single developer can rewrite the whole code base overnight, ⁓ how do I, how do I, what do I do? Like where are my points of control? know? ⁓ speaker-0: Give us some context here for timing, you because I think it's important. A bunch of folks in the audience will already know this, but for those of you who don't, it's pretty widely accepted at this point that there was an inflection point in late November when OPUS-4 or OPUS-5 dropped. yeah, yeah. I'll sort of, the quick example I use is that my sort of, Simon Wilson has his Pelican on a bicycle that he tests out miles with. You know, he has to generate the same image for every model. My Pelican on a bicycle was this open source project called the LA Dodgers Data Bot. So there's a website developer, web developer for CNN who did a great, like, you know, this huge data analytics, you know, sort of dashboard for Dodgers. The Dodgers fan, he releases an open source project. So each new model, each new tool that would come out, I would point it at this and say, okay, I want this, but I need it to be Red Sox. Red Sox site. And... for the most part, know, some of them were better than others and some of them were quite good, but they'd always get halfway through, 60 % through, and then begin to hit walls and just sort of fall apart. And post sort of Opus four five, it's totally different, right? It's meaningfully and sort of totally different. So for you, like, as you sort of think about this and walk through this, like, what was your, what's the timeframe for when you went sort of maximalist? speaker-1: Yeah, that was ⁓ January, like late January, early February. would say, yeah, we all had a similar experience. So, I mean, I've been experimenting and using these tools from the jump because I'm a practical technologist. And so the first thing you do when somebody's like, this thing will change the world. The singularity has arrived is like, you try to understand it like a technologist. You know, in my first opinions were like, yeah, this is interesting. No, it doesn't do anything useful. Never. It's not working at all for complex domains. I'm not sure how it will. You know, ⁓ and then, but you keep trying, you know, so every, every couple of weeks I would try again at something and, know, it would get better. I would also get better because you would start to learn how to use the tools. I think, ⁓ yeah, what happened, you know, beyond the fact that we all got that new model, ⁓ you know, in private amongst a lot of the technologists I know and leaders I know who are, who are paying attention, which is the vast majority of them. We all had the same experience roughly at the same time, which was like, no, it can work now. and you know, the thing about being at that early age of the frontier where it's like, ⁓ no, this technology could be used to do this right now is that, you know, everybody sees the enormous commercial upside of, of this technology. And so we're all racing to figure out how to capture a piece of that commercial upside. Realistically, no one actually knows yet how to build well with these systems the way that I'm talking about. including me, because like we just haven't, we haven't gotten to the consensus point yet where even enough people have experimented. You know, the number of people who are, and our ability to even communicate with each other has really degraded in the last six months because of it. You know, I sort of now see three camps. There's the... You know, I tried AI, it was stupid and I hate its dumb face now because all my friends are getting laid off. Reasonable take. ⁓ you know, ⁓ then there's camp two, ⁓ you know, I use some Claude, you know, I use cursor sometimes there's some fancy auto complete, but I still have to write all the code. still want to look at everything. I still review every commit. You know, I care really deeply about my existing engineering SDLC and my existing process. And, know, it's never going to work in the enterprise and that, that. Sort of contingent that contingent can kind of talk to contingent one, you know, because they're like auto-complete is pretty cool. people want, like, I guess you could use the evil enemy for auto-complete, like, don't go further than that. Now there's an emerging sort of third group, ⁓ which I feel like I'm now a part of, which is the one that's like, no, no. Like I build the software that builds the software that I want. I'm not actually building the software I want anymore at all other than architecturally. ⁓ instead what I'm doing is designing the system that ensures that the robots can build the software I want. ⁓ and I'm optimizing that system, both from a human and a technical perspective. Those people are having an increasingly difficult time talking to camp two and they absolutely can't talk to camp one. You know, and it's not cause you just sound like a crazy person right now. You know, it's like the meme with the guy with the red string, you know, speaker-0: one. speaker-1: When you talk to like me right now, if we really got into it, I would start being red string crazy. And, and, and it's just because you've experienced this thing. It's so effective and so wild and so new. And, ⁓ that, that when you try to describe what it means or how it works or why it works to people who aren't there, it's like you, it's like you describe a trip you took to Mars. And they're just like, I don't know. You know, you sound like a crazy person because you kind of are. Yeah. And we're all like trying to settle down a little, but, but that's what happened for sure. Like the last six months, what happened is a number of us have gone to Mars and then we've come back and we're like, ⁓ no, no, it could be, it can be like many, at least one order of magnitude better, at least that's true. know, ⁓ but then. speaker-0: Yeah speaker-1: It's the worst it's ever been in building software to build software, like using these systems in order to build software whose job is to build software. You know, we're still learning how to do that. So it's totally unoptimized. So, so what's the rate at which, how much better will we get at it once we actually know what we're doing. And once we actually, once, once the patterns of stability emerge, you know, cause there won't be a thousand stable ways to do this. There'll be a dozen, you know, there'll be six. once those patterns show up. our ability to optimize it, how many orders of magnitude better are we actually going to be? Yeah. I don't know more than one. speaker-0: Yeah. Well, and that's the piece to me, I think, know, sort of what you're getting at, right? So in other words, as I said, I had the same moment that everybody else did, you pointed at this sort of site and generated this Red Sox, you know, sort of page format is like, okay, cool. And I just started knocking out projects, right? And you discover two things which are true at the same time, right? So it's like, okay, went out and built a Strava dashboard, went out and cleaned up, you know, the design of a site that I've had for a while, did a Okay, I need you to just to app to go in and take notes from my note taker and append them to this file on a Google Drive. Like I knew I rebuilt our, I've always been frustrated with like Google Analytics and these website trackers because it's all the stuff I don't want. I'm like, I just built the thing that I want. Right. Yep. And so on the one hand, you experienced that sort of insane burst of individual productivity. like, you know, I'm powered. to do these things either that I couldn't do or in many cases I could and I just didn't have the time. But the flip side of it is that you quickly encounter it even on an individual basis. Even as one person working on these projects solo, you begin to encounter all of the process things. Because I'm not paying attention, I'm not being very ⁓ prescriptive, so I'm basically giving the tool free reign to pick technology stack to speaker-1: Yeah. speaker-0: a host to pick, you know, all this sort of requisite pieces and you quickly figure out, you're like, oh, this thing, this thing went down. Like, I don't even remember where that one is. This is the one that's on Cloudflare. Is this the one that's on GitHub pages? This is the one that's on S3. Like, and so. speaker-1: And unlikely to work long term as software. That's right. You know, like it's fine for now, but it won't be. It's going to be so, it's so brittle. Cause software hasn't changed. Like the nature of its output hasn't changed. Yeah. Yeah. I, yeah, for sure. I think. speaker-0: So that's the thing I think you're right. And this is the thing I think a lot of people have difficulty grasping is that two things can be true. I can individually be really, really productive in the moment in this sort of day zero. But as you sort of note, we just haven't as an industry had enough time and scale experimenting with this amongst teams for businesses and so on. speaker-1: Yeah. And it is absolutely working. like, I'm going to use my own experience. So like swamp as a code base, no one has ever read. It's, it's, it's 150,000 lines of TypeScript now. It's the most. speaker-0: Did you tell it to use TypeScript or did it make that choice? speaker-1: I told it to, well, because, back to software engineering. like, I want to build a product that is good. And so you have to build the machine that builds the machine. Right. So, ⁓ one of the things you have to do is, ⁓ is I can't hold in my head how a code base evolves. When you can put out five, 10,000 line PRs a day to that code base. I just, I can't, I can't understand it at the level of the code. You just can't. But I can understand it architecturally. I can understand like how, how are the pieces moving around inside that puzzle? And so that expression of architecture is like step one to building stable reusable code is you're like, Hey, here's the architectural pattern that I want you the agent to follow. ⁓ so like I'm, you know, I'm a domain driven design person, ⁓ have been for awhile. And so, and if you've ever tried to write code in like a domain driven style, that's like supple to requirements and. highly decoupled and all of that stuff, you don't. Cause it's such a mess. No one ever actually writes code that way because it's, it generates so much code and it's such a pain. But the agent's happy to do it. It's thrilled to do it. so like Swamp, turns out is like the most supple to requirements code I've ever written. It's the most well-factored code I've ever seen. And I've ever produced for sure. And like, yeah, if I open it up, there's pieces in it where I'm like, Ooh, you know, I don't know if I'd have duplicated that method or whatever, you know? But that was always true. That was true in the, know, in when I had a hundred software developers working for me, that was true. And so like, but that, that moment where you're like, yep, in my experiment, it turned into slop. You hear this a lot from people where they're like, yeah, I did it. And then it fell over and now it sucks. And I realized that it can't generate code. it's like, difference is that you, Steven O'Grady, you weren't building a machine to build the Red Sox site. You were just, you were just like, you just hold it. want one. And then it did it. We are not doing the same thing. This is the Delta between convert between people in conversation two and people in conversation three. What I'm doing is writing software whose job is to write the software that I'm building and I'm using it to do it. like, like we have like a, you know, swamp has like an incredibly comprehensive UAT suite. ⁓ And people don't even remember what UAT is user acceptance testing, but like you and I are old enough to remember. Remember back in the day when, when QA had binders. And the way it would work was that a PM would produce a binder and the binder would go to QA and they would take your software on a CD-ROM and you'd have a room, big rooms filled with people. And their job was to put the CD in the computer and open the binder to page one. So turns out that's exactly what you need to do if you want to make sure that your agents don't ruin the product you want to ship. ⁓ you keep them isolated so that, you know. One set of agents can't change the UAT spec, but they can change the code, which means now I can refactor with agents safely at high speed because UAT keeps it safe because those two things are outside the boundary. know, I didn't, but like, if you told me that the comp that any company on earth should have a comprehensive UAT suite that works roughly like the nineties did, there's a reason we stopped doing that. And it's because it ground off velocity to a, to a halt because you couldn't even Imagine maintaining it. was such overhead and such weight for so little value. Turns out now it's trivial because the generating of that complexity is so low, you know? speaker-0: That's going to be the interesting thing. think it's an instance of what happens to process, happens to commercial businesses, what happens to the implications of the cost of generating software going to near zero. speaker-1: ⁓ I'm not. Yeah. The implications of the cost are wild, but it's not the cost that gets me. It's it's it's velocity. Yeah. It's just a velocity. like the analogy I've been using to try to get people to understand how ⁓ upset and excited they should be at the same time is like, imagine that the water pressure in every house in your whole city increased by two orders of magnitude. Yeah. And what happens to every pipe? And like, that's what happens to your process. That's what's going to happen to every vector. It's what's going to happen to your, an engineer, it's going to happen to your self-esteem. What happens to your self-esteem when the robot produces code that's as good as you are, that you spent your whole life dedicated to learning how to do. And it does it at a speed you can't fathom or comprehend. What's that say about you as a person and how you spent your life? What's it say about how I trust, like, like one of the things we learned with Swamp was, ⁓ I have to only have people on the team where I want a hundred percent of their personal expression in the product. know, like Paul, like, like you can only work on that product if I want a hundred percent of your judgment at all times. Anything less and I can't control it. Right. ⁓ And so it has to, you just can't even try. What's that say about the size of a team? ⁓ Like, cause I don't know that I can do that with a hundred people. I can pick five, but can I put the hundred? speaker-0: Yeah. And this was, you know, I think getting into, I'm trying to remember your exact quote, but it's one of the things that I actually quoted it in a piece that I wrote, I don't know, a couple weeks ago, I think. And the history of your quote effectively was, know, hey, this is essentially a brave new world, we're never going back. And at the same time, it's going to be a mess while we figure it out. Right? Yeah. speaker-1: gonna be awful. speaker-0: And I think we are 100 % in that mess right now. speaker-1: We're at the very beginning. Yeah, that's the thing. And we're, we're like, we're ankle deep in what is going to be ⁓ a 50 foot high tsunami. It's, it's, it's, it's every, and, and the reason is that you, you simply cannot compete with it. And like when you were in stage two, you could imagine that you could, you know, you could imagine that, that there, that there were speaker-0: where Yeah. speaker-1: that there were individual software developers more productive than the ones who were at stage two. You cannot at stage three. speaker-0: No, and that's, I've a truly. Yeah, and that's, that's the part that I struggle with is, you know, for the folks in sort of Camp One or Camp Two, it's like, when was the last time you used the tool? Right? Because there's a whole bunch of, there's a whole bunch of people, smaller, know, fewer numbers of them these days, but there's a whole bunch of people who used it. And it's hard for us to remember, right? Like you go back to 2021 when Copilot dropped. Right. And. speaker-1: Truly fabulous developers. speaker-0: know, copilot was like blowing people. Well, here's the thing at the time, was blowing people's minds because it was like, ⁓ my God, like this is, you know, sort of like, you know, finishing lines of code for me. And yeah, even that sort of at the time, I mean, it was kind of like all the things we take for granted about having an iPhone now in 2006 were remarkable, like mind blowing. Yeah. Yeah. And the difficulty though is that there are definitely people who have is still are under the impression that technology is still that. speaker-1: you speaker-0: it's still just jumped up autocomplete. You're like, you have to try this. Like this is a fundamentally different exercise with fundamentally different implications. speaker-1: That's right. I also think ⁓ it's going to be harder for some than it is for others. You know, a good, ⁓ I've spent a lot of my career now, like hiring and managing engineers. And whenever I'm finding new people to work for me, I'm always looking at like what makes those people great and sort of how do they, you know, how do they express that greatness through the work that they do? And so, you know, one kind of really great software developer, is the kind that understands the system from the source code up. know, they read the source code, they, and, and, and similarly, there's another kind of good software developer who just beats the shit out of software. know, like there's a problem, they kick the crap out of it until it fits into shape. You know, they just bang on it. Both of those people are now ruined. Like, like intellectually, the way that they know how to understand the problem. has now moved away from them at a speed that is difficult to even understand. And I don't, it's not that you can't come learn how to understand the system from the top down. You can, but you'll have to decide you want to learn it. And in between here and there, what's going to happen is more and more teams are going to have the experience that I'm having. And that level of outcome and that level of quality speaker-0: Yeah. speaker-1: You know, right now the last bastion people hold onto is like, well, the quality is not high enough, you know? And I'm like, ⁓ try swamp. Try swamp. Like it's pretty quality, you know? Like it's pretty good. And, and it's only getting better, you know? And, and every time someone raises an issue, we fix it in 20 minutes and it keeps getting better. You know, but you know, sure man, quality is the thing that lets you hang on to the rope. And like, once those things burn away, the CEO-ly move, there's just not a hundred moves. You're like, okay, if I don't figure out how to get that kind of team working for me on my problem, you know, like right now, if you figure that out, you get first mover advantage. You get like, you can get a real, that can be really meaningful. in a market, in a competitive one. ⁓ but it's going to be wild. And, and that, you know, when you think about why, why it's a 50 foot wave and not a five foot one, like, know, if you're an engineer right now and you're employed and you're not heading toward camp three, my, my advice is you need to, because what's going to happen is at some point, the people who manage you are going to look around and they're going to be like, who's coming with me? When we build a spaceship to Mars and, if you're the one said, if you're in camp one or you're a skeptical camp tour, I don't know, man. Like, like, because the only thing I can think of to do, I don't know how to transition you and also build the system I need to build because it breaks every social more about the process. Forget about the engineering, way you talk to other engineers, the way you estimate, the way you understand risk, the way you understand, you give feedback. Like what's it mean to have a software developer who put a bug into the system when they didn't read the source code and the system you built to keep the system safe, let it through. mean, I think they're still accountable for something, but I couldn't tell you what. You know, like. speaker-0: No, it's funny. It's funny. The analogy that I use and the vendors do not like it for reasons that will be very obvious is, ⁓ you know, essentially it's a performance enhancing drug. Right. And so we are basically baseball circa sort of mid 2000s when, you know, there are these things circulating around which objectively make you better, stronger, faster. You can train harder, recover quicker. speaker-1: parents. speaker-0: ⁓ And you have a camp that is sort of morally opposed to them, and certainly in case of PEDs for very legitimate reasons, ⁓ but you are now at a competitive disadvantage, like fundamentally. I think it's, like I go back to, my father spent his career on Wall Street, and he sort of at one point was a ⁓ opt-in broker on the exchanges, very trading places, right? You're all in paper tickets and you're in these pits and so on. And when they first started digitize the order flow, he was like, okay, like, you know, kind of this is the wave of the future. And all right, you know, we need this and how does this work? And sure enough, you know, within a couple of years, you know, those trading places, pits are all gone, right? They just don't exist. you know, you're in sort of a lot of folks are going to have to sort of make these transitions. And I think it'll be to your point, if you are the kind of person, I, particularly the consultant, I work with many many sort of developers who are basically like, you know, sort of factory workers, like nine to five, like this has nothing to do with my identity. I come in, I punch the clock and then I go home. Those folks I don't think will sort of have the same level of angst because like I said, it hasn't been part of their identity. But for folks that, you know, this is who they are, right? They pride themselves on, I am sort of exceptional at this to your point. You love your craft, like that's gonna be. speaker-1: Minecraft. speaker-0: It's gonna be really, it's gonna be a challenge. And you see this now like, you know, I'm trying to remember who the quote was from. You know, this was back in January, I think. And it was like, I'm not sure sort of why it's this week, but every software engineer, I know is essentially having like a, yeah, yeah, essentially like a breakdown. speaker-1: existential crisis. I'm, I mean, look, I end every single day exhausted and I'm, and it's not because I'm not why I am wildly productive. That's true. ⁓ but it's because my mind boggles at, at, at the, at both the possibilities and, and at the, and, and sort of quaking in my boots, you know, like I talked to friends. who run large organizations and they're like, do we do? And we talk about it. And my answer is like, I don't know. And you know, like I spent a lot of my career teaching, like doing digital transformation and going into big banks and talking about how to do cultural organizational changes. And like, I get it. I know that that's real and hard and I think I'm pretty good at it. You know, like I have a track record that says that I know what's up. like, right this second. I got nothing and I think anybody who tells you that they know, think they're absolutely full of shit. You cannot know. speaker-0: I keep my j- People have been doing this for years, but I laugh about it even more now because the publisher talked to me about it at one point. I've had companies sort of want to sponsor. So I wrote a book called, for folks who don't know, called The New Kingmakers. It came out over a decade ago at this point. And people are like, second edition. And I'm like, absolutely not. I don't know how that's going to play out. Not at all. At the time we wrote it, it was like, OK, cool. I have had the same conversation 1,000 times. speaker-1: Not today. speaker-0: but it's not sort of on the level that it needs to be. let's get this capture this in a book and great. Now it's like, yeah, there's a couple different ways this can play out. And I can tell you some of those short-term implications, but where we end up. I don't speaker-1: Yeah. And, and like, here's a, here's a thing that I think should break everyone's brain. You know, up until now, the companies building the models had all the advantage in telling us like how the world was going to be because, because they were the ones producing the technology, right? Yep. Not so anymore. Cause it turns out they also were building, they built those things the old way. Yeah. They didn't build them this way. They built them the old way. now they have thousands of software developers and they're like, ⁓ no. You know, they too have to change their processes and figure out how they're going to work in the new way. And yes, they have the advantage that everyone who works for them is already piled. know, everybody who works for them is already down. They already understand that that's what's happening. But like that advantage in terms of knowledge and in terms of where we're heading, like ⁓ that's, you know. Like there are people who invented databases, but like the people who used databases defined the way that we think about databases, not people who designed, who invented them. And the same is going to be true for this. like the practical application of this technology and the practical outcome of our ability to do this. Like we're the ones who get to define that. and, and that's so exciting and so fun. And also. You know, because like, like you just, the, the, you know, a thing that I have been reflecting on is like, you know, going through my career started as the internet happened, you know, like I used bulletin boards when I was a kid. I knew how modems worked. I worked for ISPs at like in the back of a dentist office, you know, and then like if they consolidated, I got bigger and then the internet happened and then we had to put applications on it, blah, blah, blah. My career parallels just like transition after transition after transition. Um, you know, things that were sweeping. And, you know, when I talked to my mom about what it was like, uh, to live through, you know, she lived through all kinds of things. She was born in 1950. So, you know, there were 48 states when she was born and there were, you know, like huge transitions, both socially, economically, technologically. And when I, I keep trying to find the analogy that is big enough. For people to understand the magnitude of what's about to happen. I keep failing and the best I've been able to do is like, maybe it's the transistor and miniaturization. Maybe it's at that level, but it might be bigger. Yeah. Because, because what we're doing is virtual and like, that's also a layer here that's real important that like, because it's all happening in software and it requires really nothing in manufacturing other than data centers. Like. The pace at which we're going to change it is just, it's going to go so fast. I don't know what that means, but it freaks me out. speaker-0: Yeah, and Yeah, no, same. And I'm curious, this is the way that I've been thinking about it. I'll be curious to see sort of what you think of it. Is that, you know, I think that one of the key questions to me ⁓ is gonna sound weird, but it's like, how much software do we need? Right? So in other words, like I come at this from one of my first sort of client gig as a consultant was a retailer, right? And I was tasked with sort of one of my, one of the sort of things under my auspices was some of our, mainframe applications that had been written in the sixties and seventies. Yeah. Right. And we're still running this business like decades later and hadn't been done. ⁓ So it's all the sort of inventory and pay like all that stuff. that's right. And, you know, there were, you know, I had probably 50 to 60 % of the total applications under my purview, which meant that, you know, we're talking like a handful, like speaker-1: finished. All the stuff that runs the world. speaker-0: six, eight, something like that. then we obviously, these sort of industry goes through different stages, right? You go from mainframes to mini computers and client server, right? And the number of applications multiplies each jump, right? Then you hit the internet, there's sort of web apps everywhere. Then you hit mobile and there's a million more. And clearly, because these tools, among other ⁓ things that they do, is dramatically reduce the cost and time. speaker-1: more. speaker-0: of generating applications, we're going to have way more applications, right? Yeah. So I think one of the key questions to me is going to be what is the carrying capacity here? Is there a maximum amount of software that we can consume? speaker-1: Now it is in. I think it's infinite. speaker-0: To me, that's the optimistic take though. Like if it's literally infinite, you will hit a point where people will have to generate the ideas for these. People will have to at some point consume, you know, sort of these different applications and different forms and so on. And that then creates in theory, you know, opportunities because, you know, we're not at a point yet where there's no human loop at any point of this cycle. speaker-1: Yeah. There is a human in the loop at the beginning of the cycle. And there's a human at the loop at every stage of the cycle. At every stage, there's a human in the loop. But to the question of how much software does the world need, the answer is an infinite amount of software. Because everything you move into software, I mean, here's where I become a free software hippie again. Everything that moves into software becomes... Everything we shift into that world is no longer bound by material constraints in the way that every other thing we've ever invented has been. so, you know, be an optimist. What that means, I know this is going to sound like I'm the red string guy, but like, that truth about software that it fundamentally is infinite in its nature and it doesn't get exhausted because you use it or I share it or whatever. We're going to move as much as we can into software. Because everything about it is better for humanity. It's easier, it's better to build, it's cheaper, it works better, and it's only going to get more malleable. And when you think about the future of what this magnitude shift really means, a good example here is operating systems. Operating systems have been very sticky for a very long time. There hasn't been a real opportunity to be like, I'm going to build a new operating system. You know, not really. Like there's been a few people who tried. I wouldn't say they were particularly successful, you know? speaker-0: Mm-hmm. speaker-1: Yep. Now though, what does a user land look like in a world of infinite adaptive software? I don't know. you don't either, but I'm pretty sure it doesn't look like Linux or Windows. speaker-0: No, and, but again, like, that's- speaker-1: Does that mean you throw them out? I don't know, but you could. once you do now what's possible. like, once you start to do that, you're like, okay, yeah. The argument that says that, we've, found peak coal, know, like, nah, nah, no, no, no. And, and it's the reason that like, even though I think a lot of my people are going to suffer, like, I don't think it's going to go good for a lot of software developers and a lot of engineers. It's going to be a bad couple of years and a lot of layoffs. lot of, lot of soul searching, a lot of pain. It's going to be, it's going to be bad and it's going to get worse. We've, we're not anywhere close to the worst of it. And then we're going to realize that we need an infinite amount of software and that the only people who can build it reliably aren't people who just showed up and yelled at Claude to when they found a bug. Like they need to understand architecture. They need to understand how the system fits together. They need to understand like. speaker-0: No. speaker-1: how the actual software they're building interacts with the substrate it's sitting on. And because that's the only way to get to good outcomes in software. that is sort of immutable about the nature of software and the way that it runs and those like nothing that has happened so far tells me that that has changed. Cause it hasn't. And that doesn't mean that there aren't things that are in people's reach now that weren't before. know, of course there are, but is it? You know, are you going to be able to build, we're talking on riverside is where we're recording this. You know, could, could you vibe up three quarters of riverside? Yeah. Yeah. I think you could. Could you actually build a stable riverside that grows and scales and has 10? No, not, not, not unless you understood how systems work, how the compute layers come together. not unless you, you know, have to understand those things. speaker-0: I'm a little less, I think I'm a little less sort of alarmed than you are in the near term. Not that I think things are going great or will go great sort of in the near future. think if for no other reason than it gives them cover, right? As we saw with block among, amongst other institutions, you know, people are going to sort of perform these layoffs and they're going to blame it on AI. Some cases it will be AI and other cases it's just, that's the sort of. ⁓ the cover they need. ⁓ But to your point, I think what people are going to figure out, and really this should have been obvious because it's, like I go back to my colleague who know, Rachel Stevens, sort of wrote a good piece a couple years ago during the Dora report ⁓ when that came out. Basically what that revealed is individual developers were using these tools and feeling very productive, and the organizations weren't seeing really any impact, any benefits whatsoever. which got to the point where it's like, like generating the code is only part of the equation here, right? There's many, many. speaker-1: The entire rest of SDLC is what drives you to the ground. speaker-0: Correct. And so I think actually in the sort of short to medium term, if we get to a, this is sort of the optimist case, let me put it that way. So it's like, okay, if there's a capacity for an infinite amount of software, people are gonna start generating either startups of their own, applications are gonna proliferate within enterprises, and that is going to accelerate the rate at which people discover, okay, these tools are incredibly capable, but these tools are not. capable of doing all of these individual pieces and generating the ideas and consuming the output of the applications much more quickly than they would absent the tools, right? That sort of ⁓ accelerating rate of generation is going to provide many, many more cycles quickly for people to learn, shit, I laid off however many people, ⁓ and I think this was actually the rumor of block, that they're like, okay, we actually need to go hire some of those folks back. speaker-1: Yeah, I mean, maybe I would say that's the optimist case. mean, the social piece of it is the hard part. It's not the technology part. breaks every social norm you have. breaks every single part of your SDLC. It breaks every process. It breaks your compliance process. It breaks everything. Everything. Everything is broken. And you have to rebuild it all from scratch because none of it can work. None of it fits in. That has a huge number of knock-on effects. For example, are you a smart person who started a startup in the last six years? And the thing you were doing was solving problems that happened when people built software and shipped it? so, ooh, ooh. Because every problem that you thought that was a real problem may or may not be a problem anymore. And there's no way to know. So, you know, we're talking about block layoffs or whatever. I'm talking about like startups. How many funded startups are just done and they don't know they're done yet because you can still find customers. can still go out. Everybody's still working this way. It's all still there. But like that, that transition for, ⁓ for an increase in velocity and capacity and capability and delivery, like we're seeing now. ⁓ there will be no, no person left behind. Like we will, that will, that will rip through industry. Rip. It will make, it will make the rise of cloud computing look like it was baby town follies in terms of the speed at which it will rip through industry. And yes, if you, if you work in a giant global bank or you work at insurance or you, know, whatever payroll, like you're last. But I don't know how long last really is. Like, know, JPMC moves pretty quick when they have to, you know? They have a lot of money. They can do whatever they want to do, you know? Like they don't need a lot of permission, you know? And like... speaker-0: Well, let me have you close out there because we've, I've taken way too much of time already, but let me, you know, obviously as we've just both agreed, like we don't know how it's going to play out, a bunch of different paths it can take, some better, some worse and so on. like, if you are, if you're an engineer, right? If you're a young engineer in particular, in your view, like what are the kinds of things that people should be doing? Like how do you adapt more quickly to this world? Like what would your career advice be? speaker-1: Yeah. Number one, ⁓ you need to go pick up a book on software architecture. So, and systems design. So if you don't have a thought on that topic or an opinion, you should just pick up domain driven design. ⁓ And it's going to be a real tough read, you know, cause, and you need to understand how those systems fit together and how those mechanisms work, because that's the language you have to start using to talk to agents to build reliable software. You need to be able to express not because I read every line of code, but because I know that that code doesn't fit this pattern. Right? I can't read every line, but I can see patterns. I can see, I can see repetition. can see, I can see seams in the software where it's unsupple. That's still there. and it's just accelerated. So my first, my first piece of advice is do that. The second piece is, ⁓ if you aren't in a position where you can where you can build the system that builds the software you're building, you know, cause you go to work every day and you still have a boss and an SDLC and a scrum master and you know, like, which makes sense. Cause if you got rid of all those people today, like the whole company would fall apart and you know, that's risky and you know, welcome to the difficulty of change, but you gotta go home and not just vibe code a Red Sox app. You need to go home and like figure out what's it like when my only answer to all of my technical and social problems is I'm going to build more agents to build a new version of this process. And you got to get comfortable with that thing. And you can, there's no reason you couldn't do that at 19 in the same way that I'm doing it at almost 50. You know? And, and if you do that, then what's going to happen is you're going to have the same kind of career arc that I had, cause I understood how modems worked and I was on bulletin boards when we decided everybody needed to get on the internet because everybody looked around and went, well, who the hell knows how to put modems in racks. And how do I terminate all of these copper telephone lines and how do I get people their email? And I was like, Ooh, Ooh, I know how to do that. You know? And like next thing you know, you got a career and it's going to be the same thing. People are like, lots of people are going to need this and they're going to look around and be like, who's going to build the system that builds the system for me. And you're going to be like, aha, you know, I read domain driven design. I know how to, I put those agents together. I know what UAT is, you know? And like, ⁓ and that's, that's what you gotta do. And the upside is. you know, the hardest part of learning how to do this always was learning the syntax. It was actually, can you express the code? You know, do you know what to say? ⁓ that's, you know, if you remove that from the puzzle, I actually think it might be easier to be good at it. ⁓ I think it's probably still equivalently hard to be great at it. ⁓ You know, there's still a lot you really do have to know and understand. And the more you do understand the internals, the more you can recognize the patterns, the more you can see the seams, you know, like, I don't know what it would be like if you couldn't write the code, but that's my, but that's, that's my advice is it just, you got to flip it over and you got to come down to those things from the opposite way in the same way that like the number of times in my career that I've had to, ⁓ debug assembly is low. It's not, it's not zero. And. speaker-0: Yeah. Yeah. speaker-1: ⁓ and it won't be zero for the future software developers either. ⁓ but that's my practical advice. and, and you need to do it because what's going to happen, I think is that basically everyone's going to look around and be like, okay, so who's on team builds me this machine. And because the social problem is so hard, ⁓ the correct executive move is to cut very deep because, ⁓ because the hardest part is going to be convincing all the people. that they have to change everything about how they work. And that's always easier to do when the number of people is smaller. and so like, that's, that's why I don't come up on the optimistic case too fast because I'm like, Ooh, unless someone, unless someone really cracks the nut on like instantaneously on here's the pattern by how we all do this now and just productizes it really fast. And we all just jump to it, which wouldn't that be great. ⁓ but I don't think it's going to happen. like that in the next little bit here. ⁓ I think that's where you, I think that's where you wind up. And then self-servingly, ⁓ you know, you have to look at the rest of everything that comes along for the ride when software accelerates. so, you know, Swamp exists because when software accelerates at that rate, infrastructure must also accelerate at that rate. ability to automate things and deploy them and manage them has to, has to rise to match. And so that's us redesigning how that process works so that it can move at the same rate of speed. And you know, that's going to be true for every single piece of everything that we do. It's going to be true for how we automate tasks. It's going to be true for we do monitoring. It's going to be true for how we do reports. It's going to be true for how we do compliance. It's going to be true for how we do security. It's going to be true, you know, on and Every last thing. Every last thing. so, you know, the other piece you can do if you're sort of starting out right now or you're making this transition. is you can just take the thing of that list you love the most and do that in this way. You know, that's what I'm doing. I'm like, what I love most is automation. And those are my people. And so I'm just going to do that in the most maximalist way I can find. And it's super fun and you end every day exhausted, but like, it's very learnable. And yeah, if your brain was still malleable and you were 23 or whatever, 19, you'd like, my guess is duck to water, you know? speaker-0: Yeah, no, I think that's right. Okay, and on that note, Adam, thanks so much for your time. My pleasure. And thanks for coming on the Moncast. speaker-1: Yeah, thanks for having me.