This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [53:04-58:06]

a human would have stopped and been like, this is crazy. Like, what are we trying to do here? How was this monstrosity happening, right? And because that query was so insane, it was just doing like these joins and all these different tables like, uh, it was super, super inefficient. So I don't think a human would have written that. And then the second one, we actually looked at it when we saw that it was putting a lot of pressure on the database. And we're like, how is this putting a pressure on the database? It's like a look up to return customer profile information. Like, this is crazy. But what it was was at the end, it had this or basically said, like, look up this data for, you know, find out all this, find all this data if the ID matches the user ID or the customer ID. And because it had that or at the very end, Postgres couldn't use the indexes on the table. And so wound up performing sequential scans of both tables every time this was called, right? Which is like hundreds of thousands of rows. So, um, yeah, it was just, it was a really interesting failure mode because on that in particular, user IDs and customer IDs are completely separate things in our system. Like, we never treat them as the same thing. Yet, Claude, reason that they might be. And so add that there. And so we didn't catch it in review, which I think is another big problem with agentic development is like, you just, you know, you don't review PR code as carefully as you write code, right? And, um, and so it just snuck through. But if we never would have made that mistake, we never would have thought to put that ore there because in our understanding of our domains, like, we know that these are separate models that they don't, they have overlap. But like, they're never treated as the same thing. Um, and so I thought that was a case where like, Claude, like, doesn't really have judgment. We have an interview coming out. I don't know when, but with some authors, we really, really like, um, and we talked about Claude and and large language models. And they basically called them like advanced beginners. And they, they really laugh at the framing judgment. Yes. I was talking to the software engineer at the gym this morning. I was, like, they're in, um, brought that up. Like, we were actually talking about general. Yeah. Um, anyhow. Uh, so I, judgment has always been important software engineering. It's even more important these days. Again, in a world where velocity is faster, like, these tools are magnifiers, right? And I do think they make good developers a lot faster. Again, like, I hear talk about like the 100x developer. And I like, people just point out on Twitter, like, okay, 100x. That means that you can get done in two days, but you previously took a year to do. And like, once you start putting in like concrete terms, like, that's insane. That's laughable, right? I do think large language models for certain tasks. Like, I actually think a lot of the work you're doing with the Book Overflow website or like yesterday, because we've had trouble with some of these bad queries sneaking through, I wanted to, I wrote us a script to like run explains on every single query we have. And then I used that same script to two, uh, automatically run explains on every PR we do just so that we're, we're getting some insight and nothing terrible is sneaking across. Like, and I was able to move really quickly with that because this was like, just kind of like tooling code. Um, and I didn't really care so much about like what it looked like. And so that I'm, I think I'm willing to vouch and say that there was a 300% improvement in productivity that the stuff I got done in about half a day probably would have taken two to three days in a free LLM world. And I think that that's the thing that I've noticed as well, which is that there are, there are flow states that I'm in that I think I probably do a two to three X improvement in my productivity. As long as my constraints are in a good place, as long as I have a clear idea of what's going on. And, um, but I, but I will say that there's also times in which I've spun my wheels in odd ways that I wouldn't have otherwise without the LLMs. And again, I'm not against it because I do think, I do agree with the, how did I have like the design it twice thing. And I'm actually, I spent a decent amount of time like using LLMs as a rubber ducky thinking through problems that I'm working on looking for falsifiable stuff. I will tell you every time I deviate away from um, um, using sharp tools, making sure that I have good fitness functions in place anytime I deviate from that that's where we get into like bad places with LLMs. But if I'd spent a time up front in being like, what falsifiable things can I create as I go, right? And by falsifiability, I mean, if I make a claim of the way that the system should function, can I make something that says it does