SPEAKER_00 0:00

Hey everybody. Welcome to another episode of the Ruby AI podcast. I am one of your hosts today, Valentino Stoll.

SPEAKER_01 0:07

Hi, I'm the other host. I'm Joe Leo. It's great to see you, Valentino. And it's great to we're doing two in a row here of the headlines.

SPEAKER_00 0:14

Yeah, it's exciting. Another between the commits series here, which I've been loving, ranting and raving over all of the crazy news that the world puts out for the AI realm.

SPEAKER_01 0:25

Me too. Yeah, it is fun. It's also fun, it's a little exciting for us here, you know, being totally unprepared, just getting a list of articles and saying, all right, go. Let's see your opinion. It does make it fun. It puts me a little bit on the edge of my seat. I don't know what I'm going to say or how to react to some of this stuff. But luckily, we both bring our opinions and we've got a lot of those.

SPEAKER_00 0:45

Yeah. And hopefully it gets you riled up to want to yell at us and uh suggest new things that we should be talking about.

SPEAKER_01 0:52

So before we dive in, I wanted to tell you, I know we mentioned this to you after the show last week. So I've set up some virtual machines and used Tail Scale and used a bunch of the stuff that we've talked about on this show, or really I've heard you tell us about on the show to set up some independently operating agents in environments that where I am comfortable with them just running around and doing crazy stuff. And it's been a lot of fun. Yeah. I went a little bit into the Steve Yeage direction where I have a supervisor agent that talks to the other two agents that are building separate projects and then reports back. A couple of things that I've noticed. One is that it is so much more fun. I don't know if this is a great thing for like production software. Like this is all like internal deaf method tools that have one or two users. But it is a lot of fun to just let these agents crank, you know, just be on my phone and be like, hey, just go do this thing. And they do it. It's amazing. The other is that it hasn't created less work for me at all. And we're gonna get into this with Meta's Muse tools later on in this episode. I know that I'm getting a lot more done, but now there's like four projects, there's so much going on, and there are just things where the agents are like, hey, you need to make this decision, you need to set this thing up, you need to do this. And like, man, I've got like another track of work now to do. Like, I thought you guys were gonna make less work for me. Not really the case, but the results are pretty uh encouraging.

SPEAKER_00 2:13

Yeah, it takes some getting used to moving up the stack. Yeah, that's for sure. It's not gonna be easy, but you'll figure it out. You'll find what works for you. And it's different for everybody. Yeah, I've seen many people go through this process and end up at different things. I'm like, oh, maybe I should try that. And then I try it. I'm like, uh, that's not for me.

SPEAKER_01 2:29

Yeah, that makes total sense. I said on this show, until I was up on like a digital ocean droplet, my entire workflow was basically manual. Like, I didn't want to let Claude or Codex or anything really run loose because it's my computer and it's all my stuff. I don't want it destroying it all. I've caught it doing too many really scary things. But opening it up and saying, Oh, okay, go take down a droplet if you want. Like that's the worst that can happen. Okay, great. Maybe commit something to my repo, which is not such a big deal. Again, because it's not shared, it's not some production environment that is super critical.

SPEAKER_00 3:00

Yeah, you know, it makes me wonder uh or worry uh about all of these providers. If I were in their shoes, I would be very nervous right now.

SPEAKER_01 3:08

Oh, yeah, how come?

SPEAKER_00 3:09

Everybody's spinning up their own agent free-for-all. Oh, I see. Yeah, and making use of the bandwidth. That's for sure. Yeah, that's for sure. First headline we got up is the FTC just sent OpenAI Ananthropic a 50-page subpoena and sued OpenAI on the same day. The fun continues. Just last Wednesday on the October 15th, FTC sent both companies' civil investigative demands, which are just subpoenas with a friendlier name, each running more than 50 pages. What you might be wondering is what are these demands? They document security incidents, safeguarding practices, marketing materials, privacy policies, all this fun stuff that the FTC agency now plans to compel top executives to testify. Let's see if they actually do. The same day that all of this has happened, a group of state attorneys they filed a separate consumer protection lawsuit against OpenAI, and OpenAI's response was carefully bland, saying, as we improve our models and they increasingly help people in their day-to-day lives, safety remains a top priority, adding it will engage constructively with the FTC. And an anthropic, of course, said nothing. Yeah. FTC chair Andrew Ferguson's longstanding position just was paraphrased by reporters rather than quoting directly is that the AI system shouldn't ship if they aren't safe. The question for us is Is AI's regulation moment finally here? Does it have real teeth, or is all of this just kind of like paperwork?

SPEAKER_01 4:35

It's gonna have its moment where a bunch of Silicon Valley execs go to Capitol Hill and make some headlines for a couple of weeks. Like that's the moment that's here. I feel like I have to walk a fine line here because I am not an AI doomer by any means. At the same time, I want to say that I think Andrew Ferguson's claim here needs some scrutiny. AI systems shouldn't ship if they aren't safe. That sounds nice, but I actually think that we all, including regulators, need to update our definition of what is safe because these models, even at their best, are not safe in the traditional sense that we have all come to know and understand from computers. Things that are not deterministic are going to do crazy things. We've seen that. That does not mean by any means that open AI and anthropics shouldn't be held accountable. They absolutely should for every time that their models go off and cause an outage or make people pull their hair out. At the same time, what we were just talking about at the top of the show, I've never had to so closely guard a software program running on my machine. I've never been so worried about it. It's just not that safe, even in the best of times. You need to be a little bit more understanding of what the power of these models are and sort of couch our regulations or whatever's coming in the understanding that safety is looks a little different today.

SPEAKER_00 5:53

You make a great point because I think about we're working very small scale. Yeah, we're worried about our local computers, maybe a small little droplet somewhere, maybe a few of them. The scale here, I think, is what is the worry.

SPEAKER_01 6:07

But you're a czar, you're not that's not small scale. Like there's a lot of things that can go very, very wrong if those models go crazy.

SPEAKER_00 6:13

Yes, but even that's not small scale. Okay. These are like swarms in the hundreds of thousands of agents collaborating together and are let loose on a public domain, right? Like on the internet. Yeah. Hopefully, that's what kind of comes out of this is like, where are those guardrails? Can somebody do that for one? And I worry though, because the whole premise of how these things were trained to begin with stems from them having access to the public realm and letting things go loose at it. So what we're seeing now though is kind of like the reverse of it. Yeah. Before it was very much information gathering and collective, and now it's being put out there. They're they're actually doing stuff, mutating.

SPEAKER_01 6:54

Yeah, they are.

SPEAKER_00 6:55

I do want accountability, right? If somebody can mutate something that's available, that's the concern.

SPEAKER_01 7:00

Let's move on to Ruby 4.1, just got its first preview. It is all about Ractors. So this is really interesting to me. This is October 12th, Ruby 4.1.0 preview one is out. The headline is that each Ractor now collects its own heap on its own thread instead of stopping the whole program for global garbage collection. Now, allocation-heavy Ractor programs now scale like forked processes. That's a quote from the Ruby maintainers. There are a couple of ins and outs about this, but I think the headline is that Ruby is leaning into Ractors. They definitely have found something where they're able to make this genuinely a difference maker with respect to forked processes, with respect to multi-threaded or multi-processed programming. I think people are starting to see real gains in performance. I'm curious to know what you think about this, V. Does per ractor garbage collection finally make Ractors worth reaching for? Have you already been reaching for them? I'm starting to get a sense that people are, but I haven't seen a lot of production instances in the headlines in the news. Where do you think we stand right now with Ractors?

SPEAKER_00 8:16

I'm torn on this because fibers are great. There's a whole rage framework, which we've been living under a rock as a fiber-based parallelism framework that's kind of taking storm and it works really well from a performance perspective. But at the same time, it's not true parallelism. And I think that's what Ractors aims at solving. It's the aim, yeah. I don't think we're there yet. Does this really solve the whole global interpreter lock and things like that?

SPEAKER_01 8:43

No, it doesn't. And I think definitely correct us if we're wrong here, anybody who's listening. But my understanding is that you're not getting true parallelism as long as the GVL is still in place and the GVL is not going anywhere. This is an improvement for sure. Garbage collection is being and not going across different reactors is a performance improvement. It's not a solution to the GVL.

SPEAKER_00 9:01

I worry it's just a way of shifting around blame for the GVL.

SPEAKER_01 9:07

I had a different take when I looked at this. I think Ractors are exciting. And I guess what I noticed was when I was quickly scanning this, Ractors shipped with Ruby 3. So they shipped in 2020, which is kind of interesting, right? It's been six years. This is an AI podcast. I think that the reason that there've been a significant number of advancements in the last 12-ish months is really because they've set AI at this problem. I don't know that for sure, but I think we can tease out from Matt's talks that they're definitely leaning into that. So I think that that is a good thing. What you say about fibers is interesting, though. I have always liked fibers. The Rage framework exists. Maybe people are already comfortable. And then if that's the case, then what are we really trying to achieve with Ractors? We're not going to have a true parallelism in Ruby. I don't think that's in the offing. And I don't think anybody's really trying to do that. What's the ceiling then for Ractors? Is it that it gets as good as fibers or better? And if that did, I'm curious to know. And it this is an open question: what advantage would a Ractor have over fibers?

SPEAKER_00 10:14

What I've been reading, it's kind of reduced footprint. So encapsulation of the Ractor is kind of like a reduced version from an object standpoint and responsibility. And I could be wrong. I don't know. Part of me is just hesitant to try out a preview. So I'm excited to see it coming kind of out of the experimental phase. Will I start working with it? Probably not. Yeah. Until somebody else figures out all the sharp edges.

SPEAKER_01 10:37

What are we getting Ruby 4.1? Are we getting that on Christmas? Oh, we've got to be. Yeah. Anticipated final stable release on Christmas. Beautiful. Beautiful. Y Jit runs on Windows, and YJet we're going to do in our next segment. But Y Jet running on Windows, I think, is a big deal. We constantly give every Windows developer short shrift and no tools. And I didn't actually realize until I read this that we weren't even shipping with YJet. It was just kind of like, well, if you're running Ruby on Windows, it's going to be slow and it's going to probably not install. So we're just not going to help you. Which is not okay. It's not really nice to a whole ton of people in the world that run on Windows. I guess we're going to give them some crumbs on Christmas.

SPEAKER_00 11:18

A little warm-up. Yeah.

SPEAKER_01 11:19

Do you want to take this next one?

SPEAKER_00 11:21

Shopify just put Zajit into production. Yeah, I think I think it's Zajit. It's already going toe-to-toe with YJIT. If you're not familiar, Shopify has a special Ruby team. They have been working on various JIT implementations. This is the latest iteration of that. They have deployed Zujit, the newer SSA-based method JIT that shipped disabled by default in Ruby 4 to a couple of small regions of its storefront renderer, each compared against a same-size YJIT region. In their post, they kind of looked at the response times for what the Zajit is, in quotes, probably as fast as or faster than YJIT. Not a clear win or clean win, and the author admits running different regions for each makes the comparison a little sketchy. Memory told a clearer story, so they are seeing about 125 megabits of average JIT overhead for YJIT versus the 101 on Zijit. Measured separately from the Ruby heap itself. Her benchmark results, though, are genuinely mixed. Several are roughly tied, some are worse. One benchmark call path mostly vanished after inlining, removed it entirely. So it seems like there's some mixed reviews here on Zajit from Shopify's partial deployment and measuring of it. But Zujit ships compiled into Ruby already, but off by default, so you could just turn it on with a flag if you wanted to try it out. Is it too early to call Zajit a win then? And when the sample is small like this and the results are mixed, I don't really know what to take from this.

SPEAKER_01 12:50

This is the funny thing. Just pulling this article up, this is Max Bernstein, by the way, who wrote about this at Rails at Scale, and he works for Shopify. So just looking at this, the agents' coverage of the story is mixed. Their opinion is mixed for what it's worth. Shopify is very happy. And I'm on the optimistic side. I mean, I think what Shopify did with WideJIT was incredible. And I think they did that at a time where there was a lot of skepticism over a new just-in-time compiler. And it's already light years better than its predecessor. Now it's DJT, it's taking some time to answer this question directly. Maybe it's not time to switch over your applications, but it seems like it's close. And it definitely seems like that is the future. It's interesting. I was looking at what's the difference, just for listeners out there who might not be savvy about just in time compilers, because I'm not really. The reason that YJIT has been a huge success is because it takes this pragmatic approach. It compiles small pieces of Ruby code as they're needed. That's as very, very just in time, like just as they're needed. ZJIT kind of takes a step back, or is ZJIT, I'm sorry. It kind of takes a step back. And so instead of optimizing little pieces at a time, it takes a sort of a more traditional compiler architecture and it looks for larger chunks of code. And so it's looking at ways to optimize code paths. It looks at places that are likely not going to be executed, duplicative code paths. The idea is that over time it can actually get a lot better than YJet, but it doesn't sound like that to me, just looking at this, and I'm a layman when it comes to compilers. That doesn't sound like the kind of thing that's going to be an overnight success. It sounds like that's going to take some time. We have an entire language and decades worth of execution strategy to kind of take into consideration here.

SPEAKER_00 14:29

I think until they get around to finally introducing the typed annotations where you can give the compiler kind of like ahead of time details about what it's looking at, which you know is in quite a few other languages to help with this specifically. I feel like until we get that worked out, we won't see the drastic improvements we're looking for.

SPEAKER_01 14:48

When you say it's available in other languages, is it available in other interpreted languages, like Python, for example?

SPEAKER_00 14:53

I believe Python does do something like that. Yes. Okay. I don't know if it's full-fledged, like you can get with a true compiled language, but there are aspects of it that you can kind of inject at certain instructions.

SPEAKER_01 15:06

That's cool. I'd like to learn more about that. But I'm not going to learn about it right now because we're going to move into the next segment. Meta defaults your code to train our next model and calls the box, you have to find yourself the opt-out. In news that shouldn't surprise anybody ever anywhere, Meta's new MuseWonder and MuseWonder full models, their subscriptions default new users into contributor mode, which means that everything you do is going back into their system for training. This, of course, was a huge barrier to adoption for open AI in the very beginning, because people and companies, quite understandably, didn't want all of their private information going into some black box that a company owned. We've sort of settled that question by saying, well, hey, if you pay us some money and tell us not to do it, then we won't train our models with your data. Which of course we just have to like trust that they're telling the truth. And we may find out years later that it's not the truth at all. And that's not going to surprise any of us either. I digress. Here we are with Muse Code subscriptions. The only way to guarantee that your content stays out of training is surprise, surprise, the pay as you go API in standard mode, where contributor mode isn't even offered. Is this a fair trade for free capacity or is this a trap most people will never notice they walk into? Or actually both. The question is yours, Valentino.

SPEAKER_00 16:25

I guess both. Yeah. Muse is not an open weight model, right? Right. I don't really understand why people would contribute to it, to be honest.

SPEAKER_01 16:33

The reason is because they don't know that they're doing it, I guess.

SPEAKER_00 16:36

If you use any provider, you don't know if they're doing it either.

SPEAKER_01 16:40

Yeah.

SPEAKER_00 16:40

Which I guess they're at least disclosing that they are doing it and you can opt out. I imagine Anthropic is doing the same. Yeah. All the other companies are doing the same in some capacity. If you want to use it, who cares if they trade on it?

SPEAKER_01 16:53

Pay the money, I guess, if you want to avoid it. You know, if it does improve it too. Well, some of it is going to be used to improve the model, and some of it is going to be used, I'm sure, to send you ads and send people to it. When I read this, I thought it this is app tracking. You know, Facebook, before it was even called Meta, hit this real valley in its revenue model once it wasn't allowed anymore to track users across all the different apps they pulled up in their phone after they had Facebook up, right? And so all of a sudden they couldn't tell where you went after you clicked the link. And so they couldn't guarantee performance to the people that were paying them for ads. And that's how it runs. That's how a lot of companies run. At the same time, here we are with Meta in its 2026, and AI is ruling the roost. And it's like, well, hey, here is a way that we can potentially make money off of this or provide a better service to people that are going to run ads through our tools. So it comes as no surprise to me that they're not going to make it very easy for you to not do that. Actually, the only thing that's maybe a little bit surprising is that if you are in standard mode where you're paying, contributor mode isn't even offered. Because I would probably, if I were Meta, say, hey, everybody can be contributors, right? Unless you specifically tell us not to. We're taking your information and we're going to do whatever we want with it. I don't even necessarily have a problem with this. I mean, these are businesses that are trying to make money and to think that they have some kind of altruistic aim is really naive. When we use these tools, we don't have necessarily altruistic aims either. We want to be able to go through our day more efficiently or shop easier or not answer people's emails. We're just going to have an agent do it. If you want to get out of the trap, the only way out is to pay a little money.

SPEAKER_00 18:31

Yeah, I mean, we do that with Claude and Codex. Yeah. Until these smaller models are better, we're going to keep doing that. Yeah. I will have to retract something I said. Apparently, Meta has started this super intelligence framework and are releasing open weight versions of some of these models. Oh, no kidding. An in-episode retraction. I know. It's incredible.

SPEAKER_01 18:50

And the producer got in your ear and said, hey, you know, you can't say that.

SPEAKER_00 18:53

We're going to have to have a producer on soon that just corrects us.

SPEAKER_01 18:56

Corrects us in real time. Yeah. But right now it's so much fun. It feels like everything I say is right.

SPEAKER_00 19:01

Right. These are just going to get better and better. Make use of it if you can. Yeah. There's no out training. That's right. Next up we've got Claude writes so much code that Anthropic had to build its own version control system from scratch. Anthropic's engineers, they hit a real wall because they were just producing so much code. Fetching their mono repo with plain Git would mean over 600 petabytes of Git traffic a day. So a seven-person team spent five months replacing Git entirely with a homemade system they call Scion. Not to be confused with the cars. Yeah. Plus a new review tool they're calling Antique. So the pressure came directly from Cloud's own output. The merge volume went from about 2,500 code changes a day in May of this year to over 30,000 by September. Wow. That's incredible. So a chart that tracks almost exactly with each new Claude model release. The main branch alone on our code base runs close to 100 gigs with a compressed working copy at 25 gigs, and CI performs roughly 25 million checkouts a day before anyone's laptop or agent SAMOX is even counted. A Scion engineer shrugged off a complaint about missing offline support on Hacker News. Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn't important to do. Anthropic's own write-up is candid about what the job became. So they're saying very often we found that the role of engineers was to tell Claude no. Elsewhere, agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place. And then they're getting more skepticism online. The register is saying that this only works because a company flush with venture funding has quote cost is no object mentality. Is that a preview of where every engineer org is gonna end up, or a problem only a company with unlimited venture money ever needed to solve?

SPEAKER_01 21:08

Sorry, I wasn't paying attention at the end of that because I was just registering scionhub.com and barking it. I love this story. This is fascinating to me. All of it is fascinating to me. First of all, 2,500 code changes a day to 30,000 in the last six months. That's what's happening right now at Claude? That's incredible. I have no problem at all if you're hitting you're hitting performance issues with your tools, then maybe you got to build new tools. This is like a story as old as time. So I think it's really interesting that they built a new homemade system. My thought is well, it's fine to say, well, Scion is closed, we're not going to open source it because it's ours. And probably that's correct that most teams today do not need this. What about tomorrow? What about a year from now? Are we all headed for that? That is an enormous increase. In output and merge volume. I don't actually agree with this skepticism that it's a company flush with venture funding and it's a cost is no object. I think that this is probably the right move. I think the efficiency gains alone probably make this worth it. It's just to me, it sounds like it's maybe a little shot for us of what the future might look like.

SPEAKER_00 22:20

This problem has been solved by other companies like Google and Meta. They each have their own kind of prior art here. If you're dealing with 600 petabytes of just Git traffic, that's so much. The cost optimization for bringing that down is like huge. Yeah. The value for that. Why would you not do that? Yeah. For us, peons is serving well until you get to a certain point of adoption. So I wonder what is that tipping point for us of changes per day? What number of changes per day for you are you like, you know what? Git is not the right tool. A ton. It's gotta be a lot.

unknown 22:56

Yeah.

SPEAKER_00 22:57

At the same time, they probably use some of the prior art as their uh go bys.

SPEAKER_01 23:03

As somebody who has lived through the end of CVS and the entire lifespan of SVN, it's funny to just come to a point where it's like, oh, maybe Git isn't fast enough anymore. Git was the most incredible thing I experienced as a developer once it came out and I compared it to SVN. Oh, so fast. And so much better at resolving conflicts. We only have 90 seconds for this one for some reason that I'm I'm not sure of, because of the rules that we put in place and don't even remember putting in place. So developers are ripping the smart out of smart TVs using AI coding assistance to do it. So there's two open source MIT licensed projects that are surfaced this week that will strip loatware and ads and tracking off of your Android TV, your Google TV, your Fire TV. They're called Clean Your TV and Dumb TV. And you can check these out right now. My question for you, Valentino, is how hard is it going to be now if you put these things in place to set up your parents' TV?

SPEAKER_00 24:01

Well, you know, this is just pie hole all over again. Yeah, I was thinking the same thing.

SPEAKER_01 24:05

It's like piehole. I remember I made a pie hole. I was so proud of myself.

SPEAKER_00 24:09

Pain in the ass. Yeah. You know? Yeah, it is. And uh I imagine this is gonna be very much a pain in the ass. But you know, we didn't have agents back in the day. And uh maybe pie hole is much easier to set up now. Uh I may remember that. That's true.

SPEAKER_01 24:24

That's a good point. I have a friend who runs an engineering team, and he said that in his spare time he developed a thing. It's a tool that he loves to listen to Yankee games on the radio, and it's a tool that it detects when the inning is over and then automatically mutes his audio for the commercials. It's incredible. He's like, I never looked at any of the True Smart TV. Yeah, yeah, yeah, yeah. Next week on the show, we're going to have Rick Van Michellen. He's going to talk a little bit about Museum of Modern Art. If you're interested in being on the show, we would love to have you. We have guests booked out through February. Do you know that? Wow, really? And potentially even further. Yeah. So they're, I mean, it's really exciting. Thank you, everybody, for saying yes. So I we have somebody in the background that's not AI, that's just begging people left and right to come on the show. So thank you for saying yes. The week after that, we have Marty Hott for Ruby Central. And uh let me tell you something. Marty's had a very interesting year. So we're gonna have a lot of fun talking to him. So much going on in Ruby Central and Ruby Gems. So that'll be a lot of fun as well. Yeah, I'm looking forward to it. All of our guests are great. Making the show fun and interesting. So until next week, great to have you all. Thanks for coming. Talk to you soon.