Humility in the Age of Agentic Coding

28:11It 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 home. 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.

28:36Anyway, 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 good, probably. We'll see. And yeah, 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, with Rue and like what that means.

29:17Like maybe you could set the stage with 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.

29:45And 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 were 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 because like GitHub was like way smaller back then. But like, I was like legitimately up there. And I was always like, why don't people ever have time for open source?

30:15And 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. 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.

30:41I don't really care about parsers. I'm not really interested in the front end. I'm interested in the middle end. I'm interested in the back end. I'm interested. I don't know as much about CodeGen as I should. And so I want to like learn that. And the best way to learn is by doing. But you know what like sucks? Saying that like I have five free hours of work time a week and I'm going to spend that debugging a register allocator on why x86-64 is like using LEA incorrectly or like whatever. That's like not, you know, I, in college, a bug that I fought all weekend. Like there was a time, you know, my friends were working on an operating system in college and like we couldn't get the machine to boot.

31:14Boot in Kimu, we put the disk 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. I was like, man, that was awesome. I spent two whole weeks working on this bug. You know what two whole weeks working on a stupid bug means in my project now? It means that I'll go play video games or like hang out with, you know, the people I care about or like do something else. Like I'm just I'm old. And so for me, you're like you're not old.

31:41Yeah, sure. I know. But you're not old. Trust me. I'm getting there. And so it's really great 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, I graduated college in 2008. So 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 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.

32:18And 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.

32:48It's like reviewing stuff. And so for me, like having Claude do that work is like totally fine. So anyway, I actually started Roo last August because I had some time going on back then. And then my velocity slowed down a lot. And I started getting into problems where it would spin all night and not make progress. And I was kind of not happy with it. And at the same time, I conveniently got very, very busy. And so I dropped it entirely. And so from like August to November, I pretty much didn't really do anything because I just didn't I didn't have the time to work on it at all. And so I came back and a couple of things had changed.

33:24The 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 every max person or whatever else person like, you know. 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.

33:53But 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, meant that I kind of backed myself into a corner where I bit off too much. I made my PRs too big. These are all not new problems. You know, I merged some stuff that was of questionable quality for velocity reasons because it's a side project. And so it kind of got bogged down and I wasn't really, you know, feeling it super great.

34:29so in 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 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 some of that has to do with my own skill some has to do with my approach so 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.

35:02This is not like this is off topic of a tangent of tangent. But like a thing that I did that I think matters in terms of like practically speaking, making this better is I focused on validation. Like I think one of the most critical things to do when developing with agentic programming is give the agent the ability to evaluate if its work is correct or not, because it iterates towards a fixed point. and that fixed point is test pass. And so I actually did like language spec driven development. I actually said like, let's work on a language specification first. And then I ended up writing a custom test framework with Claude because I'm being a little extra about it that takes the language spec and connects those to test cases.

35:43And 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 significantly increased my success rate and also let me 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 at the old time, I was just running the code myself and that was slower and more error prone than this time around.

36:17And so that's one specific example of why it's going better this time. But 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, kind of now. See, I said I was a yapper. I could talk forever if you let me. So it's just like, yeah. You got to cut me off sometimes. I go too much. It's perfect. No, all good. It was good stuff. But I want to ask, 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 normal.

36:48I'm the same way. And so you kind of have this pet project. But as you were kind of defining what Rue would be as you're scratching your itch on this, and it's like I think in your blog post 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, Rue is not ready for, you know, production code and that kind of stuff in how you've addressed it with the public.

37:36being 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, and maybe eventually in the future, when the when the language is a little bit more mature, if it gets more mature, like, what would you see people using it for? and why versus Rust, which you're famous for, or one of the other, or Go, you know, how are you seeing that? Totally. So right before I get to that, there's one other part that's similar that I want to get to that I didn't say earlier, which is just that I also, a lot of people are in the question of like, can a new programming language work?

38:19Because if a programming language isn't in the training corpus, how can an LLM write the language? And so part of my goal with this project was to invent a new language and make Claude write a ton of it because I wanted to see how good it would be at using a language that literally did not exist before this project happened. So there was some of that. And the second one is like a lot of people have said, it's good at writing a React web app, but it couldn't do anything like a compiler or an OS. And so I wanted to like prove out like it could write a production compiler. So those were also parts of this.

38:48The reason I settled on this project was that stuff. In terms of the language itself, there's a lot of people. So I got involved with Rust because I knew there had not really been any credible challengers to see in a long time. Again, Go was brand new at the time and also is Go a challenger to see is a whole giant flame where we could like get into. But to me, I was very much of the like, GC means no. So like whether or not that's right or wrong, I was like, Rust is like - I'm with you, it's more Java. Yeah, yeah, yeah. And so I think those like, in reality, I think those categories are much more blurred than they are in actuality.

39:21But like at the time, I was a little less educated slash I had stronger opinions. I was a lot younger then. And like, so I was like, okay, we need this low level language. And so we'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 OGC is like the seventh reason I would use Rust for a programming project. I love the tooling. I love the error messages. I love ownership and borrowing, but like not because I'm like slinging pointers around, but just because I think it helps me make more clear programs.

39:58And 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 and performance style thing.

40:48And so I wanted to play around in that kind of space because if there was something that was like just a little, like just a little higher level than Rust and just a little more performant than Go that compiled instantly, like I think that's a thing people would use. People want advanced type systems, which again is something that Go is kind of like backed away from, you know, as a stance for them. And I think that's totally fine. But like I want some types, I want super strongly typed stuff. Like I like the heavy type system things, but those languages all come with like lack of speed for various reasons and all these things.

41:22So that's the niche I want Rue to exist in, or that's kind of the like overall spot for it, I think. 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 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.

42:02So basically you give up a teeny little bit of expressiveness for any of the Rust nerds out there, you give up the ability to save references inside of structs. That's fundamentally what you give up. And you give up a little bit of returning references from functions too, not entirely, but like a little bit. And in exchange for that, you have no borrow checker and you have no lifetimes. And so I think there's a ton of people who would absolutely make that tradeoff, basically. And so, yeah, that's kind of like the space. There are some problems with that. And so as a consequence, one of the reasons why 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.

42:46As 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 ever 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 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.

43:42And 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 as a safety checks, they're 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, is 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 kind of like what if you just take all those things and mush them together and like, you know, and that's fine.

44:12Like I'm not claiming that I've invented some sort of new magic thing. A lot of programming languages are just taking the good stuff from other things and shoving them together in an interesting way. And so that's kind of what I'm trying to do with it. I love the observation around the spec. 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 or spec, and then going to actually implement it. I'm wondering, as you've gone through that, like this is kind of was part of what you were doing on the side when you had those those times in your life.

44:57Has 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 opinion in an opinionated way brought back to your kind of day job and the team that you're working with? Like, hey, if we did X, like, have you guys, you know, have you guys also found this to be true? Like, should we be doing should we be doing this or, you know, has that happened? A little bit, but like there's a couple of different things. One is I personally have been working more on upstream JJ than on our product. And that's kind of going to switch sort of soon.

45:36But like I kind of have been not I personally have not been like hacking on our product for various reasons. So I try really hard to not force my opinions on code bases I'm not working on. So I have like not really broached a lot of that with a lot of people. But our team are like, we are not like super cutting edge, let's make Claude do all the work kind of things. We are much more of a, these tools help me write code and I use them. And we don't really have like a mandate for like, you need to write code this way and like, you know, whatever else. I think we're much more like median in terms of our AI usage as a team.

46:14And 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 a product perspective of like what we kind of need to be working on with those sort of things.

46:44But some of the stuff, I'll give you maybe a spicy one that's like a practical thing that I think is, I think that when you start using these tools, you got to 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 process. But now my opinion is like something closer to like, okay, cool.

47:21Can you fix that, please? Great. I'll merge that PR. That's fine. And sort of the reason why is that like, if we go back to think about like why way before AI, there's a time with Gary Bernhardt and one of his things, shout out Gary. He really changed some of my opinions on dry specifically where there's one of his early screencasts he did. He did this thing where there was like a bunch of SQL files or something, had a bunch of strings that were basically identical. And he said, hey, should we abstract these out into a constant? Because like they're identical strings. And it was in tests specifically.

47:52So tests are often very repetitive. So there's a question about 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 going to leave them in there for now. And it's going to be fine. There's seven strings in this file. They're all identical. That's chill. Two or three weeks later, he's still working on this code base and I'm watching him, you know, do 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 five keys with Vim and like changes all six of them at the same time or whatever.

48:21And it's like, cool, that took half a second. You know, drying this code out would not have actually, because like the reason we care about dry is because we want all the logic to be in the same place and we want the same logic and we'll make it easier to change later. We are worried about, I modify one copy of the function and then that doesn't, we use the other copy of the function and we reintroduced a bug somewhere else, right? That's like the core. That's a human thing. And so like five 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.

48:50But like what, if there's five literally identical copies of a function in 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, like I am more willing to commit minor heresies into my code base and then fix them later. Like there is sort of the bigger picture thing, I think, is that we we have been focused on shifting left in the development process because we all know from Toyota that like the earlier in the process you find problems, the more that you fix them, the cheaper it is to fix them. Right. And so we've been like sort of almost everything is downstream of like shift left, shift left, shift left.

49:27But like, what if certain things were OK 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 OK to not have the cleanest possible code because it's easier. it's and even the more advanced people with dry would say don't repeat yourself wait till the third or fourth repetition before you bother going back and cleaning it up but i think that translated to like two identical strings must be turned into a constant for a lot of people so i think there's like there's like a wave of opinions that's always been there and i think that just like we're moving back towards a little more duplication is kind of okay so yeah i was gonna say that goes back to kind of what we were talking about a little bit earlier in the conversation about kind of reevaluating, you know, you have new capability and do all of the human aids that we've put in place dry and lots of other things, do they need to be there?

50:25I don't know the answer, but it's certainly something that probably will be discussed and evaluated as we move forward. And speaking of moving forward, as we are getting to winding up, one of the things that we like to hear is getting your perspective on the future. From our perspective, we ask people not to worry about if they get it wrong, but just like as you're thinking about the future at this point, and I'm going to ask you in two versions, if you will. One is kind of future 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 way we approach software development, how do you see that going forward?

51:15So both Roo and AI-assisted software dev, go. So with Roo's stuff, I hope that it's a project I continue working on. It's my 69 Chevy in my garage, so it'll sit there for a while and I'll work on it and maybe it'll be a cool thing other people find useful in the future, but I mostly want it to be a thing that I get to return to and something that I get to play around with and try out this kind of stuff. And so 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.

51:47So 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. So we'll see. In terms of everything else, I think my biggest problem is that I don't know. I've kind of been in a little bit of a quiet period lately I have not been writing blog posts and I have one or two I've been working on but I gotta like ship but the back in November December of last year I felt like I had a couple 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.

52:32And 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 Rue on Christmas Day while hanging out with my family. And with Rue, I've 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.

53:16And 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 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 like, how do we how do we have trust in these tools that are not going to totally harm us?

54:04And that doesn't mean no oversight either. I'm not saying that you can't not read the code, but just like, I don't know, there's something in that space is like the biggest price performance payoff in terms of solving the software development engineering. The software engineering question of right now, I think, is that question. So, yeah. Well, I'm looking forward to having you back on the show when you've got that one solved, Steve. I'm excited for that. Yeah, yeah, totally. So maybe next week you could come back and let us know the result. Yeah, yeah, yeah. Yeah, this was a great conversation.

54:38Really, really appreciate you joining. Totally. It's been great. Thanks so much for having me.

54:48All 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 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 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