Engineering Rigor in the LLM Age

Last week he made us wait for like four minutes. - Well my man in the office says, hello Adam, says Brian's here, hey Brian, how are you? - I'm doing well, how are you? - I'm doing very well. - And we've got all the oxide friends here. We've got David and Rayne. - And Rayne, great. - You know, our predictions episode was only a week ago, and yet it already feels, like at least one of our predictions already feels like such a lock. It's amazing that it was even considered a prediction as little as a week ago. I think this on we, the software engine on we, and then your absolutely brilliant naming of deep blue for this sense of software engineer on we, wondering what the real purpose of anything is of the LLM could just do everything for them. It feels like this has already taken root in the last week. Is that my imagination? Feels like this has been. I think it, I think I don't think it's just your imagination. I think it would also be my imagination, but when I saw someone, not even tag us, but just describe the feeling as deep blue, I was like, wow, this is, this is really getting there. We really made it, yeah. - We made it. We've definitely arrived. How ironic would it be if that cease and desist came from IBM for naming, for sullying the good brand of deep blue into a kind of like, the predictions market does not have that one coming. - Exactly, let's see deep blue disambiguation on the Wikipedia page when they actually need to verify that we're not talking about the software engineering neo-depression, LLM based oppression. - Yeah, if we see the, if you see the polymarket on that spiking, you know that there's a C&D coming and some insiders are profiting on it. - With my understanding of those insiders just to be us, isn't that the way, isn't that what polymarket, isn't that sorry, isn't that who they serve? - I think in this case, it would be the folks at IBM about to sue us, but yeah, I mean, that's, that's basically. - Yeah, can we take out a position on getting a C&D? Is that the good brand, a C&D over the course? They're gonna be oxide and friends. I mean, old conventional wisdom oxide friends big of a car, new conventional wisdom oxide friends polymarket. - Yeah, it's got a good edge. - Yeah, yeah, it should be, but it feels like this has really been, I mean, we knew this last week, but just the presence of LLMs, what do LLMs mean for software engineering? I feel like I've seen like six different pieces a day on, right about talking about, what does this mean, what does it not mean? And I feel like there's quite a bit of noise out there. I will, noise. There's a lot of consternation out there, that is for sure. This is a, this is an issue that has a lot of people thinking about it one way or the other for sure. I definitely, I mean, there is a demographic and if you, it's hard to say 'cause like these. - All right, look, if you're in this demographic, you are gonna think that we are belittling you by making other people aware of this. - I just wanna pause right now. - Yeah. - All the stories, please write down. What Lord Group of People Brides about to alienate. - Excuse me, I'm being handed this full of the piece of paper. Listen, I just have, I've state the mortgage payment on a C&D, so I'm really, I need that. I'm really need to get the goose this thing along. So really trying to, after our, you know, we tried to get a C&D from the Republic of Germany last year after offending all of our German listeners, but we, nothing to do with that. So there are, there's a virulent anti-LLM demographic out there. And I like, I get it and, but that's not what we're gonna talk about. I guess we are, sorry. Whoops. - I was like, wait, those folks, you already alienated all those. - All those folks already are there. That one has got to be already kicked many times. - Like do not follow yourself on Blue Sky, because you, maybe you should. - I know, I also feel like I'm doing, you know, I had a boss who'd do this once, who'd be like, listen, we're gonna go into this meeting and I want no one to mention inserting a former customer. Like we're just not gonna talk about them. I'm like, I wasn't gonna bring them up. And then like the very first, I wanna explain to you why former customer is no longer a customer. I'm like, okay, didn't, okay. So, oh, I get it. When we were in the car right down, you weren't talking to us. You were talking to you. Like the part of your brain that tries to not screw everything up was trying to talk to the part of your brain that actually in fact screws everything up. And that part of the brain wasn't listening as it turns out. So, I kind of feel like the same thing for me here on the back. - There we go. - Nobody bring up the fact that there's a demographic that believes that LM uses immoral. I will do that from the top. Is that not? I'm sorry. All right, well, this is a hash. We can cut all this out, right? This is. - Yeah, sure. - But we are, to the contrary, what we want to talk about today is what we have seen is that we want to split this kind of, there's this false dichotomy out there that you are either vibe coding, a term that I get again, I believe is not going to survive the year. A prediction that maybe not be fairing that well in its first week about you waiting our predictions one weekend. Where you have a fully closed loop in an LM, it's just simply creating software of its own volition. That is kind of like, that is one poll. And then the other poll, of course, is like, no, no. These things are like, you should never use them. They should be used for anything that are, you know, et cetera, et cetera, et cetera. - Correct, Mom. I'm wrong, but I feel like a chubblet of vibe coding is this idea of like, you just do it. And if you don't like the results, you do it again. And if there's a bug, you do it again. And you're never sort of cracking open that not like seeing what all the gooey middle is, you're just like, just go for it. Like kind of a lack, a total logical lack of curiosity and curiosity about what's going on inside. - Yes, well, this, I think that the term will die with this because I think the term is going to be associated with that lack of curiosity, but yes, absolutely. And there are domains in which that lack of curiosity may be okay, but other domains, which it's not. So that's kind of the, those are the kind of the two polls. And I think what we, what we believe, what we've already seen is that there is a big, big, big middle ground. And in particular, what we have seen is LLMs can actually be used to result in more rigorous engineering. And it's actually not even that hard. I think that there are, there's, and I've got, I've got some specific, I might, some specific and recent experience. Adam, maybe I could lead off with that before I introduce our colleagues. So I have been exploring using Cloud Code to do, cannot work to do. We've got our host operating system is Helios. It's an elumost derivative. And I had some like, what I thought was a good, you know, you always have to have like a good first task for these things, just like when I picked up Rust. I wanted to find like the good, like, what is the right thing to try Rust on? My first thought of, I doubly linked List and ended up being, that was the, that was the worst idea. That was the worst thing. So okay, let's, let's not do the worst thing. Let's do a different thing. And I mean, just, and actually, you know, you kind of have the same experience with Rust of like picking up not a great first thing, although not deliberately, right? I mean, 'cause you did a Sudoku solver. Yeah, and a grammar, yeah. And, and I mean, and how was that as a good, as a first Rust project? It was, it was like, I think it was very early for Rust. It was early for Rust. It was early for Rust and just the work that has gone in the interviewing, oh, like, 10 plus years, yeah, yeah. To making it approachable and the error messages, sort of like convergent rather than divergent. Like, I think my big frustration was, was like, go, go try this. And it's like, oh wow, that's much wronger. Like, don't, like, who told you to do that? You told me to do that. What are you talking about? I didn't tell you. I didn't know you were talking about, yeah, exactly. So, but you also, so, I mean, in hindsight, would you, today, would that, that would be a fine first Rust project. There was nothing about that project itself, yeah, right? Yeah, I mean, it was, it was even simpler than the thing that ended up being your first Rust project. Right. So you always wanna have a good kind of first thing for these things and I've been kind of waiting for a good, like, what is a good thing to use Cloud Code on? 'Cause I just wanna, like, see how it does basically and this stuff. And I had some, like, some relatively straightforward scalability work that needed to be in a lock that needed to be broken up. I knew how I wanted to do it. It was gonna be a little bit tedious, but I was kind of curious to see how it did. And it should be said that the idea here also was like, you're breaking up this lock in a way that many locks before it have been broken up. Is that fair to say? Yes, absolutely. There's actually, like, what needs to be done here is really quite straightforward. And I can describe it pretty completely to Cloud Code. And I'll drop a link to the actual bug itself. It's the most 17, 816, so I'll drop a link in for that. And so you can see exactly what the problem was at hand, pretty straightforward. Now, I was gonna use, like, very deliberately, not using it, I'm definitely not closing the loop, but not vibe coding it, not one shotting it, but really, because in particular, like, I am not, I'm not even gonna let it build anything, right? I'm gonna let it, we're gonna go into the source base and I just wanted to see how it did. And I really did remarkably well. One thing that was really interesting, and I was, but not, I mean, not definitely not perfectly and had some subtle issues that needed to be resolved, but we got those resolved pretty quickly. And I think I would say, like, it had two subtle issues, but it had also did not have a subtle issue that it could, it made a subtle discovery as well. And the thing that was really interesting to me about it is I was unleashing it on, like, a pretty big source base in terms of alumas. And it was really interesting to watch it effectively read block comments to understand how subsystems worked and to understand, and so reading not just code, but also comments. And all in all, it was really pretty impressive. You know, it definitely understood, I mean, it's, we're talking almost here. So it's like, this is not, like, anything that you have trained on that is the Linux kernel, or the BSD kernel, is like literally not gonna apply. It would be very easy for you to create arguments, to functions that didn't exist. I'm talking about the KStat facility, which is a facility that doesn't exist. So it's like, you really cannot rely on something that you've really trained on. You're gonna have to kind of look at this. But it was good, and I would say, like, net net, it probably saved me probably about, in terms of the, like, the actual time to implement this, it probably saved me like half the time. I've spent about two hours on it to have something that was, I was pretty confident would work and did work, versus I think it probably would be about four hours on it. And it's someone's interesting. Well, I have the LMS trained on alumas. It's like, yes, but the way it was iterating, and if folks haven't used CloudCode, it is really, it's worth experimenting with, especially on an established source base. And so one of the things that I would just like to throw out there as, like, a first way that these things can help increase your rigor is by asking questions about a source base. And clearly, like, you know, all of the caveats apply that you can get the wrong answers and so on, you need to verify these things, but it was really, I made it much more, made the time, it figured out a lot of what needed to be done, surprisingly quickly. So I will absolutely be using it again for other kernel projects, if only to, as a starting point, to, and I, you know, one of the things it did, it was funny is, Adam, it needed to add a field to a structure. And this is, the actual structure itself, none of the fields is commented. Do you know how we, like, best practice would be to comment every structure member? And in this particular source file, none of the structure members are commented. And the, what its proposal was, was to actually comment the structure member, like, for bad reasons, like, we're not going to do that, we're going to be consistent with what's there by not commenting the new member that you just added. Like, the code you want to actually write is actually cleaner than what's there. But it does think, the other kind of thing that it brought to mind is, like, boy, there's so much, like, technical debt kind of things. And one thing I think would be interesting that I'm sure we're going to see, is people going into existing source code and commenting it better, using cloud that just had better comments. Then obviously, validating all of its work and, you know, not allowing, anyway. That's, that, that's kind of my, my story, from my experiment over the weekend, doing a Lewis kernel work. And, uh, came away pretty impressed. Awesome. And did, when you started that project, did you have a sense of what the code was probably going to look like? - Yes, yeah. - Definitely, yeah. I mean, like, this is one of these where, in many ways, I had biased it for maximal success. I knew I had a pretty good idea of what it was going to look like. But there's also some fiddly bits of people, you know, look at the, I actually, I'll put a link to the diff into the actual bug. It's like, there are some fiddly bits to get right, actually. There's a little bit of math that needs to be, that you need to do correctly. It's not, um, but, yes, I definitely knew what the code was going to look like. And this is, it doesn't span multiple files. We're not introducing a new subsystem. Like, this is pretty straightforward as it goes. So this is, I would say, in a relatively, a case that is, that I really picked because it's kind of biased for success. Also picked it because we need to do it, by the way. I mean, that's, that's the other thing. It's like, it was like, this was not a yacht shape. This was like, you were doing it in four hours or you're doing it in two hours either way. Either way, it had to be done. That's exactly right. I would say the other thing is that the four hours, versus two hours ends up being really actionable because I started this at 10 o'clock at night. And it was like, there's a pretty big difference between going to bed at midnight and going to bed at two in the morning. You know what I mean? In terms of, so, you know, sometimes like that, that difference can be, um, so, yeah. It was, uh, a pretty impressive, um, and gave me the belief that we could actually use this in lots of other places. But that is my limited experience. I want to, I definitely want to, so we've got two of our colleagues here. Um, we've got, we've got David and Rain here. And both of you have used L.M.s quite a bit and have discovered a, I would say new vistas of, of rigor. Um, the, I, Rain, do you want to kick us off on, on some of the, the, the stuff that you, uh, that you've done, where you found this to be useful? Uh, sure. Um, so there's a couple of different things I can talk about here. Uh, one of them is kind of the first work that I did. Uh, that was around May of last year. And then the other one is like the work I did around December with like reorganizing types and stuff, which one should I go with? What's, let's actually start quantum logically because let's, let's start as you're kind of getting into this stuff. Um, yeah, um, yeah. So I guess, you know, like, as, as you pointed out, the, a lot of the memes around, uh, you know, LLM based coding are, uh, you know, vibe coding, right? You don't pay attention to the code. You just like let yourself in the floor or whatever. Right. Um, it, that is, uh, I, I have to say personally speaking, that is kind of, uh, exactly the opposite of the way I want to build software. Um, and, and, and, you know, for me, like I want software to kind of, you know, aim towards correctness, I really want I degree of regard in my software. So when I came into LLM, I came in with like a huge amount of trepidation. Like I was like really worried about like, you know, I was just kind of trying it out, right? And, and I was like, okay, you know, I want to make sure that everything looks good and so on. So, um, the first use that I found that I thought, you know, was kind of really impactful was, um, so I wrote this, uh, we were having a bunch of issues at work around like, you know, how do we store, um, keys and values and maps? And so, uh, I kind of on the side around like April or so I kind of started prototyping this, um, this approach, uh, which lets you store, um, which basically lets you store keys and values side by side next to each other. And, um, I spent a few weeks, you know, kind of trying that out, right? Like, and, and, you know, I, I did a bunch of prototyping. I did, I did a bunch of work. Um, and then, you know, um, and then, uh, it was, it was like an interesting experience because that was all handwritten, right? So it was like three weeks of like around 2000 lines of code, like carefully handwritten. Like there's a lot of unsafe code and, um, and, you know, it was, it was like pretty challenging. But then, um, I realized that one of the things I needed to do was that if you define a map in Rust, there is like a lot of extra, there's a lot of things you need to add to that map in order to make that like a functional API. So if you look at Rust, like hash map or B3 map or whatever, uh, there's like, you know, there's a ton of different APIs that are all like some of them are syntactic sugar, some of them are more primitive. Uh, an example is like say the entry API, which if you've, if you've used Rust maps, you might be familiar with the entry API. So that's any API that that's you kind of say, whether an item is occupied or not, and it lets you insert an item. I think it's a, it's a beautiful design, but it is a very, uh, verbose design. And, and so the map library I was writing, and I'll just drop a link to it. It's called, uh, IDQD, uh, this map library had four different maps, right? And so one of the things I was dreading was, okay, oh my god, I need to write like all of these map APIs for different types, right? And that is just like terrifying. So, so it's like, okay, you know, you have a prototype and maybe you have like one of those types, but then you have like these, you know, three other things and eat for each thing you need to go in and like, you know, update the, the map type. And it's just like, it is, um, it would be like a couple weeks of work at least. And it would be like pretty hard for me to justify that work, uh, as opposed to kind of, you know, just like ambling along with the default maps. But then I really also wanted to get this in the hands of my coworkers, because I actually really excited about this pattern. Um, so what I ended up doing was that I ended up handwriting one of the maps. And then I told, uh, I think back in the day, it was like sonnet four dot one or something, right? So this is, you know, we were like a couple, a couple generations before, right? Back in the day of like eight months, right? And so I just told it to kind of replicate, you know, the same APIs across all of the other maps, right? Yeah. And it just nailed it. Right? It's just like, um, it, it, just like, it, it, like, you know, it, like, there were like local differences to things that kind of adapted the map types to those differences. Uh, this was like, I want to see a total of around 20,000 lines of code. Um, then I asked it to generate doc tests and, and you know, like one of the, one of the things you should do for, and if you look at say the rust core types, like, you will see that like every method has a doc test associated with it, right? And so, you know, I, I wanted to get that kind of rigor, right? Where like every method has a doc test associated with it. And I, I don't know about you, but like, I hate writing 5,000 lines of doc tests, right? And I just told the LLAM to do that, right? I kind of, you know, I, I gave it a couple of examples to start with. And I just told Sonnet 4.1, I think, to do that. And, you know, it just kind of replicated that the things that it wrote, like, thousands of lines of doc tests. And, you know, this work that I'd been dreading because it would be like weeks of work, it took me like, I want to say, like, less than a day to get like the whole thing ready, right? So it was three weeks of careful, deep analysis and work and like thinking about unsafe and so on. And then like one day of some, I was talking to someone in Blue Sky about this. And I think they described it as like a pattern amplification machine, where, right? And so, so you give it a pattern. And it just kind of amplifies that pattern into the rest into, you know, whatever, like degree you want, right? There's like, you know, I spent, like, the thing is that before LLAMS, I would have probably, like, I would have, like, investigated like a core generation library. I would have, like, tried out macros or whatever. And all of them have like some downsides. The kind of the LLAMS kind of doing things and, like, tweaking things locally as it went along. And, like, you know, things like for a B3 map, it'll say, like, ordered and for a hash map. It won't say that. Just like, you know, making sure that the documentation is all aligned and everything. It was, like, that was my first experience. And it was, like, a great experience where, like, it wasn't a one shot, but it was like, I want to say, like, maybe, like, five or six prompts total. And it just kind of just nailed it. And so that was my first experience. So about, yeah, a bunch of follow up questions. So that's really interesting. So one, I mean, this is, I mean, this is the kind of tedium that you do kind of, I just think you say about the doc tests. We all know the doc tests are great as a user of something you really appreciate them. Just takes a lot, it takes a lot of time to, like, to get that working correctly. It's really easy when you as a, as a human arc, I mean, like bluntly cutting and pasting, right? As when you are cutting and pasting, it's super easy to make a mistake where it's like, oh, that doc test, by the way, if you've looked at the doc test, like that, actually, you just cut and pasted. You change it in two places, not the third. And so now, like, what you have is kind of nonsense in the test. Like, well, that's, that's not very good. Like, or the test assessing the wrong thing, right? Like the testing the wrong method or testing the wrong structure, whatever. Like, it's so easy to make mistakes here. So easy to make a mistake. Yeah. Yeah. Yeah. Um, it's okay. So another question I have for you, because the other thing is that when you are, I mean, as you say, it's, it's, I've got the pattern. I want you to replicate it. It also makes for a code that's pretty easy for you to review. Are you like, this kind of reminds me of my experience. Like, I pretty much know exactly what I'm expecting here. And I'm going to be able to review this pretty quickly. Rain, one question I've got for you, because one thing that was super surprising for me is like, look, maybe hopefully I'm in a safe space here. Like you, I've got the, the brain that I engage when I'm writing my own software. And I struggle to engage that when I'm reviewing someone else's software. And I try to. And, and the best reviewers, I think, are able to review code as if they themselves are writing it. And I think I, but to me, like, I really have to work on that. And I definitely know when I'm in the like, yeah, yeah, this probably works mode. The brain versus the like, no, no, wait a minute. Like this, like, I need to like, I'm in like doing my checklist before take off. And I like, I'm going to die in this airplane if I don't get the flaps down correctly. So I'm like, and the thing that was super surprising to me is that when I was reviewing Claude's work, I was in that mode of like, I'm writing this myself. And like there, I heightened state of alert, really reviewing things closely, finding some subtle things in the script. Did you find the same when you, when you were reviewing the code that it had written? Um, in this case, I think. So I had, I have, I have the same struggle that, that you do, right? Like where I'm like, you know, when I'm reviewing code, especially when I'm on like looking at GitHub.com, at the, I'm sure we all have our complaints about the GitHub, you know. Yes. Yes. I'm sure, right? Yeah. Like, oh, by the way, like here, let me show you all the trivial stuff, the non-trivial stuff. I don't know. That's a lot of file. That's a lot of wine, Soul of Render. What's some of you that? Too big. Why bother? Why bother, right? Um, so I, yeah, I had a bit of the same experience. I, I feel like I was kind of somewhere in between here where, um, I think much of this depends on how, or at least for me, dependent on how intensely you and the LLM were bearing with each other, right? Yeah, absolutely. So I've had experiences with an LLM. Like, so for this, for this one of an LLM, I just, like, you know, it just was doing its thing and I was not being a huge amount of attention. Uh, and then I ended up like reviewing it and, and, you know, it, it like me, it like maybe two or three mistakes, right? Um, but like also, like, I feel, I felt like, you know, I was pretty assured by the fact that, uh, all the hard bits were kind of handwritten and then, you know, the LLM was just like wrapping those hard bits, right? Um, so it was like, it, it was doing like relatively easy things. Um, there have been other things that I've used the LLM, uh, for, and especially like Opus 4.5 over the holidays. And that's, uh, for those ones, like, I ended up having it like this very intense, like mind-meled bearing session. And like, that felt like, you know, I knew every single line of code and what it was doing. Right? And so I was like, you know, carefully kind of working through things and I was like a wild time. But like, I felt like it depends on kind of the more I end up using it. And so, so, you know, it depends. But I do, you know, like even like the current LLM and, and again, this can change because I know, I know things have advanced so quickly, but even current LLM's have, um, they, they, they do get things wrong or they do things sub optimally or do, they do, they do, they think did do things in a way that's unmaintenable. And you do have to pay attention to that, right? And that is part of the rigor, which is like, okay, like I feel like I have built up some muscles around this from having used it, right? And so I think part of the rigor is also like getting some practice with like looking at LLM code and reviewing it. Yeah, interesting. So the, so in this first use case, you, I've got like, I've got a lot of just TDM that needs to be done. And I do think that I think is really interesting about this case is you're doing something we do a lot, which is like, okay, I've got this problem. I kind of want to solve it in a way that's a little more generic where I, where my, my colleagues can use it and so on. But we always have the tension. We always on the one hand, we always encourage ourselves to, hey, this is a good opportunity to build a new abstraction to think this, but we're also all kind of realist like, yeah, but like, we can't like not ship the next release or what have you because we're kind of focused on, you know, and there's always that balance. And to take this thing that like, oh, this, to reduce the amount of work involved in this by a factor of four, yeah, maybe the difference between doing it and not, you know, we're just straight up, right? Yeah, right. I think I actually suspect David has a few things to say because I know David and I have some, have had some chats about this. But like, for me, like, there are like new vistas that open up. And I think that's the way I think David put it, right? So there are things that were simply not feasible to do given, you know, company priorities and like, personal life stuff going on and like all the different things that are involved in, you know, a human's life that I feel like have opened up, right? And so for me, like, IDDQD actually, like the goal of this library was to increase the amount of rigor in our software. So I think it is very cool that, you know, is able to kind of work on this, right? So this is a way you increase rigor. Is you build an abstraction that increases rigor, even if it is tedious, right? That is an increase in rigor, right? In the overall system. Totally. Yeah. So David, I mean, you were, as rain points out, like, you were among the earliest adopters at Oxen, I think you really shown the light for a lot of us. And, and, you know, showing what these things can and can do, do you want to talk a little bit about your experience of kind of getting into this? Yeah. Yeah. Yeah. I mean, for a long time, I think until this year, really when Cloud Code took off, I was using all of them, this kind of like a fancy search, even before they were really, even before they were actually search engines. And you know, everyone was like, it's not a search engine because you're getting this very lossy picture of what's in the model weights, even then on things that they were trained very well on, which is like what I work on web dev. They were great. Even, you know, just for retrieval. So I was using them a lot for that or, you know, small snippets. This year, I think, is when it really took off that the models could really do more complex autonomous things based on a very small description. And more importantly, I think pull in like what you were talking about where when the Cloud Code is looking at the luminose code that you have on disk, it's pulling in context that it doesn't have. And that's very different from it. Yeah. You know, it's not so much, you know, the typical use case, the typical use is, you know, you ask it a one sentence question. And there's only so much detail that you can get back out of it because there's just not enough texture in the question to tell it what to tell you back. And so like when, you know, I give that the talk about LLM's at ox cond in September. A lot of what I stressed was like the way to set up the problem for yourself is like you want to give it enough so that the answer is in some sense contained in what you give it. And what these agent tools do by just living in a repo and pulling in whatever context they want is like that, they give themselves that texture and context. So that's really what's changed this year from the way I was using it a really long time ago. I was like, I was trying to, you know, I wrote a CLI that lets you pass stuff on standard in and you could dump files into it. But, you know, giving the things the ability to just do that stuff on their own makes things so much easier because you don't have to, you know, manually select a list of files to that's worth looking at. Um, it's one of the things where you kind of, where were you first really beginning to use this to beyond just search what have you really beginning to like, okay, I can actually use this to, I can pair with it as rain was saying. Yeah. The early things, this earlier this year were things like stubbing out, like I would stub out a test. This was, this was before they got good enough to really like, you know, you can tell it the kind of, the shape of the set of tests that you wanted. It'll write 50 tests before that. It was more like, you would write the title of the test and maybe five comments saying the steps of the test and it would fill in, you know, it would still feel great because you'd be saving all this typing of the most tedious kind, you know, make this request, check this, you know, this on the response. That was where it started to feel like it was really helpful and I think it gave some demos of that kind of thing where it's like, you know what you want and you can tell it piece by piece and it will fill it in and it would do a good job. This is kind of what people are talking about, you know, in examples where they, it can follow a pattern really well. Like if you give it one example, you do this thing yourself once and you need to do it five more times, it can follow that pretty well. But more recently, it seems like it's, you know, with Opus 4.5, it's been able to figure that stuff out on its own even without the stubbing out of all the details. One example, the thing that really impressed me when Opus 1 came out was something quite different from, from you guys' examples because it was an example where I'm not an expert. It was specifically something where like it was kind of a pure test of the things ability because I didn't know anything about what I was doing and I was still able to get to a surprising good result and this was debugging crashes in the Ghost D terminal. So I ran into a couple crashes. I've never written a line of Zig. I don't know anything about the Ghost D codebase. I've never looked at a crash dump to my shame as an oxide employee. So, but a few crashes that I wanted to investigate that, you know, there were things that I couldn't find anybody talking about them on the Ghost D GitHub. So I figured they were pretty rare. So I looked into them and I just have Opus essentially figure out, you know, the only thing I really had to do was find the rust port of mini dump stack walk to like look at the crash dump and pointed at the problem and I knew where the crash dump was located on my desk and then from there it basically was able to like look at the code, satically analyze it and find the source of these, I found three different bugs this way. And then these, I was able to write up the bug reports and they were confirmed to be real bugs and fixed and so that was what really unsettled me was that this was an area where I really knew nothing and just using my sort of like sense of what sounds like it makes sense to validate that I wasn't going to be posting AI Slop on the Ghosty GitHub. I was able to come to, you know, three real bug reports without really putting myself putting very much into the process. Yeah, that is wild. And so they are, were they primarily operating on the stack factories or were they stack factories plus was it actually walking data structures and was it actually like meaning. There was no live bugging. I think it was looking at the stack trace and then looking at the code that and, you know, the error that came up and then just sort of thinking about what could have happened in the code to cause the error. Interesting. Yeah, that is interesting. I want to be using them as debugging tools a lot more. And I'm very curious about this use case. So that is, and that is wild. So when you, you submitted the, I mean this great thing about Ghosty being open source and metronautos project is like, you know, I mean, I just say, good on Mitchell, like as obviously does not need to work for the rest of his life has made generational money. And he's writing a TTYM you either. I just think that it's, you know, that's pretty great. I think that is already so far into your stream. But in then making an open source, we was the reception to the actor. He said these were bugs confirmed to be bugs. So it sounds like what if I was legit? Yeah. You know, part of it was that, you know, the bug report itself was even to some extent out of my debt, like a couple of them I was really confident. And then one of them I was like, it sounds really good. But I just wasn't able to, you know, I didn't know enough about how Ghosty worked or how Zigg worked to really evaluate. So I was nervous. But I was, you know, up front with a lot of humility of like, I'm really not sure about this. But I, but it sounds so good that I cannot hold it back. So what's that you talk about the first two where you're like, okay, I don't know any Zigg, but like I'm a software engineer. I know many other programming languages where you were like, okay, I'm pretty sure that I just based on its description and me looking at this code. I'm pretty sure I've got a legit bug here. Could you describe kind of those first two a little bit in terms of like, what did you, what do you mean, you had confidence you could like, I can actually not knowing very much today or knowing only the Zigg I've learned, I think I've got a legit bug here. Yeah, one of them was very simple because it was like a copy paste error where they were just referring to the wrong variable. And you could tell, you know, it was supposed to be graphing bytes and it was hyperlinked bytes, you know, and you could tell that that was, so it was like, okay, that sounds pretty, pretty straightforward. Another one. This was like two months ago. So I can't go. Yeah, two months ago, being several, yeah, years ago, especially in. You had a really complicated one was that, you know, something, it was a mutex lock that was like not being taken at the right time. And so there was like a conflict. And so, you know, reasoning about that was pretty tough for me, not understanding how the code worked. But it was pretty impressive that the model was able to see it, you know, like, this is where you should have taken a lock and you didn't. Yeah, okay. So another thing that I think is really interesting is the, and then so Mitchell himself replied to on you, you've linked all the issues in the chat. So obviously people can get those. I think one of the things that I really like about this, David, is that like, you lead off by saying like, look, this is, I've been using cloud code with Opus 450 and this is a very upfront with, hey, I, this is an LLM has done the work here as a way of like saying, I'm not, I like, someone is else is going to need to look at this, who's got greater domain expertise. Yeah, well, this is worth, yeah, it's worth looking at and go see specifically. They have a very, they have a quite clear LLM disclosure policy. So Mitchell has been pretty open that he uses LLMs tooling, but he also has, they really want a print disclosure. Yeah. So they made it easy by telling me exactly what to do. That's right. I was more worried about sort of the embarrassment if my issue was fake for me to be like one of those guys posting issues that are fake that the LLM told them, you know, was a bug. Yeah. Well, and the, but, you know, you, you obviously quadruple checked all this stuff and it looks like you had, so I said, so this experience, as you said, was, I mean, like the way you say it was like unsettling. When you describe it as unsettling, why was it unsettling? Yeah, well, I thought this was such a clear cut case where it was obviously not my expertise that was operative here because I didn't have any. You know, I have, like, there was a high level, like I could tell that it felt legitimate. And there were, I think there may have been one or two things where it came up with something that I, that I was like, that doesn't sound real. But, you know, the amount of guidance that I actually provided in the process was a, was a very small proportion of what actually took place. That was what I think felt unsettling about it. And, you know, the guidance that I did provide also didn't fulfill, you know, that ineffable human taste that people love to attribute to themselves. It really wasn't that it was like finding that the rust port of the, of the stack trace, you know, symbolicator, whatever. Right. Right. When I do love the fact, you know, like I'm actually even a little bit embarrassed, you say, and you're, these issues that you're like, I, I, but it's also kind of like, what else does it do? Like this thing crashed, like, I'm just supposed to like not give someone the feedback that this thing has crashed and I've got like, or am I supposed to just like sling an issue in there with, I mean, it's like, it just feels like you're being actually helpful to the project. Um, right. Well, if it had turned out to be fake, I wouldn't have been reacting to it. But if my diagnosis was wrong, then that was just creating work for them. Um, so it hinges, uh, pretty tightly on, on the fact that they were legit. Yeah. Yeah. And that, it was okay. So I think it goes to, you know, we've, we've talked a bit about artifact 76 where we can talk about our own LLM thinking at Oxide and it just goes to that like having empathy for the person that's going to read this and the, the making sure that, in this case, really contextualizing it. Um, but also like, it sounds like you're, you're doing your own checking to make sure that the degree that you can. So, um, yeah, it's interesting. Yeah. A lot of these, sort of attributes, or these qualities that we attribute to LLM generated code are all things that as we're talking about, like, I've associated with other colleagues. I'll just, I'll provide an example. I just mean when you're doing a code review, Brian, I think my guess is like the degree of scrutiny that you feel yourself applying may change depending on where that code came from. Like, it certainly does for me. And that not so much at Oxide, but like, when I was at Sun, there were sometimes to get a code review of like, I really need to imagine what I would have been like to write this so that I know what I'm looking for. In other cases, you're like, well, there's some code and there's some tests and I'll, I'll look around, but, um, you know, a lot of the thinking has probably already been done. Well, you know, on that, like, for my, you're exactly right. And like, I mean, this, oh, look, I'm just ashamed to say it, but I'm going to say it. Like the, the way I would review code from like a nemesis, you know, a nemesis integrates code and you're like, I am going to, I'm going to get my now. And I'm like, one of the things I really guys I needed to do was for my own self review and for reviewing people that were not my nemesis, I needed to like channel that dark part of my brain. It's like, I'm going to, I'm going to find this thing in here. And that's like, I mean, it's embarrassing to say, but it's definitely true. Yeah. Well, I do that because, uh, for, you know, I'm reviewing someone who I consider a friend and I want to do them the service of helping them with their code, but I guess we're just motivated differently. That's fine. Yeah. Okay. Okay. Are you, if you're just trying to explain away a lot of the code of your kick comments, a very good code of your comments, you good, I mean, feels like a comments you'd give a nemesis, but that's right. Okay. One man's nemesis is another man's friend. Um, there you go. Oh, uh, but and then, you know, David, as you're, as you're describing, you know, like, you don't want to file a crap bug report. Like, man, have I seen some crap bug reports where, you know, people take you on this wild ride through a core file and you end up just nowhere. You're like, I, okay, I'm following, but like, all of this is just blathered. Like, you don't need an LLM to hallucinate. Like, we've been doing that. Yes. Uh, and we've seen these bug reports where you're like, okay, like, you have, there's certainly a lot of information here, but you've actually not contributed. Uh, so that seemed that empathy you're talking about is it's so at the core of, of, of, of engineering, full stop, irrespective of the tools we're using. Yeah. No, that's a very good point. And it is really infuriating to see, like a bad, you know, AI bug report, like, I'm probably more optimistic than most people at about LLMs. And I think part of that is just like working at Oxide and I don't really see anybody doing the pathological things that I, that we hear about online. You know, everybody's so, um, careful and serious at Oxide. So I wonder, I worry that I'm biased, um, toward optimism because I'm not seeing the, like, the median user of these tools. Um, but then, you know, I see one example. I get one bug report on a, on a repel that I'm actually familiar with. I'm like, forget it. Throw these out. We're done. Yeah, but I bet at Adam's point, like, I don't like that when you get bogus bug reports without LLMs, either. I mean, when you get or, yeah, bogus PRs, yeah, but it's easier to write off all of humanity. Like, you can write, get rid of LLMs. I guess it's more limiting. Yeah. Yeah, absolutely. But I do think that, you know, you get people are like, and we definitely have this happen where we will make things that are, that we are open sourcing, not making a big deal out of it. We're not trying to create a community out of it. We're just open sourcing kind of hygienically. And then someone will come along with a, kind of like, Spurious PR to change things. We're like, no, sorry. No, it's like not LLMs. And this is in the pre LLM age. And we're like, no, no, this is sorry. This is actually not helpful. So Adam, just to your point that like the, the lack of empathy is, is, is definitely tried by PRing is not new as someone's pointing out the trend. I think the difference, though, is that, you know, like LLMs will like, do amplify that problem, right? Like, you know, you can kind of get, I was talking about this with someone like, you can get something that is not great by in like a few minutes, as opposed to maybe a few. You're so spot on it. And I think we, my experience has been like a unproductive, like not empathetic. A colleague, like, that's fine. Like, if I can run faster than you, I can keep up. Like, I'm going to, like, you're not going to outrun me. I don't need to, like, worry about kind of diverting you in the wrong places. A highly productive, unepithetic, careless colleague. Like, that's what takes one day to take 150% of my effort, just to, like, keep them from doing harm in your right range. That like, it takes that formerly plotting, you know, colleague who you had, or, or, or, or collaborator, who you had to, like, keep on the rails. It keeps it much harder to steer them. Yeah. Yeah. Um, it's like a gish gallop, almost, like, I feel like that's, that's how I think about it, right? Where it's like a gish gallop for issues. Um, I've luckily not faced, um, too many, like, crap bug reports. I've seen some AI bug reports, but they've all been, like, very high quality. So, you know, kind of at the standard that, like, I think, I would expect myself to write a bug report. So again, like, I am biased towards optimism here. But it is something I've worried about. Like, I do look at people just, you know, putting up garbage. And it's like, okay, well, uh, it's, it's now harder to filter out garbage. Or, or, you know, I have to say on the flip side, I think I've done is I've used Opus 4.5 and fed it a bug report and told it to tell me whether this bug report is real or not. So, uh, yeah. So that's, that's, you know, maybe that's the way to keep up. It's like, it's like some open source Jeffens paradox or whatever. Like, there's no money involved here, but I just mean the, the cost of creating PRs and projects and all of these things has dropped so much that the volume has just accelerated. Well, I think I also do think that with these open source projects, especially, I mean, you know, God bless small communities where you got, I mean, it's like, I mean, I, I would be almost like intrigued by someone who's like, I'm going to use an LLM to file a bunch of bugs against alumas. You're like, that's weird. I mean, that's like, that's not a, uh, versus like, talk to someone about that. Yeah. Yeah. I mean, like, I'm almost like, I'm almost like not opposed. That's, that's a very, okay, um, versus like a project. I mean, we saw this with node where, you know, I've been in very, very large projects with many, many, many contributors and very small projects. And there's a lot to be said about being in a small project, uh, and a lot to be said about a project that doesn't attract as much attention because it doesn't attract as much of that kind of negative attention either. Uh, so there's, uh, there are, I think this problem is, I'm sure there are, uh, there, there are some high-profile repos for whom this problem is really, really acute and, you know, maybe that was that way with, with Ghosty and Mitchell. But for a lot of the stuff, at least I work in, it's, it's not right, an acute problem. Yeah. I've been surprised that the tooling for maintainers hasn't been able to keep up. I mean, you can expect some lag, right? There's the, you, the volume of, of garbage has to balloon for a bit before it becomes such a big problem that people are incentivized to put some work into solving it. But, um, I think one of the things we're going to see in the next few months is maintainers more openly using LLM tooling to, like, cut through that, uh, more ass of, of, of AI bug reports and, uh, AI and for, and for Cotervu too. I mean, I think just like it is, for Cotervu is, I mean, honestly, like my eye opening moment with respect to LLMs and software engineering was on oxide friends when we had a listener who had access to GPT-4 when I did not have it. And I, Adam, for some reason, I can't even remember, and, and you know, this, you have to figure out exactly when this was. I guess it's a little harder to ring the chime for an episode that I can't, I can't, I can't record more, more, more, more, yeah, yeah, you just rang it. Exactly. Give, give, give the people on YouTube something to complain about. Um, but we, um, and I'll go back and find the episode. But the thing that was really interesting is I had had like a PR that day that I was, I linked to, and someone dropped in a GPT-4 Cotervu of that PR. And I'm like, wow, this is not, all wrong. Like this is not also not great. But this is definitely not like garbage. The, the, the comments that it has. And that was a long time ago with respect to LLMs. Um, and I, I mean, Cotervu, it just feels like the opportunity for Cotervu is really rich. And they have to your point of like not really giving like why don't maintainers not have, uh, you would, you would, and maybe they do and I'm missing it about like, it just doesn't feel like GitHub is providing it. Anyway, why am I doing this? Of course. Diff, too large to show. Yeah. You definitely liked it to be built into GitHub pretty soon. I mean, there are tools like graphite code, grab it. I mean, but that's kind of what started me on this. I saw someone, you know, praising this, this tool graphite, which does look really nice, um, online. And it's like 20 bucks a month to see it. I'm like, wait, 20 bucks a month to see it. I can write that in a script. So it's like, so I wrote a script that pulls the diff, the comments, um, the PR body, um, and just feeds into an LM just as review this. And, you know, you have downsides there where you're, you know, a lot of times there's additional context that's not in the diff. Like if you're using something that is imported in the code already, the import is not in the diff. So it's going to say, are you sure you're importing this? It doesn't know that the test pass doesn't know that CI passes, um, but you can get quite a lot that way. You know, it can find it, you know, a mismatch between your SQL migration and your main DB and it SQL. I can find inconsistencies really well and inconsistencies even between like your human readable stuff like your PR description and the actual code. There's a lot you can do there, um, even without what we now have, which is like the tools that can go and vacuum up anything that they need to, and to, um, validate their hypotheses about why the PR is broken with cloud code, it can write a new test that validates that the code has written doesn't do something. Um, you said there's a lot of low hating fruit there that we're not, we're not really touching at all. On the topic of low hating fruit, I think my nemesis on GitHub is stalebot, right? Like I hit some real bug. I feel like LLMs could slay stalebot, you know, the like, well, this bug is six weeks old. So I guess nobody really has it or whatever. It's like, nope, there's a crash dump and a court and a stack trace and a bunch of information. Yes. And at least helping to weed through that so that you can sort of deter maybe neuter or stalebot a little better or make sure you keep around the things that like refer to real problems with sufficient data to diagnose them or maybe diagnose them autonomously. But, um, you know, so a lot of the work that, you know, I think there's a theme here, but I'll work that just doesn't get done that could get done. Uh, and in some cases, maybe doesn't need the highest level of sophistication to complete, you know, those are great tasks. Got Adam, you are so right. And God, I hate stalebot with the white, hot passion of 10,000 sons. I stalebot is such an indictment. Uh, I mean, like we don't talk about stalebot enough. We know, we like, for all of you to crying the future, look into the past stalebot is, I mean, stalebot is everything wrong because I mean, it is just like, oh, well, no one has seen this issue in six weeks. So we're closing it. How does, what, how does that make sense? That doesn't make sense. We have dumpster on Facebook, by the way, I know Facebook has an external ill-white and then someone does an external version. And I mean, it's the Facebook culture. Like, it is exactly the kind of thing that you would expect Facebook to make. And so, you know, move fast and leave broken things around. Yeah, move fast and close out bugs that haven't had any activity in the last 48 hours. It is also so gross because like, but no, no, I mean, look, I mean, the dashboard green. It's like, yeah. So I mean, we're right. I haven't even thought about what this means for stalebot. I stalebot, you are a marked bot. I hope LOMs, because that's a great point of just like, if nothing else, I'm sorry. If like, if we get rid of stalebot, it was worth it all I gotta say is you're going to be up to like four in the morning, five coatings like the Joker of stalebot, you know, just trail stalebot around like reopening and fixing bugs that it's trying to close. I actually have an example of a bug that I feel like I would have just ignored in the past, but had a much better time with Opus 4.5. And so, this is a bug on, you know, on cargo next test, which is a personal project. And on the bug, it's titled 6TTOU when test spawns interactive shell. Now, if you spend any time on this stuff, you're like eyes, my eyes glazed over pretty much, right? And so it's like, okay, you know, this person actually did a nice investigation with Claude and kind of posted this and said that they, I've worked with Claude to get good attribution for this under reproduction. It rose towards below, but I stand behind that, right? And so it was like a pretty well written issue, but, you know, it's the sort of thing that I really would want to dive into like, you know, it kind of gave an example of like, you know, this is used by all these other projects. And so you should do this thing as well. And it is like, it is one of those, you know, things where like, okay, you got to spend like a whole day like investigating what the other projects do and how it fits and like, you know, really getting to the root of the problem, right? And I'm like pretty lazy generally. And I'm like, I don't want to do that. And so, you know, I'm like, I would either do a half-ass thing. And honestly, in the past, I would just do what, you know, what the suggested fix was, right? It turns out that the suggested fix is actually like, woefully incomplete, which is, you know, which is where, like, I feel like, you know, I kind of gave this to Opus 4.5. And so, you know, one of the things that said is that like, lessen them, and a few other projects follow this pattern, right? So I actually gave it the less source code. And I gave it the VIM source code. And I gave it the source code to like a bunch of other things. And I was like, okay, like, pick into this like, what do these projects do? And so this kind of comes back to the, you know, asking questions of code bases you're familiar with. And so, you know, I did that, right? I had no idea about the less code base. I had no idea about the VIM code base or anything. And so it spent like 10 minutes or so. And it actually like, you know, wrote up a nice summary of like, here is what all the projects do and so on, right? And then I, you know, I kind of, you know, I was like, okay, you know, this makes sense. And then, you know, I tried that. And, and so, you know, it was like an interesting, like, it took me like maybe two or three hours to do. And the final fix for that was like, pretty small. It was like 130 lines of code or so. But like, it was great because like, you know, we, we tried the first thing, right? We tried the suggested fix. I, you know, the LLM did the work and the LLM kind of, you know, wrote the test, which is its own, annoying and junky in its own way. And then, you know, I kind of tried that. I, I like, talked for a little bit. I found that, okay, this isn't complete in various ways. And then, you know, we iterated a few times. And so there are so many places along this path where pre-LLM's I would just drop down and really like, ah, this sucks. I don't want to deal with this. You know, I'm done for the day or something, right? Wait. And totally, like, when you do that, like, you're going to kind of take one of two things. It's going to be like, oh, I'll just take this kind of like mediocre fix. Or it's going to be the like, maybe I'll just let Stalebot finish this one off. I don't have to kill it. I'll just wait. But I mean, even this title reign, like, Sig TT, oh, you, okay, fine. TTY out. No, you got to, like, the Q, like, Antique's wrote show, you got to be like, okay, like, I'm now going to go into like, POSIX signal semantics from, I mean, and then you're like, when tests spawns interactive shell. It's like, well, here's a thought. Don't do that. Don't do that. Yeah, no, seriously. Yeah, but, but the, yeah, it makes it attainable. And you make it, makes you get past the, like, have you tried not doing that? I don't know. That sounds like a dumb test. Okay. And so, and then this, the thing, and I do think like, this is a really important point, because then, okay, so you, you pick this up now properly, because it's easier. We've lowered the, the friction. You actually get this completely fixed. Getting this fixed makes next test more robust. It makes it more rigorous. Like, you've actually, like, I mean, on the wedding, it's like, okay, really? I mean, as you say, Adam, like, maybe don't spawn interaction. Like, hey, actually, no, now you can, though, you know what I mean? And I think that, like, I just see this in lots and lots of places where we are going to make our infrastructure actually more robust because we can now go pick up a bunch of work that we just weren't going to get to realistically. We, the people who work on this lower level infrastructure, we're not going to get to. Yeah. So I have an example of some, some work that I got to finally. I, I, I mean, Reign described herself as lazy. Reign, I offer this counter, like, I think you're kind of bringing a knife to a gunfight here. But out lazy, Adam, will you? Yeah. Oh boy. Cause I mean, you know, that's like, I have been wanting to do an open API diff library. Since before you joined, I'm sure I've been like talking up this vaporware of like, and, and I made multiple earnest attempts at starting it. And it was just, it's just one of these pieces of code that's like, there's no good way to do it. All the ways to do it are gross and boring and stupid. And actually, it doesn't even, if this is not like your case that code running in privilege mode or whatever, this is some code that like, if it segvies, like if it reboots the machine somehow, like, it's fine. I don't know. Like, it's just not that high stakes. It's very low stakes. Yeah. And the thing that got me across the line was, you know, I started using some of the open API, open API, excuse me, open AI models in VS code. And mostly using it just through the lens of a very smart completion. And it allowed me to kind of repeat this pattern and that I was, that I wanted to use to make sure I wasn't forgetting to compare certain things. And as rain was saying, absent this, I would have like written some code to write code. I would have, you know, written some girl script or something stupid to output a bunch of code or use a proc mac or something like that. But my, my real, so that was great. And I actually got the thing working. And it was really fun to build my real breakthrough was then it was coming to demo day. And I want to show it off. And this is a library. So there's not like a front end to this thing. So it's like, okay, I'll write a little CI tool. And literally all I wrote was function main, open a comment said parse the first two command line arguments. And literally the rest of the program I just had, tab completed. It's like, I think this is, it figured out this is probably the program you want to write. And I had to fix a couple little things here and there. But it was very eye opening. And, and then that became my demo in addition to the actual library built, but was like the live coding, the live, I guess coding of just heading to I've been watching it do the thing that it inferred I wanted to do. So I would argue, Adam, that you have embodied all three of Larry Wall's famous virtues of a programmer that your, if you've shown your laziness, your impatience, and your hubris in a stroke. The, but actually, but this point of laziness is very important because we all know, and we kind of speak about euphemistically as laziness, but we all know that like a hallmark of, of good software engineering is coming up with powerful abstractions. And when you are kind of repeating code multiple times, that part of your brain is like, ah, this is not the right abstraction. And because Adam, both you and Rain mentioned like, ah, I would have made this a prock macro or I would have done something. Yeah. Where because like, I think we like over index on that, where we're like, he did this whole like the dry thing that do not repeat yourself, where you become so over indexed on it that you then do things that are actually either generating some off the more the facts, or it's like, there are times where it's just like, actually, it's just not that big of a deal to have code that is like similar, but slightly different in three places. Like, it's okay. We're all going to live. But we really resist doing that. And LMS make it easier to kind of do that. One of the things that annoys me the most. And you know, I'm very, very grateful to the Rust open source community, right? And this is just to qualify that this is nothing that's not going to be negative at all, right? The open source or community. But one of the things that really annoys me is like, you know, in like the rust stock, you click on the source link, right? And the source link leads you to like a macro definition. Yeah. You need that for like, even for like the in the standard library, there's a few examples with like the integer types. So you can actually like, for example, you want to see like the next power of two implementation, which is like, I mean, you know, it's a bit manipulation thing. I want to look at that, right? You click on it and it doesn't show you that. And it's like really sucks. And I hate it. So I kind of have made it a point in my libraries that I would much rather copy this code just so that you can click through the source link and you can get it, right? And so, you know, and so macros are just like, you know, they don't work with that. And but the DR that don't repeat yourself is to use a macro. So it's like, OK, well, LMS actually do provide a better solution to that. Yeah. I've been thinking a lot about this because like if you think about where our intuitions come from about what is worth abstracting or like what is too much repetition, they're so tied up with the expected reader of the code, whether that's like ourselves or the people that we know, like they're they're they're tied in very, very tightly with our intuitions about what people can handle and what's reasonable to expect of other people. And what is reasonable to expect of an LLM is radically different from what is reasonable to expect of other people. And so like the amount of repetition that that is tolerable and code base or is manageable is seems to me like what may way higher and it's not just in a code base like we were thinking about API design API response shapes earlier and we with I was working with Adam on this that we we aired on the side of making a response shape like more flat and less nested even though we lost a little bit of type information that way just because the flat one was a little easier to read and the type information we decided was not really worth it keeping in that particular case. But I think when you assume that future developers will have LMS at their disposal, I think that it must tilt the calculus toward encoding more type information at the expense of readability because that type information is what is going to keep LMS on the rails in the future. It's like you know all the good practices like make in valid states 100% full and all of those things. It turns out that all of that actually helps LLM's a lot too. Is there anything like it does is to Russ do LLMs like rust? I know that's a weird kind of question. But I've wondered that if the the things that we appreciate about it in terms of like not being able to like represent in valid states and so forth, if that is a useful property when LLMs are constructing code. I mean I feel we said this when we again ring the time for unknown episode, but I feel we we said this when we first started talking about LLMs and rust that like actually rust is going to be a really good fit for these things because you get the it. I mean rust I'm something I've said from the beginning that rust shifts the cognitive load to the developer in development and it forces the developer in development to consider a lot of issues that historically you wouldn't see until some code is deployed into production and I loved that shift. I think that shift is really important. I think that like that tax right into what LLMs can do and I think that it's that they reinforce one another so I think like LLMs I think and rust are a very good fit for one another. It's what I don't think it's that hard to take. I don't think of that that that's that's spicy and just say like more you know if a more elaborate type system will let's let's you put more of that work in up front to sort of constrain the program further you could say that LLMs like allow you to tolerate an even more elaborate type system like maybe now dependent types are going to be feasible to for people to learn and work with maybe easy address like like you know take like we'll it like if there's a diesel error like it'll be able to understand what it means easy easy easy we're not like listen we're not living in that kind of a future yet. Yeah artificial super intelligence required for that. No I think the ASI is going to be like I have actually I actually don't know what this that or message I can't make sense of this thing. It's like it's like two K long yeah that that is really interesting when I just think it's in general having the great type information I mean the code that I would be scared that to me would scare me the most would be just like a pure job of script. I know a general it's a lot of it but we used TypeScript. I mean David crypto wrong week we used TypeScript from Ross and anything everything it would really terrify me to use because it's just so easy to have an issue that doesn't show up until you get into runtime. So my blog is uses a static site generator written in JavaScript and I and I don't really know JavaScript. I mean like I know I can hum a few bars but but that's kind of it and I used LLM a lot to sort of get things the way I wanted them and part of it is like I don't give a shit right like it's a static it's gonna generate it statically and there's some like run time edge condition I need to consider so it's like yeah go for it. So I just be in in some cases like it's gonna be depending on the context you know think that and I think that may be true in many JavaScript context and that's why in the cases where people are writing frontend code and they have additional rigor they want to apply they're using TypeScript or use more robust languages yeah yeah just to defend the JavaScript world a little bit I think the spectrum of you know rigor that you might need it it applies in a lot of different situations like you might make a one-off rust CLI as a debugging tool in that same situation like you can tell if it works by running it you know the sort of the depth of static analysis you don't really need that because you run the thing and it does what you want and you can tell that it worked you know so there's a lot of situations I think that's kind of an underrated point that you know people assume that's all or nothing that the code needs to be perfect or it doesn't work at all which is like ridiculous yeah you know our most rigorous engineering code is still going to have some bugs in it so obviously there's sort of a spectrum of amount of bugs that we can tolerate or amount you know of leeway that we have yeah yeah that's fair um range you want to talk about some of your more recent experiments with LM's because you've really kind of gone non-linear with some of the things that you've been and I think in particular well because like I mean getting past the like okay these things are kind of experimental and getting into the like no no like actually we're gonna at some level we're going to I mean I I don't want to say assume them because we're not really assuming them but we're um but we kind of acknowledge that like these things can actually um it can be used as part of software engineering would you want to describe some of the things that you've done recently yeah so um this is kind of a project that uh you know kind of a bunch of us were discussing and I decided to take on some time around early December and and so the project here is that you know we as as some of I'm sure some listeners may have heard of like we have done a lot of work in building automated update for our system right so we have you know the self-service update uh thing now um and one of the things it has to cope with is the fact that you know you're not going to be able to update everything atomically right you're not taking the entire system down and back up again and so you need to deal with um you you need to deal with like how do you or kind of you know like manage this and like this kind of skew while an update is happening so you know like my colleague Dave Fitchico kind of has done this like genuinely brilliant uh design where like you know there's kind of the server side API's which is the idea is that this is an API that can talk to multiple versions of clients and so you know you update the server first and you have like this dag of tendencies that you update it's just like this you know really well constructed system it's pretty great right um so one of the issues we'd ran into is that as we gained experience with the system we were having trouble figuring out how like you know you have all these different versions and so you have like a type right and that type and like has the same name but it has different like fields for example or like you know maybe maybe one of the subfields is different and so um how do you actually like store those in the repo right like and and it sounds like a simple problem for this actually blows up and comes like this incredibly complicated problem with many many many different factors involved so you know kind of I did again like this is one of those things where it's like this combination of human and LLM work where like kind of you know I spent a bunch of time um you know prototyping a bunch of things and like you know kind of coming up with a with with like you know an approach that works and that satisfies all of the hard constraints and like also as many of the soft constraints as we can and and so you know this was like a lot of work and then um one of the one of the interesting things that I found really useful for LLM is that what I did was I ended up essentially like compiling the set of of things that you know the final state we want to get to and like writing it out as a set of instructions that both a human and an LLM can follow and so in this guide that I dropped a link to this is rft 619 and in this guide it is in section 5.1 and so this 5.1 is kind of this initial migration right and so again like you know spent like a couple weeks working on this on like this whole rft and then what I did was like okay you know I'm like I just kind of fed this guide into the LLM and you know I told it to like migrate a small repo right one of this one of our smaller APIs and it just did that in one shot so this was like you know not a very big API it just did that right um I found that okay there were a few things that was unsatisfied but so I went back and like changed the guide update at the guide I kind of started from scratch so you know I like iterated on it I want to say like overall like this guide kind of went through maybe a couple dozen iterations of like me looking at the LLM output and being like okay you know this this is great or this is not good and so on and and you know kind of basically ended up converging on something that is like this clear very reproducible set of instructions that are simply way too complicated to capture in any deterministic algorithm right so this is like you know the there's like enough judgment here and it's just like this really complicated set of things that I mean you know there's no way I can write like a migration tool to do this I mean maybe someone smart and you can do that I I don't think I can but what the LLM let me do is it kind of again like let me like design this guide once and then you know apply it like everywhere so it was funny because like there's one morning where I just like rapidly put up three PRs where like you know the first one was like a thousand lines of good the second one was two thousand lines of good and the third one was three thousand lines of good and I got like all three of those done in like an hour and that was just wild like you know and this is like one of those things where like it turns out that LLMs are really really good at following instructions that are like you know clearly written and are written in a way that you know the LLM kind of works well with so either like this is again one of those things where like it sounds like so like you know mid priority right it's like how are we going to you know migrate like 40 thousand lines of good and like rearrange the types right this is the kind of thing that just falls you know people just don't do or like we might do it in the future and there's this long migration period or like you know this is the kind of thing that we do in like tech that week but this would be more like tech that month right but like you know and LLM just like as I said it just nailed three different APIs in like one hour and that was just like it just blew my mind is like oh you can you can spend two weeks carefully designing a thing and then just have the LLM just like repeat that pattern over and over again it was also really helpful for like the process of iterating on the guide itself because like I would just like you know it's like if there's something I'm not satisfied with or like you know maybe when we want our coworkers had some feedback on something you know I could like very quickly like update the guide right and then I would be like okay run like jager diff on you know the changes that I made and like replicate those changes into you know this like prototype that we were working on and it just like did that and it was amazing like it was one of those like wow you just you could just you could just do that something people have mentioned the chat and we haven't talked about too much is that you know something that really helps the LLM's in these kinds of loops is they have a signal like a verification signal that can tell them like when they're done and how far away they are from it and like types passing obviously test passing is one of those things but I'm curious like how you think of what the verification signal is to the LLM as it's doing this like is it just does it satisfy these plain these you know natural language requirements so uh so this is uh yeah this this is an interesting question right so in this case you know we kind of had like a couple of hard verification signals so so the first one was just that you know what would you describe which is like you know like the code compiles right that that is kind of the most fundamental requirement and then the test box and we have a lot of deterministic validation in fact a bunch of this actually uses the work Adam was describing on like comparing being able to compare open API documents to make sure that if there are changes those changes are only trivial once and so you know we put a lot of work into that and so having all that deterministic validation was really helpful um what I ended up doing for for you know some of the more like the fuzzier signals here was that I basically kind of you know after kind of did this work I would like start a new context window I would feed the diet again and I would ask you to carefully review the um you know the the the current the art for conformance right and it's like who the hell wrote this this is like and so that ended up finding you know a bunch of degrees of freedom which some of which I wanted and some of which I didn't but that was like that was a good experience I would just do that like two or three times and and then you know obviously I would go through and manually review and make sure that you know everything kind of aligned um but again like that felt like a very quick process because you know I was just I was just able to like you know maybe like spend five minutes doing the migration and then another five minutes reviewing it and that was it right this wild and I mean this is kind of a just a much more elaborate example of really you're the the IDD QD example that you had that where like look I've done this once I need you to kind of do it in these subtly different but important ways that are kind of tedious I mean this is just a a in many ways a much more elaborate version of that where it's like okay this is the the we designed this RFD very deliberately with a lot of engineering has gone into wake the way we think about doing this and we have that has come out from actually like doing it by hand and so on for a couple and now we actually need to be like kind of knock this out for a bunch of these different services. At someone in chat described it as like using English as a programming language and yeah I mean that this is basically like you know using English as a programming language for programs that are just too hard to write in a deterministic like computer language and and that's what it felt like doing and and I think it's actually you know it's it's kind of remarkable like these are the kinds of things that you would absolutely have humans do before you know before before the advent of this stuff or not you are I mean like they like they mean just to your point it's like the work that is like it's just though the work is just like not done and you have been like someone's like hey I was in this service and it has a different like what's going on over here it's like oh we just haven't gotten to that one yet and go into our this dashboard from two years ago and we're waiting for the next you know and you I mean tech debt week just like oh my god I can I kind of feel like my the tech debt flu coming on protect that week so and like and for me like you know I think there's there's a way David put it that was really memorable like a court like that uses like Lums extensively had better be the best freaking court on the planet right like if you're if you're doing this like you like all your like code should be extremely tight you know you should like your you should like put all the work into refactoring like good documentation like all of these things that I think you know many of us feel like are are you know maybe maybe kind of slip down our priority list there it is very helpful to think of these tools as not ways to improve the velocity of what you do but ways to improve the quality of what you do and so I'm like you know if there is one thing that I think I want people to take away it is like slow down right like don't just like you know spit out as much code as possible instead like use the LLM right which is a tool there to be like okay you know maybe let's refactor this maybe let's you know split this up like there's so many things you can do to improve code quality along the way that will lead you to higher code quality then you would be able to do it in the same amount of time right rain I just cannot emphasize enough how important it is that if you're listening to this is a podcast where you like please go back and re-listen to what range has said because I think this is so important and I think it is so important to realize that you've got this power now to go deliver a higher quality artifact like yes the world emphasizes like the the the the velocity which in term that I again don't like because it makes us also like projectiles but the this is what it allows us to do is do things that we simply never would have gotten to before that allow for more rigorous artifacts and I think that you can make an argument that that the world that the software rewrite is going to kind of bifurcate Adam some of it is going to be your job as script in your aesthetics I generator which which to quote your own language back to you you quote do not give a shit about my yeah correct and but then in order for like underneath that is now these rigorous artifacts that we actually in a world where we're doing much more software we actually need these rigorous artifacts to actually work much better and you know I think that like because I mean I and I think this is like with it the I for this is like the fossil time hour Gen X fossil time hour where I would maybe we can knock down some things on people's bingo cards but when you talk like software in the 90s sucked and operating systems had bugs that you would hit frequently compilers had bugs that you would hit frequently and the I mean what ultimately like the day I put C++ down is because I was dealing with two different compiler bugs simultaneously and just like the end of getting basically random results I just and that was common in the 90s and man like go go go go have a compiler bug to really like take the wind out of your sales let alone two of them we and we needed to get to a world where we had open sort of artifacts that we could make much higher quality and the quality of software went way way way up as a result we could do more of that and I mean I point why see that happening vividly here yeah no I think I think you're right that that you know the reason why I don't care about the call my blog is like yeah that that that's not a foundation on which I'm going to build you know decades worth of technical innovation that's like yes one and done and I think there's lots of software that kind of fits that model and I think that's where you kind of get the slop you know a slop where pejorative term but for some of this code and like it's sort of fine like if you're if you're building something that is a one off it is associated with like some time and place and whatever fine like whatever I don't know and yeah there's gonna be a lot more of it and that's frustrating but on the other hand for this stuff that is foundational that has always been rigorous and the rigor is increasing this becomes a lever by which the rig or continues to increase yeah I mean for me it's just like I've there's so many things that I feel like I've been able to do with this to increase rigor like my interest like I've you know I've got it a couple of things here and there but like my interest as a professional is really focusing on rigor and my background is in DevTools where like correctness is like absolutely essential and non-negotiable and for me it's like okay you know there's so many more tests that I'm writing now like I you know the other day I was like I want to learn how to use Connie right which is you know this model checker for rust and I wanted to use that right and I'm like I there's always been this activation energy we have to go read the documentation and stuff and so what I instead ended up doing of this is that you know I took an existing project that I had which I felt like was a good fit for Connie and and I just asked plot opposite five to hey like you know come up with a few properties that we can in verify that way and it just did that and I'm like now I understand how this stuff works and what the limitations are and stuff and just like like there are so many ways you can kind of use this stuff to go like increase the level of rigor in software and honestly it really bothers me that the dominant narrative is the whole like slop white good stuff right because like or infrastructure engineers there's so much more you can get out of it yeah but is that is that always been the case for the kinds of code that we care about rain that like you know one of the things that's beautiful about oxide is we go to a demo day where you know we show off you know rain you show off this 30,000 line change or whatever or I show off like this library that compares one thing to another thing and it's like people are hooding and hollering as opposed to you know systems demos are traditionally seen as boring and the thing that's wizzy is when you know you can demos something cool and graphical and whatever and you know rigorous is not to everyone have the same kind of sex appeal yeah totally although I think and raining but you're also right about the dominant narrative and I was trying to think about I mean because it clearly it is truly a dominant narrative and that it's dominating kind of everything and Adam I was trying to think back in terms of our careers when if you had these kind of like big narratives where it feels like it's reductive you know one thing I was thinking about was the rise of Java was that way where the rise of Java was really self-cating because there was this idea and it's like very different so I don't want to be too reductive here but with the rise of Java there was this idea of it's like it's the end of every other programming language like this is this is what we're going to do and it this is kind of crazy to think about that the because this is the yes I mean right it is it's like it's like it's it's it's it's it's humorous now but it was at the time there was this idea that everything's going to be a Java we're going to do the operating system Java the microprocessors are going to execute Java bytecode we are lit and I mean at Sun at the time it was really it was like I know this is not right and I think Java is like really powerful and important and it's going to allow many more people to write software and I remember thinking at the time like well at least it's the death of C++ but what it took a while for people and some like some failed experiments right it took it took nano Java and pico Java inside of sun and a bunch of light and two different OS is inside of inside a inside of sun running Java so there were a bunch of like where we got and then people were like okay no this thing is like it's important and it has a role but it's not everything and it wasn't just all languages it was operating systems and operating environments yes right it was like the right once run anywhere meant right you don't have to worry about the details of Mac and Windows and Unix and and all the different flavors of Unix no you just read it once and you ready to run it anywhere and it meant all of that other stuff was just going to become meaningless and the only thing that that was going to matter with Java you're totally right that it it took all the air out of the room for like a big chunk of like the the late 90s maybe early 2000s yeah totally and if you were implementing in C it's like well I hope the past is working out for you and this is the whole idea of like you are you are actually a living fossil and Java is actually going to come to replace you and you know and in some ways it was like I actually I really do think it was kind of worse because if you were doing guys what we were doing like you know we're in the operating system developing this thing in C it's like Java didn't really have anything for us you know it was not like oh I mean we did it around the margins but not like our tooling I mean even the kind of the value that Java legitimately delivered we didn't really realize any of that um and you know ultimately we uh we we ultimately had a good relationship with Java but it wasn't like whereas I think with like LLM it's like you know you can actually everybody can kind of up their game with this thing in a way that's really exciting and uplifting yes bottom um well I did rain anything else we I know there's obviously a lot to talk about here I think we covered everything there is to say about LLM I mean the thing I will say personally is like having a culture where writing things down is valued is like you know it is like a real multiplier here and so I mean our oxide like I'm very happy that you know all of this work that we do like we now have a new way to gain leverage from from all this writing work that you know we have culturally do if you're if you're a place that you know maybe it doesn't have as strong rigorous like requirements or like you know isn't as committed as oxide membership hardware or whatever um I would still consider like you know doing work to write things down and produce good documentation good design documents because like L at least the current generation of LLM's like really like that and so you know like kind of you know get get a little more discipline right with some of these things right um so yeah that's that's what I would say like write things down that's a great advice and actually wait let me ask you to expand on that just a half a beat because I do feel as as part of of deep blue you do have especially and it's unclear me by the way if this is truly young people of like undergraduates versus a kind of a more mid-career malaise and maybe that's like maybe deep blue cuts across all of it but people who are wondering like what is you know how can I what is my role in this kind of this new LLM age um what what will be some advice that you would give to an engineer that's early in their career um and looking at this stuff honestly like this is kind of the advice I did like I would say like practice you know like writing like for me like writing is not an astral skill for me this is something that it's taken me many years of work to kind of get where I am now um I would say like if you're starting out like like practice writing um don't have the LLM right things but like have feed it into the LLM and see how it behaves when you kind of do that and like practice do you know that is the one bit of advice that I think I think this is the kind of advice that you know is like time less in the sense that we have always written things down and we will always keep writing things down there's always a lot of value to that but I think the in the LLM age like this is one of those ways where you can really multiply the amount of rigor you have yeah that's great advice I think the advice I would add is like hey you can now you've got the ability to pick up a new language pick up a new system much more quickly than before and you should use that as a way of getting into something maybe you would have been intimidated by I mean I do think that like I mean look look colonel development feels intimidating to people lots of people don't pick up colonel development because they're intimidated by it and if you view an LLM as like giving you the opportunity to jumpstart you in colonel development go for it that's great like it that's that is has got a very robust basis so hop in there and you know hop into to alumos or or something that you wouldn't do otherwise maybe a database what have you um and I use that LLM to get you jumpstarted and to get you mastery over this thing um LLM stone judge like asked all the questions this is true yes yes yes if anything they could judge just a little bit more be like that is kind of a bad question but this is okay this is why pair programming never really worked out for me is because you always have someone being like you used what you don't use devorak like I thought like no I don't use or like you're like you actually know there's actually a fast for key binding that's like no can we aren't we like trying to work on this problem together like why are you coming like you're using syntax highlighting what am I even here for you know it's like okay we're just now having fights over things and you know it's just like we don't you know you don't have those those the LL I don't think the LLM maybe I'm a little maybe I should confide to cloud code that like by the way I don't use syntax hiding what do you what do you think about that see what it's uh um but yeah it's it's free of judgment which is really terrific well thank you all I you know I know this is a hot topic and um I I think that I'm hoping that we can show that big moderate middle and um really show that there is a third path that by the way is the most likely path which is that we actually use these things as tools they're not coming to replace you but they are actually going to allow you to do a lot more and um that the one that should be most worried about LLMs is stalebot stalebot for you death to stalebot I say so uh Adam thank you for stoking that rage um but um thank you all I think this is really great stuff thank you for for coming in on a hot topic um and thank you all in the chat too I think this is this is really important this is not going to be um our last LLM episode this year I don't think Adam that's a great prediction that's exactly it feels like a walk all right thanks right thanks David thanks Adam take care