Humility in the Age of Agentic Coding

Welcome to the Practical AI Podcast, where we break down the real-world applications of artificial intelligence and how it's shaping the way we live, work, and create. Our goal is to help make AI technology practical, productive, and accessible to everyone. Whether you're a developer, business leader, or just curious about the tech behind the buzz, you're in the right place. Be sure to connect with us on LinkedIn, X, or Bluesky to stay up to date with episode drops, behind-the-scenes content, and AI insights. You can learn more at practicalai.fm. Now, onto the show.

Welcome to another episode of the Practical AI Podcast. This is Daniel Leitnack. I am CEO at Prediction Guard, and I'm joined as always by my co-host, Chris Benson, who's a Principal AI and Autonomy Research Engineer. How you doing, Chris?

Doing great, enjoying, uh, having fun. And, and gosh, the weather, uh, where I'm at is awesome. So like, yeah, I had to, I had to force myself to come in to do the show today.

So yeah, yeah, I unfortunately had a mild case of, of COVID last week, and so coming into this week, it's both like really nice weather and I'm over that, so I feel like extra boost. Um, welcome back.

Yeah.

Thanks. Thanks. It's good to be back. Um, and, uh, and yeah, for our listeners, um, just one thing you might want to be aware of if you are in the San Francisco area or if you're attending RSA, I'm going to be at the conference at RSA, um, out in San Francisco, end of March 2026. If you're listening to this years later, um, I won't potentially be there years later, but this year, this year I'll be there. Um, and, uh, and I do have like, uh, some some meeting space where I can meet up with people if you want to talk about enterprisey AI things, or I'm going to have some demos on like, you know, AI bill of materials and some cool prompt injection stuff. So if you're, if you're into that side of things from the security enterprise AI side, um, uh, I'll, I'll include the link in the show notes if people want to figure out where to find me or, or, um, find a time. So, me up there. But really excited to get into the conversation today. We have an amazing guest with us who I'm excited to get to know a little bit. Really intrigued by his work, Steve Klavnik, who is a software engineer. And I'll leave it up to you, Steve, maybe you can describe why—

Software engineer extraordinaire.

Software engineer extraordinaire, how you ended up on a on an AI podcast, what your background is and where that intersects with AI, I guess.

Yeah, thanks guys. 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 kinds 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 lot about what product is yet, but as you might imagine, developers collaborating to build software means, uh, 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 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, uh, you know, and so I kind of was always in that space and I found myself, uh, 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-authors, Carol, uh, the book. Yeah. Thanks.

Uh, I'm just saying it is the book.

Yeah. Yeah. People in the Rust world call it the book, um, 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. Cause that's what everybody's doing. So I had this kind of like complicated-ish sort of background. And at the start of 2025. AI, like if we went back a year and change ago, uh, I would have just been self-described as an AI hater. And then now, by now, a year later, uh, 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, uh, you know, that's sort of, I think, how we kind of got introduced or how you originally sort of 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 can 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 Blue Sky 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 be maybe in a sort of peer empiric 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 and what I care about the space. I think that the future is interesting, uh, and I don't know exactly what it's going to be like, but, uh, but that's sort of, yeah, I don't know. That's hopefully that's enough rambling to get started.

At least it is. Not only that, but I'm about to draw, draw you out a little bit more, uh, along that line of thought because, um, uh, you know, I followed you for a number of years. Uh, I was when I got into Ruby on Rails years ago. And then you wrote, I think it was the Rails 4 book.

I helped with that.

Yeah, yeah, yeah.

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 3 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. Maybe there's an angle. I was really surprised when we got to the holiday season and you announced Roo, which I know we'll get into in a moment. You talked a little bit about setting the facts and everything, but there was a 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 shit. Yeah, I shouldn't say that.

There's a couple things.

We're family friendly, so.

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 accidentally say it myself. Uh, it's all good though. No, so, um, 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, uh, when ChatGPT came out because I was with my family and, uh, like, um, 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. Cause 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, um, I ended up showing in particular my mom's boyfriend, uh, ChatGPT initially. And so, um, some time goes by and people are talking about things, uh, 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. Um, and then, you know, uh, no one is, no one is exempt from the opinions of those around them. We, we live in a society, we have friends, you know, you're, 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, uh, there's a couple different sort of angles to that that I'm sure we'll kind of get into, but I kind of just by default felt into, fell into kind of a like, you know, I 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, uh, 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, uh, 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 tar like, it's 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 kinds 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 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 timing is so interesting. I like happened to try I was like, I should be a more informed hater, so I'm gonna give these tools like a better try. And so I was like, what, what is the, 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 2 months after the first agentic 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 works. 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 going to 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 an actual human, not that there's that, not that much of an overlap, but like, I'm kind of a very strong opinions, weakly 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. So that's like a big sort of like shift in me. Um, 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. Cause I'm going to fix that in post. Cause 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 cause 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 productivity. 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, uh, 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 give 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. Cause 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 going to 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.

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 know.

I don't know the word normal. Yeah, exactly.

What they, how they kind of view computers, how 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 what they could do. I'm wondering, like, we'll talk, I think, more about Roo and some of that stuff as we go along, but In that respect, like, um, 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, um, 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. Um, but also I, 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. Um, and you know, what's, what's important, I guess, to preserve in that and important, like you say, to like, uh, 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 let go.

Yeah, I think that there's a couple of 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 are people at all, mind you, but like I, I have this, I've had this longstanding sneaking suspicion that being nice to AIs makes them perform better. Um, 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, cause I'll, I'll see people who are like, I tried this and, 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 cause I'm like, hey Claude, cause anyway, it's like a lot of—

that's an excellent sort of say. Uh, let's move on to the next step.

And yeah. And like, you know, there's like a non-zero part of, you know, I, um, I've started date, I'm about a year into a relationship with someone who 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 2-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 2 times in a row after I say it every time. But again, I don't think humans are people, LLMs are people, and she'll grow beyond that and LLM 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 thought Philosophy of mind was still arguing about what that means, actually. And you sure 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, um, but I think the trick is, so there's an old advertising, uh, joke that's like, um, you know, uh, 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, uh, acknowledgement that many of our industry practices are not actually backed by evidence at all, especially around things like clean code, like what, 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, 8 spaces is far too indent. You can't read that stuff. And so we really need to move to like 4 or 2. That's like a, I'm happy to never argue about that ever again.

It has to be 4.

Come on, man. Exactly. It's gotta be 4, not 2. And like, and so, but like, that's an easy one to like sort of like joke around about. But what I mean is, is that like another really interesting thing is that like, if we want to acknowledge that these tools interact with codebases in a different way, like what is good code to an LLM may not be good code to a human. And we need to recognize that like 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. It means a lot of mistakes. It means a lot of problems. It 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, um, like everybody's talking about software factories, uh, 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 to 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 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 OpenClaw 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 going to, problems are going to happen. Like people are going to lose their livelihoods. And I'm not saying that'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? So that's like, so that's like the thing. Yeah.

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

Yeah.

Yeah. But you've, you've hit, you've hit, uh, you've hit a point there that I'm spending a lot of time thinking about right now. And I really wanted to. To kind of ask you, because it sounds like you're getting there too, and that is that so many 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. You know, they actually add overhead in terms of that. And so that's been a, that has been something I have been thinking a lot about is like, as we get into this kind of new, new approach to software development this year, like 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, you know, maybe not today, but at some point in the not so distant future may be able to produce amazingly capable software without the need for all these things. So, uh, 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.

Yeah.

Uh, is that, is that accurate?

Like, again, I haven't really talked about my product at my job, but it's like Forge-shaped, right? Like, like you upload code to our thing and then, you know, people use the code to work on your stuff. And so like, this is a, 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? Cause 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 or 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 that is sort of, you know, the core, like you still, like humans are still doing this and we're doing it 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 Claude 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. And 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, uh, 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 you know, it's sort of like, that's an example of 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 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 at my 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, it's a little selfish and a little self-serving. And I think a little like almost insensitive, uh, 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 at 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 overhiring. And I think some of it is just like poor management. And again, And 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. Cause 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 hire people. Yeah. 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 going to be 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.

And, uh, yeah, I, I, I, I love, I think I'm going to fall asleep thinking about a lot of these topics because 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, um, yeah, I, I am curious about this particular, um, you know, effort that, that you did with the, uh, with Roo and like what that means. Like maybe you could set the stage. Just like, how did this idea come up? And like, what was the concept, I guess?

Yeah. So there's a couple of 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, and so like, you know, it's been a couple of 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 in open source, Steve. Like there was a time when I was the 17th most committed person on GitHub. And like, that's cause like GitHub was like way smaller back then, but like I was like legitimately up there. And, uh, 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 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 Roo 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 backend. I'm interested. I don't know as much about CodeGen as I like I 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 5 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 are working on 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 boot it up and it would fail boot. I was like, man, that took us like 2 weeks to figure out that there was like something slightly wrong. I don't even remember what it was, but I used to tell that story as like, man, that was awesome. I spent 2 whole weeks working on this bug. You know what 2 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, 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. Um, 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, 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 Roo 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, 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 do that work is like totally fine. So anyway, I actually started Rue last August because I had some time going on back then. And then, um, it's 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 at the same time, my community 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 work on it at all. And so I came back and a couple of 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 what we generally acknowledge that Vim is useful, even if it's not, maybe for 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 Roo, combination of the models being worse, plus me being worse at it. Uh, meant that I kind of backed myself into a corner where I bit off too much. I, I made my PRs too big. These are, these are all not new problems. Uh, 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. Um, 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 along it has gone way, way better. And I am like very happy with the overall quality. And, uh, 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, 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 tests 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 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. I could talk forever if you let me. So it's just like, you gotta cut me off sometimes. I go too much.

It's perfect.

No, all good. It was good stuff. Um, 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 Roo 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 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, you know, Roo is not ready for, you know, production code and 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, you know, hey, we're on the show right now. And So like, what is your intention in terms of like what problem to solve and maybe eventually in the future 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. So right before I get to that, there's one other part that's similar that I wanted to get to that I didn't say earlier, which is just that I also, a lot of people are are on 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.

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, um, there's a lot of people. So I got involved with Rust because I knew there had not really been any credible challengers to C in a long time. Again, Go was brand new at the time. And also, is Go a challenger to C is a whole giant flame war 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, Rust is like—

I'm with you. It's more Java. 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. Uh, 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 needs maximum performance and all that stuff. And that's why I got I 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 no GC is like the 7th reason I would use Rust for a programming project. Uh, 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 for me, like, 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 in 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 has kind of like backed away from, uh, 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. And so that's the niche I want Roo to exist in, or that's kind of the, like overall spot for it, I think.

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

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? 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. It, uh, 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. Um, and so yeah, that's kind of like the space. Uh, there are some problems with that. And so as a consequence, one of the reasons why Roo 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 Roo. And he's like, I've tried to write real programs and you're like so close. Like even if you'd never do anything with it again, can you please just fix these 2 or 3 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 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, uh, 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 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 that's the 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, Roo is like sort of this weird mix 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, uh, with it. 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 actually using AI to help me write that script with my validation and then, or spec, I mean, 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 times in your life. Has anything of those like skills that you learned in this AI-human teaming kind of project, has that filtered into things that you have 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 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 gonna 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 codebases 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, Hey, 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, uh, 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, uh, that means you need to be aware of what people are doing. And so I spend 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, uh, 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 got to give up stressing out about drive. A little bit. Um, I, I definitely have 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 5 copies of this function in here, dude. And in the past I would've 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 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? Cause like they're identical strings and there was, it was in 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 going to leave them in there for now and it's going to be fine. There's 7 strings in this file. They're all identical. That's chill. 2 or 3 weeks later, he's still working on this codebase and I'm watching him do this 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 5 keys with and like changes all 6 of them at the same time or whatever. And it's like, cool, that took half a second. You know, DRYing this code out would not have actually, cuz 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 core. A human thing. That's a human thing. And so like 5 copies of the same function, sure, it makes my program a little bigger. Maybe we need to care about our program sizes, maybe in some contexts, but like, what if there's 5 literally identical copies of a function in my codebase 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 codebase 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 or 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 going to say that goes back to kind of what we were talking about a little bit earlier in the conversation about kind of reevaluating 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. 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, if you, uh, 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 of Vru, the way you see it, and then the other one is kind of future of coding this way that we're talking about, you know, 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, you know, how do you see that going forward? So both Roo and AI-assisted software dev, go.

So with Roo stuff, I hope that it's a project I continue working on. It's my '69 Chevy in my garage, you know, so like 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 an experiment, a thing that I get to return to and something that I get to play around with and try out this kind of stuff. 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 Roo 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. Uh, so we'll see. Um, 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 got to 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 like things are happening. And then Anthropic released Claude, you know, swarms and like 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 like 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 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 100 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. Click 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 going to 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 or is the next step of the future is How do we, how do we have trust in these tools that are not going to totally harm us? And that, 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 some, 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. So, yeah.

Well, um, I'm, I'm looking forward to having you back on the show when you've got that one solved, Steve.

Um, excited for that.

I'll bet on it. Yeah, yeah, yeah, totally. So make Maybe next week you could come back and let us know the result.

Yeah, yeah, yeah.

But yeah, this is a great conversation. Really, really appreciate you joining.

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

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 Bluesky. Blue 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 PredictionGuard for providing operational support for the show. Check them out at predictionguard.com. Also, thanks to BrakeMaster Cylinder for the beats, and to you for listening. That's all for now, but you'll hear from us again next week.