Steve Klabnik (2:56)

Yeah. Thanks guys. I. Thanks for having me. It's good to be here. And yeah, I have like a weird background and so I never know what to say with these kind of things I can say. Presently I work at a company called East River Source Control. We're building some source control tooling around the JJ version control system. But like, we haven't really talked a whole lot about product is yet. But as you might imagine, developers collaborating to build software means at least knowing about AI right now. So, you know, that's one, one reason I'm connected to this. But I think the biggest thing is like, so I, I started programming when I was 7 and I turned 40 this year. I've seen a lot of change happen, you know, both my professional time and also just like being around computing for, you know, this long. And I did a computer science bachelor's degree, but then I almost went back and got an English degree. And so like I, I am in this weird section where like I've been programming for a long time, but this bookshelf behind me is full of a lot of like dead French people books, you know, and so I kind of was always in that space and I found myself being really interested in sort of the intersection of writing and software. And so I sort of became known as the Docs guy to a lot of people. So I spent 10 years working on the Rust programming language and wrote a book also called the Rust programming language with my co author Carol.

Chris Benson (4:13)

The book.

Steve Klabnik (4:14)

Yeah, thanks.

Chris Benson (4:15)

I'm just saying it is the book.

Steve Klabnik (4:17)

Yeah, yeah. People in the Rust world call it the book, which is very nice. But so I've kind of been like interested in, in all of that. And also like I loved compilers and so I like scheduled my computer science classes around how to get to compilers as quick as possible. And then I kind of like Ruby on Rails became a thing and I was like, oh, I guess I'm going to make websites now because that's what everybody's doing. So I had this kind of like complicated ish sort of background and at the start of 20, like if we went back a year and change ago, I would have just been self described as an AI hater. And then now by now, a year later, I have a lot of people who are like, damn, that guy really fell off because now all he talks about is AI. And so that transition has been very interesting and complicated and I've been trying to like write about it. And so, you know, that's sort of, I think how we kind of got introduced or how you originally sort of, we were talking about me being on the podcast was about some of that stuff. But yeah, and so I think that like, regardless of one's opinions on AI, I think it is like arguably the biggest change to our profession in a long time. And whether or not you think that's good or bad, I don't think you could really deny that it is a thing that is making things change significantly. And so that's sort of what I'm most interested in is like, at the moment I feel like I have a sort of base disagreement about what reality actually is with a lot of people. And so it's, it's sort of almost like I have my own sort of thoughts about where stuff is going and whatever else. But, but when I read things, a lot of, a lot of the stress of this past year and what led to my writing was me being like, I, I, I wrote a post almost a year ago, it was in May of last year called like, I'm disappointed in the AI discourse that during that time there was this big thing where essentially like I was playing around with ChatGPT for the first time and I asked it a question and it was like searching the web and it showed me all the websites it searched and stuff. And then I'd switch over to bluesky and I see a post that's like, ChatGPT cannot literally search the web. It is not a search engine. Stop calling it a search engine. And that kind of like disparity, like maybe that's like a formative moment, but it also, I think exemplifies the way that we have been talking about these tools is that there's like a disagreement about the facts and you can't, I feel like you can't really get to a higher level amount of discussion or like come to any sort of consensus or building things without like understanding what the facts are. And so I've spent this last year, maybe in a sort of peer kind of way, trying to be like, can we all just agree on the facts, please? And then the facts keep changing and that makes it hard anyway. That's sort of a lengthy, I guess, background to, you know, where I am, what I care about, the space. I think that the future is interesting and I don't know exactly what it's going to be like, but, but that's sort of, yeah, I don't know. That's. Hopefully that's enough rambling to get started

Chris Benson (6:58)

at least it is. Not only that, but I'm about To draw. Draw you out a little bit more along that line of thought. Because, you know, I followed you for a number of years. I. When I got into Ruby and Rails years ago. And then you wrote. I think it was the Rails 4 book.

Steve Klabnik (7:17)

I helped with that.

Daniel Whitenack (7:18)

Yeah, yeah, yeah.

Chris Benson (7:18)

And that helped me level up. When I moved, I moved through Go for a long time. That's how I met Daniel. Eventually got to rust. And you're one of the three authors of the current edition. I think you got it started in the first edition and so still reading that book. So, you know, it was one of those things where I was interested in. But you were consistently kind of, you know, a little bit negative on the AI side as things were getting in. I was thinking I got to find a way to get Steve onto the show, but he's not writing blogs that are very conducive to that, so maybe there's an angle. So I was really surprised when we got to the holiday season and you announced Rue, which I know we'll get into in a moment, but you talked a little bit about kind of setting the facts and everything.

Steve Klabnik (8:08)

But there was a.

Chris Benson (8:09)

There was. At least from the outside, you know, as someone who's reading your blog stuff, there was a definite shift in how and in. In, like the. The approach or the tenor, if you will. And can you talk a little bit? Like, I know you were talking about the facts a second ago and kind of laying those out, but, like, what. What happened, man? You know, like, how did. That was a turnaround? I was like, holy.

Steve Klabnik (8:30)

Oh, I shouldn't say that. There's a couple things.

Chris Benson (8:34)

We're family friendly, so.

Steve Klabnik (8:35)

Okay, that was a good. That's. Oh, yeah, that was the only pre podcast question I didn't get answered is how much can I curse? Because I'll say it myself. It's all good, though. No, so. Okay, so I basically did not pay any attention to this space at all until ChatGPT came out. And I very distinctly remember where I was when ChatGPT came out because I was with my family. And, like, the first thing I did because, you know, maybe I have some small narcissist tendencies, is to try to ask it if it knew about me because, you know, you're curious when you post a lot of stuff online and it says it's been trained on the Internet. You know, you're like, who? You know, do you know who this is? Or whatever. But, like, I. I tried it that day that it launched, and I was like, this is cool, but this is like, kind of a curiosity. And then I had a lot of, like, stuff going on in my life at the time. But because I was, like, around family, I ended up showing, in particular, my mom's boyfriend, ChatGPT, initially. And so some time goes by and people are talking about things, you know, in general. And, like, I wasn't paying super close attention to all of it because, like, you know, it was, like, neat, but it also was, like, wonky enough and weird and odd enough that, like, it didn't really seem useful. It seemed like a fun kind of, like, party trick, but I didn't really think about it too much. And then, you know, no one is exempt from the opinions of those around them. We live in a society. We have friends, you know, you're kind of the people that you're around. And the people that I found myself around were very negative on AI for various reasons. And I think also there's a couple of different sort of angles to that I'm sure we're going to get into. But I kind of just by default felt and fell into kind of a, like, you know, ask it to write some Rust code, and it barely does it correctly, and it's, like, kind of bad. And, like, that seems like whatever. And. But, like, as the sort of Silicon Valley hype cycle kind of, like, ramped up on this, it sort of seemed like the hype was mismatched from the actual reality. And so that kind of matched my kind of, you know, what my friends were saying and stuff. But my mom's boyfriend, like, he's not a programmer at all. He was managing a coal tariff, like, ant, like, where you take physical tar out of things and you move it around. And I don't really totally know anything about that, but, like, furthest thing from a software developer ever, he just kept being, like, so into it. And we'd have conversations every so often about, like, these kind of topics, and I was like, man, you're like, the only dude in my life who's, like, positive on this thing. And so it was actually kind of like, you know, some. There's some positiveness to, like, touching grass. I guess what I would say is that, like, when I get out of the online echo chamber and I talk to somebody who has, like, no idea where the echo chamber even is, let alone what the echo chamber was about. So his fundamentally, what really changed it around for me was, like, conversations I had with him was sort of the. The beginning of that. But then this sort of, like, the thing that really made the shift happen and the thing that led to that initial blog post was I happened. It's. It's timing is so interesting. I, like, happened to try. I was like, I should be a more informed hater, so I'm going to give these tools, like, a better try. And so I was like, what. What is the current state of the art with these kinds of tools? And like, what should I use? And it just so happened that was like two months after the first agentix stuff started appearing at all. And so I installed an extension called Klein into VS code and I started, you know, using it. And I was like, oh, this is like, very different than me asking ChatGPT on a website to, like, write me some code. And so I started playing with it and I was like, okay, wait, this is like this, like, work works. Like, this isn't like, hold on a second. You know, like, I was like, not a fan of this stuff because it didn't really seem to work very well. But, like, I'm not gonna say it's perfect. There's like, stuff going on. But, like, it does, like, fundamentally work. And so I can't be like, running around saying this is useless when it's clearly not useless. And so what other stuff am I wrong about? And, you know, I think a lot of people maybe that are more familiar with my Twitter account than, you know, me as a actual human. Not there's that. Not that much of an overlap, but I'm kind of a very strong opinions, weekly held kind of guy. And so I definitely, like, say things more strongly than I believe them sometimes just sort of by default. And so. But I do like to think that if I say something and the circumstances change, that I will change my opinion. That's like a thing I would like to believe about myself. I'm not going to say I'm perfect at it, but in this case that's just literally what it was, was I was like, okay, I was willing to criticize this as useless when it was useless, but now it is not useless. And so that's like a big sort of like, shift in me. And, and those conversations with my mom's boyfriend largely revolved around things like, I was like, okay, it, it makes stuff up sometimes. Like, how do you, you know, like, what are you using this for? And like, how do you deal with these downsides? Because, like, my peers are talking about how, like, it hallucinates things and therefore it's totally useless. And he's like, well, here's the deal. He's like, I need to write a lot of Reports for my job. And you know what I hate doing? I hate having a blank piece of paper. I, I need to, I love editing stuff, but I hate writing things. I'm going to fact check everything that I write before I send it out. And if it's 10% wrong, that's totally fine because I'm going to fix that in post because I'm never just dumping the text. It gives me into that report. But it solves this major problem. Like I am more productive. Not because even I'll fully rewrite the entire thing from scratch, but like, because that's an editing process and not an authoring process. Like that. That to me has really, really helped my own. And like I don't trust computers at all. You know, he's, he's retired now to give you a vague idea of his age. And, and so like he's like I don't really trust computers at all. And like what I sort of came to realize is that like as software developers we've conditioned our brains to think of like so many programmers. Like it's, it's not a compiler because it's not deterministic. There's non determinism, it doesn't gives the wrong answers sometimes to normal people. Computers this whole time have been magic boxes that you just punch random things into and they give you the right answer 60% of the time. And you can't trust what they say anyway because they like barely work. And so that like that like non programmer mindset up to computers really was what made me go like, oh yeah, like that's like kind of a good, you know, point sort of like, like he's more equipped mentally and like in techniques to deal with something that lies 20% of the time than I am. Because I'm used to, I'm used to determinism and I'm used to the computer doing exactly what I say. We, I trained my entire life to like the computer does exactly what you say and bugs happen because sometimes you say to do the wrong thing. Right. But like that sort of, that was like a really big shift for me specifically. And there's also, I think if I, if I'm at my most critical about my industry, that we kind of, sort of believe that because we're good at computers that we know what we're talking about and we're like better at them than normal people. But I like want to believe in normal people as well. And so I think a lot of software developers are like no, this tool is wrong and is bad. And if you get value out of it. That means you're stupid. Not that you know something I don't. And I think we could all deal with a little more humility, which again I know a lot of people are gonna be like Steve is saying we need to do more humility. But like it's true though. I need it too. And so that's, I think a lot of sort of the turnaround for me came out of all of that kind of stuff basically. Yeah.

Daniel Whitenack (15:47)

So Steve, something I was thinking about when you were talking about this kind of shift in mindset and what kind of quote not I forget what you use normal people or non programmers or whatever it is. I don't ever. How they kind of view computers, how they, they're interacting prior to AI and now and how you want to believe in, in sort of, you know, that that kind of person or more people utilizing, you know, powerful tools like this and, and what they could do. I'm wondering like we'll talk, I think more about rue and, and some of that stuff as we go along. But in that respect, like you obviously have domain expertise that has been built up over years and I'm guessing in that kind of human AI experiment which has to do with compilers or you know, developing a programming language in some way, you had an advantage over someone who had never thought about compilers or that sort of thing in terms of your like human AI teaming. But also, yeah, I guess I'm wondering about what you think is that kind of unique element that software engineers bring to these kind of human AI teaming exercises these these days. And you know, what's, what's important I guess to preserve in that and important like you say to like maybe be willing to sacrifice or say like hey, this thing that I held very closely for many years is something that I need to be okay to, to let go.

Steve Klabnik (17:29)

Yeah, I think that. So there's a couple things. I'm actually not entirely sure if it's my like English grad school background is actually more valuable than my software background when it comes to understanding these things because they are fundamentally about language and like also like, I don't know, I got a book back there called Alien Phenomenology what it means to be a thing like the idea of like a non person entity existing in the world and what that means. Like I, you know, I grappled with that question a lot and I feel like a lot of people kind of like haven't necessarily and I'm not, I'm not on team like AIs or people at all, mind you. But like I, I have this, I've had this long standing sneaking suspicion that being nice to AIs makes them perform better. For example, I also think it's good for like you as a person to not be mean to them. But like there's kind of, there's sort of like a. The hottest programming technique is to go to therapy. Like it's sort of this like, like, because I'll, I'll see people who are like, I tried this and oh, I almost swore right there, I tried this crap and it didn't work properly and whatever. And I'm like, can you show me the transcripts? And it's like when Claude makes the first mistake, they're like hey jerk, what's your problem? And I'm like, I think that that's like why it's performing worse is because I'm like hey clot. Because anyway, it's like a lot of excellent try.

Daniel Whitenack (18:42)

Let's move on to the next step.

Steve Klabnik (18:44)

Yeah. And like, you know, there's like a non zero part of, you know, I, I date. I'm about a year into a relationship with someone, has kids. This has never been a thing in my life. And so, you know, another funny part is like when you're around a two year old and people are like, it just repeats what it's heard before. Humans don't do that. And I'm like, she literally says the last thing I said two times in a row after I say it every time. And again, I don't think humans are people. LLMs are people. And she'll grow beyond that and LMU won't whatever else. But it's just like those are the kind of experiences that were like breaking my brain in terms of people being like man, you wait, you know what consciousness is like you, you claim that it can't be because you know what it is like, wow, that's new to me because I philosophy of mind was still arguing about what that means actually. And you sure very much feel very strongly about like. And that doesn't mean it is conscious. I'm just saying like have some epistemic humility. So anyway, like I do think there's some aspects of the programming background that are useful though. And I think that like. But I think the trick is. So there's an old advertising joke that's like, you know, only 50% of my advertising budget is useful. The problem is I don't know which of the 50% and I really think that that is the moment that we are in. In 2026 as software engineers is. I think that there are. I think that we need to have a sort of, like, acknowledgement that many of our industry practices are not actually backed by evidence at all, especially around things like clean code. Like what Ver. Like, I have never given less of a care about how many spaces my tab key produces. You know what I mean? Like, we used to, like, man, eight spaces is far too indent. You can't read that stuff. And so we really need to move to like four or two. That's like a. I'm happy to never argue about that ever again.

Chris Benson (20:25)

Not two. It has to be four. Come on.

Steve Klabnik (20:27)

Exactly. It's got to be four, not two. But that's an easy one to sort of joke around about. But what I mean is that another really interesting thing is that if we want to acknowledge that these tools interact with code bases in a different way, what is good code to an LLM may not be good code to a human. And we need to recognize that some of our practices have pretty good empirical basis, but other ones are just stuff some guy made up and he had a blog in 2002, and then everyone's been repeating it ever since. And like, that's just the case. And. And so. And it doesn't mean that I totally believe in the idea of code quality is dead. That's not what I'm saying. I'm just saying that, like, we don't. There's so many things that we now don't know. This is not a time for, like, shutting off ideas. This is a time for reexamining the beliefs that we have. And I say beliefs because they are beliefs. They're not like, proven guaranteed correctness things. And so that's like. I think the biggest part of what I'm trying to do this year is to have some humility in what I believe about what the correct way to develop software is. And that means also a lot of experimentation, means a lot of mistakes, means a lot of problems, means a lot of, like, you can't. You can't figure out what's right until you do a whole lot of things that are also wrong. And so I feel like, you know, like everybody's talking about software factories, you know, these days, which is already a thing that's only a month old. And it was just called Gastown before that, and then before that it was barely anything else. And sure, those things may be bad ideas, but, like, also, you know, in the 1910s. Let's see if I remember history Right. There's a bunch of dudes strapping wings of their arms and jumping off buildings and dying. But like, I still take an airplane around the world today as part of the process that they gave their lives for. And it's kind of silly to be like, you know, but like those people did they, they literally died experimenting to try to figure out how to make flight happen. And then eventually we applied engineering rigor and we understood things. But that like, experiment time, like, that's what we're in. I don't use open claw, like at all. Like, to me, those are the guys strapping things on their wings and jumping off a plane. And like a bunch of them are gonna, problems are gonna happen. Like people are gonna lose their livelihoods. And I'm not saying it's a good thing, but I'm just saying, like, different people have different risk tolerances. And like, even as psyched as I am about this stuff, there's like, things that I won't do, but I'm also not going to poo poo them exactly. Because like, they may uncover something cool. And I welcome their sacrifice. You know what I mean? And so that's like, that's like the thing. Yeah.

Chris Benson (22:53)

So I was, I was going to like, next question drive you toward rue a little bit.

Steve Klabnik (22:59)

Yeah, yeah.

Chris Benson (22:59)

But you've, you've hit, you've hit, you've hit a point there that I'm spending a lot of time thinking about right now. And I really wanted to kind of ask you because it sounds like you're getting there too. And that is that so many of the, of the processes, you know, Agile frameworks, you name it, there's so many things that are in place today in software development because of the humans, because the complexity and you're trying to manage all the things and you're trying to say, okay, we're going to have, you know, microservices, nanoservices, you name it, all these things that are really more about the human in that than the technology itself. They actually add overhead in terms of that. And so that has been something I have been thinking a lot about is like, as we get into this kind of new approach to software development this year, what is the future of these various artifacts that we've created to help ourselves be software developers? When you have LLMs that may not need any of those to produce, maybe not today, but at some point in the not so distant future, future may be able to produce amazingly capable software without the need for all these things, changing that role of how the Human fits in. And so it sounds like you're hitting a little bit on the same kind of questions there.

Steve Klabnik (24:19)

Yeah.

Chris Benson (24:20)

Is that accurate?

Steve Klabnik (24:21)

Like, again, I haven't really talked about my product at my job, but it's like forge shaped right? Like, you upload code to our thing and then people use the code to work on your stuff. And so this is an active of, like, question in terms of product direction at my job is like, it's very easy to make pull requests and make those good. And we know how to make pull requests good. But, like, is that building for last year and not next year? Because, like, another funny thing is that people hate pull requests and code review, even while we do acknowledge they're really important for actual, like, good, you know, stuff. And I'm not saying that pull requests are bad, that we're not doing them or anything. This is not like a statement about what's going to end up coming out the other end. But, like, you know, I do like, wonder like, okay, what is, what do these steps look like? And like, what's that happening? Like, like, that is sort of, you know, the core. Like, you still, like, humans are still doing this and we're doing in collaboration with machines now. And so if we, if we're willing to take it seriously, like, what affordances do, you know, do we need pull requests where they're automatically marked as this is a cloud open pull request versus a human open pull request? Or do we need different review standards for different ones? Or how do you go about implementing these kinds of things? All of these are sort of open questions as far as I'm concerned. Like, we need, we need a little more epistemic humility around, like, being willing to be like, okay, what practices work and don't work? A concrete one that I don't know the answer to, but I can give you a specific example rather than just generalizing about, like, things that we used to believe that we don't anymore. In OpenAI's most recent blog post about using agents to build a product, and most people think that's codex, but, like, we didn't really say specifically what it was. They mentioned that when they develop software in this sort of agent first fashion, when they added more developers to the project, their velocity increased. And that's like a sacred cow since Fred Brooks. Like, that's like a 1950s, 1960s. Adding more people to a project makes it slow down. Well, if that's not true anymore, like, that changes a lot of other things. And like, you know, and that's like that's like one and there's been, I think also I think Anthropic has said a little bit about this as well. And so like you know, it's sort of like that's an example of a, of a, a thing that is a belief that is very strongly held and for good reason. It has been true in the past but that doesn't mean it's not going to be not, not true in the future. And I think that matters because like so much of this like being upset about AI stuff is this existential question about when, when I'm, I'm meanest, I'm like software developers jobs, our industry's jobs has been automating other people out of jobs for 50 years and now it's coming for us and now we're like oh, automation might be bad. Like, like it's a little selfish and a little self serving and I think a little like almost insensitive in the way that some people react. But also I got a mortgage. If I don't have a job I'm going to be upset. You know, like I understand it at the same time as it maybe feels a little hypocritical. But like the thing is is that I do look to the Frontier Labs a lot because if anyone is doing something that's forward looking it's probably them. There are other startups too, but I think that they are the ones with the most inside knowledge about what's going on. They all have software engineering job positions open, they're still hiring people. And so while it's true that you have very famous examples of executives firing people because of AI, I think that like that is first of all like do you really believe CEOs? We're believing we're taking CEOs their word now for what they're doing. Like you know, you trust that they're doing what they're doing correctly. Like I think a lot of it is cover for post zurp over hiring and I think some of it is just like poor management. And again, again you lost your job due to poor management is not like a soothing thing to say to someone that lost their job. I'm not trying to trivialize that aspect of it either. But I think that once we get through this period of learning, like we're going to learn that we need more programmers than ever. We're going to need more people than ever. Because like when you, when you make an individual person more productive, that doesn't mean you like a forward thinking company doesn't go oh that means I need less people to do the same work. It means, oh my God, I can get even more work done. Because I don't know about you guys, but I've never worked at a place that's been like, well, we're out of ideas and we don't have a backlog and there's nothing to do around here, so just go home. Like, there's always infinitely more work to do and when you start being able to do it faster, that just means you can do even more things faster rather than do the same amount of stuff with less people. And so I can understand the cynicism, but like, for me personally, I'm not sure that I believe that that will be the case in the long run, basically, anyway, that's a little small digression, but that's kind of like once the AI labs start firing software developers, that's when I'm worried about software developers losing their jobs. But as long as they're hiring, like, I think we're, we're good. Probably we'll see.

Daniel Whitenack (28:49)

And yeah, I, I, I, I love, I think I'm gonna fall asleep thinking about a lot of these topics. Cause it's something I'm wrestling with all the time. We've even had some of these code quality discussions even like this week in our, in our business around like, what standards should we have and what does that mean? So yeah, I, I am curious about this particular, you know, effort that, that you did with the, with Rue and like, what that means. Like, maybe you, with like, how did this idea come up? And like, what was the concept?

Steve Klabnik (29:22)

I guess. Yeah, so there's a couple different things. The first one is, is like, I worked on Rust, but I worked on documentation. I weighed in on language design occasionally. But like, I did not, I was not on the language team. I didn't do that. I was on the compiler team. I didn't work on the compiler. I did other things because that's where I thought my skills were most useful because I wanted Rust to exist in the world more than I wanted to work on a compiler. And so, so like, you know, it's been a couple years since I've worked on Rust, and so I was like, maybe it's time that I could work on a compiler. But the thing is, is that like, I know that all of this is a tremendous amount of work and I have had less free time in my life than I ever have. Like in my 20s, I remember distinctly being like, why doesn't it? People are like, you are so productive and open source, Steve, like, there was a time when I was the 17th most committed person on GitHub. And like, that's because, like, GitHub was like, way smaller back then. But like, I, I was like, legitimately up there. And, and, and I was always like, why don't people ever have time for open source? And like, I literally had a conversation with my girlfriend last night about, like, Like, I wish I could buy more time because I don't have enough time to even do my side projects. If you go look at Roux right now, I haven't committed since January. And when we scheduled this thing originally, I was like, I'm taking a little bit of a break. I don't know when I get back to it, so maybe we should put it off for a little bit. And I've not had the time to get back to it yet because my life has been busy. So. I had never started a language project because I knew that if I'm the one typing out all the code, I'm not going to get far enough to the interesting parts. I don't, I don't really care about parsers. I'm not, like, really interested in the front end. I'm interested in the middle end. I'm interested in the back end. I'm interested. I don't know as much about CodeGen as I, like, should, and so I want to, like, learn that. And the best way to learn is by doing. But you know what? Like, sucks saying that, Like, I have five free hours of work time a week and I'm going to spend that debugging a register allocator on why x86 64 is, like, using LEA incorrectly or, like, whatever. That's like, not. You know, I. In college, a bug that I fought all weekend. Like, there was a time me and my friends were working on an operating system in college and, like, we couldn't get the machine to boot. Boot in qemu, we'd put the disk into the actual computer and we'd boot it up and it would fail to build boot. I was like, man, that took us like two weeks to figure out that there was, like, something slightly wrong. I don't remember what it was, but I used to tell that story. I was like, man, that was awesome. I spent two whole weeks working on this bug. You know what two whole weeks working on a stupid bug means in my project now? It means that I'll go play video games or, like, hang out with, you know, the people I care about or, like, do something else. Like, I'm just, I'm old. And so for me you're like, you're not old. Yeah, sure, I know, but you're not old. Trust me, I'm getting there. And so it's really great, you know, to have the 40 year old midlife crisis at the same time as the like, is my industry going to disappear crisis happening with a classic millennial. Like, you know, like I graduated college in 2008, so like, you know, we got all these other things happening in the world at the same time. It's been, it's been cool. But no, so, so what I saw with like stuff like Claude was like, oh, this is good enough now that I wonder if I could revive this project I've always wanted to do, which is work on a compiler. And like, like I know because I put in that amount of work, how much it takes to make a programming language popular. And like, I'm not really interested. I'm not here to sell you on root or you should use it. It's actually not even really ready for human consumption yet. Talk about that in a second. But like, the point is just like I wanted to work on a compiler. And by work on a compiler I mean I wanted to like design one, play around with one, read the code, figure out how that stuff works. But like, I almost have repetitive stress in RSI sometimes. So like, like typing out like putting the code into the IDE is like not the part of the programming that I care about anymore. It's the architecture. It's like reading stuff, it's like reviewing stuff. And so for me, like having Claude at work is like totally fine. So anyway, I actually started Roux last August cause I had some time going on back then and then it, my velocity slowed down a lot and I started getting into like problems where it would spin all night and like not make progress. And I was kind of like not happy with it and, and at the same time I conveniently got very, very busy and so I dropped it entirely. And so from like August to November, I pretty much didn't really do anything because I just didn't. I didn't have the time to, to work on it at all. And so I came back and a couple different things had changed. The first one is that I do think using these tools is a skill. So another thing that I think is really important with all this AI stuff is to acknowledge that it's, it's like Vim. Like we joke about Vim being hard to quit, but like, nobody says that Vim is a Bad tool. I mean, some people do, but like, whatever. We generally acknowledge that VIM is useful, even if it's like not emacs person or whatever else person. Like, you know, we don't, we don't deride the tool for being bad simply because it has a learning curve. We may say that learning curve is not worth it, or I don't want to put in the time. That's totally fine. But like a learning curve does not inherently mean a tool is bad. So I think that AI tools and developing, using AI and especially agentic programming is a skill that takes time to get good at and you need to practice it. And so this first iteration of Roux, combination of the models being worse, plus me being worse at it, meant that I kind of backed myself into a corner where I bit off too much, I made my PRs too big. These are all not new problems. You know, I merged some stuff that was of questionable quality for velocity reasons because it's a side project. And so it kind of got bogged down and I wasn't really, you know, feeling it super great. So in like November, December rolls around and I start having time again. And I was like, okay, I learned a lot from this first iteration. I want to do it again. And I had some new ideas as well about like, what I wanted the language to be and like some other things. And so I just started over again from scratch. And this time around it has gone way, way better. And I am like very happy with the overall quality. And some of that has to do with my own skill, some of that has to do with my approach. So for example, a thing that people get upset about with Rust all the time is like, it doesn't have a spec and it sort of has a spec, but like, like, whatever. This is not, like, this is off topic of a tangent of tangent, but like a thing that I did that I think matters in terms of like practically speaking making this better is I focused on validation. Like, I think one of the most critical things to do when developing with agentic programming is give the agent the ability to evaluate if its work is correct or not, because it iterates towards a fixed point and that fixed point is test pass. And so I actually did like language spec driven development. I actually said like, let's work on a language specification first. And then I ended up writing a custom test framework with Claude because I'm being a little extra about it that takes the language spec and connects those to test cases. And those test cases are example programs that get run through the compiler and can determine like what the program outputs should it output something, what are the error messages, did the program work, what's the program's output to verify that the code was, was compiled correctly. And so that like, that significantly increased my like, success rate and also let me like, do things a lot better, a lot faster because I put in the upfront time on validation and giving the agent the ability to invoke those things automatically because, like at the old time I was just running the code myself and that was like slower and more error prone than this time around. And so that's like one specific example of why it's going better this time. But like I, I changed sort of the architecture of the project and a bunch of other stuff like that. Um, so that's where it's at like kind of now. Yeah. See, I said I was a yapper. You could talk forever if you let me. So it's just like, great. You gotta cut me off. Sometimes I go too much.

Daniel Whitenack (36:32)

It's perfect.

Chris Benson (36:33)

No good. It was good stuff. But I wanna ask the. So as you like totally get like, wanting to scratch the itch, you know, wanting to create it, and you now have a tool that kind of helps you get there, given the fact that you're short on time, like, you know, which is, which is normal. I'm the same way. And so you kind of have this pet project, but as you were kind of defining what Roux would be, as you're scratching your itch on this, and it's like, I think in your blog posts and there's a number of other articles out there on the web that people can find. It kind of talks about, you know, position between Go and Rust, you know, maybe some C and things like that. But what is your thinking about that? Like, what a. Why, why did you. What was the problem you were trying to solve and what is your thinking about solving that problem? While you've been very explicit so far that Roux is not ready for production code, that kind of stuff in how you've addressed it with the public being a personality in the software development world, a lot of people are interested in this. Hey, we're on the show right now. And so like, what is your intention in terms of like, what problem to solve and, and maybe eventually in the future, when the, when the language is a little bit more mature, if it gets more mature, like, what would you see people using it for? And why, versus Rust, which you're famous for, or one of the other, or Go, you know, how are you seeing that totally.

Steve Klabnik (38:07)

So right before I get to that, there's one other part that's similar that I want to get to and I didn't say earlier, which is just that go for it. I also a lot of people and the question of like, can a new programming language work? Because if a programming language isn't in the training corpus, how can an LLM write the language? And so part of my goal with this project was to invent a new language and make Claude write a ton of it because I wanted to see how good it would be at using a language that literally did not exist before this project happened. So there was some of that. And the second one is like a lot of people have said it's good at writing a React web app, but it couldn't do anything like a compiler or an os. And so I wanted to like prove out like it could write a production compiler. So those were also parts of this. The reason I settled on this project was that stuff. In terms of the language itself, there's a lot of people. So I got involved with Rust because I knew there had not really been any credible challengers to see in a long time. Again, Go was brand new at the time and also is Go a challenger to see is a whole giant flame where we could like get into. But to me, I was very much of the like, GC means no. So like whether or not that's right or wrong, I was like, russ, I'm

Chris Benson (39:14)

with you, it's more Java.

Steve Klabnik (39:15)

Yeah, yeah, yeah. And so I think those, like in reality, I think those categories are much more blurred than they are in actuality. But like at the time I was a little less educated. Slash, I had stronger opinions, I was a lot younger then and like, so I was like, okay, we need this low level language and so we are building a thing that's for operating systems and kernels and use maximum performance and all that stuff. And that's why I got got invested in Rust and why I think it's important and why I think it took it off. But a lot of people are like, man, memory safety. And Node GC is like the seventh reason I would use Rust for a programming project. I love the tooling, I love the error messages, I love ownership and borrowing. But like, not because I'm like slinging pointers around, but just because I think it helps me make more clear programs and I like the performance and they're also like, I hate the slow compile times. So. So for me, basically, I think that there is a sort of a market Opportunity for some sort of language that is like in the middle of Rust and Go, that's like willing to like Rust is willing to give up everything for the performance of the code and the ability for you to write as low level code as possible. Go is willing to give up compiler optimizations and control over certain things in order to have a good developer experience. I think there's like some room in there for a language that is like able to reach down the stack a little further than Go is able to effectively, but also not as fully committed to like this much must equivalent or beat C and performance style thing. And so I wanted to play around in that kind of space because if there was something that was like just a little, like just a little higher level than Rust and just a little more performant than Go, that compiled instantly, like I think that's a thing people would use. People want advanced type systems, which again is something that Go is kind of like backed away from, you know, as a stance for them. And I think that's totally fine. But like I want some types, I want super strongly typed stuff. Like I, I like the heavy type system things, but those languages all come with like lack of speed for various reasons and all these things. So that's the niche I want Roux to exist in. Or that's kind of the like like overall spot for it, I think.

Chris Benson (41:28)

Did, did you go with garbage collection or without garbage collection?

Steve Klabnik (41:32)

So currently no I have not. But what I'm sort of leaning heavily on is an idea that came out of Swift and also another language called Hilo, which is some of the somebody from Swift has been working on for a while, which is called mutable value semantics, which basically is like you only need to GC if you have references. And what if you just didn't have references is. And then you're like, well, how do you write any programs? And the answer is like well, you treat references as values and then you kind of. I'll hand wave for the purposes of this conversation, but like there's like things that you can kind of do. So basically you give up a teeny little bit of expressiveness for any of the Rust nerds out there, give up the ability to save references inside of structs. That's fundamentally what you give up. And you give up a little bit of returning references from functions too. Not entirely, but like a little bit. And in exchange for that you have no borrow checker and you have no lifetimes. And so I think there's a ton of people who would absolutely make that trade off, basically. And so, yeah, that's kind of like the space. There are some problems with that. And so as a consequence, one of the reasons why Roux is not really ready for regular programmers yet is I have a little bit of some stuff I need to implement where if you put a string into an array right now, you can't get it back out or access it. As an example of like. And that's not because there's no plan to do that, but because just like the moment that I had no more free time was cut off right before I fixed that problem. And so you, like, my friend Dorian has like probably the human who has the most experience programming in ru and he's like, I've tried to write real programs. And you're like so close. Like, even if you never do anything with it again, can you please just fix these two or three issues and then you can start to write real programs? And I think it'll become a real thing. And I was also like, I'm on the cusp of like a standard library being, being seriously implemented. And so if I get it to that point, like, it's. It's like just before it's real enough to be used for good things. So I do want to not permanently abandon it. I just have a lot of stuff going on in my life right now. And so. But like, yes, that's kind of the, the core of it. And a lot of Rust compile time woes are a combination of wanting super speed, but also some decisions that were made a long time ago that weren't really well thought out in the sense of, of their effect on compile times. Because that was not something that we really thought about back in those days. And so those have now made it a problem that makes it really, really hard to make Rust compile quickly. A lot of people think this is safety checks. They are not correct. It's almost always these incidental things that were sort of not really thought about that have come back to bite you years later kind of thing. And so fixing that, like, can, you know, sort of part of the thing that's on the table. And so I've really, honestly, like Roux is like sort of this weird mix of like swift rust zig and go like, basically like, it's kind of like, what if you just take all those things and mush them together and like, you know, and that's fine. Like, I'm not claiming that I've invented some sort of new magic thing. A lot of programming languages are just taking the good stuff from other things and shoving them together in an interesting way. And so that's kind of what I'm trying to do with it.

Daniel Whitenack (44:24)

Yeah, I love the observation around the spec that was also, I mean I haven't, I haven't done this with a compiler or a new programming language, but certainly it's something I discovered along the way. One of those skills things and you know, actually using AI to help me write that script with, with my validation and then, or, or spec, I mean and then, and then going to actually implement it. I'm wondering as you've gone through that like this is kind of was part of what you were doing on the side when you had those, those times in your life. Has, has anything of those like skills that you learned in the, this AI human teaming kind of project has that filtered into things that you have in an opinion, in an opinionated way brought back to your kind of day job and the team that you're working with? Like, hey, if we did X, like have you guys, you know, have you guys also found this to be true? Like should we be doing, should we be doing this or you know, has it.

Steve Klabnik (45:25)

That happened a little bit. But like there's a couple of different things. One is I personally have been working more on upstream JJ than on our product and that's kind of going to switch sort of soon. But like I kind of have been not, I personally have not been like hacking on our product for various reasons. So I try really hard to not force my opinions on code bases I'm not working on. So I have like, not really broached a lot of that with a lot of people. But our team are, are like, we are not, we are not like super cutting edge, let's make Claude do all the work kind of things. We are much more of a, these tools help me write code and I use them and we don't really have like a mandate for like you need to write code this way and like, you know, whatever else. I think we're much more like median in terms of our AI usage as, as a team. And so some of my thoughts and opinions about this have been from exploring these things in sort of that more cutting edge kind of way because again we're fundamentally building developer tools for humans and AI to collaborate. And so like, like that means you need to be aware of what people are doing. And so I spent a lot of my time reading a lot of stuff from all of every blog post on this ever. Like I have read all of them and probably many That I should not have too. But, like, just to be aware from like a product perspective of like, what we kind of need to be working on with those sort of things. But I. Some of the stuff, I'll give you a. Maybe a spicy one. That's like a practical thing that I think is. I think that. I think that when you start using these tools, you gotta give up stressing out about drawing a little bit. I. I definitely had times in these code bases in my side projects where I've been like, hey, could you give me an analysis of code quality, please? And Claude's like, you got five copies of this function in here, dude. And in the past I would have been like, this is an actual problem. Like, this is a failure of the development process. But now my opinion is like, something closer to, like, okay, cool, can you fix that, please? Great, I'll merge that pr. That's fine. And sort of the reason why is that, like, if we go back to think about, like, why Way before AI, there's a time with Gary Bernhardt and one of his things, Shout Out Gary, he really changed some of my opinions on dry, specifically where there's one of his early screencasts. He did, he. He did this thing where there was like a bunch of SQL files or something had a bunch of strings that were basically identical. And he said, hey, should we abstract these out into a constant? Because, like, they're identical strings. And there was. It was intended tests specifically. So tests are often very repetitive. So there's a question about, like, should you dry up your tests? Has been a thing people have been fighting about for a long time, right? So he's like, we're gonna. We're gonna leave them in there for now and it's gonna be fine. There's seven strings in this file. They're all identical. That's chill. Two or three weeks later, he's still working on this code base and I'm watching him, you know, do the stream and he's like, oh, we need to change those strings. Let's see how hard that was. And he does some. He taps like five keys with vivid and, like, changes all six of them at the same time or whatever. And it's like, cool. That took half a second, you know, drying this code app would not have actually, because, like, the reason we care about dry is because we want all the logic to be in the same place and we want the same logic and we'll make it easier to change later. We are worried about. I modify one copy of the function and then that doesn't. We use the other copy of the function and we reintroduced a bug somewhere else. Right. That's like the human thing. That's a human thing. And so, like, five copies of the same function sure makes my program a little bigger. Maybe we need to care about our program sizes, maybe in some contexts. Contexts. But, like, what if there's five literally identical copies of a function of my code base? Now I'm like, that's fine as long as it doesn't cause those other problems. And if you notice it early and you clean it up later, like. Like, I am more willing to commit minor heresies into my code base and then fix them later, like, there is sort of. The bigger picture thing, I think, is that we. We have been focused on shifting left in the development process because we all know from Toyota that, like, the earlier in the process you find problems, the more that you fix them, the cheaper it is to fix them. Right. And so we've been like, sort of almost everything is downstream of like, shift left, shift left, shift left. But, like, what if certain things were okay to be fixed later in the process? Actually, though, like, what if some sorts of problems are not the biggest problems that we shouldn't be paying our attention to our time with? Like, you know, and so that's kind of like, where I'm at with some of these kinds of things is like, it's. It's. It's kind of okay to not have the cleanest possible code because it's easier. It's. And even the more advanced people with dry would say, don't repeat yourself. Wait till the third or fourth repetition before you bother going back and cleaning it up. But I think that translated to, like, two identical strings must be turned into a constant for a lot of people. So I think there's like. There's like, a wave of opinions that's always been there. And I think that just like, we're moving back towards a little more duplication is kind of. Okay. So, yeah, I was gonna say that

Chris Benson (50:11)

goes back to kind of what we were talking about a little bit earlier in the conversation about kind of reevaluating. You know, you have new capability. And do all of the human aids that we've put in place dry and lots of other things, do they need to be there? I don't know the answer, but it's certainly something that probably will be discussed and evaluated as we move forward. And speaking of moving forward, as we are getting to winding up, one of the things that we like to hear is getting your perspective on the future from our perspective, we ask people not to worry about if they get it wrong. But just like as you're thinking about the future at this point and I'm going to ask you in two versions if you will. One is kind of future vrouw the way you see it and then the other one is kind of future of coding this way that we're talking about, whether it's Claude or other tools going forward as we're starting to learn that and adjust to it and change the the way we approach software development. How do you see that going forward? So both RUE and AI assisted software dev go.

Steve Klabnik (51:19)

So with Roux stuff, I hope that it's a project I continue working on. It's my 69 Chevy in my garage. So it'll sit there for a while and I'll work on it and maybe it'll be a cool thing other people find useful in the future. But I mostly want it to be a thing that I get to return to and something that I get to play around with and try out this kind of stuff. And so. So that's what I see in the immediate future, I hope, hopefully, maybe it's ideas. Like a cool thing about programming languages is you just have to demonstrate an idea could work and then it's useful for other things. So I would totally be happy if Roux is a thing that like somebody else says oh, that's cool, and then makes a real language, you know, that's more serious after it or something like that would be fantastic. So we'll see. In terms of everything else, I think my biggest problem is that, I don't know, I've kind of been in a little bit of a quiet period lately. I have not been writing blog posts and I have one or two I've been working on, but I gotta like ship. But the backend November or December of last year, I felt like I had a couple of different things that I thought were important. And one of those is like teams of agents and another one was like validation that things are happening. And then Anthropic released Claude swarms and other people and I was like, cool. Now I'm out of ideas and I don't really know what is going to happen. And so if anything, I've had the opposite kind of mental breakdown in a. Like I can't see the future. And the whole point is seeing the future. And so I struggle with that. But I do know that I do have a cha. A challenge that we have to figure out. I don't know what the answer is. But the question is important. There is so much velocity to be gained by letting Claude merge PRs. That is just. It is like a thing. Like, I shipped a hundred PRs on Roux on Christmas Day while hanging out with my family. And with Roux, I have read every PR that I merged. But what I mean by that is not like I spent 30 minutes reviewing every diff. I've glanced at it and said, that doesn't look obviously horrible. Clickbait green. And so I could have shipped 200 prs if I was more willing to like, be honest with myself that I was not really truly reviewing those things. And so when I look at like my personal projects, like, allowing, allowing that cycle to happen naturally, just like it makes you go so much faster. And the problem is, is that how do we maintain quality in that universe? And that is, to my mind, that is the biggest question that we need to answer as is a profession right now is like, either that is impossible and we're just gonna have to give up on that acceleration, but it's just too tempting. And that's why you see all these people doing this irresponsibly right now is because, like, you get so much back. And so like, how can we make that a thing that is okay somehow is I think the, like, the biggest question I don't have an answer to, but I think is the future. Whereas the next step of the future is like, like, how do we have trust in these tools that are not going to totally harm us? And that doesn't mean no oversight either. I'm not saying that you can't not read the code, but just like, I don't know, there's something in that space is like the biggest price performance payoff in terms of solving the software development engineering. The software engineering question of right now, I think is that question.

Daniel Whitenack (54:22)

So, yeah, well, I'm looking forward to having you back on the show when you've got that one solved. Steve, excited for that on it? Yeah, yeah, totally. Maybe next week you could come back and let us know the result. But yeah, this is a great conversation. Really, really appreciate you joining.

Steve Klabnik (54:39)

Totally. It's been great. Thanks so much for having me.

Podcast Host (54:48)

All right, that's our show for this week. If you haven't checked out our website, head to PracticalAI FM and be sure to connect with us on LinkedIn X or Bluetooth Sky. You'll see us posting insights related to the latest AI developments and we would love for you to join the conversation. Thanks to our partner, Prediction Guard, for providing operational support for the show. Check them out@prictions guard.com Also, thanks to Breakmaster Cylinder for the Beats, and to you for listening. That's all for now, but you'll hear from us again next week.