Latest / Practical AI / Humility in the Age of Agentic Coding

Transcript

Humility in the Age of Agentic Coding · Practical AI

0:04
Narrator: 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 Blue Sky to stay up to date with episode drops, behind the scenes content, and AI insights. You can learn more at practicalai.fm.
0:38
Now, onto the show.
0:53
Daniel: Welcome to another episode of the Practical AI Pod cast. This is Daniel Whitenack. I am CEO at Prediction Guard, and I'm joined as always by my cohost Chris Benson, who's a principal AI and autonomy research engineer. How are you doing, Chris?
1:07
Chris: Doing great. Enjoying, having fun, and and, gosh, gosh, the weather where I'm at is awesome. So, like Yeah. Yeah. I force had myself to come in to do the show today.
1:17
So
1:18
Daniel: Yeah. Yeah. I unfortunately had a 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.
1:28
Chris: Welcome back.
1:29
Daniel: Yeah. Thanks. It's good to be back. And, and, yeah, for our listeners, just one thing you might wanna be aware of, if you are in the San Francisco area or if you're attending RSA, I'm gonna be at the conference at at RSA, out in San Francisco March 2026. If you're listening to this years later, I won't potentially be there years later, but this year I'll this year I'll be there, and, and I do have, like, some some meeting space where I can meet up with people if you wanna talk about enterprise y AI things, or I'm gonna have some demos on, like, you know, AI build materials and some cool prompt injection stuff.
2:09
So if you're if you're into that side of things from the security enterprise AI side, I'll I'll include the link in the show notes if people wanna figure out where to find me or or, find a time. So, look me up there. But, really excited to to get into the conversation today. We have, an amazing guest with us, who I'm I'm excited to get to know a little bit. Really intrigued by his work, Steve Klabnik, who is a software engineer, and I'll leave it up to you, Steve.
2:41
Maybe you can you can describe why
2:44
Chris: Software engineer extraordinary.
2:46
Daniel: Software engineer extraordinary. How you ended up on a on a AI podcast, what what your background is, and how where that intersects with AI, I guess.
2:56
Steve: Yeah. Thanks, guys. I thanks for having me. It's 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.
3:04
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 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 seven 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.
3:38
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, 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 ten years working on the Rust programming language and wrote a book, also called the Rust programming language with my co authors. Hey, Carol.
4:13
Chris: The book.
4:14
Steve: Yeah, thanks.
4:16
Chris: Just saying, it is the book.
4:18
Steve: Yeah, people in the Rust world call it the book, which is very nice. But so, I've kind of been like interested 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 gonna make websites now because that's what everybody's doing. So I had this kind of like complicated ish sort of backgrounds. And at the start of 2025, like if we went back a year and change ago, I would have just been self described as an AI hater.
4:48
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 kinda 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.
5:26
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 sort of almost like I have my own sort of thoughts about where stuff is going and whatever else but when I read things, a lot of the stress of this past year and what led to my writing was me being like, wrote a post almost a year ago, it was in May 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 ChattypuTi for the first time, and I asked it a question and it was like searching the web and it showed me all the websites that searched and stuff. And then I'd switch over to blue sky and I see a post that's like ChattypuT cannot literally search the web. It is not a search engine stop calling it a search engine.
6:14
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 Pyrrhic 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 where I am and what I care about the space. I think that the future is interesting, and I don't know exactly what it's gonna be like, but that's sort of, yeah, I don't know.
6:56
Hopefully that's enough rambling to get started at least.
6:58
Chris: It is, not only that, but I'm about to draw you out a little bit more along that line of thought because, you know, I followed you for a number of years. Was when I got into Ruby and Rails years ago, and then you wrote, I think it was the Rails four book.
7:16
Steve: I helped with that. Yeah. Yeah.
7:18
Chris: Yeah. And I 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 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.
7:33
So, you know, it's one of those things where I was interested and 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 gotta find a way to get Steve onto the show, but he's not writing blogs that are very conducive to that. So, like, 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 kinda 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 in 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 kinda laying those out, but, like, what what what happened, man?
8:27
You know? Like, how did that was a turnaround. I was like, holy Yeah. Oh, I
8:31
Steve: shouldn't say that. There's a couple things.
8:34
Chris: We're family friendly, so
8:35
Steve: That okay. That was a good that's oh, yeah. That was only a prepodcast question. I didn't get answered is how much can I curse because I'll accidentally say it myself? It's all good though.
8:43
So okay. So, 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. So you know, you're curious when you post a lot of stuff online and it says it's been trained on the internet, know, you're like, who, know, do you know who this is or whatever? But like, 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.
9:41
It seemed like a fun kinda like party trick, but I didn't really think about it too much. And then, you know, no one is exempts 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 that I'm sure we'll kind of get into, but I kind of just by default felt into kind of a like, I asked it to write some Rust code and it barely does it correctly and it's like kinda 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.
10:36
He was managing a coal tar, 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 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 got out of the online echo chamber and I talked to somebody who has like no idea where the echo chamber even is, let alone what is the echo chamber was about. So his fundamentally, what really changed 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, happened, it's timing is so interesting.
11:31
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 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 agentic stuff started appearing at all. And so I installed an extension called Klein into Versus Code and I started, you know, using it.
11:56
And I was like, oh, this is like very different than me asking Chateappiti 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. 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.
12:17
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 that much of an overlap, but like, I'm kind of a very strong opinions, weekly held kinda guy. And so, I definitely like say things more strongly than I believe them sometimes, just sort of by default.
12:47
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 gonna 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.
13:09
And those conversations with my mom's boyfriend largely revolved around things like, I was like, okay, 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.
13:27
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 need to, I love editing stuff, but I hate writing things. I'm gonna fact check everything that I write before I send it out.
13:40
And if it's 10% wrong, that's totally fine. Cause I'm gonna 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 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 to me has really, really helped my own productivity And like, I don't trust computers at all. You know, he's retired now to give you a vague idea of his age.
14:08
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 so many programmers like, it's not a compiler because it's not deterministic. There's non determinism, it doesn't gives the wrong answer 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 non programmer mindset up to computers really was what made me go like, oh yeah, like that's like kind of a good point sort of like, he's more equipped mentally and like in techniques to deal with something that lies 20% of the time than I am.
14:52
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 it to do the wrong thing. Right? But like that's sort of, that was like a really big shift for me specifically. And there's also, I think 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.
15:21
But I like wanna 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.
15:40
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.
15:47
Daniel: 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 I forget what you use. Normal people or non programmers or whatever it is. Don't know. Don't if they're normal.
16:03
I don't know. Yeah. Exactly. What what they how they kind of view computers, how they they're interacting prior to AI and now, and how you wanna 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 Roo and and some of that stuff as we go along.
16:29
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 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, I yeah. I 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.
17:29
Steve: 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 mean.
17:55
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 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 show me the transcripts?
18:30
And it's like, when Klabnik 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, Klab. Because anyway, it's like a That's
18:40
Daniel: an excellent try. Let's move on to the next step.
18:44
Steve: And yeah. And like, you know, there's like a non zero part of, you know, I started dating, 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 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.
19:04
But again, I don't think humans are people, LMs are people and she'll grow beyond that and LM you won't or whatever else. It's just like, those are the kinds of experiences that were like breaking my brain in terms of people being like, man, wait, you know what consciousness is? Like 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.
19:23
Daniel: You sure
19:23
Steve: see 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%.
19:47
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 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, oh 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.
20:23
That's like a, I'm happy to never argue about that
20:25
Chris: Not ever two. It has to
20:26
Steve: be four. Come on, Exactly. It's gotta be four not two. 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 wanna acknowledge that these tools interact with code bases in a different way, like what is good code to an LLM may not be good code to a human.
20:45
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 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.
21:08
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.
21:31
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 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 nineteen tens, let's see if remember history, right? There's a bunch of dudes strapping wings of their arms and jumping off buildings and dying.
22:06
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 Open Claw like at all.
22:27
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 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 gonna poo poo them exactly because like they may uncover something cool and I welcome their sacrifice.
22:49
You know what I mean? So that's like the thing. Yeah.
22:53
Chris: So I was I was going to to like next question drive you toward Rue a little bit.
22:59
Steve: Yeah.
22:59
Chris: 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 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, nano services, 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 to help ourselves be 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, changing that role of how the human fits in.
24:14
And so it sounds like you're hitting a little bit on the same kind of questions there.
24:19
Daniel: Yeah. I mean
24:20
Steve: Is that accurate? Like, again, I haven't really talked about my product or my job, 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 an active 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?
24:45
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 or that we're not doing them or anything. This is not like a statement about what's gonna end up coming out the other end. But like, you know, I do like wonder like, okay, what is the, what do these steps look like? And like, what's that happening?
25:03
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 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.
25:29
Like 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, 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.
26:09
Like that's like a nineteen fifties, nineteen sixties, 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 one and has 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 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 gonna be not true in the future.
26:37
And I think that matters because like so much of this, like being upset about AI stuff is this existential question about when I meanest, I'm like, software developers jobs, our industry's jobs has been automating other people out of jobs for fifty 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 in the way that some people react, but also I got a mortgage. If I don't have a job, I'm gonna be upset.
27:04
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 used to 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?
27:35
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 ZERP over hiring. And I think some of it is just poor management. And again, you lost your job due to poor management is not like a soothing thing to say to someone that lost their job.
27:53
I'm not trying to trivialize that aspect of But it I think that once we get through this period of learning, like we're gonna learn that we need more programmers than ever. We're gonna need more people than ever because like when you 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. Yeah.
28:19
I'm hire 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 be worried about software developers losing their jobs. But as long as they're hiring, like, I think we're good, probably.
28:48
We'll see.
28:49
Daniel: And, yeah, 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 could set the stage with like, how did this idea come up and like, what was the the concept, I guess?
29:23
Steve: 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, did not I was not on the language team. I didn't do that.
29:33
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 work on a compiler. And so, and 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.
29:53
And, I have had less free time in my life than I ever have. Like in my twenties, I remember distinctly being like, why doesn't it People are like, you were so productive in open source, Steve. Like there was a time when I was the seventeenth most committed person on GitHub. Like, that's because like GitHub was like way smaller back then. But like, I was like legitimately up there.
30:11
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 Rue 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.
30:29
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 on all the code, I'm not gonna get far enough to the interesting parts. I don't really care about parsers. I'm not like really interested in the front end.
30:45
I'm interested in the middle end. I'm interested in the back end. I'm interested. I don't know as much about code gen as I should. And so I wanna like learn that and the best way to learn is by doing, but you know what like sucks?
30:54
Saying that like, I have five free hours of work time a week and I'm gonna 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 operating system in college and like, we couldn't get the machine to boot. Boot in Kimu, we put the disc into the actual computer and we boot it up and it would fail to boot. I was like, man, that took us like two 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.
31:25
I 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.
31:38
And so for me You're not old. Yeah. Sure. I know. But like
31:42
Chris: You're not old. Trust I'm
31:43
Steve: getting there. And so it's it's really great, you know, to have the forty 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 cool. But no, 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.
32:13
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 RU or you should use it. It's actually not even really ready for human consumption yet. I'll 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.
32:39
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 deal at work is like totally fine. So anyway, I actually started Rue last August because I had some time going on back then and then 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 kinda like not happy with it and at the same time, my community got very very busy. So, I dropped it entirely.
33:14
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 like Vim. Like, we joke about Vim being hard to quit, but like nobody says that Vim is a bad tool.
33:36
I mean, some people do, but like what we generally acknowledge that Vim is useful even if it's not every Emacs person or whatever else person like, you know, we don't derive 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 wanna 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.
34:03
And so this first iteration of Rue 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 kinda got bogged down and I wasn't really feeling it super great.
34:28
So, like November, December rolls around and I started having time again. And I was like, okay, I learned a lot from this first iteration. I wanna 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.
34:45
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 has to do with my approach. So for example, a thing that people get upset about with Rust all the time is like, 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 test pass.
35:27
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 Klab 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.
35:57
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 changed sort of the architecture of the project and a bunch of other stuff like that. So, that's where it's at, like kinda now. Said I was a yasper. Super Steve. I could talk forever if you let me.
36:29
Daniel: So, it's just great.
36:30
Steve: You gotta cut me off sometimes, because I go too much.
36:32
Daniel: It's perfect.
36:33
Chris: No, all good. It was good stuff. But, I wanna ask, so as you totally get wanting to scratch the itch, wanting to create it, and you now have a tool that kinda helps you get there given the fact that you're short on time, which is normal. I'm the same way. And so you kinda have this pet project, but as you were kinda 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 kinda talks about, you know, position between Go and Rust, know, maybe some C and things like that.
37:12
But is your thinking about that? Like, what a, why why did you what was the problem you were trying to solve? And and what is your thinking about solving that problem while you've been very explicit so far that, you know, Rue is not ready for, you know, production code, and that kind of stuff in in your in 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.
37:41
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?
38:06
Steve: Totally. So, right before I get to that, there's one other part that's similar that I wanna get to that I didn't say earlier, which That's fine. Is just that
38:13
Chris: Go for it.
38:14
Steve: I also, a lot of people are in 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.
38:42
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.
39:02
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
39:14
Chris: I'm with you, it's is more Java.
39:15
Steve: 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.
39:30
And so we're building a thing that's for operating systems and kernels and use maximum performance and all that stuff. And that's why 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 seventh reason I would use Rust for a programming project. I love the tooling, I love the error messages, I love the 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.
40:03
So for me, like basically I think that there's 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 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 kinda like backed away from, you know, as a stance for them and I think it's totally fine, but like, I want some types, I want super strongly typed stuff, like, I like the heavy type system things, but those languages all come with like lack of speed for various reasons and all these things.
41:22
So that's the niche I want Rue to exist in or that's kind of the like overall spot for it, I think.
41:28
Chris: Did you go with garbage collection or without garbage collection?
41:32
Steve: 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 DGC 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 kinda, I'll hand wave for the purposes of this conversation, but like there's like things that you can kinda 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.
42:11
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, that's kind of like the space. There are some problems with that and so as a consequence, one of the reasons why Rue is not really ready for regular programmers yet is, 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.
42:46
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 Rue, 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 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.
43:20
I just have a lot of stuff going on in my life right now. And so, but like, yes, that's kind of 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.
43:49
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 Rue is like sort of this weird mix of like Swift, Rust, Zig and Go. Like basically, like it's kinda 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.
44:16
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 kinda what I'm trying to do with it, yeah.
44:24
Daniel: I love the observation around the spec. That was also, I mean, 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 the 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 the 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?
45:22
Like, should we be doing should we be doing this or, you know, has
45:25
Steve: that A little bit, but like, there's a couple of different things. One is, I personally have been working more upstream JJ, than on our product, and that's kinda 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 code bases I'm not working on. So, have like not really broached a lot of that with a lot of people, but our team are like, we are not like super cutting edge, let's make Klab 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.
46:09
I think we're much more like median in terms of our AI usage, 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, 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 product perspective of like what we kinda need to be working on with those sort of things.
46:44
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 when you start using these tools, you gotta give up stressing out about dry a little bit. 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 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 But now my opinion is like, something closer to like, okay, cool.
47:21
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.
47:34
He really changed some of opinions on dry specifically where there's one of his early screencasts he did. 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 it was in tests specifically. So tests are often very repetitive.
47:54
So there's a question of like, should you dry up your tests? It's been a thing people have been fighting about for a long time. Right? So he's like, we're gonna leave them in there for now and it's gonna be fine. There's seven strings in this file.
48:03
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.
48:15
And he does some, he taps like five keys with VIM 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?
48:40
That's like the core A human thing. That's a human thing. And so like five copies of the same function, sure it makes my program a little bigger. And maybe we need care about our program sizes, maybe in some 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 clean it up later, like I am more willing to commit minor heresies into my code base and then fix them later.
49:08
Like there's sort of the bigger picture thing I think is that we have been focused on shifting left 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 kind of okay to not have the cleanest possible code because it's easier. It's 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.
49:56
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 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.
50:10
Chris: Was gonna say that goes back to kinda 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 and lots of other things. Do 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 we'd like to hear is is getting your perspective on the future. From our perspective, if you 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 gonna ask you in in two two versions, if you will.
50:54
One is kind of future of RUE, 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 the way we approach software development, you know, how do you see that going forward? So both Roo and AI assisted software dev, go.
51:19
Steve: Yeah. 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.
51:38
And 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 RUE 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.
52:03
I've kinda been 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 back in November or December, 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.
52:24
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.
52:49
That is just, it is like a thing. Like I shipped a 100 PRs on Rue on Christmas day while hanging out with my family. And with Rue, I have read every PR that I merged. But what I mean by that is not like I spent thirty 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 myself that I was not really truly reviewing those things.
53:16
And so when I look at like my personal projects, like 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 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, 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 like, how do we have trust in these tools that are not going to totally harm us?
54:04
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 pay off in terms of solving the software development engineering, the software engineering question of right now, think is that question. Yeah. Well,
54:23
Daniel: I'm I'm looking forward to having you back on the show when you've got that one solved, Steve. Yeah. Excited for that. I want it. Yeah.
54:31
Yeah. Yeah. Totally. So maybe next week, you could come back and Yeah. Let us know the Yeah.
54:35
Yeah. This is a great conversation. Really, really appreciate you joining.
54:39
Steve: Totally. It's been great. Thanks so much for having me.
54:48
Narrator: Alright. That's our show for this week. If you haven't checked out our web site, head to practicalai.fm, and be sure to connect with us on LinkedIn, X, or 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, Prediction Guard, for providing operational support for the show.
55:09
Check them out at predictionguard.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.