MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike. I'm hosting again today. With me, I've got Eddy Lopez, Vivian Moore, Kyle Archer. We actually may have some additional people who are delayed [chuckles]. But we're going to jump in because we've got a good panel today, and I'm going to start by talking about transportation. Bicycles have been around for a long time, actually a surprising long time. You know, they were...like, the Wright brothers, who built airplanes, they were originally making bicycles. And bicycles were very popular, you know, that was, like, 200 years ago. I haven't dug into the history, but they've been around for quite a while. And they're revolutionary because they allowed you to go a lot faster, a lot further, right? You know, and even before...you could go before that. You have other wheeled vehicles, wagons, right, wagons, carts, chariots, you name it. There have been wheeled vehicles, far more efficient, allow you to move faster, quicker, but they all have maintenance, right [laughs]? We got into automobiles, so I'm going to focus on automobiles because it's getting a little more modern. Original automobiles were handmade. I think in the late 1800s they started making some automobiles, and they were handmade. And you kind of, like, had to have a mechanic riding with you [laughs] because it needed so much maintenance that it was basically a constant thing, essentially daily, right? Maybe multiple times daily maintenance, just constant work. And you think, "Oh, I'm just going to drive from here to there," but it probably took a lot more work for those original automobiles than the alternative. But then again, you think about the alternative; they were using horses. And you think about a horse taking your carriage somewhere, you think, "Oh yeah, it's easy. I just hitch it up to the horse, and you go." But then you've got to take care of your horse. You've got all of the, you know, taking it inside in the winter, keeping it protected from predators, making sure it's fed. You can say, "Oh, I'll just send it out to pasture." Well, sometimes there's snow on the ground, and there is no pasture. So, there was a lot of literal care and feeding required for your transportation in that era. And they switched over to, you know, gasoline vehicles. There was...you just had a different kind of care and feeding. You still have to pay for the gas. You got your oil changes. You've got, you know, all of the many items of maintenance. And thinking about the horses, you know, maybe most of the time, you probably spent more time taking care of your horse than you did traveling in many cases. And, actually, to tie this all together a little bit, recently, somebody broke the Pony Express record, the record that was set by Pony Express riders riding across the country, on a bicycle [chuckles]. So, there's still room for doing that kind of thing in the world. They went faster than people did on horses. People can be very efficient with a good vehicle in good repair. Well, vehicles are changing too, right? Recently, they've introduced electric vehicles. Now, electric vehicles have actually been around for a long time as well, but there wasn't a lot of innovation, so they're kind of coming back. And you buy an electric vehicle, well, you plug it in [chuckles], but there's no oil changes. There's far simpler drivetrain, right? You got a motor that runs the wheels, so far less maintenance. It doesn't mean there's none, right? It's fundamentally different. You think about what's required for an electric vehicle: a whole lot less maintenance than the horse. And it's less likely to fall apart than probably your wooden carriage, right? So, as we've gone along, that maintenance has continued to go down. It's been transformative, and sometimes there's these big changes, like, oh yeah, we'll use an electric drivetrain instead of a gasoline one. It fundamentally changes the amount of work required. But, you know, so I'm talking about transportation, about how there's that maintenance you don't think about. Getting from here to there, yeah, maybe it's quick in your vehicle, but if you don't take care of all that other stuff, it doesn't work, and some things require even more work than that. So, that's what we're going to talk about today. We're talking about the hidden costs, the hidden costs of work, the hidden work that's there in software engineering. I actually saw a statistic earlier this week that suggested that only in the mid-teens of a percent, so, like, 15%, of software engineering involves writing code, and the rest of it is hidden work. So, we're going to talk about what that hidden work is and how it's changed, how it's changing now, you know, for various reasons. Certainly, AI is transformative, but there are other reasons as well. So, to draw a parallel to how transportation has changed and how that hidden work has changed, we have that same kind of hidden work that's in software, and a huge amount of it, right? If it's more than 80%, a lot of that work is not actually writing code. It's other things. And let's talk about how it's going to change. So, first of all, where do y'all spend your time? KYLE: Meetings of every flavor [laughter]. WILL: Oh man. Who's got the data? Who's got the data? And how do I get the data to the people that need the data? Who's got it? Where does this thing live? I think, more than anything, for, like, brownfield work, it's just increasingly sophisticated searches for, like, who's got the API that I need? Who's got the database row that I need? Who's got the widget that I need? Because it's all there, but you got to find it, and if you can't find it, is it brand new? Did you invent a new color? Probably not. Probably you didn't. But then if you get it, then first you have to find it, but then you have to extract it. You have to pull that Jenga block out of the bottom of the tower without anything getting wobbly, you know, and then you can put it on top, right? Just like playing Jenga, you know, picking the right block, getting it out, that's hard. Putting on top, eh, you know, just keep it under three cups of coffee, and you'll be all right. KYLE: And that's it. Even if you find the right person, and I think this is what you're talking about, too, you find the right person, it may not be within your right to necessarily touch existing code. And what I mean by that is you've got something where you need to wire systems together, and you can [SP] sic AI at the entire codebase. AI can find it, but that may not mean that you should be pushing code to another team's repo just to get your work done. You're going to have to go through the appropriate channels and distribute it appropriately rather than having a single unit do it. So, there's that work under the hood, too, that just [SP] siccing an agent on cannot solve. WILL: I mean, and the agents, you know, the agents, God bless them, like, they're not always or even often wrong about it. But, like, do they do it idiomatically, or are they making up their own idioms? Because, I think, so much of, like, software engineering at its core is all about eliminating complexity however you can. And one of the unsung tools of eliminating complexity is a very Ruby on Rails-centric philosophy in that, like, you sort of build the stuff in a very similar way, right? You know, your MVC frameworks, your MVVM frameworks, like, just sort of, like, this is where these things go. This is how you organize the tools in your garage so that when you can find something, you could just pull it off the shelf, and it's ready to go. And, AI, frequently one of the biggest problems that I run into over and over with, like, sort of AI-generated code is, like, A, they're very happy to reinvent the wheel with no compunction, and two, this is how we do it here. This is how we do it here in this repo so that everybody who works here knows where [laughs] to find, you know what I mean, like, the stuff. And, like, I don't know, I don't really care if it's a good idea. I just want everybody to have the same bad idea so we can get to work [laughs]. MIKE: Absolutely [laughs]. You need to know where to find it. Maybe the garage shouldn't have been put in the back of the house where it's awkward to get to, but at least you know where to go find the stuff, yeah. WILL: Exactly. Exactly. Exactly. The same bad idea. It's close enough to good that we can all work. KYLE: And that introduces actually a new-ish realm, right, with AI. Because, I mean, living in the DevOps world, it used to be more often that I would get questions from engineers like, "How should the infrastructure be designed?" And now I'm starting to get, "Here's the software I want to deploy, and here's the infrastructure I need." And it's like, could that work? Maybe for a few months, but it's not ideal. And so, I feel like that's the other spectrum that I'm saying is, like, the overhead is now we've got AI, you know, saying, "Oh, okay, you should do it this way." And it's like, now we've got to go back through and re-engineer what AI is proposing and going, "Not quite [chuckles]. We need to change all these pieces, too." MIKE: And going back, we started this by saying, "Meetings," right? Is having a bunch of meetings the most effective way to extract this information, to go and perform this search and find out who to talk to and which API we need to touch? I'm guessing the answer is probably not. KYLE: Maybe. MIKE: Yeah, maybe. KYLE: It depends on the situation. DAVE: It might not be a good answer, but it might be the least bad. WILL: No. DAVE: Well, what are the other options? That's the question. You can't say no without defining what the other options on the table are. WILL: The hell I can. DAVE: There's probably five things that are better than that, right? WILL: I would say this, right? Like, if your meeting looks like Hollywood Squares with, like, cams down, mics down, and, like, there's two people talking, well, there was seven people at least that didn't need to be in the meeting. I have found meetings with a number of people that you couldn't count on the fingers of one hand to be singularly unproductive. If you get past that point, you're doing a presentation, and there's nothing wrong with a presentation. DAVE: Yep. If that's what you're meeting for. WILL: Could the presentation...should it have been an email? Probably. But, you know what I mean, like, in the end, you know, like, I still really kind of strongly believe in this sort of, like, one-on-one pair programming paradigm. I haven't found a better one for it. Because when you get in these meetings where you have all these people who are not engaged, and they've got 10 other things going on, they're going to work on their other problems, their other deliverables. And they're not just going to sit on their hands waiting for it to be, like, their three-minute status update. You know, "Does this schema look okay?" "Hey, do you need any API parameters here?" Like, "Oh, what's the access token I need to pass on to that request," right? And then they say, "Looks good to me," you know what I mean? And then they go right back to what they were doing, and it's just [chuckles] the meeting -- DAVE: If they ever stopped doing what they were doing to begin with, right? Were they actually analyzing what you were saying, or were they just listening for the thing that they're..."No, you're smart. You probably got it figured out. Yeah, it looks good to me. It's fine." They're not approving your design. They're saying, "I didn't hear anything that alarms me," and if you've made an assumption error, it just got blessed, right? You said something, Will. You said pairing. At Acima, we're trying to do Scrum again, and I keep telling everybody, "Please, if we're going to do Scrum, let's do Scrum. Let's not do Scrum, but..." right? "We're going to do Scrum, but we're not going to do pairing." Okay. Well, now...there's going to be effects of that. Your standup meeting is going to take half an hour because it's no longer...it's no longer...what do you call it? A coordination. Standup should just be coordination. I'm touching this module today. I'm going to change it. I'm going to deploy it. Oh, hang on. I've got a piece that's blocking on that. Let's get together afterward. That's what standup is for. But if you're not pairing, you don't know what anybody else is working on, and if you're not doing promiscuous pairing, where you're changing pairs frequently, you don't know what's going on in the rest of the bullpen. And the upshot of that is now when you meet every day for your 5-minute meeting, you need 15, 20, 30 minutes to find out what everybody's doing. That would have evaporated if we had been pairing the entire time. MIKE: So, it sounds like there's agreement here, like, the one-on-one rather than getting everybody in a room and having them answer the questions. Now sometimes you've got a tricky architectural decision, so you bring in the experts, and you hash and argue until you're all in alignment. So, I think there's a place for meetings where everybody's engaged and productive. DAVE: Yes. MIKE: But if I need to know what API to talk to, the best way to do that is probably not to get 20 people in a room and ask them all. No, right? I mean, there's better ways to do that. You ask somebody who might know. And even if you go through the chain, you ask somebody reliable who knows who to ask, and you go through a couple of hops, and you get that answer. And you establish that by building that mesh of connections, of human connections, and then it becomes more efficient, right? Information flows through that network, and the more connections you make, the faster it flows, right? I think that establishing that human connection mesh is something that takes time, and it gets harder and harder the bigger you are, right? Because then you lose some of that. So, I think you need to be actively caring and feeding it. But it's still -- DAVE: That drives Brooks' Law directly in an interesting way. You join a team..." Adding people to a late project makes it later" - Fred Brooks, right? Brooks' Law. I've always thought of that as, like, oh, you've got to ramp up on technical debt. But there's psychological, psychosocial...it's not debt. It's like a mutual fund that's front-loaded. Like, you have to invest into the team before you start, you know, getting it back and start getting bidirectional. If you've got good mentors, you join a team, and somebody's like, "Come with me, and I will take you under my wing," and they introduce you to people. But if you just come in and sit down and just start typing code, things defrost slowly, I think. MIKE: If you had a bunch of machines in your data center but they all had a really low bandwidth connection between them, your overall ability to accomplish things as a group, like your cluster of compute, is going to be awfully weak because -- DAVE: I would say not necessarily weak, but specialized. It's like having 15 Haiku bots and no access to Fable, where if what you need to do is knock out 15 database migrations and they're all just add this column to this thing, don't bring down the whole data center and fire up Fable to, you know, cook, you know, the Atlanta data center off on it. I push on people...there's a great book (It used to be free. Now it's like five bucks.) called "Read This Before Our Next Meeting." And he makes the argument that there's only three purposes for a meeting. One is to brainstorm and solve a problem. That's engineers fighting in front of a whiteboard and, you know, like, brainstorming, mob programming. Then there's information dissemination, which he's got a special case for that. And then there's making a decision. And the interesting thing is, status isn't in there. I said information dissemination, and information dissemination, that's when we get a Mike Challis come in and say, "I'm the engineering director, and I'm going to tell you, all of you, here's what's happening in this department for the next quarter." I'm disseminating information. It is a one-way flow, where status is, like, Q&A, and let's push back, and let's discuss and da da da. And if Will was saying, you know, "Could this have been an email?" 9 times out of 10, if it's information dissemination, okay, yeah. If it's the C-suite and they want everyone to get buy-in, they don't want to just hand out an email and risk people misunderstanding it and being upset and frustrated. They want their chance to stand up and sell it to the...Great. I'm fine with that. WILL: I'm less fine with that. DAVE: You're less bought in like that? WILL: No. I'd rather have it be...because, like, I've found these, like, giant town hall-style information dissemination sessions are pathetically light on actual information being disseminated. They take 10 times too long. Nobody's interested. It's not a back-and-forth. There's not going to be a Q&A at the end. It's not going to happen. Like, that's not how it works. Like, you give it to me; I get it, that's that. I go through channels to have feedback, questions, or whatever. Like, it's just...and I read 10 times, 20 times faster than you talk, so just let me read it, man. And then I have a written record of it, too, which is great because I can be like, "Oh, what about that thing?" you know? Like, people will give me architectural decisions, right, that are not immediately relevant to my tasks, my current set of responsibilities I'm trying to deliver. But they're like, "Hey, we're going to try and build this new thing in this new way," right? But it's not related to what I have on my desk right now. I have finite bandwidth that I can take in these new ideas from. And so, when it comes, and I'm like, oh yeah, we did. We were porting over to this new analytics platform that I need to write, you know, I need to write these queries, these analytics things in a different way. What did he say in that meeting? Oh yeah, there was a demo. Okay. And I find myself, like, digging through the video transcripts of meetings just trying to extract, like, oh, what was the demo class? He had one that said, "Hey, look at this implementation. This is the new thing." And I'm going in and looking at that as opposed to, like, if you just wrote the docs out for me, then we would be good. And you know what? You know who loves reading documentation? DAVE: AIs? WILL: Claude loves docs. He's crazy for it. You'll just...gimme, gimme, gimme. But the video parsing and, like, transcript munging is something that is unfortunately, you know, us meat bags have to do. So, personally, I don't know. We can AI synthesize these, you know, documentations out of a meeting transcript, but, like, couldn't we just start there? DAVE: Yeah, yeah. It's...go ahead. MIKE: This brings up...well, you know, we said we were going to talk about how there's been changes, you know, in the hidden work behind software development. We've talked before on the podcast about how there's more meetings. Like, after post-pandemic, everything's a meeting, right? The meeting count seems to have gone up dramatically because the cost has gone down. DAVE: There's no bullpens. There's no bullpen. The things that the meetings are doing, we used to get for free. A couple of months ago, we started a bullpen channel in our Slack, and literally people just walk in and walk out whenever they want to. And there's a couple of people who only show up when they need something, you know what I'm saying? But it's explicitly, you're not allowed to say, "Guys, we're trying to get work done. Get out." If you want to have an official, important meeting, go start your own channel. This is the BS channel. We're going to talk, you know, we're going to talk about Micro Machines. We're going to talk about Transformers, and not the AI kind. You know, we're going to talk about video games and hobbies and hiking. And then the conversation winds its way back to, "How come the stupid invoice doesn't validate when it's a Tennessee customer, but the store is in Kentucky?" "Oh, it's because..." And there's the payoff, right? It's just somebody said something in the bullpen that never would've been raised through an official channel. Nobody would have...You're not going to broadcast that to the whole, you know, department. But you happened to mutter it out loud in a room where the person who happened to know the answer happened to be there. It's like Twitter on a stream. And there have been a lot of attempts to do this in the past, like, we had a public murmur channel. There was a really cool positional one where you could look at a map of the building and drag yourself around the room, and people's audio would go up and down based on how close you were to various rooms. It was way cooler in the demo than it was actually in productivity. It didn't get used. But because of the bullpen, there have been things that, like, I would've been blocked on until the next, you know, stand-up meeting to ask for help or for whatever. Yeah, it's kind of -- MIKE: So, you created a mechanism for that communication to happen outside of a formal meeting. DAVE: For that pressure to go off. WILL: I mean, the thing that I find most frustrating, you've heard this rant before, and I won't derail the entire podcast about it, is, like, okay, so yes, it's post-COVID, right? And, you know, we tried, like, fully distributed where no one's going to exist anywhere, right? And, I think, people have pushed back on that, you know, especially in the labor market being what it is. People are, like, advocating really strongly for RTO. Okay. RTO, right, because of these complications in terms of the stuff. But, like, we're not...you can't go backwards because you have a situation that you can't get out of where, like, oh, I've got the Utah office. And I've got the Dallas office, and I've got an Atlanta office. And I've got some weirdo who's grandfathered in, and we really can't get rid of him, and he lives in Galveston, which isn't in anybody's office, but he's a pivotal person. We've got some guy, some VP big shot flexing his muscle, and he lives in Chicago. I've never even seen his face in real life. And so -- DAVE: Exactly where I was going to go. WILL: We have a distributed team, and it's distributed. It is all the way distributed all over the place. And I feel like this sort of management paradigm where we're trying to shove our heads in the sand and just be like, "Okay, okay, everybody just RTO," you know, because, like, this is too hard, and we can't figure it out, you know? It's too tough. We can't figure it out. We can't make the pieces fit, so we're just going to claw everybody back to the office, but it's not working. And you can't un-ring the bell, and we haven't figured out how to get right with this distributed paradigm. And so, we find ourselves in the worst of both worlds, where we have these sort of management challenges and dysfunctions because we are distributed, in fact, but we don't avail ourselves of the sort of, let's call it, labor market advantages and incentives around -- DAVE: Geo-arbitrage. WILL: Yeah, well, you can arbitrage location. And, like, bluntly, if you're talking about a software engineering organization, and I say this as somebody who, honestly, as long as my commute's not too bad, would rather be in an office, because I like the vibe. I know I'm a weirdo. That's fine, but that's just me. DAVE: I hate the commute, but I love the vibe. WILL: I like the vibe. As long as the commute's not too painful, I like the vibe. But I understand that I'm an outlier. I got good at distributed work because I was running a sketchy startup, and I needed bodies, and I could offer remote work for free [laughs], you know? So, I had to get good at it, and I feel like everybody's just sort of, like, trying to un-ring this bell. DAVE: By the way, for people playing along with the home game, RTO is return to office, which is a fantastic miscommunication at Acima, because we are a lease-to-own company. But we are owned by Upbound, who owns Rent-A-Center, which is a rent-to-own company. And in the return to office, I literally went into HR, and I said, "I'm really having trouble with the RTO." And they were like, "That's, like, our whole business model. I don't know that we can help you." And I'm like, "Oh, no, return to office [laughter]. I'm fine with leasing. I'm okay with, like, the moral implications of that. I'm fine with that [laughter]." The other thing, anybody listening who isn't at Acima, Mike Challis, are you in Chicago proper, or are you in, like, Champaign or -- MIKE: Not in Champaign. Champaign's quite a bit further south. I'm -- DAVE: Oh, okay [inaudible 24:33] geography. Rockford area. MIKE: I'm pretty much due west of Chicago. I'm near the...where does the Chicago area end? I don't know. I'm near the Chicago Rockford Airport. So, I mean, it's got Chicago in the name, but if I were to drive downtown, that's going to take me at least an hour and 20 minutes. DAVE: Okay. Fair. WILL: Ooh [laughter]. DAVE: I'm kind of west of Chicago, too, but it's, you know, get on I-70 and drive for two days [laughter]. The first time I met Mike in person, I was on the data team, and Zach, our team lead, came over and said, "Dave, someone here to see you." And I turn around, and it was Mike, and I don't know if Zach knew that, like, we had hung out a lot and had never actually met, because, like, I made a squeak noise. I jumped up, and I gave Mike a hug, like, without even saying hello. I think Zach was a little startled by that, which kind of pleased me [laughter]. MIKE: So, let me make a suggestion here. We're talking about how to transform. We've talked about some of the dysfunctions that have happened with meetings and how they take so much of our time, the thing that just steals from our time every day. If so much of it is about getting information, getting context from somewhere, and AI is super good at finding something when you ask it a question and returning it to you, then we have a job to do. We have to connect the information to the tooling to search, and that's not trivial, right? That's not a trivial thing. And some organizations have got it better than others, but there's future work there, I think, that can be transformative. Because if you can say, "Well, what is the API that does this?" and it can just tell you, that pushes you a big step forward. DAVE: It has some really interesting direct implications as well. I mean, merchant portal, it's no secret that it's a very large, very legacy codebase. We've had contractors in and out. We've got entire sections that that initiative has been abandoned, but about 10% of that code got repurposed for some other thing, so we can't rip it out. And that's 90%, you know, technical debt that we've...right? And you send an AI into that, and I literally had a PR today that Claude came back and said, "Whoa, whoa, whoa, whoa, whoa. This might actually interfere with customer physical card." And I'm like, "That hasn't been a thing for seven years, and the guy that was pushing it got fired, so that's not ever going to be a thing [laughter]." But Merchant Portal is really broad and really deep, so an AI that goes into it has to be prepared to look at a thing, and then get some terminology, and then recurse into that terminology, because the words that we use to describe a thing aren't the thing that...how am I going to say this? We have a feature impersonation, right? We all know what impersonation is. And if you think you do, you probably don't want to work on the impersonation feature in Merchant Portal because it doesn't quite mean what you think it means. It kind of does, and Claude gets it wrong every single time. So, we had to sit down and say, "Here's a dictionary. When you see the word 'impersonation', it means this." But that's called anaphoric drift. An anaphor is when you use a word that...it's a pronoun, but it's not like he, she, it, they. It's like, the thing we were doing. That's a pronoun, right? What thing? The thing we were doing. I haven't actually told you what that thing is, right? And when you say impersonation, and it doesn't mean that thing, that's anaphoric drift. The word makes you think of a thing, and Claude has billions of tokens of training data that it means this, and it doesn't. So, we constantly have to be refreshing the AI. It means this other thing. It means this other...every time you do that refresh, that's another compute plane, and those are finite, and they run out. And that's effort that the AI can't spend solving the problem you want. You're searching, okay, yeah, find me all the instances of merchant_favoritecolor. That's a quick, little grep. But if I ask it, "How many merchants are in a state that's transitioning from, you know, this thing to this other thing? And when I say state, I kind of mean 50 states of the union, but I also mean this kind of status," all of a sudden, Claude is cooking and hasn't even started digging into solving the problem. And half the time... I say Claude, we use all the LLMs here. But the LLM can come back and just have everything wrong. Or it'll get the right answer, but it goes to give you the solution, and it doesn't follow any of the coding rules that we specified because something had to get pushed off the back of the stove to make room for all the other stuff that's in there. So, I'm sorry to go off on a, like, huge, like, side thing, but this is directly, like, what we're talking about, Mike, where the complexity...and AI is very, very good at search, but we need to be careful that the thing we are searching isn't needlessly complicated, and if we can unroll it...And the way I've been trying to adapt to this is I chat with Claude or with ChatGPT or with Groq, and I basically say, "What's your understanding of this?" And anytime the LLM introduces a new idea, a new word, or a new term...last week it came up with repricing an invoice, and it used it like that was a thing we do here, and it wasn't. What it was doing is recalculating all the prices on the invoice. And we have a lot of code and a lot of lore for if you change the things that you're buying, take something off, put something on, it changes the price. You've got to recalculate the invoice on the thing. The AI decided that that was repricing because all the words we've been using to describe it weren't perfect fits to what it was. And repricing was even worse, and there was no history for it, and we had to remove it back out. Sorry, I'm getting way down in the guts. I've been down in the bowels of the minds this week, so... MIKE: Well, you're suggesting something. So, we're talking about the hidden work. Let's say that coding goes down to zero; AI can write all of your code. Well, if coding is only 15%-ish of your time, then you've still got all the rest of your time. And you're saying that now you're spending a lot of time giving context to your agents so they know how to make the right choices. And now you have a new bottleneck. You've got a new bottleneck in what you need to spend your time doing. You're training the new guy, right? You're training the new owner who just started, and brilliant, but doesn't have any context yet. And so, you have to spend a lot of your time doing that. So, that's a new...it's not fully new, right? We talked about pairing earlier. It's kind of the same thing, but you still got to do it. WILL: If I was going to...like, if somebody made me, like, Grand Poobah of AI for some company somewhere, if I'm doing anything, I'm formalizing context. Because that context exists, and it doesn't just exist in meat space, right? I mean, it is in your head. It's in, like, okay, you've got dead code, right? Okay, dead code. Well, you could never get dead code. Or, I think, it would be very difficult if you just looked at your repo and said like, "Oh, well, these are the things that we don't do," right? Because they're there. They're latent. They're live, and they're disabled by some feature flag. Or they're disabled by the fact that, like, we've disabled this endpoint or something like that, right? And so, if I was Grand Poobah of AI for some place, like, I mean, the first job that I would be doing is defining context, defining hidden context, defining secret business models, making sure that the documentation really was both exhaustive and, like, accurate and, like, really drilling into that because I think that LLMs really are limited by, like, your formal, informal, semi-formal, let's say, right? Because, like, there's formal, formal. There's mathematical formal, formal. But then there's just sort of, like, documented API specification, the Swagger documentation, and all this stuff. The LLM, the utility of an LLM, in my view, in 2026, the LLM is more than capable of doing the task, of doing nearly any coding task you want to name, as long as you could tell it in relatively precise language what it actually is. This is how we design an interface. This is how we define a task queue, all these things, right? Like, these are the things that we are doing, and these are the things that we are no longer doing. You know, this is what our traffic looks like, you know what I mean? This is the test suite for, you know, this microservice, right? Like, this is the microservice's own internal representation of all the things that it can do, which might not necessarily be the Swagger documentation, and really drilling into that. And, I think, if I was going to do anything, right, to really, like, sort of, like, turbocharge AI adoption, it would be formalizing this context, which an AI could do if you turned it loose on, like, a data set that reflected reality, you know? And that's kind of a tricky problem. But, like, more than anything, I think the definition of that context is the thing holding us back. VIVIAN: We've mentioned the kind of guy that's been working at the company for 20 years who lives in the middle of nowhere, and that's why he's remote. So, if we can establish all of the context, if we can gather all of the information that's needed for an LLM or a human to be able to fully understand, like, a system and how it works together, what is the value of that person? What is the value of that person who spent the last 15 years in the same codebase maintaining it, writing new features, building out the architecture, refactored it twice? What is the value of that person if we have established all of the context in documentation? Do we eliminate that need? Is that the goal of that process? And if so, how do we get all of the knowledge out of that person if they don't necessarily know what context they do have that is missing? WILL: The graveyards are full of indispensable men, you know? And so, like, yes [laughter], if you extract, like, every single thing that some person knows, then they are more replaceable, right? And, I mean, bluntly, I mean, if you think of...okay, let's think of a different example, because I feel like we're putting Mike on the hot seat in ways that he doesn't deserve. But let's say we're a bank, and we have this old, crusty, nasty COBOL service that nevertheless is managing all of our interbank wire transfers for trillions of dollars every year. And there is a grumpy, crusty, but very smart, full Richard Stallman wizard beard, mainframe programmer guy. And he's a jerk, but he's smart, and he was there, you know, when the old magic was written, and he knows everything, right? And so, we turn an LLM loose on all of this information, and we, you know, synthesize, like, all of this stuff. And we're like, "Hey, we're going to rewrite this thing in Go because we can have it faster. It can be more stable, better documentation. We're going to do the whole thing." And the LLM is going to do the whole thing. Like, that guy? That guy might, you know, he might get got. I don't know. I don't know what to say. The nature of the industry has not changed a lick since I started, and it is constant reinvention and renewal and do it the new way, and then the new, new way, and then the new, new, new way. And now it's an LLM doing it the brand-new way. And I think the people who are going to make it are the people who have been making it, and they're the people who are old, and they got gray in the beard. Maybe the hairline isn't what it used to be [laughter]. And they're like, "Hey, here's this brand-new way of making stuff even better, even faster, and here's how we're going to do it," and they are fired up. Because, ultimately, if you're going to make it in the business, you're interested in making cool shit, full stop, you know? DAVE: Yep. I had a chat with Uncle Bob Martin a few years ago, and I said kind of that same thing. Like, you get into programming because you want to work on cool shit, and his eyes got real big, and he says, "The problem is it's all cool shit." And he was right, because we were literally talking about tuning database queries, and it was very, very exciting. And coming off of that and going into, like, graphics drivers for video games was also really cool stuff, so... MIKE: There's a difference between knowledge and wisdom. I like this distinction. You know, you can know a lot of stuff and not be very good at applying it, right? Or you can...maybe you don't know that much stuff, but you've learned a lot about how to solve problems. And that second category, the person who's developed that problem-solving skill, will continue to be valuable. And that comes from a lot of the curiosity that Will was talking about, and Dave, you were talking about. You know, like, if you're always wanting to learn new stuff because it's fun, well, yeah, you're going to develop that ability to think at a meta level, right? It's not about the stuff you know. You're not valuable because you're the last person who remembers how it was built. You're valuable because you can go and figure it out even when that guy's gone. And that will continue to be valuable, I think, forever. DAVE: There's a great...Old age and treachery will triumph over youth and skill every time. The converse of that, though, from the book "How to Behave So Your Kids Will Too"...which is a fantastic book by the way, not just for parents. It's great for interacting with other humans. Understand that somebody who is young, especially, like, teenage years, they have every bit the amount of brain mass that you do as a grown adult, which...and they have unlimited, like, thyroid metabolic energy. So, your teenager has endless enthusiasm and just as much intelligence as you are. Old age and treachery, you know, experience and treachery, knowing where your teenager's going to end up once they've solved it three times, how does that adapt into software? I've worked with teams where everyone was a recent college graduate, and they were all, you know, 120 IQ plus, really, really bright. I knew I could give them any problem and they could solve it from first principles. And after a year and a half of working with that team, I realized I desperately need somebody on this team who has forgotten three ways to solve this problem. Because it takes three days to solve it one way from first principles, and then you have that one solution, and you assume that you've got it. Where the gray-haired guy sits back, and he goes, "No, I wouldn't use that kind of queue. I would use this other kind of queue. I would do the guarantee once, but now the, you know, many retries you can...it'll solve the Two Generals' Problem kind of, but the receiver has to de-dupe your retries and da, da, da, da." And, weirdly, that exact queuing thing came up at Acima last month and literally was how we were solving The Two Generals' Problem with an external service. VIVIAN: Okay. So, you guys have talked about how it's kind of a wisdom piece is what makes a person valuable in the age of an LLM who can extract and pull out and organize knowledge into concrete pieces. The ability to understand and almost intuit, like, on a deeper level than just being able to do, like, higher-level thinking about it and logically process through it, just in an intuition of understanding of why things work in certain ways and why things don't work in certain ways, like, that is what is so incredibly valuable and will continue to be valuable even as technology advances and coding becomes easier. And maybe you're not writing any code, any, like, code itself, like, as these things change. But how does that...I guess I'm trying to say how do we take that wisdom and continue to propagate it throughout an organization when the process of developing that wisdom goes away? How does that increase the kind of, I don't know, maintenance burden on a person who, like, doesn't see the maintenance upfront or in the end because they never wrote the code that causes them to need to do the maintenance? WILL: So, I mean, first off, I don't want to throw around the term wisdom to justify my process quite so casually because I never said that, and I don't think anybody would accuse me of it. But I do like making stuff. I like working efficiently. I hate doing things twice, and I like it when my stuff, like, works good. You know, I like quality, and, I think, I would chalk it up to sort of adaptability and a commitment to look at engineering standards, right? There was a guy with a...one of the grumpiest, oldest, crustiest devs currently working, Linus Torvalds. I was reading an email that he said...which was, like, explicitly pro-AI and LLM and stuff like that. And, like, the justification was like, "Hey, guys, do you guys not use a compiler? You guys don't use compilers to compile your stuff?" Like, come on. Like, when I started this stuff, like, there were still a hardcore few who were handwriting machine code, right? Like, I myself have written some amount of machine code, and I suck at it, but I could do it if I need to. I'm actually probably pretty good at it, like, relative to the curve at this point in my career because I am, like, competent at it, but, like, you don't do that anymore. But, like, I'm as busy as I've ever been. So, I mean, if you're trying to build stuff well, like, there's very few carpenters or woodworkers out there who are really very good at hand-cutting a dovetail, right? Like a mortise and tenon joint. People don't do that anymore, you know? There was a time 100 years ago people were great at it. I've watched, old, old-time woodworking videos where, like, they have these crew of, like, old school turn of the 20th century dudes who, you know, they invented a movie camera to watch them do their work. And they have amazing skills. But we're building better, faster, and cheaper now. And the building is the problem, and, like, the thing that'll keep you in business or not is your adaptability and you're willing to, you know, ride with innovation. Like, there's going to be work to be done, you know? Like, there's going to be work to be done, if for no other reason than the more I give people, the more they want, you know? Like, they want more, more, more, more. DAVE: But you're training them that you deliver, yeah. WILL: Yeah. And, I mean, we've seen this happen over and over, and over again, and, I don't know. We may shrink the size of the pool of developers. That is certainly a possibility. But -- DAVE: How many people are there out there that can arc weld a car together, right? Probably precious few. WILL: Thousands. Yeah, I mean, but, like, you know, they work for racing. You know, racing... DAVE: Yeah, that's fair. Yeah, it's esoteric, right? How many people are there now that smelt iron? It's a bunch of guys that work at a factory that do, you know, high-precision, high-mass metal refinement, and one guy with a YouTube channel who's out there digging up peat bog moss and smelting it down and showing, "This is how you make the iron bloom," and da, da, da. That's where we're going to be in 20, 30 years. It's going to be one of us...you know, one of our kids is going to be running a hearkening back to ye olden days of the Melissa virus and Y2K, and, "This is how they actually wrote software back then. Did you know they had to type it in?" MIKE: Well, you asked a question, Vivian. How do people get up to speed on this stuff? Going back to what Will and Dave were saying, we're not writing machine code, but that doesn't mean we're not learning from our elders. We've got our mentors who are teaching us how to use the new tools. You still have to care about architecture. You still have to develop that taste that Will was talking about, you know, these things I care about. You have to develop that, and you can still learn that. There's still a...and software is very much an apprenticeship kind of industry, right? You learn from...you do learn from your elders. That doesn't go away. You're just working at a different level of abstraction. You still care about the architecture. You still care about things getting done. You still think, "Wow, we're spending too much time on this. We should improve our process." You still learn those things. You're just learning the modern tooling to accomplish the same goals. DAVE: The job is, and still will always be, inspect, adapt, iterate, right? Those are the three principles of agile. WILL: Yeah. I mean, look, I've said this many times. This is another one of my soapboxes, but, like, that LLM will explain to you what it did and why and how. Like, there's never been, I mean, I don't know, my opinion evolves on this topic day by day. DAVE: It should. WILL: But, like, I have gotten into so many things that I just never had the time to learn, just because I'm like, "What the hell was that?" And it'll be like, "Oh, here's how you do it. This is what it is." And it's all, like, case study, and I don't know whether that's sort of, like, shallow knowledge, shallow sort of ephemeral knowledge, because I didn't have to, like, really suffer for it, like, maybe some other things that I had to learn. But absolutely indiscriminate in terms of, like, sort of interrogating these LLM outputs and like, "What's that? What's this? How are you doing that? Why are we doing this? Is this another way?" Like [laughs], I ask Claude questions. I ask many more questions than I say, "Build me an app [laughter]." Like, it's a two-way conversation. And so, like, I have, like, on one level, like, the best pairing partner that I could have ever asked for because, like, it will happily digress and, like, you know, back and forth, and we can war game things and, like, all that stuff. It's endlessly patient. I tend to exhaust people. But yeah, Claude, as long as the tokens keep flowing [laughter]. DAVE: So, the last episode, I wasn't here for the last episode, and I really wish I had been. Vivian had posted...did you guys do the how AI is affecting learning and understanding? Was that the last episode? VIVIAN: MM-hmm. DAVE: I saw the discussion of it go by in the chat. And there was a study that Anthropic did where they gave them an assignment of go learn this Trio environment and write this thing, and then they came back afterwards, and they said, "Now answer these questions about the environment." And the people that leaned very heavily on the AI, were very dependent on it, couldn't answer most of the questions. And the people that got it done and got it done well and right tended to have a lot of overlap with people who stopped to actually understand the system. But what I found interesting about that study is we're going to have to...it's easy to take that study and go, "If you rely on AI, you're going to be stupid, therefore it's bad. AI's bad. Learning is..." No, I don't think that's what the study is telling us. I think we're going to have a day when we're going to look at somebody in an environment, and we're going to say, "Do we want somebody who will get into this environment and understand it to its bones and become the subject matter expert? Or do we want somebody that we can sit down with this chunk of code and hand them some Claude tokens or some Copilot tokens and say, 'Make it take Canadian dollars,' or give it this other thing and say, 'Rewrite the UI in React. Make it happen.'?" And then when you're done, you're fired because you're a contractor, right? It's a gig economy. And, in that particular case, you want the person who can deliver that product, and you want to be the person who can deliver that product as quickly, and effectively, and efficiently as possible. I guess what I'm saying is don't pre-decide the morality of your outcome. Be aware that if you are leaning heavily on the AI, it's doing a lot of your thinking, and some of that is feeding your understanding. And that can come back and bite you, especially in a world based on everyone assumes you're going to have heavily understanding because the industry is made out of people that were in the industry 10 years ago. VIVIAN: So, are you saying that a change in the industry moving forward is going to be a more significant focus on identifying and making kind of informed decisions and explicit decisions about where you want to spend the time to build the understanding versus where you want to throw tokens at the wall until you have a product coming out the end of it? DAVE: I don't want to plant a religious flag on it. But probably, right now it is my opinion, strong opinion, loosely held, I guess, that that's probably going to be the case. The underpinning thing for me is pragmatism is a belief system on whatever works is what is true. And, in this industry, the people who can get it done are the people who get the jobs, who get the pay, who get the raise, who get the promotion. And if you heavily...you should find something and heavily specialize in it because it's good for the soul. And you need to have practice in specializing in something. And you're going to specialize in things that the market turns out to have no need for. Nobody needs my Skyrim modding experience, so I'm not going to leverage that anywhere anytime soon. But my time spent programming in Lua turned out to actually have a professional use case. You know, it's like all the drivers for read-write splitting in MySQL were written in Lua. That kind of weird stuff. If you specialize in things, the market is going to pick up and reinforce the things that were pragmatic and useful. And I strongly feel that the people who can have their head up and go, "What do I want to get out of this? Do I want a working solution? Do I want understanding of the system? Do I want both? Do I want them at a given price point? Do I want to make the customer pay more for a working system so that I can have the time to understand it because I'm going to follow up with a, 'Oh, and by the way, I can do these five other things for you?'" That's the kind of stuff that if you get it wrong, it'll cost you your job. But if you do it enough, it will make your career, because you're always looking at what is going to work, what is the customer going to want, what does the market need, what is going to be useful to people tomorrow. That's the thing that I want to be skating ahead of the puck to try and catch up to. VIVIAN: That reminds me of an interesting recent development. There's a company, I can't remember the name of it, but, basically, they've focused on reverse engineering a whole bunch of productivity software, specifically the entire W-Suite. They've rewritten it in Rust, using a kind of clean room technique that was pioneered back in the olden days. But these systems are very unstable, very full of bugs. And, honestly, I think the key piece is that there is not a person out there that understands it that can fix those bugs because no one wrote the code. DAVE: Yes. VIVIAN: And you can say, "Hey, LLM, fix this bug," and it can go out and fix that bug. And in the process, it will introduce four other bugs that won't be discovered until five months down the line when somebody's trying to do some mission-critical work, and then it corrupts their file, and they lose three years' worth of design work that they've been working towards. DAVE: Absolutely. VIVIAN: Those are the types of things that people will continue to pay Adobe, however much they're charging you. Even if it feels like it's too much, you'll continue to pay Adobe because you know that at the end of the day, someone thought through why they made a decision at each point in that process. And it's interesting to me because, like, you can build code really, really, really fast now, and you can build incredible code really, really fast. But that maintenance, that maintenance cost will rise every time there isn't a person that can make a decision about the code because that decision is the thinking that builds the understanding that allows you to maintain it and make it better moving forward. DAVE: It's the LEGO problem. You give an engineer...So, TL; DR, short version: AI can write us a little bit of software. Therefore, AI can replace all the software for free right now today. That's the fallacy. It's the LEGO problem. You understand how a LEGO brick works. You can plug it into more LEGO. And now you think, "I can build anything." No, you can't. You can't build a suspension bridge because, at some point, the weight of the LEGO will exceed the tensile strength of the plastic. Like, you literally can't put any more bricks in it, right? It's like, how much fuel can you put in a rocket? There's a point where the weight of the fuel is more than the thruster can lift, and so you have to tune this, right? It's how much payload do you want it? How strong are your rockets? That determines how much fuel you can put in the rocket, or the rocket literally can't lift its own gas tank off of the ground. This is what's happening in software. Vivian, for your benefit, also for Mike's, I started a wiki page in-house of AI horror stories. I got very, very excited about Google Antigravity early in the year. So, this is not the Antigravity that you're familiar with today. This was VS Code with a browser control, and it kind of knew how to write things in, like, React or, you know, one of the pretty lickable JavaScript frameworks. It was gorgeous. I had to write a full website, and two weeks later, my website was slowing down and slowing down and slowing down. It turns out that on every keystroke, it was regenerating the entire page, and as the pages got longer and longer, it was regenerating the entire page character for character on every keystroke. And the size of the website and the codebase was now larger than Gemini, their AI, could fit in its head. So, it could not hold...like you were saying, it could fix that bug, but not without breaking 17 other things, because that was in a blind spot caused by holding all these other things, so it had to give up entire systems to fix that bug. Well, now those other systems are broken because it paved over them because it didn't think it needed them. You got two solutions to this. One is learn how to train the system better and have a human to understand it, or wait a few more years for an even bigger AI system with, you know, a bajillion tokens of context and, you know, a zillion compute planes and all the data centers. I don't want to do that. Yeah, Will's shaking his head. I don't want to do that either. WILL: Well, no, no, no. Like, I mean, I think we're demonstrably hitting the edges of the sizes of the LLMs, like, what we can fit on an LLM, like, our token ceiling. We're hitting it, you know, and that's fine, right? And so, then it becomes now, oh, now it's engineering again, right? Where it's like, okay, like, how do we take a complex task and slice it up into little tasks? It's like, oh, you're saying you want me to do microservices within my token window? Okay, let's do that, and look at me, employed again [laughter]. DAVE: I think AI LLM size probably has several more orders of magnitude available to it. Just looking at the way they're built, like, the attention heads are in separate computers, and that's...their ability to communicate, that's the speed of that synapse. If we could move those synapses, those attention heads into the same CPU...But yeah, now you've got a silicon chip the size of, you know, a Greek shield, and that's going to give off plenty of heat. And yeah, so you're up against physics, right? Eventually, the breadth of the distributed system is so big that you have kind of, like, informational relativity. The photon leaving this side of the chip is decades old, metaphorically, by the time it gets to the other side of the chip. The idea literally takes time to propagate through the system. WILL: Don't worry, don't worry. Thermodynamics is going to come and steal your lunch before you get to any of that. DAVE: Yes. I'm banking on Roku's Basilisk just inventing time travel and solving all these problems for us. WILL: Maybe quantum computers will fix it for us, who knows? VIVIAN: I mean, all of this is ignoring the yield that you get out of a silicon chip that size. WILL: Exactly. Exactly. DAVE: It's not ignoring it, but it's another problem with limits. Yeah. WILL: And like -- DAVE: There's a great YouTube video right now on X-ray lithography, was an unsolvable problem until just a couple of years ago. And then they finally solved it by literally creating a fusion system that's hotter than the sun, detonating tin molecules. And it gives them the X resource strong enough to do lithography for computer chips that's much smaller than anything anybody else can make with boring, old visible light. WILL: No, I don't even think that's...I don't even think that's X-rays yet. Like, I think that's how they do, like, super, super high ultraviolet, but that's not X-rays yet. I don't believe you. DAVE: I have to double-check. WILL: I mean, it's -- DAVE: Sorry, you're right. It's EUV. Yeah, extreme UV. You're right -- WILL: Like, X-rays is yet another level. DAVE: It's science fiction. That's X-rays. Why not? But yeah, you're right, extreme UV, extreme UV, yeah. WILL: No, it uses, like, these tiny nanometer things where they're, like, blasting, like, droplets of molten tin. Like, they're suspended in the air, and they're, like, zapping it and, like, pinging off of that to do lithography, which is insane [laughter]. That's real life. That's insane. DAVE: And that'll be in your 3D printer. Well, it'll be in your grandkid's 3D printer, you know? VIVIAN: Well, and what's crazy to me -- WILL: And that's why I say this whole, like, multiple orders of magnitude of, like, AI scaling capability I'm like, no freaing way. DAVE: I will say that you're right that they were running out of...the dimensions are running to their limits. It's like Moore's Law. For the longest time, we treated Moore's Law as, like, CPU speed, and, you know, clock speed, clock speed, clock speed. The problem is that at seven gigahertz, my memory's failing on this, but, like, the wavelength, the signal of the clock literally can't cross the CPU in one clock cycle at the speed of light in a wire, which is two-thirds the speed of light in a vacuum. Going out to RAM is hundreds of clock cycles because it's a full centimeter away. It's unavoidable, right? That kind of thing.-- But we didn't lose Moore's Law. We just started adding CPUs in parallel, and we started doing things. But now you've got synchronization problems and, you know, thread safety and core safety. WILL: Yeah, pipeline stuff. We've got branch predictor modules. Like, computer engineering is freaky. It's super freaky. We change the instruction set. Like, that's already kind of...it's already kind of done, and all kinds of crazy stuff. And, like, progress still, you know, moves along, but we've already seen these sort of frontier models. We've seen these frontier models slow down, and so, you know, what happened? I was like, we're constructing the tooling around these models, right? DAVE: Right. They're shifting. They're shifting around, yeah. Like, Fable has now this...so I write creative fiction at night. And when you write fiction, bad things happen to people, and that will trigger a classifier in, you know, any of the flagship LLMs, where they're like, "I'm sorry, I can't produce that content," because it thinks it's a real-world thought experiment. I'm like, "No, no, we're writing fiction." And for the long...like, Claude 4, not a problem. I was able to reason through with Opus and get through. Now, in Fable, the amount of things that Fable can reason about and say, "Yes, I can create that because I know it's fiction," like, Fable kind of understands even more than Opus did that, oh, this is fiction, and I can explore that. But there are some things that Opus would explore in fiction that Fable won't, and it's not because Fable isn't smart enough; it's because they put a smaller AI in front of it looking for jailbreaks and unauthorizable content. And there are some things that you can write on Opus 4 that just put the spook into that classifier to the point that it drops the hammer, and it'll literally suspend your account on Anthropic. I didn't get all the way to a suspension, but I did get an annoying yellow warning on my account that said, "If you keep this up, we are going to suspend your account." I'm like, "Well, I'm going to go back and change what I'm writing about. I think I'll write something about, you know, daisies and puppies next time." MIKE: We've wandered quite a ways from our topic of the, you know, the hidden work because we've gotten into AI, right? Which is kind of central anyway, how it's changing our process. DAVE: Yeah. I'm sorry, AI is my personality now [laughs]. MIKE: It's true for all of us, and that's kind of where we wanted to go, is that it is changing it. It is changing it. But there's still going to be hidden work, and maybe the hidden work becomes most of the work. We said this before: writing the code, like fingers on keyboard, that's not software engineering. DAVE: Not anymore. That's typing. MIKE: That's typing. But it always has been, right? It's always been a minority of the time you spent. You know, maybe you have that flow state where you get to bang something out, but you got that by preparing for it, right? You had all the requirements that went in ahead of time. So, there's always going to be other kinds of work. We can reduce our meetings. We can reduce other things, but there's going to be other things. There's going to be this other kind of work, and it's just going to grow probably as the AI gets better at doing some of the automated stuff. It's going to change. We don't even know all of how it's going to change. You know, if we flow with...you know, if we grow, we'll have new and interesting things, which makes our life more cool. DAVE: I saw this topic go by in the chat before the thing, and there was a whole separate thing I wanted to get into, which is that we have these, the hidden work, that we have these problems that we have well solved. Like, thread safety is a solved problem, but you have to have this engineering. Or object-oriented programming versus functional programming, they have ways that they approach things; data encapsulation over here and immutability over here. But there are things that those languages don't do well, and problems get...in a real system, you have all of the things, the things you're good at and the things you're bad at. And the things you're bad at sometimes get pushed into the spaces between things, and that's terrible. That's where seniors make their careers because these problems get pushed into the gaps. They get kind of pushed under the carpet and pushed to the edge of the thing in the parts that aren't well lit, the dark gaps between things. These ideas become cockroaches, and they go to the darkness and hide. And so, somebody comes in and says, "I've got this great, new idea. We're going to do this completely different programming methodology. And look, it's got all these well-lit islands." And you do this a couple of times, and you think, "Great," you know, new hotness, new religion. Let's go this way." And after you do a few of these, you start realizing you've just moved the dark spots. You've solved these problems, but your solution to it, by definition, leaves these other problems that used to be well solved are now formally undefinable. And that's where the cockroaches are now going, is they go to that set of holes. WILL: I mean, in the end, right, like, I feel like this wasn't so much of a digression as it may have sounded in that, like, you know, the actual programming part of programming is it was 15%, and now it's maybe closer to 5. Maybe not 5, maybe 10, right? We took a bite out of it, though. And so, as we're talking about, like, okay, you know, this is sort of AI and LLMs, right, like, this is what programming's going to be, we're talking about the future of programming and, you know, dealing with the elephant in the room directly rather than by implication. This is what our job is going to be like. MIKE: I'm sure we'll be talking about loads of AI in the future because it is our world now. And we started by talking about transportation and how it's going to change. Maybe we're in this electric car era, and we're not in the flying cars yet, but someday, right? Someday [chuckles] we'll get there. Actually, did you hear that Tesla just released a flying car this week? So, I mean, maybe we are in the flying car -- DAVE: No kidding. WILL: Allegedly. MIKE: Allegedly. I'm not buying that. DAVE: You know, it could be the beginning. MIKE: I'm not buying that. If you want to pay a million dollars, probably [chuckles] or 2 million, I don't know how much it costs. DAVE: I've argued for 20 years that flying cars would come only after auto-driving cars, and everyone's like, "Oh, auto-driving, it'll never work." And then the AI people just slowly started solving it. Yeah, I believe flying cars could happen now. I kind of do. WILL: Oh, we've got flying cars. Had 'em. I mean, seriously. In fact [crosstalk 1:04:30] like a sedan size, more or less, like, personally ownable, like... DAVE: You mean like ultralights? WILL: No. [crosstalk 1:04:39] flying car. Like, they've built it if you have millions and millions of dollars. Like, that stuff exists. It's just, like, a weird, like, hovercraft thing. I've seen it. I've seen it in, like, Popular Mechanics 20 years ago. Like, they've had them. It's just the regulation and stuff around that kind of thing is pretty intense. They're fantastically unaffordable. And, like, you know, if you could do that, you would just buy a helicopter and, like, have some [inaudible 1:05:10] [laughter]. DAVE: No, I'm thinking about, like, a mass market Buick that has to contend with rush hour traffic in the sky. Like, those are problems that would have to be not just solved, but well solved, like, way better solved. Like, ground traffic needs to go 10 years with no collision accidents at all before I would trust somebody in a flying car where any kind of mistake is a deadly one. WILL: Listen, I'm going to be honest with you. This is a very big digression, but, like, it's just going to be the bus. DAVE: Mike is like, "The podcast just went even weirder [laughter]." WILL: You're thinking it's going to be The Jetsons, and it's going to be the bus. DAVE: Yeah. MIKE: Bus. DAVE: Yeah, it'll be the light rail, even lighter rail. WILL: No. You probably don't need the light rail. Who needs light rail? It could just be the bus, right? If it can drive itself, there's no value in, like... DAVE: Oh, sorry. Yes. Metaphorically. Mass transit is what I mean. Yes. Mass transit. WILL: Exactly. Exactly. MIKE: Well, and we're going to the future. In the future, you know, that's kind of where we're headed. We don't know exactly what it looks like, but we're headed there, and it's going to change. Until next time on the Acima Development Podcast.