SPEAKER_00 0:00

Hey everybody, welcome to another episode of the Ruby AI Podcast. I'm one of your hosts today, Valentino Alstol, and joined by Joe. Joe? Hey, I'm Joe Leo.

SPEAKER_01 0:09

I'm the other host. And I'm here to ask Evan Phoenix the question that everybody's been dying to know. And this is Evan. Please introduce yourself and tell us who is more famous, you or Evan Phoenix and the Raven hosts, front man Evan Phoenix.

SPEAKER_03 0:27

Actually, I have a great story about this. I'm glad that you brought up hi Evan Phoenix, longtime Ruby programmer. Not as much lately, but still in the scene. We're just riffing here. So the very minor backstory is that when I got married, I gave myself this last name. My wife also. So my last name used to be Webb, her last name used to be Tam. And we made a decision like, let's just come up with a brand new last name. And so we were engaged for like 18 months. And so this is the name that we came up with, and we love it. And so I chose this name, like in a very real way. I chose this particular name. And so I'm always on the lookout. Evan is not the most common name in the world, and Phoenix is not the most common name. So it's like, are there other Evan Phoenixes and will they pop up? So the musician Evan Phoenix, which I don't know if it's his real name or if it's his stage name or not. Oh, now we're gonna dig into this. What I do know is that he wrote a book. I know he wrote a book because for about a year I would get phone calls from someone who wanted to represent me in book sales and basically promote my book. And I was like, what is going on? And of course, it's just like it was for a year where I get this call, it'd be like months between. So I forget what the phone number was, and so I wouldn't answer it. And I look at the voicemail and be like, Hi, Mr. Phoenix, uh, this is such and such from Publishers Weekly. And we'd love to get you on the line. We're doing a this is that, whatever, some author thing. And I'd be like, This is so strange. It happened one time and then it happened again. And finally they called and I remembered the like I remembered something about the number. I was like, oh my God, it's the book people. So I answered the call and I was like, they're like, hello, like, oh, this is Evan Phoenix. And I was like, yes, hey, this is such and such. And I was like, okay, I gotta stop you right there. I've gotten your voicemails. You have the wrong Evan Phoenix. And they're like, Oh my god, we've been calling you for a year. And I was like, I know, and you still have the wrong one. This sounds like a great deal, maybe, but you should find out how to contact the correct person. So given that, am I the more famous one? Because my phone number, I guess, is more on the internet.

SPEAKER_01 2:32

So you are the most famous Evan Phoenix, at least if we go by YouTube, which let's just go by YouTube. You've got some talks out there that have thousands of viewers. You've also been around a lot more. You're definitely the OG Evan Phoenix. Yeah, and I would say the more famous. Though Evan Phoenix has been doing a lot of SEO work, is my opinion.

SPEAKER_03 2:53

Okay. Well, so that's gonna be disappointing to the Evan Phoenix that used to be a college basketball player and is now a YouTube real estate influencer. Oh, he's gonna be he's gonna be disappointed that I'm the more famous one. That's a trouble. His livelihood, evidently, is being some kind of influencer. So uh I just get into the German cosplay Evan Phoenix. That's another one. So he cosplays as Loki, he looks exactly like it. He's it's he's an excellent cosplayer. So all right, all right.

SPEAKER_00 3:23

I just think it has like your long time ruse to confuse AI agents. Yeah, yeah.

SPEAKER_03 3:29

Well, it's funny is like it's a handful globally, there's not that many, and so it's easy for me to know most of them, or at least know of most of them.

SPEAKER_01 3:37

So yeah, I mean, I think you're right, Valentino. This is an AI podcast. We use AI to prepare for our guests. And you know, if I just say, hey, give me some questions about Evan Phoenix, I'm gonna get poetry stuff, I'm gonna get cosplay stuff.

SPEAKER_03 3:49

Very good. Yeah, but my book, yeah, yeah, my book of sonnets.

SPEAKER_01 3:53

Yeah, yeah, it is a book of poetry.

SPEAKER_03 3:55

Yeah, yeah. So who are you, Evan? I am the programmer, Evan Phoenix. As far as I know, uh that's the only Evan Phoenix with that persona. Um, right now I'm the CEO of Mirin, which is my own company. We're building deployment systems. I'm a longtime infrastructure backend programmer. Even when I was in Ruby, I the thing I was most known for was building back-end tools. I built a Ruby VM for many years and building things like Puma and benchmark IPS and all that kind of stuff.

SPEAKER_01 4:25

So and now I saw the announcement for Mirin. It seems like it's been about 10 months, yeah. Which, you know, now that we have code gen tools, is like 10 years. And so where is Mirin in the marketplace? Are you dominating yet? Have you taken over all deployment software?

SPEAKER_03 4:45

It's such a great question. I mean, not yet. We did our first preview release just last week. So it was me for a long time. Well, not a long time, but like it's only three of us, three engineers. I hired the other two engineers back in March. It was three of us for most of the year. I can say definitively, the amount of work that we've been able to get done as three people using Claude for the most part as our AI assisting tool is way beyond, I think, where we would be able to get done as three people without it, right? And so back looking and more so forward-looking that like we have this roadmap, and I'm like, okay, we're gonna get this done, this done, this done, this done. And I would say that the productivity that we have seen over the course of the last six months has really informed me in like looking at the roadmap and being like, okay, we got this big feature. How long do we think that'll take? I don't know, maybe a month. I think that without those tools, it'd be like, I don't know, maybe six months. That is probably where it's mostly changed. It's like we all have to like kind of lick our finger and put it up and be like, I think that how long is this gonna take? And I think that's the biggest thing that I've noticed is that my wild ass guesses about stuff has completely changed.

SPEAKER_01 5:50

I'm gonna say something that sounds funny, but I don't mean it to be. That also changes, like when we as engineers inevitably take twice as long as we think, that means that it's a year, it's two months and not a year, right? So it's an order of magnitude. Well, not really, but it's it's a lot, lot shorter.

SPEAKER_03 6:06

Yes, exactly right. I mean, we always underestimate how long it's gonna take. I sort of just build that into that calculus, right? Like I look at it and I go, like, I don't know, I could do this in two weeks. So it's gonna take six weeks or whatever it is. That's the normal calculus. But again, it now it's six weeks and not okay, well, I don't know, like I probably three months and then it takes six months. That's exactly exactly right. Yeah.

SPEAKER_00 6:26

Right. When you say you're like you've integrated Claude into your like workflows, like how deep does the rabbit hole go there?

SPEAKER_03 6:35

It's mostly every day. So, you know, like as we're writing code, it's probably the first stop on what we do. So we have a pretty good writing culture. I was at HashiCorp for a number of years, and one of the things about HashiCorp is having a good writing culture. HashiCorp is a remote-only company, or was when I was there. I don't know how things have changed in the last year since they've been part of IBM. My company, Mirin, is remote only. And so I knew how important it was for there to be writing culture. And so one of the places that we start for any large piece of functionality is hey, let's write this down. We call them RFDs, request for discussions. And so we sit down and like write it down. And we used Claude in those tools. It's like, hey, I'm gonna write an RFD on this topic. I want you to hit these points, I want you to hit this, and then we use that to sort of like flesh it out. And then a lot of that's like, okay, I need you to hit this point, I need you to hit this point, and then going back and being like, okay, I'm gonna put this in my own voice or I'm gonna address this stuff, but hey, can you add an example that looks like this? Can you add an example that looks like this? So using it at that phase, and then we go through the human review process. And then once we okay that, what we usually do is we literally take that RFD over to the directory that has the mechanically, we download it as markdown, we put it in the directory where Claude has the code, and we say, go read this RFD and make a plan to implement it. And it goes and it does that. Okay, great. I see what we're trying to do here. I understand the product definition. Great, we're gonna go through with this. And sometimes we one-shot features like that sometimes. Because again, I feel like the defining the boundaries for these tools is the name of the game.

SPEAKER_00 8:12

So we had you on here to talk about like real versus fake AI. Yeah. What do you mean by that? And maybe like how does that fit into your workflows, which seem like very much, I would assume, real AI. Yeah, for sure.

SPEAKER_03 8:27

I think about it in the frame of how companies advertise AI. Like our tool doesn't have any AI built into it right now. So, for instance, you download it, you can deploy an AI agent onto it, but like as a part of the thing that we build and we give out, we're not selling an AI-enabled thing. We've got plans, but we don't do anything like that today. And so I think about it more in the like, uh, what is the product part of AI? Like, in other words, what if I look at a product and I'm like, oh, this thing has AI, what does that mean? What does that mean from a product context? Have AI in your product? And so I think that's really what I get into like what is fake and what is real. My take in this, and I've got other examples, like technical examples of this, is like AI can't be the product feature. It can be like a technical feature that you use to implement something, but it can't be the feature unto itself. Let me give you the example. You maybe have a workout app, and the workout app says, we now have the ability to do customized workouts based off your past workout history. If they use AI for that, fine, I don't care. But the feature was custom workouts, right? Whereas if I go to another workout app and they say, workouts now with AI, I'm like, that's not a thing. That's like workouts now with blue. I was like, I don't know what blue is. Like, what is blue in this context? Like are blue weights, blue, like, and so this is a sort of a viewpoint cultivated in the history of seeing how blockchain is used for the most part. Blockchain, I think, is a really interesting technology, but it's not a product, it's just a way of building a product. And so I think that's really what I mean by like fake versus real AI. Is it just a way to implement some product surface area, or is it the product surface area? Because if it is the product surface area itself, it's probably what are we talking about? Are we talking about just like you shoved a chat bot into this thing that it doesn't a real product? That's what I mean.

SPEAKER_00 10:25

I see. Yeah. Is it actually using I agree with that in a lot of ways? It is becoming more and more blurred to the point where, like, do you even foresee like cloud code living in your product in some capacity? Or is that like you would never do that?

SPEAKER_03 10:42

I think that cloud code is a good example as it relates to our product in like some of our like longer-term vision stuff, right? So I think that cloud code is itself a product, and so it has real tangible value that it uses an AI for. And so I can see us integrating cloud code in that like one of our far-turn roadmap items is we want to be able to provide good development environments, right? We want to say, like, instead of having people have a wiki page or Google Doc that lists how to set up your dev environment, we want to have a story for that. And I think that coding agents are part of that story today. So it's, oh yeah, could we have cloud code in the product insofar as like we give you a development environment that has cloud code? Yeah, absolutely. I think that from a perspective of like using AI, I think we have one way that you use AI today, and I will talk about because I think it's so much fun. And the second one is a more product focused way. I'll start with the product focused way because it's more boring, which is that one of the things that I think as people in working with AI that's been clear is that it's so good at summarization. It's so good at picking out the signal from the noise. And so, like, one of the things that we want to start doing is like, okay, well, we're gonna have like, for instance, all these logs for somebody. We want to be able to say, like, hey, I want to turn on daily summary. And the daily summary can be AI driven. It can be taking in what happened with your deployment today, all your logs, and it can say, like, hey, everything was good, just one sentence, everything is fine. Or, hey, we had a weird 20% latency spike. I don't know that it's anything, but you might want to look at it. Those are good examples of where you just want something that's summarized and surface. I like that actually.

SPEAKER_01 12:19

I don't think that's so boring. So I'm excited for the exciting part. Sure. Just because you know, we spend so much time trying to instrument everything so that it can tell us a story, but right almost inevitably we end up looking at multiple screens or we spend a ton of time putting a dashboard together. I like that quite a bit.

SPEAKER_03 12:36

Yeah. One of the design philosophies that I have is that people don't really want to look at an Excel spreadsheet of numbers and then try to figure out what the numbers mean in a like higher level context. Yes, that's like philosophy. Right. And so lots of the tools in the deployment space are like, here's all the numbers, figure it out. Right. We just want the ones that are red or green or you know, somewhere in between, you know, or why yeah, or like some gut check, like, hey, you know what? These numbers look like they did last week. If you were okay with last week, you're okay with this week. Yeah, that's okay too, right? I think that understanding baselines and being able to just like give uh things are looking weird. I don't know if it's bad. Maybe you got really popular and all of a sudden the metrics changed in some radically different shape, right? But I think that the philosophy we have is like if there is important data, we should have an idea of how to show it. And if the data isn't important, we should just not show it. We should just be like, everything's fine. Yeah, you're good, move on with your day.

SPEAKER_01 13:36

It also addresses something that I think we all experience, which is this notification fatigue. Absolutely. I could have a talk at RailsConf, and in the middle of the talk, I stopped and I asked the audience like how many people had ignored a warning that had come in like on Slack or email in the time that I had been in talking, every hammer. You know, and it's amazing. Yeah, which you know, there's a lot of people that are like taking their job and their program and their software seriously, but it's just too much.

SPEAKER_03 14:04

That is the place that I think that I'm really excited to use those sorts of tools to apply to because I think that is tangible, it's real, it's a everyday sort of thing. It's like I don't have to worry about it telling me when something is weird. I know that the weirdness detector will literally go off and say, like, I'm glad that I haven't talked to you since last Thursday, but that weird thing is happening again on Thursday. Like, you can tell in the way that like I also think about these things, I think about them in a conversational way that like I think that that's the human interface. I think that we're better in terms of digesting conversation than digesting like field of numbers, you know. So if you may, I want to talk about the other use that internal use that we have, which I love. One of my founding engineers, Paul, is going to do a blog post about this, but I can't not talk about it. The ability to summarize, the ability to pick out signal for the noise is also the thing that I think really makes the coding tools great. I had a session yesterday where I had this weird bug that I was trying to fix before doing this release, and it showed up in this kind of weird way. It was just like unknown type empty string. And I was like, unknown type, what are we doing? And so I kind of dug through the code and I was trying to figure it out. And I worked on it for like, I don't know, half an hour, 45 minutes of like trying to trace the flow, and I couldn't get anywhere. And so then I used Claude code. I have a custom agent called Go, the product's written in Go, Go Distributed Debugging Engineer, which is like literally optimized for like your job is to go find really weird problems. And it's amazing at it. Like I basically said, like, hey, I got this weird message. Can you go off and see if you can figure it out? And it's spun for five, seven minutes or something like that. And it's like, okay, yeah, I figured it out. This code in this place was not reading its arguments, which was leaving data on the stream, and then that data was getting interpreted by the next thing as a request. And I was like, that would have taken me quite a while to figure out, if at all, right? That summarization that like finding the signal in the noise is the big part. So, one of the things that one of my engineers built was when I started in the company, I was like, let's try to not go overblown on tools. If we can get along with a simple tool, let's just work it for a while. And so for that reason, we didn't get a Zoom subscription. We're like, we're just gonna use Google Meet. We just want to see how far we can get with Google Meet, right? And one of the things that we did was we were like, you know what, this sucks that you can't start a Google Meet from Slack. We really wanted to be able to start a Google Meet from Slack. So we're like, okay, well, eventually we'll build our own little Slack bot that can go start them. So we go and build that and we're like, oh, very good it's working, you know. Like again, we use cloud code to build that. And so then we kind of like we're spreadballing, what else could this little Slack bot do? And we have this idea and it is so great. So Gemini will do this. Is using Gemini as a cloud, Gemini will do the summaries. Like if you do a call, you can say, hey, give me the call summary of what happened, right? And it'll output its own version of the call summary. But you've also got the transcript in there. So what Paul, my engineer, did was he used that and fed that whole thing. I can't remember if he fed the summary or the transcript itself back into Gemini again, but with a different prompt, which was I want to send a bullet point list of what happened in this meeting to Slack. So I need you to give me bullet points. I need you to pull out bullet points to give over there. I need three to six bullet points of work. And if there are any off-topic, off-work items, I want you to pull those out separately and include those in a separate section. And I can't tell you the amount of joy that it brings us to see the summaries after the meetings because it's like talked about debugging. Uh, Evan and Teresa talked about debugging, and then at the bottom will be like Evan and Teresa expressed a fondness for making snow angels. Like that'll be the thing at the bottom. And I can't tell you the amount of amazing, just like it's so great. Yeah.

SPEAKER_01 18:05

I wanted to uh go back to the writing culture that you talked about. The thing that I love about what you described, and we do some of that as well at Def Method, but some of the stuff that you described, if AI wasn't involved, we would be saying, but that's big upfront design. That's so much work that you're doing ahead of time, right? And I think that's a really interesting shift in how agile methodologies can be understood when you have all these tools at your disposal. Studying like the waterfall patterns that don't work or anti-patterns that don't work, it's always like, well, it's because it takes you two months to write all of this and then design it and then come up with a plan, which is what you described happening in basically like less than a day. And so all of a sudden it's like, okay, well, the plan is always wrong because the plan is not faced with reality. So you have to change the plan. But if you have AI helping you along the whole time, then why not? Why not do the big upfront design? It's you're actually not doing it, you're having it done for you.

SPEAKER_03 19:03

For me, in some ways, it's less a fact that the AI is doing it and more in terms of the time investment, right? Like, so in other words, if it takes an afternoon to do, do it. The problem was it was taking two months to do an upfront design, right? And so one of the things that I really try to push and cleave to is like just try things, right? Like we're in the age where just spend the afternoon trying three or four different solutions to a problem and to see which one you like. In the past, the developer time was always seen as this thing that, like, it's very, I have to guard it very carefully and preciously. And agile is a reflection of that, right? Like, I want to be able to like engineer time is so precious that I want to be able to pivot that engineer time to actively look for oh, we're going this direction, now we're going that direction. Like, I don't want to put them on a path that they're not able to get out of because they might not be able to get out of it for six months, right? Right. I think now we're at this place where it's like, no, like I have an idea. It would normally have taken me a month. I'm just gonna spec it out. It's a Friday, I'm gonna try to build the whole thing out in a Friday. And oh yeah, that did work. Okay, great. What did I learn? What did I not like from it? What did I want to incorporate into like the my next attempt at this?

SPEAKER_01 20:14

Yeah. Yeah, I think it's a fascinating development and how we can work together.

SPEAKER_00 20:18

You make some interesting points here, and I want to call out a few of them. A lot of people are like, I save so much time, and I'm like not coding as much anymore. And I think what I hear is that you're just not spending the same time on the same things. And it's not like we're actually saving any time yet. Yeah. And that we're just now like writing more up front, spending a lot of time thinking about what it should be making.

SPEAKER_01 20:44

Well, that's the thing, right? Code is a liability. Yes. So if you're spending a whole ton of time coding, that may not be great. Spending less time coding could be good.

SPEAKER_03 20:52

I get that perspective, but I actually think that it depends on the person and the task. Maybe I'll give you a little bit of background to like what my own process looks like. I am a systems thinker, so like in my head when I'm building a thing, I end up having like a map. I have a very tangible to me view of what I want to build in my head. Okay, there's gonna be this, and it's gonna be this, and this is gonna do this, that, and the other thing. And like I have it in my head, right? I can now just describe that thing. I can sit down and I can say, like, okay, I want this to talk to that, and this should be using this, that, and the other thing, and then be like, okay, great, I will go off and do it. And so for me, the code was never deliverable. For me, the system was always the deliverable, right? The code was just the thing that implemented that system. And so the ability to work with the coding agents to say, like, this is how I want the system to work. And I give it those guidelines. I give it, hey, this thing should go over here and this thing should do that. In some ways, it acts like a typist, right? Like it's gonna do a lot of the legwork, it's gonna do a lot of that stuff for me, but it's also gonna say, like, hey, like, you didn't Mention this thing over here, but I went and I did this abstraction for it. I was like, oh yeah, that was a great way to handle that sort of thing. Right. And so I think for me personally, because of the way that I approach the problem, which is like in a systems way, and I describe it in a systems way, I do save a lot of time because what I am getting very quickly is a, even if it's a broken system, I can go and look at the code and I can be like, okay, great, we're 75% of the way there. It doesn't work because I under specified this section and we'll go fix that, right? I think that where it falls down is when you go into the problem space and you don't have a clear idea of what the outcome is supposed to be from a product perspective, right? Or from a systems perspective. So if you're like, someone should be able to log in, is a horrible thing, an absolutely horrible thing to ask a coding agent to solve for you because there's a mountain of different variation that you could get. And sure, I guess if you want to just see like what it's going to do so that you can form your own opinions, that's fine. But then you're going to be doing that thing. What you're going to be doing is iterating with, oh, okay, oh, you logged in. Oh, actually, I know that's not, I wanted you to use JWTs. Oh, okay, great. Let me go redo it again. Oh, actually, no, no, no, no, that's a bad idea. Go off and do that. If you want to do that iteration, that's fine. I guess in the way that I think about it is that person is probably saving themselves some time, not a lot of time, because I'm old enough to remember that when teachers would tell you to write stuff out longhand and rather than type it out. The value of writing stuff out longhand is that your brain has time to think about what the next word is before you get to the next word, right? We're basically just accelerating that times a thousand here. So now, whereas before it was like, okay, while I'm typing, I'm also thinking about what the architecture is going to be. And I'm writing this method, and then I'm thinking like, oh, I should write the next method that should look like this. And the next message should look like this, right? We're sort of skipping that step with the coding agents, but that also means that if you don't have a clear-eyed view of what that outcome is, you're going to go back and be like, no, uh, sorry, no, let me re-specify three or four times in order to get what I wanted.

SPEAKER_00 24:02

Yeah, I don't know how many times I pseudocode pair just to see what like communication patterns evolve out of that. So that it can help inform me of the system thinking that I should be thinking about, also, right? Like, do you see any of that where you're like you had this map in your head and it was like, uh, maybe you shouldn't think about that map that way. Are you getting surprised by some of your own like use out of it? Or are you getting a good guardrail out of your own use?

SPEAKER_03 24:32

I would say I get pretty good guardrails, right? So, like, if I go in and I am wildly under-specifying, or I have it completely out to lunch, what I will get is a thing. One of the things I love, a newer feature of Claude Code, is now it'll ask you questions in plan mode. For Claude Code users out there, if you're not using plan mode, it's amazing. It can ask you questions. So you will specify, hey, I want to do this, that, and the other thing in plan mode. And it will say, like, okay, I have some questions. Did you want a big house or a little house? And that's like, I didn't specify the house size. Did you want a driveway or did you want it to be like an underground garage? Oh, let's do some Batcave shit. Great, let's go off and do that, right? And so I think that when it asked me those questions, I have been reflecting off the fact that, like, man, I really am under-specifying a lot of these sections, right? And so I think that those questions end up representing guardrails that I didn't get to, right? Because I've definitely done had sessions where I've been like, hey, let's go off and build this thing and I'll go and see that it completely cheated its way out of it. It's like, oh, well, yeah, like uh you wanted this to return true. I just made it return true. And I was like, okay, well, I radically underspecified that like the reason it's true is because you went and looked at the logs and you figured out the answer, right? And that's on me, that's not on it, right?

SPEAKER_01 25:46

It's interesting because that also may influence your behavior the next time you go and plan. Right. You're thinking about, oh, right, there were some edge cases I didn't think of the last time. So let me make sure I attend to them the first time now. Absolutely, absolutely.

SPEAKER_00 25:59

You've spent a ton of time low-level optimizing things, I imagine. Yeah. Do you find yourself maybe not doing that nearly as much because the LM's just gonna make stuff and you can run script later to optimize itself? Or do you find yourself still being like, I really need to go benchmark this thing and fix this performance? Do you even think about that anymore, or is it not really anything?

SPEAKER_03 26:25

No, I definitely think about it the intentional way. I used to think about it, but I don't dread it anymore. Like one of the things I used to do would be like, okay, we finished a thing, now we gotta go and figure out is this fast enough? What are the performance characteristics, what are the runtime characteristics of it? I used to be like, oh man, it took me a week to get this done. I don't really want to go back and do that right now because it's gonna be another week of like, and so sometimes I would just skip it. I gotta move on to the next thing. Like now, what I get is we talked about it briefly earlier. I'll reiterate again. Now what I have is like in Claude specifically, I have a bunch of custom agents that are specifically tuned for those activities. The one that I love is called production deployment readiness engineer. And it is literally says you are supposed to give your hard and fast opinion about whether or not the code that you're asked about is okay to deploy to production. And you should be very critical, but also like don't make the bar so high that no one can jump over it, or I can't remember exactly what it looks like. That's really smart. Yeah. Well, so what I will do is after I've done something where I'm like, I think there's probably something in here is I will just say, like, I'm gonna go use the bathroom and get a drink. Can you go tell me if this is ready to deploy to production? It produces a report in Claude afterwards. It basically says, Hey, this is kind of weird. Like, obviously, you stub this out. You probably don't want to have this in production. This section right here is like quadratic performance-wise. I do not deploy this, whatever you do, because it's gonna be insane, right? And so great, it's finding things. Then I feed that back into the workflow and I'm like, okay, great. Like, let's refactor that out, let's write some performance tests for it. And, you know, I kind of just use it in that way. And so that's work that I, you know, I'm uh what were Larry Walls, like hubris, laziness kind of things. Like, that's where it comes into it, right? Like I have the hubris to ask this tool, dude, can you see if you can figure this out? And then also, like, I wouldn't be doing this in the past, right? And there's a lot of these second things that I would just be like, I gotta move on with my day. I'm not gonna check this out. I'm just gonna deploy it and great, I'm done.

SPEAKER_01 28:32

Right. And then you wait and see like what exactly what performance actually gets hit or what it actually looks like and make the changes. Yeah. Agile deployment. Yeah. Right. Right. Iteratively improve it. Now I'm I'm interested in what you mentioned about the product side of using AI to summarize what's happening. I was wondering if you could give us the sort of low-level details of what LLMs are deployed, you know, how it's deployed and what what all goes into that so that it can make accurate decisions about what's interesting.

SPEAKER_03 29:06

It's not deployed yet. It's not fully built. It's really just spec out as a thing that we're planning on building. But we've gone through a number of experiments. Even just this experiment, like I said, with analyzing the transcript was really great in the same way, right? Like, hey, I've got this field, and what I really want to know is I think that what we have learned over little experiments in summarization in sort of like looking for signal and noise is asking for something extremely specific is hard, right? So, in other words, asking for like there's so many memes about like asking an LLM to count for you or asking it to like do math or count letters in strawberry, right? Like all those sorts of things. So I think that what we have learned is that you don't really want to ask questions that are of that variety. You want to ask questions that are of a sort of a higher order, like more of a summarized thing. So, in other words, you want to say last week you said that this field of numbers was okay. The field of numbers this week looks like this. Can you compare and contrast your feelings as it relates to those numbers and your previous stance? That is a thing that it's actually quite good at because what you're doing is you're asking for a difference summarization between these two things. And then you had a an opinion about this number. And so you're saying, like, okay, well, the difference between I had this opinion about this. Now I'm asked to forget an opinion about this, given the difference. Well, how do I think my opinion changes? That is like, again, a very human. The LLMs are trained on human sentiment, human language. And so they're better at giving answers in human sentiment and human language than they would be giving it in mathematical terms, right? But you can still feed it mathematical data. You just can't expect to get reasonable mathematical data on the output unless you're doing something specific with a math model. I don't mean like that. I just mean like the frontier models, right? And so that's why the way that I think about it is in terms of like human-centric, human-oriented data and interactions that you're gonna ask for. Like that's why I talk about this idea of like just a Slack bot that you ask it, like, how's things going? And it's like, yeah, things are fine. They look like they did last week. And you're like, okay, great, I'll move on with my day, right? Yeah, the no status update. Right. Exactly.

SPEAKER_01 31:27

When I saw the demo and the walkthrough online, I thought one of the things that I thought was killer was that Mirin detects your architecture. Like you don't have to do any setup, right? It says, Oh, okay, this is a Ruby on Rails app and it's being deployed with X or Y. I will say Capistrano. Sorry, I'm dating myself. But we'll say it's deployed. I'm here for I'm here for Capistrano. So yeah. Now I'm gonna, yeah, now I'm gonna try and test you know 2010's architecture out on. Please do. But I was curious when I first saw it, I was like, oh, okay, that's where they're using some AI to do some detection. But are you actually, is it just a tree where it's like, okay, I if I see X, then I know it's Y? Okay. That's right. That's right. All right, interesting. And then what about when it moves down to deployment files? Because you also don't have to write those, which I really like.

SPEAKER_03 32:13

Yeah. So it's still just doing it on a decision tree today. I think that one of the things that we wanted to be able, so one of the features of the product is that you can just run it offline. You can just run it wherever you need to run it and it won't do anything else. And so we always wanted to have that, like, hey, the deterministic system version of this, which is just like, hey, you've got these files. I'm just gonna assume that this is the situation. We are exploring the higher level things, which is like, hey, I've got this big app. Can you just derive information that you want from? We've done that experiment. We didn't put it in the product because we wanted to run offline for now. But in that experiment is like, I want you to go through and I want you to figure out like, what are the databases this thing uses in production? What kind of configuration does it need in order to configure those databases? Does this need S3? Like, what is the storage? Like asking systems questions. I don't think that we're ever going to ask systems questions from a decision pre perspective because the decision tree would be massive. Because, like, where am I looking? Right. And so our intention is actually to use the agents in that way eventually, which is to say, like, I want you to go analyze this code base and I want you to give me back a bunch of specific things that I'm pretty sure are true about it. And I want to present those to the customer or the user. I want to say, like, hey, I you analyze your code base, looks like you're using S3, looks like you're doing this is how S3 is configured, looks like you're using Postgres. This is how that's configured. Is that correct? And you're like, oh yeah, absolutely. That's exactly how it is. But now we can use that information to say, like, okay, great, you need Postgres. Let's just go spin up Postgres for you. You need S3, let's just go give you an S3 bucket endpoint within the cluster to do that kind of stuff.

SPEAKER_01 33:49

Yeah, yeah. Make it so that I don't ever have to persist in a Postgres password in a dot file again. And I would be very, very happy.

SPEAKER_03 33:56

We're gonna get there. That's really our aim. Our aim is to say, like, look, you're gonna spend a bunch of time developing an application. Eventually, hopefully, we can help you do that. But for now, you're using whatever workflow you're using. We want to meet people where they are. We wanna then apply our taste to what that means to take that thing into production, what that means to deploy it. And a lot of that is I don't want to have to configure it. I just want it to just sort of figure it out or at least go attempt to configure this thing and say, like, hey, is this true? Pretty sure this was true. Can you just confirm with me that that was true?

SPEAKER_00 34:30

So, yeah, this makes me think a lot about like ambient AI, where things are just watching and taking notes. And I could totally see, you know, circling back to the where do these agents fit? Yeah. Do you foresee maybe like an ambient mirroring agent just like sitting in and watching what you're doing and then suggesting and then auto-configuring stuff? Right. Like, where does it stop? Right.

SPEAKER_03 34:55

Like, I'm I'm actually really I'm glad that you brought it up. That was one of the things that when I was first going out looking for funding, that was actually one of the things that I was like, we're gonna build that eventually. I'm gonna I pitched almost what you said, which is what I really want the ability to do is have it's maligned at this point, but a coding version of Clippy, right? A thing that's basically like it's not soaking up CPU, it's not trying to exfiltrate your data, but what it's doing is it's just quietly saying, like, it looks like this person's working on this, it looks like they're configuring this over here, it looks like they're doing this, and that maybe when it says, like, I could help you do this better. Do you want me to go ahead and configure this for you? It can, based on activity, say, Hey, do you want me to go turn this on? Because I think it would, or I noticed that you've been running some stuff. I just ran some profiling for you. You don't need to worry about it. I ran the profiling, and here was the output from it, right? I think that like that's absolutely the place that we also want to get to because I think that again, it becomes this thing of like we have taste. Like one of the things that I talk about with Biran is how do we put out our view of how things should be done? And one of the ways is to say, like, hey, we have this thing that is sort of encodes our taste about how to write apps, our taste about how to configure your systems. And so you can always just ask it. You could say, like, how should I set this up? Oh, great, you should go, I can do that for you. Or, hey, I've been running in the background and I see that you've got all these files sprinkled around. Do you want me to write a config file manager for you instead? Oh, great, yeah, go go go do that, please. Right. So that you didn't know to ask about.

SPEAKER_00 36:32

That's why Reels was successful, really. Is it was like super opinionated, but also flexible. And so, like, because it was opinionated, it was very straightforward to like follow the paths that you needed to follow, like within building a web thing.

SPEAKER_01 36:45

I think that you're right about that, Valentino. And I also think that when you have something that's that opinionated and becomes very popular, you also get to find out what people actually care about and are gonna like dig in about and what they're like, okay, that's good. That's good enough. Right. And so then, and I see the similar thing happening here with Mirin, right? If your ambient agent goes and does 12 different things by default and it sets things up and it gives you notifications, you could start to find out, well, okay, great. You know, 90% of developers actually don't care that much about this, they just want it done properly and they don't care that much about the format. And here's the other 10%, which, you know, inevitably other libraries, potential plugins, stuff like that will address.

SPEAKER_03 37:26

Maybe backtrack slightly. What a crazy 18 months it's been in this field. Yeah, yeah, sure has. This wild.

SPEAKER_00 37:34

And I think Claw didn't exist a month or a year ago, right?

SPEAKER_03 37:38

That's exactly right. And so I feel like we are finding real interesting uses for this technology all the time. And one of the things that I am really excited about is software has been accelerating for a long time. It feels like there's so much we've put up with such crappy solutions for things for a long time because it's like, well, who wants to go invent another expense system or whatever it is? Just something that's not exciting, that's been sort of a legacy piece. Maybe I want to go finally do that for real. Like, and how do we enable people the ability to like stretch their wings and say, like, let's go try this? I love experimentation. I think that you learn so much about the edges of a problem by doing experimentation. And so I really want people to use these tools, to use Marin, to use all the different coding tools to really exercise those muscles to say, like, let's just go build this. Maybe it's a travel tool where it only shows you places where there's great raccoons. I don't know. Like, do it, man. Like, see what it's like. Maybe there's something there, right? I feel like I'm so excited by that. And that the tools have gotten from where they were 18 months ago to today. I don't think anyone would predict that. I don't know what the next 18 months is going to look like. Maybe it'll be just like this. Maybe we've sort of like we've eaten all of that initial plateau. Maybe we've got tons of plateau in front of us.

SPEAKER_01 39:09

Actually, I know. I already know. I know most people are just guessing, but I actually know what the 18 next 18 months are. Oh, super. And actually, this is let me get my notepad. Yeah, this is my prediction. And actually, it benefits Mirin tremendously. So I think you'll you'll like it. My own personal hobby horse is that we're still in this phase of, okay, this new technology can do amazing things. So let's do everything a lot faster and more efficiently. And I don't actually think that's the way paradigm shifts in our industry work. I think if you look back over the history, once we get, you know, an amazing new efficiency gain, what we actually start doing is building much more complex and structured systems that did not exist before. And so I think for that reason, and I always go back to this example, even though it's imperfect, is before and after cloud computing. Even though cloud is really just a bunch of machines sitting in a room somewhere, all of a sudden we started by just building the same web applications with the same architecture. And then, you know, over time we said, oh, actually, we can do much more complex things, right? Which necessitates something like Mirin. And I think that a further challenge for small software development teams, which is what Mirin targets, is that, well, hey, now table stakes is going to be you building something in this way, right? And you probably can afford a two or three person DevOps team to make that work, but you're gonna need it because no other application is going to work, you know, unless it's like a today's equivalent of like a restaurant web application, right? That's just telling you what's on the menu. Right. And so I really do think that over the next 18 months, you're gonna start to see that kind of the growth and complexity of systems. That's my guess.

SPEAKER_03 40:43

I'll piggyback off that and I'll throw a little mini bomb into the conversation, which is to say I feel like the rise of the monolith is also going to continue to occur. So, in other words, I feel like we shifted towards microservices because we wanted to sort of like lean into Conway's law. We wanted to be like, you're this team, you own this thing, you're this team, you own this thing. And the ability to integrate that software was a difficult, hard problem. That difficult, hard problem about doing that integration is kind of gone. It's not entirely gone, but it is 90% gone. And so I think people are gonna be like, hey, like, what's the point of that? Like, I can work in the monolith, I can tell my coding agent, hey, just make this work within the confines of this thing, find out the edges, stick it in another directory, go refactor it so all the code inside here to use my new interface. And it's like, sure, no problem, boss. And then it's like a thing that would normally take a week that your manager would never give you the ability to do happened while you were at lunch. And so now you're like, okay, I can just have a big monolith. I don't need to break this stuff up in microservices. And I think that we've, you know, the last two years or so has sort of seen a retrenchment of the monolith. I've seen that as well. And I think people just like them better. Well, I think they're easy in order to fit in someone's head. Yeah. It's yeah, they're just easier to fit in somebody's head. And I think that we're gonna continue to retrench that.

SPEAKER_00 42:01

I feel like you're right until you get to certain scale. And like maybe this will be solved with context window issues, right? But that ultimately is like a huge problem. Is like once you get to a certain scale of like everything in the same place, the coding agents start to lose track of what everything exists. And so once you have a certain size of an application or code base, you try and like get it to like how do you then orchestrate the agents, right? So they find the path and be able to cross-collaborate across those things in the monolith. Sometimes it's easier in like a separate service, and you could just say, here's the API for it, right? You don't need to worry about how it works. And that can definitely work better currently. Not to say it won't. Like, I feel like the monolith is still the right bet because, like, from what we've seen, things only get better. I want to circle back to like because you're both Joe, you have a great point of like your outlook. We've been talking about like real versus fake AI, but I feel like there's like this middle imaginary line, Evan to your point of experimentation, of like hypothetical AI. You know, like the AI is being like getting them to come up with ideas of what hypothetically would be. We have this exercise which we all enjoy of like, oh, what would it look like if it were this, right? And we run this experiment. What happens when the AIs start doing this? I experiment this all the time personally. I call it autogenetic, like from biology, where like, you know, self-assembling things, where it's just like reflecting on its own things, but also its environment, right? What happens when it starts to uh imagine things, right? If you give it certain personas, if you're like one of these sub agents of yours, right? And it's like honed up focused on like reviewing, make sure it's production ready. Well, what if it starts having an imagination of its own of like what production ready looks like, right? Like, how does that evolve as an agent? Do you mess around with any of this style of like hypothetical?

SPEAKER_03 44:00

With your coding habits for I have weird projects that I'm like, hey, like let's just go build this thing. I want to know what this looks like. Just give it a shot. I want to see how it works itself out. But I think that like I kind of want to hit on a slightly different point that you brought up, which is the software is for the most part only good if it's good for other people. In other words, like the human-centric version of what we create is going to become more and more and more and more important, right? I think that there is a whole bunch of backend systems, like this backend system talks to this back end system that talks to this backend system, but it's doing that not because it's like that would be fun to do. It's doing that because like the power needs to stay on in someone's house because it needs to keep them warm or they want to watch TV, right? So there's a human in all of those loops for the most part, right? And I think that we're going to get to situations even more that are like, okay, well, like what does the person want? And I think that that is such a great place for us to get to because again, that gets us to taste, that gets us to aesthetics. And we're sort of rapidly approaching, like, okay, well, what is the art of building a thing that people like that is good for people, right? As opposed to just like, what's possible? In other words, like we could all differentiate between the aesthetics of like that old XKCD that's like a web page with a million options, right? Versus a thing that's just like a wizard that will walk you through. Like the second is obviously human-centric because it's like, I need the context, I need to know what I'm doing, right? We're gonna see just more and more conversations about that. Because the inverse is that, like, again, if it's software for another machine, the API doesn't matter. How you describe it doesn't matter. The fact that there are even words involved doesn't matter. It becomes a pure mathematical construct. And yeah, maybe there's a place for that, but I think that the bulk of what people work on is going to be like, okay, well, what is the interface boundary between this code and the person? And how can I inject my own taste about how that should work into that conversation?

SPEAKER_00 46:10

Yeah, and to extend that too, how does that change over time? Right. You mean the human preferences? Yeah, human preferences, but also like usage. Say, like, you know, clock codes out, like that changes how people use the internet, how people change all kinds of different things in their life, right? Like which are human-centric. How do other things evolve when there's change? That's true.

SPEAKER_01 46:29

But we do change slower. Maybe there'll be a faster rate of change, right? As we get more and more used to all of these different tools and all this different advancement.

SPEAKER_03 46:37

But I think that that's where the experimentation is really interesting, right? Like, I think that the easy example here is we didn't know how great the smartphone was as a tool, human tool, until we had the smartphone. We had to attempt that experimentation, but to go down that road and to say, like, oh, this is actually like the human hand is this big, right? And so the device needs to be this big exactly. Like it has very specific human-centric things, right? And so I think that that's where the experimentation is really interesting for people to try out, right? And I think that the push in AI right now from the people who have Boku dollars is like, how do I put a hardware AI thing on your body, in your face, on your whatever? And I think that, sure, run those experiments, go to town, burn as much money as you want down. I have nothing to say about that. But I think that the You mean you don't own VR goggles? My kids have a quest too. How about that? I bought them for that during the pandemic. That was a really good pandemic purchase, by the way.

SPEAKER_01 47:35

That sounds great. It sounds like a lot of fun for the kids. Yeah.

SPEAKER_03 47:38

Yeah. But I think that like I love the fact that the coding tools are making solving problems more accessible. I have a friend of mine who works in the, I live in LA and he works in the film industry. And he vibe coded an entire app on his own because he's like, I just want to understand this. I have feelings about it. I want to just vibe code this whole thing. He showed me like a couple months in. He's like, is this a real thing? And I was like, man, it looks like a real thing to me. His first few iterations were literally like uploading code to Chat GPT, telling it, and then telling him what to change, him copying the files and putting them locally. I was like, man, I got to show you some of these tools that you can just run locally, right? It'll be a big unlock for you. But he wouldn't be here. He wouldn't be doing that experimentation. He wouldn't be saying, like, what is the interface between this? What makes sense? How can I change this? Right. I think that outcomes are based off of human time. How long your manager is going to let you work on polishing up this interface is a direct influence of what your time is worth in terms of money, because we live in capitalism. And so I think that by cutting down the amount of time it takes, we can run more of those experiments. Now there's going to be companies out there that are like, okay, great, you can do stuff 10 times faster. I'm going to give you 10 times as much work. I actually hope that doesn't happen as much. I hope that it's like, okay, great. I have more time to iterate. I have more time to come up with novel, unique, interesting solutions to this problem that normally I would have to do the most obvious one because that's all I've got time for.

SPEAKER_01 49:10

Yeah, that's interesting. I'd like to see that too. And I've got a little bit more of a dim view of it. I guess I should say I have a dim view of it across the entire landscape, but I also think that the companies that do take the time to say, let's experiment and let's build something new, let's be a little bit more ambitious with the time that we have are going to go really far. So that's what I think. I am forever the optimist.

SPEAKER_03 49:32

So good.

SPEAKER_01 49:33

We should spend more time. We should spend more time together. The first thing I thought when you told me about your friend was, well, as soon as he gets a couple of users, tell him to call Deaf Method because that application is going to be a wreck and we could help. Yeah.

SPEAKER_00 49:44

You know, there's a lot of truth there. Sure. Absolutely. I was at the AI e code summit in New York City recently. I saw Google up on C. You were at the summit? I was there. We should have hung out. Oh, you were there. I don't know how you have to. All right. We've just been done next time. We got podcasts from there. They had a booth setup. We probably could use. Yeah. You know, Google's up there and they're showing their AI studio. And so I mess around. I'm like, can I make something out of it? And then there's like a little deploy button. I'm like, okay, yeah, I'll just deploy this thing. Deploys it to some like subdomain on Google and it like kind of works. But like so many things were missing because you can't just push a button to deploy something. And like as soon as you want to change any aspect of that deployment, like I wanted to cache stuff in a database. It's like, well, you gotta hook up a database. Right. Yeah, I started asking for too many things. Yes. And I'm just like, maybe it's not there, but like it could be. But you know, at the same time, like, do we even want it to be there at that level? Because like I just foresee, like, people that just don't know what they're doing, they're like, how do they even know they need a database? Right? Like, they don't know that. How does that consideration even come up?

SPEAKER_01 50:55

I love the idea, Evan. I want to let you respond, but I just love the idea of those people at that Google booth that just were getting rubes all day long saying, This is amazing, just did not see Valentino coming. Like, oh God, this one's gonna be hard.

SPEAKER_03 51:08

I think that like it's a real frustration with these tools that are built on a pedestal or where the cliff is like a thousand feet tall, right? Where you're like, oh, I deployed a thing, and you're like, oh, this is great. I absolutely love this. This is what I want. And then they're like, okay, how do I do the next thing? And they're like, sorry. You're like, sorry, what what do you mean sorry? It's like that's not for me. Yeah. It's like, okay, so why did I even spend my time here? I think that that is good marketing and user hostile, in my opinion. Because I think what you're doing is if that tool is not actually available for that person to grow and evolve with, then you're sort of cheating them. You're sort of trying to like, oh, this is really only good for single page apps that only run HTML and JavaScript and are completely stateless. It's like, okay, like, but what do I do if that's not the case? And they're like, I don't know, you can find another system. Yeah, yeah. Call someone else. What are we doing? Yeah.

SPEAKER_00 52:07

So yeah. We've talked about a lot of great stuff here. Circling back to the Ruby aspect of this show. Where do you see Ruby's strengths being in this landscape? And like, where do you see it missing where the industry is heading, right?

SPEAKER_03 52:23

Ruby is a really ideal platform and language and stack for doing a lot of like writing a lot of agent work because it's always been really flexible and like, oh, well, like I want to take this data in and I want to massage it in this one way, and I want to talk to these network services to do this, that, and the other thing. And there's a lot of that going on right now where you're offloading to an agent to do something or do whatever. There's a whole ton of automation that's just that sort of thing where you're going to be doing so much daily iteration on just like what that automation looks like. That Ruby is super great for, right? Because you're not writing very much. You're just like, oh, go do this. And when this comes back, go do this, that, and the other thing. And great. I've expressed that in exactly as many lines as I had sentences there. And I can move on with my day, right? A lot of the things that people fault Ruby for are just disappearing, right? So it's like, oh, well, it doesn't have types. It's like, well, for the most part, the coding agents are actually really good at this. And if you really want types, there's a billion type tools that the coding agent would be happy to fill in 90% of the types for if that's what you really want, right? So I think that is sort of going away. I think that like we've seen these huge advances in just what a single core computer can do. So like the performance disadvantages that Ruby has as a comparison to Go or whatever are rapidly declining in terms of what the actual application is supposed to do. Right. So if it's supposed to like, oh, I'm gonna go off and I'm gonna talk to this, that, the other thing, great, like the performance is not a problem anymore. Like I think that those things are starting to sort of bleed away, right? So I think that in many ways, it feels like the reality of writing Ruby apps is that those disadvantages are slowly melting away. And all of the advantages that have always been core to the idea of dynamic typing and the organization and the framework and all the code and the libraries and gems that are available for Ruby are starting to outweigh any of those disadvantages because all the advances in other technology are just sort of eating away at those disadvantages, but they're not eating away at the advantages. You could probably make the argument that, like, oh, well, you don't really need to write small chunks of code anymore because the coding agent can. And so I can just write this thing that I would normally write in Ruby in C, and now it's 10 times faster. It's like, yeah, but then we get into, as you were talking about Valentino, we get into context, we get into understanding, we get into all these things. It's like we're still in token count world. The fact that Ruby generates fewer tokens to in and fewer tokens out is a distinct advantage, also in terms of like how it can reason and what it can hold and how it can know what the system does. And so I see the technological advantages eating away more at the disadvantages that people would bring up for Ruby and less so at the advantages.

SPEAKER_01 55:10

I like that a lot. I was one who was swayed, it was probably a year ago, by the hey, Ruby doesn't have types, and isn't that going to be a disadvantage as we go forward? And I'm glad to see that that's not the case.

SPEAKER_02 55:20

Yeah.

SPEAKER_01 55:20

Because I don't really want to use Sorbet. I guess that's what it comes down to.

SPEAKER_00 55:25

Custo makes use of Sorbet and very effectively, especially with GraphQL coupling. It's like it works in a lot of ways.

SPEAKER_03 55:33

I think what's funny is that the coding agents don't care about types. I guarantee you they do not have a type inference engine built into the LLM at its core layer. Like it is reasoning about the types in exactly the same way that a human would reason about the types. And in that way, it can reason about having the code not having types in exactly the same way that someone else could do that, right? And I think the advantage in terms of Ruby is that it's got a really great testing culture, it's got a really great way of managing that. And that's where you're like, hey, you're gonna go write this thing. Okay, I need you to go make sure that like we have 100% test coverage. It's like, yeah, no problem, boss. I got it. And so that was always the structural advantage that the Ruby community had was that it had built itself up off agile, it built itself up off, hey, let's have tests. Now, those tests, those are the bumpers, those are the guardrails for those AI agents. And great, you come into adding a thing to a gem, and that gem's got huge test coverage, you're feeling good about going through and adding that stuff because you know that that test coverage is there, but also the agent can like help you enhance that test coverage.

SPEAKER_00 56:43

Yeah, I agree with that. The biggest advantage I've seen from like Ruby from an AI perspective has been the training data available to it based just solely on the people that have been in. Rubyists, like they're a unique bunch, right? You go through any like any online forum and you're just like, oh, they're Rubyists that are like strange and crazy. Um I feel like that's historically accurate. And I feel like that does influence, and you do get a different result than you might get out of another language, which is kind of funny.

SPEAKER_03 57:18

You bring up such a great point because the training data has a huge impact on their abilities. I know that you had Chad Fowler on the podcast previously. Chad, he's mentioned a friend that was building a language that looked exactly like React from three years ago, explicitly because React from three years ago is what most of the Frontier AIs were trained on. And so they're so good at it, right? And in that way, the fact that Ruby's tastes they move a lot slower than, say, JavaScript's tastes in what packages to use and all that kind of stuff. That is a structural advantage to using the coding agents, right? If you go out to use, like if you go say, hey, build me a JavaScript app that does this, that, and the other thing, it probably is gonna use a bunch of dependencies from two or three years ago. And the JavaScript devs would be like, why did you use the no one's using that today? Everyone's on this other thing. That's a good impression because they are gonna yell at you. Okay, yeah, they are gonna yell at you, and they're gonna say, like, no one uses React, that's React with a Q. I'm just making up a random library here. Everyone is using React, the one with a K now, and it's not gonna know that because that community moves so fast, and that is a structural disadvantage to using the coding agents. Whereas you want to go reach for, I'll beat my own drum here. You want to go reach for a web server. The web server market, the web server gems in Ruby have changed very little over the course of the last 10 years. You want to go reach for an HTTP client. Again, it's changed very little over the so it's gonna make a choice that you're gonna be like, totally. That is the simplest choice that everybody would make.

SPEAKER_00 58:50

So that's really funny. You know, I also see a unique advantage in Ruby switching from SVN to Git so late. Yeah. In that the training data is missing for a lot of the old stuff, yeah. You know, yeah, yeah, yeah.

SPEAKER_03 59:07

It'll be interesting to see how that works itself out over the course of the next many moons, right? Because I think that like I don't know that it's necessarily going to go away because I think there's always gonna be a lag on the training data and what those things are capable of doing. The tool use has an impact here, but I definitely think that you could make the argument that the AI coding as tools are better modern Ruby S than they are better modern JavaScript programmers, because modern means something different in those different communities.

SPEAKER_00 59:40

Are there any departing words you want to share? I'm gonna personally check out Mirin because uh definitely deployment for small teams is a good mantra to have for a deployment company. And you know, some things I miss about Roku in that way, now that they've clopped on so many different features.

SPEAKER_03 59:56

Yeah, I mean, like our mentality is also based off of us being small teams. We want to be a small team that's building things for other small teams. And equally, I feel like if I had to give an 18-month prediction, mine would be that like by small teams, I mean like fewer than 15 people are going to be punching way above their weight over the course of this 18 months than they were maybe in 2019. And that means them moving faster, that means them doing more experiments, and that's really where we want to be supporting those sorts of people.

SPEAKER_01 1:00:28

So yeah, strong prediction. I like it. I don't want to let us go without wishing everybody a happy holiday season. And I just would like to, maybe on Valentino's behalf, or maybe he doesn't feel this way, I'd like to thank everybody who's been listening to the show and anybody who's sent a message or come up to me at a meetup or to Valentino at a meetup. It means the world to me. I've had so much fun doing this, and I never expected to have this much fun. So thanks to everybody listening, and thank you, Valentino, because it's really been great. I almost did a podcast on my own, which would have been so boring for everybody. Instead, I got you, and it's been wonderful.

SPEAKER_00 1:01:05

Yeah, absolutely. Surprise, Evan, your last recording of the year.

SPEAKER_03 1:01:11

That makes sense. I'm glad to hear that you guys are exercising good work-life balance in the last one of the year. So yeah.

SPEAKER_00 1:01:17

I'm out the rest of the year. Yeah, I don't know about Joe, but yeah. This has been like pretty wild. You know, Joe and I met at a small meetup in New York City, thanks to Scott Werner, and yeah, just snowballed into this. And we haven't quite got the full year of recordings in, but like pretty close. And uh, we finally got a regular schedule. And Evan, I've been a huge fan of yours since was that 2015 Ruby Kyagi. I'll never forget the JIT, you know, how does a JIT work? Yeah. That was that was a fun one. That was a fun one.

SPEAKER_01 1:01:47

Yeah, getting to talk to some of our heroes is the is one of the biggest, uh the biggest benefit of doing this show.

SPEAKER_00 1:01:54

Thank you to all our listeners. You know, we appreciate you. I definitely share your sentiment, Joe. Yeah.