Finale & Friends

We can listen to the change loggin' friends And then Jared and people you know Change loggin' friends Ever show

Well, it is called Finale and Friends for a Reason, my friends. Today is, uh, the end of an era, Jared. Are you sad about this? Are you happy about this? Are you, like, just beside yourself? Can you believe it that next week you won't have to podcast? I know. You don't get to? Which is it? Don't get to? Don't have to?

It's both, I guess, in a certain extent. Don't get to, don't have to. There's something about having to do something that makes you not want to do it And then there's something about not being able to do something that makes you want to do it as well.

Ah, I got the itch. I got the podcast itch. Well, once you've had this itch for a while, it's kind of hard to stop the itch. I get that.

It is. It certainly is.

It's fun to talk to people about the things we love And our technology landscape has evolved and changed, I would say, dramatically Over the arc of our relationship, I'd say, even. Like, gosh.

Holy cow.

I think we first met 2013, 2012. I would say, like, into 2012. And then 2013, you started contributing.

Right.

And even then, like, the internet was so different.

It was.

The interests were so different.

And it wasn't like we were besties right away. We barely knew each other. So, like, it took a while for us to grow and to meet each other.

It had taken a little while.

I was just logging news back then. News items or whatever we called them back on the Wordpress blog. And then, after a little while, hopped on the pod.

I just think we called it logging. I don't know what we called it, honestly. I don't know. I think you called me a changelogger.

I remember, that's cool. I want to be a changelogger.

It was a term of endearment, obviously.

And then we had, like, semantic debates. Like, well, are we the changeloggers? Or are the people who are listening changelog? It doesn't matter, but, you know, these are the things you bike shed when you're trying to figure stuff out. And things were different back then. 2012, I mean, mostly it was, like, framework wars. You know, the framework wars were cool. React was out. Ruby on the Real wasn't as cool anymore.

I think React had launched. Pretty much. Early in your tenure. Yes. I want to say, what was the fork of Node? IOJS. That had happened, like, early, I would say. I can't remember when. Probably like 2014.

Shout out to Michael Rogers. RIP Michael Rogers.

Yeah, I was just looking at some messages with Michael recently. And for those who don't know, Michael Rogers is, actually, I think he was, he, like, helped Isaac, I believe, if I can recall correctly, like, on the early versions of NPM. Like, he was critical, and it's early. Not that it gives NPM any credence at this moment, because there's some shares there. But, hey, it begins in great places, right? The idea was altruistic to have a registry. Michael was at the front of a lot of stuff. Michael Rogers was an early contributor, great friend over the years. Came down with cancer this last year, and shortly passed away.

Yeah, passed away.

A dear friend of ours, and he is, for sure.

And he was instrumental in the IOJS fork. And that's when we met him, right? I remember that show. And we all hit it off. That was a great episode. It kind of served a little bit of a purpose to get that story out and help, I think, to a certain extent, in a small way. IO and Node get back together, and they resolved it. I mean, it was a fork. It was a hard fork slash re-merge in record time, probably for the history books, I wonder. There was the Merb Rails thing, but this was bigger than that, because it was more social and political. That predated 2013. It did, yes.

Merb Rails was probably like early changelog. 2009, I bet.

Yeah, probably Penguin days.

Yeah. P-E-N-G-W-Y-N-N. Yeah, that was good for IOJS and Node to kind of come back. I mean, it was joyant, and I believe Scott, I can't recall his last name at the moment, was the CEO at the time. And we had him on the podcast discussing that change. And really, just it was about the proper steward of that open source project. And I think at the time, it was so new to folks. It was like, how do you actually do this in a way that represents the business? Now, if Brian Cantrell was on this podcast, he was CTO at the time that happened, he could probably speak to some of the technical details behind there. Brian, if you're listening, let's do an insider on the Node IO. If you have one, obviously, you probably do. You have an insider on most things. That's right. From D-Trace to ZFS to Sun to now Full Rack massive cloud compute that you own on-prem. So cool. Oxide. Seriously? Yeah. It has been a journey, man. It's been a journey, obviously. I think it's bittersweet for me, too, because there's a lot about our relationship that I love. There's a lot about podcasting with you that I just truly cherish. And it's going to be tough. It's going to be different. It's going to be tough to do the show without you. I look forward to it in positive ways because you have to, but also in a lot of negative ways. I think that's one thing with a relationship that you truly cherish that it's hard to walk away from and not do it with grace. And that's what I wanted to do with us was just make sure that we walked away with grace and dignity in the process. Because I love you, man, and I love what we've done together. And while the show isn't ending, it's just challenging.

It's the end of a chapter and the start of a new one. That's right. I'm sure it'll continue to be great. And it is bittersweet. I mean, Change is part of our name. Change Log.

Change Log. It's the hardest name to only say half of, right? Yes. Like some names, some brands, you can sort of like give them a nickname in a way. It's kind of hard to nickname Change Log. Yeah. It's either Change or it's Log. That's right. And then you've got to candle case it or snake case it or hyphen case it. Don't get me started on everybody. There's a gap in between Change and Log.

Is that probably our biggest shared pet peeve of all time is the uppercase L on a Change Log. Every time I see them, they don't know us.

They don't know us. It's a tell. It's a smell.

You don't understand how pedantic we are about such things. It's a lowercase L, guys. Come on.

I think to sweat the details, Jared, you know this. You have to sweat that kind of detail. You have to be that level of pedantic to deliver quality at a clip that we have for so long. You have to have that level of care and detail. You have to.

Right on.

If you don't, it shows. It's not that you can't do it. It's going to show.

It's going to show. Yeah. Yeah. If you care, then you'll care. And we certainly care. And that was what makes this hard. Of course, it's going to be good and bad. It's bittersweet, as you said. I'm excited for a new chapter. I don't know what comes next for me. I know in the short term, a little bit of a break will be nice from everything. I'm planting a little tree farm. So getting my hands in the dirt, you know, kind of doing some of that analog stuff I've been talking about recently. Back to the dirt. Back to the dirt. Oh, that's a good name, too. I came from dirt and I'm going back to the dirt. Call me Joe Dirt.

Joe Dirt. Yeah, man.

But we don't need to hover on it for too long. There's big news that surprised the heck out of me.

I was going to speak of a crack since you mentioned cracks. Did I mention cracks? Somebody mentioned cracks. My idea was this. I think that the Rust world is cracking in a positive way. Lady Bird cracked and said, you know what? Swift is actually not what we need. Even after they did a careful evaluation early on, they cracked. They said, you know what? Rust is actually better. And I think the bigger, more unique crack here, which is kind of expected in this world, was the leveraging of AI to get there. Which I thought was quite, I don't know, I guess at some point it's going to be everywhere. And it's going to be expected and anticipated that AI is involved in everybody's day-to-day coding adventures. So it's not surprising, but nice to see they cracked and came back to the good land, which is Rust.

Which is Rust. So a little bit of context here. When Andreas Kling and Chris Wanstroth, who has a difficult name to say quickly, were on our pod probably last summer, maybe two summers ago. I don't know exactly when it was, but it's when they announced the foundation around Lady Bird and all the stuff they were doing with the money raise and stuff. Or not money raise. What do you say? Chris donating. Just speaking plainly. That whole deal. We asked them about that, and at the time Andreas said, we're going Swift. Like, Lady Bird was written in C++, but they're going to start porting certain portions of it over to Swift. And we released that as a short clip of a longer conversation, and it's become quite a popular YouTube video where people like to go there and argue about whether or not that was right, and why Rust is better, and why Swift is better. Why didn't they go with Go? I don't know. There's all kinds of comments on that particular video. I was very surprised to see this, because Andreas didn't really pull any punches in saying, not that he dislikes Rust, but that he didn't think it was a good fit for a browser because of how object-oriented the DOM is and how browsers work. Take his word for it, not mine. And how that Rust doesn't really have the facilities he thinks that he would want in order to do that. And he still hasn't really changed on that. He actually mentions it in his blog post about Lady Bird adopting Rust. He still thinks that, but it's just a pragmatic choice. Rust has the ecosystem. Rust has the momentum. Rust has a lot of other good things about it. Security, of course, for a browser is imperative, and it's so important to a Lady Bird team that it was the pragmatic choice. And that's a curveball. I was just like, didn't see that one coming.

I think the way they proved it themselves was less of a curveball when you get into the details. I think when you look at the details, they start with libjs. That's Lady Bird's JavaScript engine. Andreas describes it quite well in terms of what it is, but it's got extensive test coverage per Andreas. Which I think that makes it a good starting point, because if you've got great tests, it's pretty easy for, I would say, an LLM to say, OK, here's a bunch of tests that prove all the things. Let's just use that as a great way to get to the other side here. One thing he pointed out was there was the result was around 25,000 lines of Rust. The entire port took around two weeks. We had noted that the same work would have taken him about multiple months to do by hand, which is kind of obvious to anybody who's been using AI coding or agent decoding or an agent. It's pretty obvious what you can do in a day or two or a week or two with a tool like that. 25,000 lines of Rust, the entire port took around two weeks, and the same work would have taken multiple months to do by hand. But the fact they start with a great project from the inside, like libjs with great testing, that is what I think gives you confidence. Like, OK, we've got a great code base with great test coverage. That's a great start to pull in this transition.

Yes. And is it safe to call Andreas a gray beard? I know he has a beard. I don't think he's necessarily gray. The guy's been around. And his title of this post was Ladybird adopts Rust with help from AI. And when I logged this in changelog news for Monday, I almost pulled that part out because I searched for the whole thing with AI and I was like, well, where is the AI? And I didn't get to that libjs part fast enough. He actually specifically names Claude Code and Codex for the translation. I was looking for AI and I thought, was he just link baiting? Is this link bait? Just saying with the help from AI because he wanted to get more attention, as if he needs help with Ladybird. It's already a very popular project. And that being said, I actually did find the portion. I was like, OK, this is legit. Makes sense coming from him. But the thing produced a lot of what he calls like C++ style Rust, which is totally fine for what they've done so far. And it was just such a very good use of these tools, especially in the hands of an expert, to see how it made that which is intimidating. If not, I wouldn't call it impossible for him. He certainly could have got it done. But just an intimidating project, so much more approachable. And that's really, I think, the unlock for people of all skills, but even for somebody who could sit down and hand code every single line and does a lot of that work and continues to and takes pride in his craft and all these things is like there's huge unlocks here. And that got me thinking about Rust in general and maybe its benefits. I know you've been picking some up a little bit with the help of Claude and other tools and whatever it is. Rust's biggest drawback is its complexity, mental overhead, right? It's hard to learn. Let me just say that.

It's very terse.

Yes.

It requires a lot. The compiler pisses you off.

Exactly.

That code sucks. Yeah, all the things, you know. You're well aware. Even before you put into prod, you know your issues. That's the thing. Right. You learn how to perform at compile time.

Yes, compile time bugs better than runtime bugs, as all of our static friends will tell us. I'm still a fan of some dynamic languages, but I totally get it. Ruby. Yeah, I'm just going to, Ruby for life. I love Ruby. I was writing Ruby before I started change login. I'm going to be writing Ruby after I leave change login. Ruby for life. That's right.

So beautiful, so elegant, so amazing.

Yes, Elixir too, so big fans of both of those. But I'm thinking that it's such a win for language like Rust to get mass adoption because now we have tools that help us over all of those difficult parts. Eventually, I think if you stick with it, even if you're not hand coding, like you are code reviewing, you are instructing, you are testing, et cetera, I think you learn it over time. But I think you learn it without any of the like showstoppers that certain people of stubbornness make it through, but a lot of us just throw up our hands and say like, ah, this language is not for me. So I think it really lowers the barrier to Rust and I think makes Rust way more approachable to way more people.

As it should be, honestly, as it should be. I think after using it, there's obviously, in any language, there's rewards, right? And there's tradeoffs. But I think largely the safety around Rust is just bar none. It's efficiency, the way it handles memory is amazing. You know, I'm not the super Rust nurse. I can't go into it. I'd love to have that kind of person here to just go deep into it. But the memory efficiency with Rust is just the one that would go is you've got the garbage collector. You know, and so if you have an interface or even like a network interface kind of thing that requires zero latency or very, very minimized latency, almost zero. Then Rust is your choice over Go because Go will introduce those steps, those stops with the garbage collector. And they're small, but if the byte matters, then the byte matters. It could be a database, for example. That's a challenge. One thing he says, though, is if you… I'm in the blog here. He said if you look at the code, you'll notice it has a strong quote translated from C++ end quote vibe. That's because it is translated from C++. And so I wonder, you know, if that's a bad thing for the long-term code base. Let's just like spitball this a little bit. While there was a test coverage, while there was, you know, an existing code base, existing test coverage, why translate from C++ versus new implementation? And I know that he was trying to solve a problem. He was trying to prove the concept probably. But if Rust truly is, and it seems like they're going to keep writing C++ alongside of Rust is what he mentions later on in the post. So it's not like a straight cutoff, like this is not the winner and they're still in like an interrupt kind of scenario where they're doing both boundaries. But just thinking about it, like why not… what would have been the process, do you think, to not translate but rewrite it? Take feature for feature. How could you not translate it versus just say, here's this, examine this code base. We're not translating it. Here's the test coverage. Here's all the things it's testing for, which can be intent-based, which is what you hear a lot or what you will hear a lot in this new world we're in, which is like specs, intent, you know, document-driven. All those are synonymous with, I understand what intent is. I understand what the user experience should be or the DX should be. I understand what I'm trying to get to. Here's where I'm at. My intent is X, which is what he could have done here. What do you think about an intent-driven versus I guess ported, like this way where it was translated from C++. Why not inspired by versus translated?

That's a really good question. I think that he could answer it better than I could, but what I would surmise is kind of like when we talk about, you know, what's going to change here around the changelog and the answer is like as little as possible. You know, like I won't be here, but like everything else is going to be pretty much try to stay the same because you don't want when you have big change, you don't want to have big radical change necessarily. And I think in this case, when you have a big change being introduced into a code base, which is like here comes a new language and you're proving that out and you're you're taking steps in that direction. It's like, let's do as little as we can, but still make progress. And so as little change as possible, you're way more likely to get it replaced when you can give the tools, the existing code and the tests and say, let's not rethink the architecture and everything. Let's just, you know, here's our scaffold. Let's pull out this part and let's put in that part and make sure the building still stands and let's call that a win. And that will help us decide if this is a direction that we want to go. And yeah, we're going to have some C++ looking rust code at the end of the day, but we can slowly swap that out as we as we do rethink and rewrite, you know, subsections. Just like you're going to make little tweaks here and there, you know, to changelog news as you go out making it yours. And so, like, I think that that's probably the reason. Probably you just got done way faster that way, too, because, you know, give Claude and Codex as much as they can have, and they're going to crank way faster than having to. I mean, I guess that's an assumption. Maybe they won't. What do you think? Will they do better with existing code than with none?

You know, I don't know. I think I would honestly, because the the cost is near zero or as close to zero as it's ever been to give it a try. I would say I would try, honestly, because a fresh new code base. Honestly, it might be something where and I'm not sure how much experience with Rust Andreas has, but I think as he becomes more confident, the one thing that Rust does for you is it gives you confidence in what you're delivering because of the way it compiles, because of the way that you get past that compile time. It gives you a lot more confidence in the code you've actually written because you squashed so many possible bugs in the future with that. I think a future endeavor of his might be to literally rewrite from scratch with Rust, but I think that would only come if they give it a true. This is the only language we're going to use. This is the way forward, et cetera. But that's not what they're doing. I think that I would, you know, because the cost is near zero, I would try it. This is a long story short there, but friends, I'm here with my good friend Chris Kelly over at Augment Code. Chris, I'm a fan. I use Augie on the daily. It's one of my daily drivers. I use Clod code. I use Augment, Augie, and I also use AMP code and others, but Augie, I keep going back to it. And here's where I'm at. I feel like not enough of our audience knows about Augment code, not enough about Augie, the CLI. It's amazing. I love it. What can you share?

Yeah, we often say Augment is the best coding assistant you've never heard of. And that's both frustrating as someone that works there and it's like very proud of the work we've done, but also like inspiring. Like we want to go and sort of punch above our weight. We just like we aren't anthropic and we aren't open A.I. And so the quality of the product itself, you know, with our context engine, once you do touch it, people are like just blown away by that. And so like that keeps me going every day.

So not to bear the lead here, but this is a paid spot. You are sponsoring this show to get this awareness. Now, at the same time, we're selective and I love to use your tool, but there is in the world. So a lot of developers look at the space and they say, OK, well, how long can this work? How long is this sustainable in the case of cursor or windsurf or you pick the name and you think discounted tokens? Help me shape a lens for audience.

I think it's a lot of awareness, right? Like Cursor got a lot of publicity early on for like fast revenue growth, which well deserved.

I think, you know, frankly, some of the media got this gets the story wrong and that like if I gave you a dollar fifty for every dollar you sent me, I'd be the fastest growing startup in the in the valley. And so when you're selling discounted tokens, yes, of course, you're going to go very fast. But all that money plus more goes to the model providers.

So I think the real story is the story of anthropic and being an API provider. I think the market has just moved so fast and there's so many pieces of competition out there that it's just hard to get noticed.

So, friends, I love augment code and I love using Augie and I highly recommend you use it. I love using Augie. I can hand Augie a well-defined specification, a well-defined pep, as I call them in my world, an agent flow, and it executes flawlessly. So the cool thing about Augie that I love most really is that context engine and I can hand it a task and it can just churn away on my well-defined plan and just never bother me and accomplish the mission. It is so cool leveraging the latest models, the context engine and all the fun things behind the scenes in that awesome CLI. So, yes, go try it out. Augment code dot com. Right in the top there is a CLI icon, a terminal icon. Click that, install it and change your world. It's going to be awesome. Augment code dot com. If you're thinking about contributing or saying, you know what, I want to try this. I want to port some of this code. Not invited. Okay. Don't get sad. Not invited. It says we want to be deliberate about which parts are getting ported in which order. So porting is managed by the core team. Please coordinate essentially. Don't do it and waste your time if it's not something that can't merge. Paraphrasing that last sentence there. But, you know, I think if you're interested in this port or if you're at least tantalized by the effects of Rust and you're seeing it daily in your news feed. And in this case, I saw it three times. We haven't covered all three yet. Then I think go check out the code base and watch them in action and see what's happening. You'll see what does it take to go from C++ to Rust and what's happening behind the scenes. And I'm sure on their YouTube, they'll publish more content, but I'd like to see more of this because Rust is the language in that space of the future. Just this.

You heard it here first. He's calling it.

Just this. Well, I'm just following the lead, you know, just in the stream.

Yeah, man. Just seeing what happens and just saying it out loud. No, I don't disagree with you. It's overwhelming. It's adoption and its benefits. And I think he did. I mean, I think C++ will be in this code base for years, if not in perpetuity. I don't think they're going to like ever completely crush it. And I think he said that even on the show. It's like, yes, this is more like a direction. There'll be parts that we exchange or other parts that might even make more sense to just leave alone. My answer back to your why not just try, you know, since the cost is zero. The only answer I have for that is like, if it ain't broke, don't fix it. Like there's other stuff that you can be working on. Obviously, you can get multiple multiple agents going. But, you know, the price of agents is not nothing. And it's probably I don't know, is it going to go up? Is it going to go down? It feels like so many.

There's a lot of blood and water right now between the agents at large, you know.

Right. There's this whole like clogged code subscription thing with open open code. I don't know if you've been tracking that, but the way that. Yeah. So Anthropic, I think, had an amazing idea with clogged code subscription, which I'm I loved it. Like as soon as Jose added ACP, as that was called, agent client protocol. As soon as I could use my clogged code subscription inside Tidewave, I was ready to dive in. Whereas if I had to go out and get a separate source of funding and get an API keys and like spend API tokens.

Yeah, agent client protocol. That was Zed's thing.

Yeah, Zed started it. And I think that Tidewave is using it in order to use clogged code from inside Tidewave versus a clogged API token. And it's like I can piggyback that on top of my already existing monthly fixed limit as a guy who likes to know what he spent every month. I like that. Like it just makes it an easy adopter. Same thing with like these new OpenClaw style tools. If we can just plug in our codex, we're already paying whatever, OpenAI, we're already paying Anthropic, just plug them in and then it gets rate limited as I have tokens available per month. It's a fixed cost. I feel good about that. Well, Anthropic does not feel good about that. So they've been changing kind of the rules around your clogged code subscription and saying that you can't use it for third party tools. You have to use API tokens. And this has a lot of people not too happy. I'm one of them, but I also totally understand it because, I mean, they got to make some money, right? They got these huge valuations. They got to have revenue, right?

Yeah. When you look at the landscape, this is at least where my lens is at. Google has money to burn. And they can operate at zero margin and profit for a long time.

Totally. They got a cash cow, which is different.

Precisely. And so then you have Anthropic, large investment, large capital raised, massive valuation. You see the big number, but the spend is so astronomical. And then you couple that with OpenAI, the same, right? The same large investments.

Yeah.

And you got two key players that can't lose, right? That's the game of business, like don't lose. This is the object, right? Don't lose and play for as long as you can, right? Play forever. But when you have Google, and they're doing well. I mean, they're doing quite well. They're very impressive. They're actually surprising me. I didn't think they would, but they are. But when you have this kind of scenario where you've got such massive capital raised, and you've got Google who can essentially operate at no profit for as long as they have to, they can bleed them dry to some degree. So they have to win. They have to profit. So when you look at this landscape, y'all, it's not by surprise that Anthropic and OpenAI are going for ways to make money. And Google is giving away NotebookLM, giving away Nanobanana, giving away things in a lot of ways, because they're the ones with the moat to lose. You know, these other folks are essentially new that OpenAI is the incumbent when it comes to the first large language model that was largely usable by mass.

Yeah, the first chatbot.

Right. But Google's catching up, and they have the dollars to fund catching up, and they have the dollars to lose catching up and flatten the market. And so you've got those worlds, and you've got to expect this. Now, is it good business for open code? No, I think our friends over there, you know, that's not cool to do that. I don't know what that means. There's also this news about, which is not in any of our notes, but this news of, what is it called, distilling the open models, distilling from, you know, a mass infiltration into Anthropic and Clod and whatnot, like a massive amount. And the world's kind of applauding this. I'm not sure that I'll agree with that either.

Can you explain that some, what that means?

I didn't prepare for that.

Okay, it's not in our notes. I can probably do a short version. I think I know what it means, but I'm not totally up to it. Which is that, and this is Anthropic, is saying that there are organizations abroad, I'll just leave it that vague, that have been basically creating tons of accounts and prompting Clod and extracting a whole bunch of stuff in order to train their models on the results. And that's what you mean by distilling, I think, like taking the results and turning them into a new model. And they're mad about it, which I understand why they are. Am I explaining it right? Is this what you're talking about?

Yes. Okay, so let's see. I grokked it really fast, because honestly, grok is the best for real-time news.

Yeah.

Let's see if they can actually help me out here. So I'm going to paraphrase a little bit of it, but the biggest recent story involving Anthropic, this is me reading directly from grok's response, so forgive me if there's corrections or a lack of correctness. The biggest story involving Anthropic, the company behind Clod code, Clod AI models, and distillation broke just yesterday, which was February 23rd, this is February 24th, 2026, as we record. Anthropic publicly accused three major Chinese AI companies, DeepSeek, Moonshot AI, and Minimax, I'm sorry, Minimax, of running large-scale coordinated distillation attacks on Clod to steal slash improve their own models.

There you go.

Now the world will say, our fellow friends out there on Twitter slash X and other places will applaud this. You know, I'm just not sure I want to applaud anything in this tumultuous world where there's massive downness, I would say, in a world where we want sort of massive upness, okay? I'm not sure I want to applaud this. I'm sort of in the middle there, because they would say that, well, Anthropic did the same thing to other things to get to where they're at. Right. You know, how did their models get trained in the first place, et cetera, et cetera, and I get that argument. But that genie is out of the bottle and applauding somebody's downfall, I suppose, because of somebody else's upfall, especially in a coordinated distillation attack. I mean, would you categorize it as an attack? I suppose so.

If they are categorized as an attack, I guess it depends on who you are, I think.

They said, like, there was 12 million. I saw this post from 24,000 fake fraudulent accounts, if this is correct. That they were using the slurp down results. Generated over 16 million exchanges, which are conversations slash prompts with Claude.

Yeah. So, like, are they, I mean, are they paying? If they're paying, then it's like, I'm sure it's against the terms and they could suspend their accounts. I don't know. It's a tough one. I think that obviously the existing players who have trained their models on the world's information, including proprietary content and the work of artists and the work of photographers and just et cetera, et cetera, and the work of coders. In the case of some of these models trained on publicly available code, but not liberally licensed code, not merely liberally licensed code, and so they're stomping on GPL code, for instance, which we know has happened. I feel like they, there's recourse for them in the United States, at least. These are all American companies in the case of Microsoft, OpenAI, Anthropic, and Google. They all can be adjudicated in the court of law. And if there's any justice in our court system, which sometimes you get it, sometimes you don't, I think that will play out. And there has been results based on scanning books, buying books, et cetera. But when it comes to the world stage, I mean, what do you do when it's coming from a different country or different jurisdiction? I don't know. So that's a tough one. It's murky.

Yeah. It's summarized at the bottom. It says in short, distillation itself is normal tech. I mean, if you look at just a short tangent, I believe the way that Airbnb became so successful initially was because they leveraged off of a non-existent web-based scraping API against Craigslist. Right. They would find things they could post. I mean, this is in the history books. So this is, that's a version of distillation, right?

It's kind of like one, one person's scrappy startup is like another person's attack, you know?

Yeah. Yeah.

It's like, well, we were just trying to figure it out and we needed data. And so we scraped some data. And who hasn't gone out and just scraped some websites for their own use? I mean, we all have.

I mean, how do you, yeah, I mean, a hundred percent. You got to do it with taste. Obviously, terms of service is a real thing. Yes. And that's what they say here is like doing it at massive scale against the competitors paid API in violation of TOS terms of service, especially across borders. This is what Anthropix is calling out as a major problem right now.

I understand that. I guess it's.

Who's got time to read those terms of service? Okay.

Right. We need the one person. I just have your agent click on it. Okay. All you need is just spin up an agent, call them, you know, clicker, clicker bot, agree bot and have it do it for you. Now.

Yes.

Did you actually, are you at fault then? If you didn't actually click that acceptance, something else clicked it for you. Time will tell.

Time will tell.

It's a weird world as things get increasingly agentic and increasingly like the snake eating its own tail. You know, I think we'll start to see it unravel even more. I don't know.

Well, that was not at all in our list of things to talk about today. Well, we side tell. That's what happens. Yes. Let's quickly mention two things more about rust and move on to a couple other topics. I want to mention Ubuntu is also using rust. We're not going to go into detail there, but there's a lot of cool things happening there. Okay. I think rust has a recent survey out that I don't have notes on, but I want to mention there's like a new survey for it. We'll put that in the show notes. And then obviously there is some change in terms of compilers, registries, tooling for Python, JavaScript, et cetera. Yes. It's now being written in rust. And one of the most recent was OXC's JavaScript oxidation compiler, which is a collection of high performance JavaScript tools written in rust. Okay. Let's just put two, maybe a phrase together. Say two words together. High performance. I guess that is one word if you hyphenate it. Yes. Right. High performance and written in rust. Those two phrases will forever. Those, those, that's the way to describe the next project you do. Right. In rust. If it is a tool for X written in rust, it's going to be high performance written in rust.

And if you just wrote it recently, then it's modern. So put modern on there. True. Okay. Now, I mean, that, that dog hunts. You're selling, you're selling right there. So.

They wrote it. I mean, they're reusing the same verbiage that Astril did with UV and others. Like the, rust is high performance. Rust is fast. Rust is memory efficient. And just one thing on C++, the one issue with C++ is how you have to manage memory in your mind as you're designing and writing the code. And now if you're using an AI, then you're not writing much of the code to write it, but you still have to manage the memory manually, whereas rust doesn't for you. So that's kind of what makes it high performance is the developer can let go of that concern because the compiler is just that smart. That was the design of Rust all along. That was what, what the, they tried to do writing it, but I wanted to mention that quickly on that front there. You want to touch on any of that at all before we hightail to somewhere else?

Yeah, totally. So first of all, this is not from Astril, even though it's.

It sounds like it should be.

You know who it is from? It's from Void Zero, which is Evan Yu's startup, Evan Yu of Vue and Veit fame. And so he has his bona fides. And so this is from people who know what they're doing. OXC.RS. And so it's the foundation of modern JavaScript tooling. And so what is it? OX Lint. There's a linter. So again, following a little bit in Astril's footsteps there, they started with Rough, which was their linter, I believe. And then there's OX Fumt, as the gophers like to call it, OX format. But in, in Golang, they always like to say Fumt.

Yeah, Fumt, FMT.

So there's either OX Fumt or Ox Fumt, you know, you decide, which is a prettier compatible formatter. And then they have a parser, which of course I think these other things are probably built on and a transformer and a resolver and a minifier. So it's a bunch of subprojects with free and open source. So this is cool. This is cool.

How in the world do you build such amazing things on free and open source these days? It is a conundrum in this new world. Wow. I'm so happy about it, but it's also very scary.

In the case of Void Zero and OXC, that they're calling this OXC. Built on sponsorship. So there's some silver sponsors on the website, bronze sponsors and then individual backers. And so, you know, they're going straight up sponsorship style and hopefully that works for them.

Yeah. OX, look at this domain, Jared. We didn't even mention the domain yet. Dot RS Rust.

Rust.

Right? That's the extension for Rust.

That's a five letter domain right there. That's a nice one.

OXC dot Rust slash sponsor. If you are interested, they have details on why the sponsor, who current sponsors are, which seems to be plentiful from individual backers to corporate sponsors. One of the recent sponsor of ours, so kudos to them, is Miro. Miro, actually, I should say. They told me to say it's hero. I can't see the word M-I-R-O and not think Miro. It is Miro, but it is actually Miro. Miro, like hero. Just so you all know. So when you think Miro, think Miro like hero. There you go. Just to be clear, not sponsored, but they have been a sponsor. And so that's just bait into my brain.

This message brought to you by our desire to say things correctly.

That's right. That's right. Let's go on prem. Let's go self hosted. I think I don't know what you're feeling this year, but I feel like the future this year, this last year was the was the crack in the earth to say on prem is where it's at. I think as we drive more of our own internal tooling, as we start building more of our own SaaS replacements, let's just say, you know, you're going to desire to self host. And now is the best time ever to get into home lab if you're not into that at all. And I think the future is going to be self hosted slash on prem. And I'm excited about that. I am so excited about that, as you can probably tell.

Well, I have a little secret I'm happy to reveal, which is that I bought a Mac Mini. I bought a Mac Mini.

Wow.

Yeah.

Was it for our friend OpenClaw?

Well, it's soil to a certain extent. I've just been building more stuff, you know, like it's just living in a world where you can go from idea to something working in minutes. It's just hard not to just build kind of every not everything you think of, but just more things. And, you know, I just build stuff here on my laptop and maybe I wouldn't source it. Maybe I don't, you know, it runs here. Fine. I end up building stuff that runs on schedules and I'm just like, you know, my laptop closes. It's not a server. It's not a server. This is a work computer, you know, that moves places. And I don't have all I have. The only other computer I have in my entire house besides laptops for my wife and kids is a Raspberry Pi that's in the basement that's not plugged in.

Hmm.

And, you know, I just.

Raspberry Pi 3. Yeah.

Yeah. And people totally depend on what you're doing. Well, then I thought it's just time for some some new hardware and, you know, everyone was buying Mac Mini's. I kind of got caught up and I told you about my friend that emailed me after or texted me after the news about Open Claw. He was like, I just bought a Mac Mini and I'm just like, you know what, I'm just going to I'm going to buy some. I actually bought the exact specs that you said you would buy. I think that when we talked about it.

Yeah. The second tier of the top tier.

It's the top tier. Oh.

It's the pro.

Yeah. I did not go full RAM because I'm not going to run much local. I don't know. I didn't want to spend. Always go up to random.

I know more RAM, especially when it's big.

Here's the other problem. I wanted to play with it. And when you go more RAM, it kicks it back like three weeks to ship. Oh, yes. And I'm like, yeah. I mean, if I'm having tons of fun, I don't know. Maybe I'll buy another one or something and give this one. So you can bolt on storage.

You can't bolt on RAM. Yeah. And you can bolt on storage at Thunderbolt 5, I believe, in the Mac Mini. I could be wrong. It could be a Thunderbolt 4. So you've got that full bandwidth.

Anyways, so I'm going on-prem at my point. I'm going on-prem for whatever it is that I have. I have nothing to run, but I've been having some fun. And I do. I did try out Nano Claw. I haven't set up Open Claw. But I do want to know this weird world all these people are living in. And try it for myself. Zero Claw, actually, might be the one I set up first, because that's a radio host. Yeah. And way less resource heavy. I don't know. But I'm excited to just move some stuff off my laptop over to there and put it on a scheduler. That got me thinking, like, you know, Mac's built-in scheduler is Launch D, which really doesn't have a good interface, you know. And then just in the shower the other day, I was like, I should just build a GUI for it and be sweet, you know. Like, I could do that in an afternoon with me and my friends. And then it'd be like a cool Launch D GUI. Otherwise, you can use cron, but it's a little bit different on Mac and things get weird, you know. So, yeah, I'm all about it, I guess. We'll see.

I'd like to see that Launch D GUI. That's actually... That's cool.

Cool idea. You want to help me name it? I got stuck on a name. I couldn't think of a good name. That's why I didn't build it, you know. You got to have a good name first and then you build the thing. But I don't know.

Yeah. I can noodle on that a little bit. Well, friends, today's podcast is brought to you by our friends over at Squarespace. And I use Squarespace personally. I love it. We use it on one of our small businesses. It's amazing. But here's one that hits closer to home for some of us. Maybe you got friends, family, yourself, maybe even. Maybe you're selling content. Maybe you do consulting. Maybe you have the desire to do content and put a paywall in front of it. And make some money from different ideas you want to share. Well, that's the gap that Squarespace fills. It's the all-in-one platform for turning what you know into a real business. Not just a website, but a way to offer services, book clients, send professional invoices, and even get paid. It's all in one place. Two things worth knowing. First, offering services. If you do consulting, workshops, coaching, freelance, speaking, dev work, Squarespace gives you scheduling, on-brand invoicing, online payments, email marketing, all of it built right in. No stitching together five SaaS tools. Just one dashboard, one way. No chasing payments in your inbox. You set up your offerings, clients book and pay, and you get back to actual work. Back to that AI project you're doing. Second, selling content. Got a course idea? Maybe. Video tutorials? Probably. Second, maybe you're selling content. Maybe you have a course idea, video tutorials, premium posts. Squarespace lets you gate content behind a paywall, add value, deliver on that value, get a one-time fee or subscription, your call, and even recurring revenue from what you already know. The platform handles the access control for you, the payments for you, the presentation for you, and all you gotta do is bring the expertise and ideas. Here's the next step. Here's the next step. Head to squarespace.com slash changelog for a free trial, and when you're ready to launch, use our offer code CHANGELOG to save 10% off your first purchase of a website or a domain. Again, squarespace.com slash changelog. Get that free trial, use it, enjoy it, and have fun. I did think about Bill O'Reilly, a little request from the audience. If you're a memer, if you like the meme out there, take Bill O'Reilly when he says, F it, we'll do it live, and say F it, we'll do it on-prem, okay? Because that's what the world needs is on-prem and self-hosted is the way of the future. The cloud's still there, and it's still great, but I think I just miss, you know, like a lot of folks touching things like rack and server. Like I've got off camera, you can't see it here, I've got one motherboard there, a case there, an SSD NVMe over there, a cooler right there, and lack of time, man, lack of time. But I got things, I got two motherboards, two CPUs, a couple things to build, and I'm just enjoying that kind of stuff. I love building as you already know, but I say we'll miss it as if I miss it, but I don't actually miss it because I get to do it frequently. I miss it in terms of time, but I'm paraphrasing and mentioning this post on Reddit, this fella, own general6755, one day ago. Am I the only one who genuinely prefers on-prem over the cloud? Now, Jared, we use Fly, we love Fly. That's right. We're friends with Render, we're friends with other folks as well. I think there's, I'm not saying those folks are bad by any means, but I think when you're only answering, I think this is what own general6755 is alluding to, and I'm not going to say this whole entire phrase, all the details in his Reddit post on our DevOps. But it's this fact that when you go into a new job, you go into a new position, you go into a new scenario where you're stacking new infrastructure, it's largely APIs and services you're kind of piecing together. And as you know, the GUIs are dying and CLIs are winning in this new world. And you have to navigate all these settings. We recently just did this with keys. Yes. I couldn't see the keys that, I mean, it's... What's up with that? They're called account keys. Right. Why can't I not see the account keys you create, Jared? Help us out Cloudflare.

Does that make any sense? What's up with you guys?

Cloudflare, that doesn't make any sense, okay? It doesn't make any sense. I mean, like the fact that I couldn't see them and you could, like...

We're both looking at the same screen and we're just like talking past each other.

The same credentials even, like the same permissions, the same administrative level permissions made no sense. Okay. No sense. And so when you're in that world and you have to like, okay, sure, you have to have keys in on-prem. You have to have SSH keys and permissions and things like that. User accounts and you got GUIDs, GUI IDs, you got all sorts of things, UUIDs and stuff.

Sure.

Sure, you have those issues, but that's something you can control on-prem by just SSHing in and Linuxing, the way Linux works. You know, when you miss this world and you have to build infrastructure on the cloud only, you just get to miss it. So that's all I'll say. You get to miss that kind of scenario where your only choice to build your next big thing is cloud. I say, no, that's not cool. Self host at first. In fact, tail scale funnel, your way to success.

What's that?

Well, it's like a tunnel, but it's a funnel. Okay. So you could take something, let's say you got something running locally on a port, let's say port 8080. You can tail scale serve and tail scale funnel that thing into essentially punching a hole, which actually doesn't punch a hole, through the firewall because it's a mesh network and enable connectivity from the outside in and the inside out. For example. And so you can actually run a service on your Mac media like you've got or on your ain't got time to build it yet, but I'm going to soon kind of thing. Okay. I got other things. Proxmox is over there. Don't you worry. Proxmox is humming along and doing well. My gosh. I've never had more on Proxmox in my entire life. But you can use it there and build there and just tail scale your way to success. Okay. Look into it. The next episode, actually, next week's episode. Is that tomorrow? Tomorrow's episode? Soon. Very soon. Very soon.

Check your feed. Check your feed. Go listen to it. If not, it's coming very soon.

Is talking about identity in tail scale. What I didn't realize so much so when I did this pod, and it's a slight teaser for it, is how embedded identity is in tail scale's networking. So you larger thing about tail scale is this glorified VPN.

And it is that.

Yeah. But think of it like everywhere you go in the network, if you're authenticated, you are you. You got things like OIDC and things like OIDC connectors and being able to just already be logged in to TrueNAS or already be logged into Proxmox or pick your internal service that can support OIDC. Because your tail scale network, your tail net, when you go about it, you are you. And so you are you as your identity as well, which I think is super, super cool. Anyways, on premise away. That's all I'll say.

Tunnel and funnel. I like it.

Tunnel. It's not a tunnel. And we did mention that in that pod. I was like, you know, I thought it was a misspelling because tunnel makes more sense. But I think Cloudflare D has tunnel while tail scale D has funnel. It's actually called tail scale D, but it is tail scale.

And this is effectively like what ngrok was always doing for us back in the day, right? Which is like open up. Yeah. Yeah. Now does that require some sort of- A version of it.

A version of it. Yeah. ngrok requires you to port open on your firewall, whereas tail scale does not.

Okay. I did not know that. Yeah.

There's no port opening whatsoever with tail scale. And not an ad, but they are sponsoring us very soon. And you know I love them. You can go get a free account today. They're free forever. That's how they are. And so if you're a home labber or somebody has sent you with 100 or less devices, Jerry. You've got to have one.

Basically free forever.

So you can home lab to your heart's content to 100 and they're happy to have you. Happy to have you. All right.

So you should use it. Quick side quest here. Yeah. In what calendar year do you suppose you, Adam, Stokowiak are going to hit that? You're going to have 101 devices on your tail. Like when are you personally going to hit that? We're talking like you're getting close. We're talking like a decade. Never. What do you think?

Let me log in real quick.

Devices are proliferating on our networks. You know, sometimes before we even know it, but it doesn't mean we're necessarily running tail scale on them. Yeah. Tell us what you got. What are you working with?

Let me tell you how many are here. 54.

Oh.

And that's only because there's no cleanup. Okay.

You should probably get that down into the 40s.

Yeah. Let's see. I haven't announced it yet. And I'm not sure when I'll actually open source it, but I'm building a self-hosted GitHub runner. Because I was just tired of how slow GitHub runners are. And it's called Turk.

Do you know how much you run that?

Yeah, they do. Yeah, they do. Well, they may change the ball. They may change the playing field on that front there.

Yeah.

But for now, you can build an app and connect to GitHub and build your own. Now, I'm trying to do this. And so the reason why I have so many is because it's in test mode. And it uses tail scale for the networking to connect to things. And so because of that, it's got a lot of test machines that are actually not active. So these are all dead ones part of my test. So truly around 20 devices across my network. But in actuality, around 54 per the count right now. And a lot of that is just cropped from... So what's the calendar year, do you think?

Do you think you ever hit that at your home office slash home lab?

No, I think honestly, I probably hit it within this next year. But at that point, it's propping up either an open source project that has a business attached to it or could have a business attached to it. So I think at that scale, if those were truly sustained, true devices on the tail net, that's not a home lab anymore. I mean, I think, I don't know, maybe. Actually...

Home prod.

A home lab with 100 devices? Somebody out there is calling foul. They're like, Adam, I got 99, man. I got... Dude, somebody's out there with like 400. I don't know. I guess in the world of home lab, I'm not really sure.

Yeah.

I'm not sure I will personally ever have 100. Now, if I had new projects I'm building and each one's self-hosted in my home lab and they're self-serving, that's a lot of software, man. I don't know. That's tough.

You want to talk more about this runner?

That's why they made it 100. It's just impossible essentially to hit that number.

You want to talk more about this runner? I mean, I'm intrigued. So, this is like basically self-host your GitHub runners, right?

Yeah. So, let's see what I can share now. So, there's a, I guess, newer to me, probably less newer to others out there is a new thing called Incas. It's new to me again. That's why I'm saying new.

Incas.

Incas is, I'm on their website, Linuxcontainers.org slash incas. Incas is a next-generation system container, application container, and virtual machine manager. Some history behind this, which I'm loosely aware of, is a Canonical's LXD. It was Canonical's LXD. And the fellow behind this, his name is Stefanie, or Stefan, I'm sorry, not Stefanie, Stefan. Short-named, just a staff, I believe, and I could be wrong on that front, but I'm trying to get them on the pod. In the near future, but this is the underpinning. So, when I looked at Incas, and because it supports like any Linux, ZFS, copy on write, you know, it's going to be really easy to build on top of Incas. And so, I'm building Turk right now because I needed to build some, let's just say some stuff on GitHub through runners, and that's super slow. And we've known this because we've been sponsored by Depot and sponsored by namespace, we're users of namespace, and this is well-known that GitHub runners are just slow. They're not purpose-built runner platforms to run faster. And so, the runner part of it is you have GitHub actions. Instead of your project, you obviously have .github or something like that, and you have slash workflows. And inside of those workflows are things that will run on GitHub actions. And so, when you push a repo, those live there, and they can run on schedules, you can hit them, they can do your releases, you can tag a release, it'll automate that stuff. And so, then that instantiates GitHub actions, which is essentially a logic platform, an if-then-else builds Linux, a bunch of crazy stuff. You can run a runner that just checks things, kind of like crawling away, too. But then it dumps that off to their own actions runners, which, as I mentioned, they're kind of slow. But you can also do self-hosted runners. And so, if you just want to build your own simple self-hosted runner, you can do that today. But the problem is that I found, and the reason why I went this route, was because they give you temporary keys, they expire in 90 days, they make it painful. They basically make it painful to self-host your own runner. And then you also have to do it per repository. You can't do it like, I'm Adam Stack, or I am, you know, slash the change log, and put it at the org or user level. You have to do it one by one, and the same painfulness on the key expiration one by one. And I'm like, well, how did Home Depot, where did that come from? Well, Depot. How did Depot do it? So, I started looking at this, and it's an app. You build a GitHub app.

Gotcha.

And so, I'm like, okay. And my goal with Turk, it's called Turk, because our friends back at Amazon, they used to have Mechanical Turk, right? I was like, man, the coolest thing for this. Now, I'm going to reveal this now. If you go there, you're going to see nothing, because this is like literally brand new. Turk.run, okay? That's the coolest domain ever.

That's cool.

Turk.run is what it's going to be. I'm still not sure on the licensing, but I'm thinking about building this into something that could be commercial. I'm just not sure yet exactly where I'll land. But the licensing battle on open source is a struggle, because if I give this too permissive of a license, it's easy for all these existing runner platforms just to use it. So, I'm torn there. I could use some guidance and some advising on that front. But I'm thinking, gosh, man, don't hate me for saying this, man. What? I'm thinking some version of, what do they call that? I'm not even sure what it's called when you have open code, but not open source.

Open core? Oh, business source, perhaps? Business source.

Fair source. Source available.

Source available.

That infamous phrase we've said a few times. I'm thinking source available. And the call we had with the SDK folk, that was what really gave me a lot of insight into this world of, okay, you can be source available, respect the world of open source, but still build a business on top of it. So, I'm just not sure yet. I'm just not sure yet. At this point, it's a fun project I'm building internally that has some long legs. And I'm using it in prod. It's actually right now building DNS hole. So, that was actually the most recent win I had was let me actually dog food this thing. And so, DNS hole is a private repo right now on the DNS hole user. So, if you go there, github.com slash DNS hole, there is an org there, but nothing for you to see yet because it's coming soon. And the biggest issue for me was being able to build this thing, not in a VM locally and a couple other things to kind of get it over the finish line. And time, and time really. Sure. And so, Turk is what I built to do that because I was just like, I want to self-host runners because GitHub actions runners are just so slow. Went down that rabbit hole, built Turk, and now I'm actually building DNS hole with Turk. I'm just so close to two cool things happening. Yeah.

Well, that's exciting. I'm sure you'll let all of us know when these things go out there, right?

I mean, it's ASAP. Why not? So soon, so soon, I actually thought about an image registry as well because another project I have has to have a custom Linux image. And this threw a curve ball at me because I was like, I was not expecting to have to build a registry for this thing. But a Turk image registry is the next thing. I just started to pin the spec on the Turk image registry. We often left, but yeah. Coming soon, Turk.run. For now, well, just know that I'm building it. And if you are interested in, if you believe that self-hosting is the future, which is why I feel so strong about building it because I'm like, this can solve our friends' problems. This could solve some enterprises' problems. And I want to build it right to solve my problems, but also think of it in a way that's reusable by the world. And so I'm trying not to make it an internal project, which is kind of easy in this world and just say, okay, it'll be internal. I won't do anything with it. I really want to build it in a way that's usable by me. I want to prove it works for me, which was DNS whole being built with it and then being able to take it to the masses. So that's the next step.

That's cool. Very cool. Should we move to our next story?

There's more self-hosted. I think we'll gloss over a couple. So DHH, this is not in the list, but he's talked about moving away from the cloud for a while. Head standards prices are up 30 to 40 percent. I think this is largely predicated on the fact that RAM and CPU and storage, mostly RAM is just astronomical. Jared, I think I told you this recently, I bought four sticks of RAM for like 200 bucks recently. Four. Two of those sticks is a thousand. The four and ten problem. Back to that. Yeah.

So you spent two thousand bucks on them?

I didn't spend two grand. No. No, I spent two hundred bucks on four. Those four now are worth two grand on the market.

Oh, you are having a good time.

My gosh. I think the last day the prices were low, I think. I was surprised. I just bought RAM. This can't be true.

Throw those on Craigslist, man. That's a good markup right there.

I got self-hosting to do, bro. I can't do that. Those things are too viable to me. Now I'm like, OMG, I'm so glad I bought them when I did. Yeah. Yeah, I think NanoClaw was the other one I wanted to put the list to. Gotcha. NanoClaw moved from Apple containers, which I'm not that familiar with.

Yeah.

But I'm about to be because of Turk. Okay. And then because part of Turk is going to be built on Mac as well, not just Linux.

Interesting.

But actually to automate Apple containers, which is cool.

So I did download NanoClaw and I used it. I think maybe I told you that. We were talking about Apple containers, you and I, weren't we? Yeah, recently. Yeah. And so that introduced me to Apple containers, which is Apple's first party project. It doesn't ship with Mac OS. You'd think it would just be in there, but it's not.

It doesn't?

No. Bummer. It's like a container project on GitHub. And you go out and click releases and download a DMG. It's very manual and weird.

Ugh.

Maybe it's just an experiment and they're not going to want to support it long term. I don't know. You never know what Apple's up to. But it's basically like Docker for Mac without Docker. It's like an Apple version of what Docker does for Linux for Mac. It has very similar even command line UI and stuff. And it's fine. And I used it because NanoClaw was built on top of it because the author of NanoClaw wanted just to do that, and I wanted to try something out real quickly on my laptop. It was cool. I got NanoClaw up and running. The problem with it was he only supports WhatsApp. Oh. And he also doesn't take pull requests. It's kind of an interesting project. Like the way he runs it, I thought it was fascinating at first, but then I thought it seems actually impractical, which is that you do not add features to NanoClaw. You add skills, and you have your agents build features on your personal clone slash fork of NanoClaw. Yeah. And so it's basically like if you want the feature, you can add a skill that will teach all of these things to use it, but he's not going to accept any PRs that says, you know, let's support Discord. Let's support whatever, Slack. And I thought that's an interesting model. And then I thought it'd be very fragmented and very difficult to actually stay up to date with NanoClaw if you have tons of modifications. Like everybody has tons of custom features that are never going to be merged upstream. So I don't know. Seems kind of impractical, but.

This is the same way that OpenClaw went, too. This is Peter Steinberg. I was actually, he said this on the 21st on X. He said if you were a service, I think it's also because he's getting inundated with like a lot of inbound, right?

Yeah.

Side note, Peter, if you're listening to this podcast, respond to my DMs, man. Now we were actually, it's funny because just before like the uptick in the major craze, like there was a lot of inertia around Claudebot at the time, now OpenClaw and all the names it has been. It was names even before Claudebot. We were talking and trying to coordinate timing. And then he got hit with that DMCA from Anthropic, which I think was just a little side tangent. What a bonehead move, right? How do you not see that this was an opportunity? And then you slap the guy with a rename and a DMCA.

Yeah.

You know, like that was just like, how did you miss the point for the trees, you know?

Like you're basically bringing a bunch of attention to a thing that otherwise had not that much anyways.

Yeah, absolutely. And not only was it a cool project, but somebody who had a following. Like, don't do that. That's just not very smart.

The fastest growing repository in GitHub history.

Yes, that's well deserved too.

And now he's buddy-buddy with, you know, Sam.

He's a genius.

He's a genius. And now your competitor, OpenAI, employs him. That's right. So I feel like Anthropic did drop that ball.

Oh gosh, man, they botched that one hardcore. That's such a sad moment. But what he says here, and this alludes to what you're saying about Nanobot. He says, if you are a service, make a score plugin. Not going to add random features or skills to core for visibility. Yeah.

So I think this is the same stance, but I think the NanoClaw guy is like way more hardcore on it. Like his is way smaller already. Right. And he's still not going to add anything. So it kind of makes it where it's like, I'm going to go use either the real thing or something that's closer to it. And so I'm planning on not continuing with NanoClaw. I don't use WhatsApp, you know? It's just not my ball of tricks.

So his name is Gabrielle Cohen, to my knowledge. Got a DM out to Gabrielle as well, Nanobot creator. So come on the pod and share your thoughts on NanoClaw if you have them. NanoClaw, sorry. Change that name. NanoClaw, to be super clear. Nanoclaw.dev.

In one sense, it's like good for maintainers, you know, open source maintainers. Because they're just like, you know what, you know, it's kind of the old Ben Johnson, open source contribution. He was the instigator of all this stuff, I think.

Trailblazer, wasn't he?

He was, man.

It's kind of that.

It's like, yeah, we're not taking PRs, but you can build a skill and you can just fork it and have your agents build whatever you want to. And I get it. I think that's an approach. I think you have a hard time fostering a community around that. But maybe I'm wrong. I know that OpenClaw has not had a hard time fostering a massive community. Did I say the right one? Yeah, I did. And they have, I think, two orders of magnitude more source code than NanoClaw. It's like 400,000 versus 4,000 lines. I don't know. So different approaches, different results.

Yeah. Different approach from results. I think that as a maintainer of an open source project, in the world of agents, you are being inundated with pull requests.

Yeah.

As a side note, even on pull requests, what's your stance on code review on pull requests, Jared? I know you've traditionally just not been a fan necessarily, but do you think it's a dead thing? Do you think code review is dead in the sense of the way we've known it? Do you think pull requests are a version of dead?

Well, I think the old phrase, the future is here, just not evenly distributed is so true right now in so many different ways. And I think code review is going to continue to live in different places for a very long time. Even our good friend Amel was like death on no code review. We started talking about just like basically vibe coding and, you know, merging, vibe merging stuff. I mean, in her domain, that was like anathema basically. I think that'll be the case in a lot of places, especially high stakes software for a long time. But I do think the way the wind is blowing and I did give her, I think, my own experience of change. And I've had a similar experience with self-driving cars where it's like at first you're like super nervous and you're criticizing everything they do. And then like a couple of weeks later, you're just like, yeah, I watch it, but it makes the right decisions like most of the time. And then a few months later, you're like, why do I have to even be watching the road? Because this thing is darn near flawless. And I do watch the road, but it's so good that I'm just like, I'm not checking on it as often as I would. Now, there are moments when you do, of course, in like high stakes traffic, you know, or dangerous scenarios. You know, weird one offs where you're like, yeah, here comes an emergency truck and et cetera. Now I'm starting to pay more attention, but I think that is the trend line for code review from agentic coders. Unless the advancements in their ability to write software stops right where it is. Like if it stops right here, code review is going to exist forever. But if it continues to advance, I think even as a longtime software engineer, you just stop watching as closely. And you're thinking at a higher level. And I think eventually if it continues to advance, we all do that. And in that sense, code review dies. That's my kind of dual sided take, maybe a cop out because I answered both ways. But that's what I'm thinking.

Yeah, I think it's going to evolve. I think it's going to be code review in the sense like you push APR, someone, something reviews it, there is going to become an evolution. I think we'll care more about code quality than code review, which is really the purpose of code review. Yeah. Is what changes? What's the implications of this change? Is it massive? And so in the sense of human review, massive change, massive PRs have been largely frowned upon, whereas smaller changes are easier. That's where you get the LGTMs on a massive PR versus a small one which gets scrutinized to the nth degree. Right.

Like bikeshed it.

Because it's so much easier to reason about, right? Yeah. And so I think you have this idea of reasoning about the code change and you care about that. I think we'll always care about some version of code quality, but that's going to change. It's going to be about who. It's the same thing with shift left. It's like we assure shift left, but now it's just like more on the developer. How much further left can we actually go with a shift left? Same idea there. I think you'll have more to reason about, to think about, and you'll always care about some version of code quality. But the purpose of caring about code quality is, is the intent met? Does it pass tests? Does it actually work in, you know, in development environments? Does it pass the smoke test where we spin it up 50 times and battle test it? And that's the point of like where you can do Turk type things where you can just spin up a ton of runners because they're more free. Yeah. In a self hosted world. So like you wouldn't spin up 50 runners on GitHub to test because like one, potentially super expensive. Two, my gosh, super slow. Okay. But in the world of Turk, where you can like self host and infinitely test on, you know, easily clinical VMs or containers, system containers, like that's the world you live in. So you can, you can ensure code quality at a much higher degree. And I think AI will continue to evolve. This will care about what has been code review, I think will translate into some version of code quality. And I'm actually wondering if the next big thing on this front isn't some version of a code quality gateway. You see this happening in the AI where you have AI gateways where you want to gateway the AI. This happened in networking, right? You have a network gateway or something like that where you can log into something.

So like open router is a good example that you're talking about, right? Exactly.

Something that lets you access more of the network, you know, is a gateway. I think I have more of that in the code quality. And what has traditionally been code review is going to be more in the real time. I want to know just in time, not before I push and hope and pray, but, you know, I just built this feature. Does this meet my intent? How does it work with others? Like, I want to see it on my machine, not push to, you know, some place and hope and pray. I think things will change on that front there. I'm not sure exactly how, but I'm thinking code quality. Over code review. That's where I'm leaning. Two more things on our list. They're both kind of deep. And I'm not sure how deep you went with them because I shared this list with you moments before the show.

I was just going to ride your coattails, which is, you know. Okay. Dangerous, but I do like a little bit dangerous. It could be dangerous.

Okay. So I'm going to loosely mention Boris Tain. So Boris Tain is going to come on the pod soon. The invite has been accepted. The plan has not been made. So there's not a date on the calendar yet. But one thing he said recently was the software development lifecycle is dead. You often hear the term Jared, if you haven't, this is new to me. I don't learn it recently. SDLC. I'm like, what is SDLC? Oh, software development lifecycle. So only if you sell SDLC type products, do you know SDLC acronyms, right? Right. Because you don't want to keep saying software development lifecycle. It's a lot.

Right.

It's a lot. Yes. So I get it. I get the acronym. But for a while, there was like, okay, what does SDLC mean again? Okay. It kind of makes sense. But he proposes, I should say, he purports that the SDLC, as you've learned it, is a relic. He shares, not so we could throw some video up on this, but he shares a classic software development lifecycle where we're taught requirements, system design, implementation, testing, code review, hello, deployment, monitoring, and recycle battery requirements again. Like this has been a known loop. And he goes on to suggest how the, every stage is collapsing, how AI is really collapsing a lot of this. And it's not because AI is eating it. It's because more of what happened in the SDLC is happening more once and in real time versus in different disparate places. And I think that's why I really care about just in time code review as well. And it's not really code review. It's just more like, is my code okay? You know? I actually want a software called that dudeismycodeokay.com. And then that'd be kind of cool. I want that, right? Because I don't really want code review. But it kind of goes on through this. And I think that kind of leans into the fact that we just talked about code review and code quality. That's going to be the thing. It's going to be more this is getting compressed, more this is getting replaced and compartmentalized in a way that it's just collapsing. A lot of this is collapsing. And I kind of mourn in a way the old way. But I don't. But I do. Like I really I was watching How It's Made recently, Jared. And there was this fella. And he was making let's see like you can make tortillas and stuff like that. You steam them and you want them in this thing. You want them to be steamed. Or maybe it's rice. It's this basket. And so he takes these four bamboo trees and you watch him go from four bamboo trees to many baskets. But it was not it was not like minutes. It was hours, potentially even days of labor to go from multiple bamboo trees down to, you know, baskets. And I think that's like serious craftsmanship to hand make those things. And that's what we did in the old days, which was like basically last week in software. You know, as we used to make software by hand, we used to hand craft.

Some of us are still doing it.

And some of us are still doing it. But I think that word was so changing. And then, you know, what Boris Tain is suggesting here is collapsing and changing is part of that. And so, like you said before, the future is here just not evenly distributed. I think maybe that's the case for most folks. Maybe the SDLC is not dead for everyone. Maybe it's just dying or changing or evolving. The word dead is just thrown around so easily. Right?

Well, it's sensational, right?

Sure. I mean, it's got my attention, right?

Yeah. You want to get attention. You don't say that things are changing. You say like, this is dead.

That's right.

And that's how you get attention. So, yeah, I mean, I've always looked at the SDLC with disdain myself, you know, probably because I was forced to learn in college and anything you're forced to learn in school is lame. Right?

Defacto lame. So SDLC was not new to you. This is a term you've known for a few years.

Yeah. This is like textbook stuff. I think he did it to you in the textbooks, you know? See? And then you come out of school and you're like, I'm not doing that. That looks rigorous. You know, Gerhard would do it. He would love it. He loves rigor. The rest of us in this room, not quite as much. It's hard to love rigor as much as Gerhard. The guy loves it. So, I always didn't like the SDLC. Of course, it gets kind of associated with waterfall. But, I mean, there are all these steps. And I always have felt like it was like the way that it was described to me and the way he's showing it as this like step-by-step process. You're assuming each of these is like a massive undertaking. I always felt like it should be smaller, tighter, and loopier. And he's basically saying it's getting that way. So, in a sense, I think it was always should be less serialized and things happen at the same time and less people doing more things together at the same time. And now we're just taking the people out, you know? Like that's the big difference now is like it's you and an agent and you're not waiting on design review or whatever it is. You're not waiting on DevOps team, which as our friend Elie Hostel pointed out, as soon as you have a DevOps team, it's not like DevOps has failed basically. Because the whole point was to, you know, integrate the Dev with the Ops and have them all be together. So, anyways, waiting on some other org, waiting on some other person, you know, waiting for your code to compile like the old comic or outside in the hallway. Sword fighting. Sword fighting, yeah. Waiting for…

My code's compiling. Okay, cool. Carry on.

Yeah, exactly.

Carry on. I understand why you're horsing around. It totally makes sense. You could do nothing else.

Right. Like why are you guys not working? It's like, well, we're waiting for system design, you know? We shouldn't be waiting for these things. And I certainly think that it's been collapsed for a while and it's just getting tighter and tighter.

Well, friends, this episode is brought to you by my good friends over at Notion. We use Notion here at Changelog. I love it. It is so helpful. It keeps me on track. Notion agents, Notion AI, Notion all the things. Here's the thing. You probably spent weeks building out your team's knowledge base. You probably wrote the onboarding docs by hand, the runbooks, the architecture decisions, the how we deploy guide. Of course you did. And it's all Notion. Organized, searchable, beautiful. And your team still DMs you. Hey, quick question, except it's never quick. It's not just one question. It's 10 questions. Every interruption cost you 23 minutes of context switching. Your productivity is going down and your carefully documented knowledge base collects dust while your DMs are on fire and stack up. Well, Notion is an AI powered connected workspace for teams. It brings all your notes, all your docs, all your projects into one space that just works. Seamless, flexible, powerful. And it's actually fun to use with AI built right in. You spend less time switching between tools and more time creating great work. And now with Notion's new custom agents, the busy work that used to take hours or actually never get done at all. It now runs itself. Custom agents automate time consuming, repetitive workflows directly within your Notion workspace where a team already works, where all your knowledge base already lives. Here's what makes them different from most AI, because most AI still waits for you to prompt it. But custom agents run on schedules and triggers. One person sets it up building a workflow for repetitive tasks like weekly reports or triaging feedback. And it becomes a shared resource for the whole team. Think of custom agents like AI teammates with a specific job, whether it's a status update agent, a QA agent, a task routing agent or a custom agent. You've just built for your workspace. The busy work is now handled. And don't just take my word for it. Notion is used by over 50 percent of Fortune 500 companies and some of the fastest growing companies like Open AI, RAMP, Vercel, they all use Notion AI every single day to help their teams stay ahead. So here's the next step. Try custom agents now at notion dot com slash changelog. That's all lowercase letters notion dot com slash changelog to try custom agents today right now. And when you use our link, you know you're supporting the show. And we love that. So notion dot com slash changelog. Who was it that taught us about cues? His name is is is missing on my brain in this very moment. Dear friend, he loves process.

What else was he talking about?

Been on the pod before. Gosh, man.

Oh, anytime you're queuing, like you're not efficient kind of thing.

Yeah.

Yes. I want to say Barrett Hubert, but it was not Barrett Hubert. We'll dig it up. It's in that same wheelhouse.

Lucas DaCosta, I think, wasn't it?

Yes, Lucas DaCosta. I could call.

Yeah. Yeah. Lucas, he would talk. I mean, that was really where I was. I mean, I knew that. So it's funny whenever you know something, but then you don't know it until somebody gives it a name and defines it for you. Like, you know what? I've experienced that problem 17,000 times. OK, now I know it. I feel like I learned it there, but I experienced it for a long time. But just this cue process like the when you have a cue and a backed up cue, that's an inefficient system. That's obviously not a good thing, right? If you can solve the queuing problem, then you solve a lot of the bottleneck. And, you know, one thing that the Boris suggests here is that, you know, going back to code view in a way or I guess directly, not in a way completely, he says, you're like this man. Give me one moment. Where is it at?

Sure.

Code review. Give it up. Think about it. An AI agent generates 50, sorry, at a zero, 500 PRs a day. Your team can review maybe 10. Review cue backs up. This isn't a bottleneck worth optimizing. It's a fake bottleneck, one that only exists because we're forcing a human ritual onto a machine workflow. And I believe that's true. Like in the SDLC, as you learned it, and as we've all experienced it over our years, what is the point of the SDLC to ship software? Yeah. Right? And we've ritualized and held sacred these steps along the way because we've had to. And that's been our comfortability. So as humans, we have this comfortability gate. Well, we do this because that's what gives me confidence and comfortability to go to the next step. But if that's not required anymore or in these scenarios, if you're still doing it by hand, then obviously this SDLC as it has been is the way. But if you're moving to this new AI agentic world, it's just not. It's just not. We'll link it up in the show notes. But Boris Tein goes into a lot of detail there. Worth checking out.

A couple of good comments I could pull out briefly before we switch contexts here. The 17 comments in there are pretty high quality. So definitely dig into those as well. Oh, yeah. Sorry. I didn't go to the comments. One Kevin.

I don't read the comments, man.

The comment section sometimes is the best stuff.

I meant that in the, I do read the comments, but you're generally like, hey.

So one Kevin says a really high quality article, blah, blah, blah. I generally agree everything you described here. But now I'm wondering what's left of the software engineer job. So as everything gets collapsed down, it's a really good question. Of course, I think that's what on a lot of our minds and Boris's response, I thought was pretty good. He says everything that isn't typing code typing on a keyboard was never the hard part. The job shifts from person who writes code to person who knows what to build and why. Taste, judgment, knowing when the agent is confidently wrong.

Yeah.

There's nothing new there. We've been saying that kind of stuff, but I think it's just, I think that's on point.

Yeah. It seems, I mean, even Scott Hansman comes to mind in this scenario here. Like when he says person who writes code and in particular typing on a keyboard. One thing he told us in that show we did probably eight years ago, I want to say, Jared.

Wow.

He said he had so many keystrokes left in his life. And that stood out to me really as a very wise thing to think about. And he, he judges, I think he had even a program that.

There's a website you can go to.

Yeah. I knew he like quantified in a way. It was, it was important enough to not just say it on a podcast, but to actually put something behind it to, to quantify it for himself. I think about that. Like, you know, I would love to, while I'm a craftsman at heart or a crafts person at heart, I want to be able to make the best thing. I have taste. I have judgment. I think, I think Jared, I like to know when the agent is confidently wrong.

Yeah.

You know, that's questionable these days. I'm like, what, what did you say?

Right.

What did you say to me?

That really is the hard one, right? Because you need to know more than it knows.

And you don't.

Yeah. And a lot of times you're like, well, I'm up, I'm in over my head. And a lot of the tooling that I've been building, it's all pretty simple. Now I'm building that Mac OS deal where it's like, I don't know, a liquor Swift. I don't know the UI kit, Apple, you know, it's not an SDK APIs. And so I'm just like, I'm swimming in deep waters when it comes to like being like, nah, that's not the right way to do this because I literally have no clue what's the right way to do it. Now, when I write node base tools and go base tools, and I'm looking at some JavaScript and it's kind of streaming by while, you know, Claude is doing his thing. I can be like, yeah, this is looking pretty gnarly. I bet we could rewrite this and I'll talk to it. But how do you know when you don't know? That's kind of scary.

You know, that is scary, but then I think it's going to get so good that even when you don't know, at some point it catches up to fix itself. At least that's what I want to tell myself.

Right? That's the hope is it gets better from here. I mean, it's gotten way better in the last 12 to 18 months.

So tell me if this is your flow with Swift and in Xcode, are you just command R-ing and getting the next build? Or are you actually doing some stuff in Xcode?

Less than that. I'm not even running Xcode. In fact, when I first started, Claude told me to go ahead and launch Xcode and here's how you compile and run, which is like, yeah, command R hit the button. And I said, I don't want to run Xcode if I don't have to. Do I have to run Xcode? Can't you just write some sort of a build script that does it for me? And then it was like, yes, you're absolutely right. I can write a build script. And so I had to install Xcode, but I never have to launch Xcode. And so I just tell it to, I just tell it to rebuild for me. And if I want to run the script by myself, I can. So all I do is double click on the app bundle and then I close it. I double click on the next one after it's rebuilt it for me.

That's the same version of a command R, but not really. I guess command R just gets you a command R versus a close and open, close, open. It's the same repetitive task. You're still in the API in some way. But I guess in my case, I have more RAM consumed because Xcode probably requires more RAM to be open.

Just so I can command R. Xcode is a hog, man. That thing wants RAM.

Well, the only experience I've had recently with Swift was actually with my Remarkable is I started to build a file browser essentially for it because like this thing is kind of slow. If I'm being honest, it's Linux and it's not the best CPU, but it's good for what it's intended to be. But navigating it, it's a touch interface. It's kind of latent a little bit. And so the API, I wrote against it, a Go API against it is super fast, super fast. And then I built an app UI. It's a lot like Finder to navigate it, rename it, reorganize. But I've learned that it can't be a real time system. I have to like create a version of the truth over here in the Mac app that I then synchronize back to the Remarkable. And then the Remarkable has to do a refresh because of the way the Linux itself, or at least the UI persists new rights to the database and new rights to the disk. So it's got to do a little restart there. But in the weeds a little bit on command R and Xcode and Swift app development. I say, you know what, listen, if you're out there and you're like, man, I got an idea for this or that, go and try it. Explore a new world. Touch all the things if you can. You're in a candy store. It's all for you. Eat it. Enjoy it. Don't get fat. Just enjoy the candy.

Yeah. Here is a quote from Wes McKinney who wrote a piece of software. I think he might have. I've got it. Who knows? Called Message Vault that I've been playing with in his post the mythical agent month, which was the title of the last change log news. He says the coding is easier now and honestly more fun. And I can spend my time thinking about what to build rather than wrestling with the tools and systems around the engineering process. I found that to be absolutely the case with me just to, you know, give my Amen to what you just said and to back it up. It's just fun to work at this level and just touch, touch all the things, try all the things, you know, build something, see if it sticks. If not, throw it out and build something new, something else.

Touch all the things that you should touch. Okay. Respect terms of service. If that's your life. If not, live dangerously.

Right. You know, you need consent for sure.

Yeah. You do need consent in the world. And the word of touch for sure. Let's not, don't clip just touch all the things. Only clip it in context.

Clip the disclaimer. Clip it in context.

One thing we didn't mention, and I'm just going to mention it here on the outs that you should check out. And then I want you to also check out Anish. I'm not sure how you say his last name. Acharya maybe. He is from A16Z and Dreesen Horowitz. And there was a, you may have seen this Jared and tell me if you did, but there was a post that circulated called the 2028 Global Intelligence Crisis. Does this ring a bell to you at all?

No. Tell me about it.

Well, it is a thought exercise in financial history from the future. And so it actually writes itself. The very first, the dated line is February 22nd, 2026. That's scratched out. And it's June 30th, 2028.

Okay.

It's largely, you know, bearish, not bullish and negative, but it's, they say it's grounded on some research and it's essentially the consequences of abundant intelligence. And it paints this picture of just a downside that's coming when it comes to what automation does. And I'm just not sure. I'm just not sure.

Yeah.

That's all I'm going to say because it really is that deep. It's a whole podcast worthy thing. But one thing that Anish shared was a different way that this could go down. And I'm only going to go up both because I don't want anybody out there reading this thing and getting all negative and sad and, you know, going into a hole and we say go touch all the things. And then touch all the things turns into all this nasty stuff that this seemingly well-researched article from the future purports. So I would read Anish's prose on X, which we'll link to in tandem with this and try your best to come out not crying like a little baby. Because it is pretty, it's pretty, it's pretty wild. I'll read the first line. Okay. The unemployment rate printed 10.2% this morning, a 0.3% upside surprise. The market sold off 2% of the number on the number, bringing the cumulative down draw in the S&P to 38% from its October 2026 highs. It just goes, it's one of those kind of like doom and gloom. But they even say in the preface that they're not trying to be doom and gloom. But it is a doom and gloom kind of post. They say what follows is a scenario, not a prediction. And it's based to some degree from what I understand on research. So we'll see. We'll see. All right. But don't go and read that. Get sad. Go read that and then go read Anish's post on X and just see a different side. There's always two different sides. Don't go read it like I did and get super sad for a day or two. Crawl into a hole. No, I didn't. I was pretty bummed out for like 45 minutes. I was existential for a minute. I was like, gosh, babe, I'm having so much fun. Tell my wife this. Gosh, babe. That's usually how I sigh in life is I'm usually telling my wife some sort of story from the battlefield, so to speak. Gosh, babe. This high or this low or this, you know, this possible future. And I was like, she's like, what's wrong? I'm like, some big consequences out there coming. I was like, I don't really know how to take this. So I was a little down for a little bit. But then I read Anish's post and was like, all right, I'm right back up again. Let's see the bright side here. So we'll see.

There you go. We'll see. We don't know. We don't know. That's why it's interesting. And read both.

Yeah. Read both. Read both. Well, friend, it has been the absolute pleasure of my life to spend time with you on the weekly, on the daily. Yeah. In the trenches of this war room called Software Development, SDLC, as you may say.

Oh, yeah. Living the life cycle.

You know, living the life cycle, so to speak. You know, yeah, I guess. Yeah. Yeah, man. What did Lloyd Christmas say? Goodbyes are hard, man. Was that what he said to Holly Hunter? To the person he just met a few minutes prior.

I hate saying goodbyes.

Yes. Something like that.

Yeah. Goodbyes are hard. And we can always add a for now on there. It lessens the blow. Not for good, but for now. And yeah, it's been a blast. Appreciate the many years of potting together. And doing life together, you know? Yeah. From afar. From afar. And we met on the internet and we've, you know, built a life for each of our families for a long time. And I'm excited to see where the changelog goes from here. You know, you were changelogging before I got here and you're changelogging after I leave. Yeah. I'm excited for what's next for me. I have zero plans for those who are interested in my future. I don't have one. I'm happy about that. So, I'm not locked into anything. I don't have ideas. I am going to take a break. I definitely need to step away. I've been going full bore for a while now. And excited for what's next. Open to ideas. Don't have any of my own. I have a few things I like to build, but, you know, who knows? I've had thoughts of going and taking a jobby job, you know, going and working for somebody else. It's been since 2011 was the last time I had a real job. So, I'm not sure if I could ever actually do that. My wife thinks probably I can't. Like I'm just, at this point, unemployable. Could be true. Don't know, but happy to see where life takes me next. So, it's been a blast. I think the only thing left to say is bye friends, right? We always finish with bye friends.

Well, I was going to leave a little surprise for our plus-plus folks. I thought you owe them a little bonus. So, if you're in that crowd, just get a little more excited. I'm not sure what's there. I'm not sure. I don't have a plan either. Just an extended take potentially or extended, maybe a couple more details that are for our pertinent, really close folks who we really appreciate, who have supported us over the years. Sounds good. Plus-plus content is always good. So, if you're on that dial, then stay tuned. And if not, changelog.com slash plus-plus is how you become that person. So, with that friends, bye friends. Bye friends. Well friends, it is a finale, but it's not over. That means this show continues. Yeah, nothing changes really. Jared's stepping away. He's retiring all the things and we'll miss him, but the show must go on. The changelog remains. changelog.com is here to stay. And if you haven't yet, join us in Zulip Chat, changelog.com slash community. It's free to join. Everyone is welcome. And I mentioned the bonus. If you want the bonus, you gotta be a plus-plus subscriber. changelog.com slash plus-plus is better. You know what? It's better because bonus content rolls, getting closer to the metal rolls. And of course, you roll. changelog.com slash plus-plus. That's it. The show's done. We'll see you real soon. All right. I don't have a plan, but I figured a little bonus for the plus-plus folks would be cool.

Let's do it.

I have no idea what to say there, except I would say the treadmill of creating content is probably pertinent, right? Yeah, yeah, yeah. It's easy to look at. It's easy to look at this and maybe even in the comment section in Zulip, which I'm very happy that people are sad, I suppose. I'll say that. I'm very happy that there's a feedback loop, I would say, right? Like, it's one thing to put something out in the world on this media treadmill for so long. And I think where we get most of our feedback loop has largely been in Slack, in Zulip, and at conferences. Yeah. Sure, there's DMs. There's people coming on the show. There's people who say, I've listened to your show for years. And maybe that's the polite thing to say. Maybe it's just something you say. But then somebody who actually gives you that hug or that handshake in person, or someone who says, man, I'm really just thankful because you got me through some hard times when I navigated my career in software and you were just entertainment in my ears. I think there's just something to be said about the media treadmill and the absolute chore it is to show up weekly for so long.

Yeah.

And not be biased or negative, which I think we've both been a little cynical and negative in this age. It's hard not to be when you've been through so much, you know?

Yeah. Yeah, I mean, I used to describe it internally. And you can edit this part out if you think it's too negative. What I say, we created our little jail cell and now we've got to spruce it up and make it a nice place and live in it, you know?

Yeah, we created our jail.

Me and my most cynical. But we made it a nice place. It's a very nice one. That's just how it feels over time because of just the constant repetition of a new week, a new set of shows. You know it as well as I do, if not better. That it's just nonstop. And sometimes that's good and sometimes that's bad. And then over the course of years, you get good at it. I mean, I feel like we've been pretty good at it to where I don't think about it all that often. And you do, to a certain extent, especially with podcasts, feel like you're just putting something out into a void and hoping that people like it. And I would say that, especially in the last couple of years, we've had some, I think we've made some real connections with some friends. A lot of our Changelog++ people are those friends. So thank you.