The Standup with ThePrimeagen · Hands-On Engineering Podcasts · October 2026
Muratori says he doesn't necessarily disagree with the positive things people say about AI coding, but thinks they leave this part out. He goes on to argue that modern software is unreliable because every program depends on many outside services that keep changing.
more true since there's that. It actually has gotten
more true. And repost it.
So essentially what I wanted to try and point out to people, because I don't think that this is appreciated enough, we talked about it in the previous episode of the stand-up that we did, where I was saying like all of like a lot of the things that I see people saying positively about AI coding, I don't necessarily disagree with. I just think they're not including this really important other part, which is that a lot of the things that people are talking about doing with AI are things that no one should have had to do in the first place. They're being done because we've created such a bad programming environment that nobody wants to interact with it anymore, right? It's always breaking. It's always changing. It's got way too many layers of abstraction. Most of those layers don't work very well. There's way too much complexity, like all this stuff. So yeah, it's like that. I mean, it makes perfect sense why someone reached for an AI because why do you want to do it, right? And so I just want to talk about sort of a separate part of that, which is just the very unreliable nature of software nowadays, and especially builds. Like it's like, okay, I got this piece of software that I wrote. And like, what are the chances that I could compile it again in six months or something, or a year, or two years, right? Or even not even compile. What's the chance that it'll run still if it uses things like REST APIs with some web service, right? So, you know, I've got these different web services I'm using. So even if I don't have to recompile my thing, or even if it's an interpreted thing that runs and I'm keeping the same version of the interpreter or whatever else, it's going to make these API calls out to web services and those services could change. So what I did, and hopefully we can put the graphs up as I'm talking about them, but I posted these on Twitter. They're very simple. It's just taking the fact that, look, if you assume, right? And I say this in the tweet stream, that if you take the chance that something will remain working after a year is some probability. So like 90% chance that this Twitch REST API that I'm going to call, a 90% chance that they will have kept it the same a year from now. So that it will still work, right? My app sends this REST API call out to Twitch. It expects a certain response back, and they're not going to change it in some breaking way, right? In a year. If we assume that we just have some probability, like 90% for that, that we can pick, we just imagine one, right? Or, you know, so we don't have to measure just imagine your head 90% or something like that. Then the chance that your code remains working after X years is just given by P to the X times N, where N is the number of those calls to things that you have, right? So you can graph this. And what I showed is that if you had a 99% chance that every API call you use, 99%, right? Which is way higher than anything in the web world typically has after a year. But 99% across all tools, the graph still looks pretty bad, right? You look and you look at it, it's like, okay, after a year, it's like, it still looks pretty darn bad. It goes down pretty rapidly based on the number of tools. So you can see the graph I show is like one tool, two, tools, three, tools, four, tools, five, just it goes down. I love that
book. You said Dr. Seuss book.
Yes. It's great book. He captured. Dr. Seuss was, a lot of people don't know that he, the doctorate that he had was in computer science. It's very, you know, he was author
engineering. He was one of the few who did become a professional engineer in software as opposed to the rest of us.