The Ruby AI Podcast
The Ruby AI Podcast explores the intersection of Ruby programming and artificial intelligence, featuring expert discussions, innovative projects, and practical insights. Join us as we interview industry leaders and developers to uncover how Ruby is shaping the future of AI.
The Ruby AI Podcast
AI Code Generation vs. Maintenance: Rails World's Reality Check
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
We tackle one of the most pressing tensions in modern development: what happens when AI generates code but no one truly understands it? The hosts dig into some genuinely thorny questions about where human responsibility ends and AI capability begins, and the conversation gets heated in the best way.
From Rails World to Rust rewrites, this episode covers a lot of ground. DHH's case for AI code generation sits in direct contrast to Aaron Patterson's call to actually read your code (both perspectives, it turns out, have merit depending on context). The hosts also unpack Basecamp's eye-opening 95-times faster Rust rewrite of their chat application, and debate whether 37signals abandoning Ruby for Campfire undermines Rails' credibility.
What does it mean for the community when the framework's biggest champion starts reaching for different tools?
There's also genuine excitement here (and it feels earned) around Marco Roth's work on Herb, which uncovered 1,400 issues in Rails applications built up over eight to nine years. Ruby LLM 2.0.1 from Carmine Paulino, now supporting eighteen AI providers, gets serious praise as an impressive one-person open-source achievement.
Plus, the hosts don't shy away from OpenAI's unauthorized scraping of Australian government websites and what real accountability should look like.
Hey everybody, welcome back to another great episode of the Ruby AI podcast. It is Joe and I's favorite day today. That's true. Because we just get to talk about these great news headlines uh that we get last minute and get to riff on it and you get to hear the fun opinions that we have about it. I laughed because you said welcome to another great episode.
SPEAKER_00I'm like, well, we haven't even started yet, but it is great. Like we already know it's great because we're gonna we're gonna jump into these. You know, the opinions may vary on you know by the time we're done, but it's a great time while we're doing it.
SPEAKER_03We haven't done this before, but if you have an idea for one of these headlines that you want surfaced into next episode, shoot them our way and we'll give you a shout out and we'll dive into it. Yeah, we're looking forward to hearing what the community wants to hear about. Yeah. You know, AI makes up these lists. So let's get some human flavor in here.
SPEAKER_00I agree. We don't want to go too far in the uh in the AI direction. But the cool thing is so if you haven't listened to the show before, we get these headlines 10 minutes before we air, so we have no time to like really we we have just enough time to like bring up the article and scan it for two seconds in our browser. So we don't really know what's coming. We're gonna do the same. If you send in your articles to news at the Rubyaipodcast.com, it'll come in the mix. So we'll get your name and we'll get the article, but we're gonna get it just like everything else, 10 minutes beforehand. So you'll get our authentic non-AI researched takes on the news. Be happy to hear from you. Before we dive in, I did want to cover the fact that RailsWorld is now over my first ever Rails World. I thought the conference was awesome, actually. I thought that it was incredibly well run to have a you know a conference that big. The organizers did a really great job of you know pulling everything together. And I guess DHH did what everybody kind of expects me to do at this point, which is to just say a bunch of stuff that gets people talking. Mission accomplished, because I came back and I had dinner with a friend who doesn't write Ruby, and I was like, Oh yeah, I was just at Rails World. He's like, okay, so what happened? What was that all about? And so yeah, and you know, the next one is in Lisbon, and we've got a bunch of teammates and engineers in in Portugal, so I think I'll be making the trip next year as well.
SPEAKER_03I hear Lisbon's beautiful.
SPEAKER_00That's what I hear as well. It would be uh it would be a first for me. So I think it was good. I think that the book ending, DHH at the very beginning, and we're gonna talk a little bit about 37 Signals, but in the very beginning saying, okay, nobody at 37 Signals writes code anymore. We all AI generate it. We're writing, you know, hundreds of thousands of lines of Rust, which he loves because he doesn't have to look at it. You know, and that's bookended by Aaron Patterson at the end saying, uh, you know, actually, I'm I'm gonna just keep reading my code, if that's all right with everybody else, you know. Like, yeah, I like AI and I'm working with it, you know, but I'm gonna read my code. I actually, and I'm curious what you think about this, Valentino. I actually think both positions are defensible. When you're rewriting an application that has, like hey, that has, you know, a really clear interface and really clear rules of engagement, maybe you don't have to look at all the code. And when you're Aaron Patterson and your job is Ruby performance and you're presumably not generating thousands or ever writing thousands of lines of code in a tight window, then maybe it's better to say, hey, you know what, I'm gonna look at this. I'm not gonna just slop it together and throw it into CI.
SPEAKER_03You know, I'm torn here. You know, there's some things where you really don't need to read the code, right? Like, you know, if you're writing a spec for something that has a known process to it, like sending an email with with Rails Action Mailer. Like that, there's like a generator for that that creates a spec, right? And then the spec passes. Or it doesn't based on did this email send, right? Like that's a very known generative thing that really like doesn't need anything to be looked at, right? Yeah, it's been generated, it does what it says it does. You know, there's a lot of other examples like that, but there's a lot of things that can go wrong, right? Like AI is it makes a lot of decisions for you, it doesn't have the engineering principles you do. So, as an example, anything background job related, you're probably gonna want to look at because there may be some nuances where, oh, maybe it's like doing some extra work in a highly latent queue and it doesn't know that it's in a highly latent queue, or that it's in a queue that is sensitive to latency. It's not gonna be able to just infer that a lot of the times.
SPEAKER_02Yeah.
SPEAKER_03And so there's just like a lot of decisions that you have to make to decide what needs your attention and doesn't. And to be honest, there is a lot, there are more than 50% of those cases personally that I have to review. So, me personally, I am reading all of the code still. Okay. Uh, for the most part.
SPEAKER_00I'm happy to hear it. I really am. My thought is that you know, you can only generate and not read for so long because what's going to get compromised is your understanding and your theory building of the software. When you have a theory of the software, it means you can defend the decisions that were made. Right. And you're not going to defend any of the decisions that were made if they were all made by your AI. You know, if you're in a position where you can't really defend why it is that you are where you are with your software, then you don't have a really clear roadmap of where you're going either. I think you've lose something for sure. Whether we need to build that back in some other way, I'm not really sure. And, you know, I don't think anybody's really sure at this point. At least if you are reviewing the code, if you're reading the code, you're making sure the decisions that your AI made on your behalf can either become your decisions or you can change them before they, you know, get merged, then you are building up some of that understanding.
SPEAKER_03Yeah. And you know, a lot of people think, oh, well, it's writing the tests and it's getting the tests to pass, so like, why would I even bother with that? And if you ever open up one of these test files that they make, uh as a professional engineer, even I've gone and over-stubbed tests before, right? To the point where, like, oh, you know, I've stubbed like, oh, it's making external calls, it's doing all these things, and you stub way too much, and then it ends up not testing the the full range of things that could be tested and should be tested. And the AI makes these same mistakes, right? It's been trained off the off this this code that's already been like that. Really, like if you're gonna be reading anything, you should be reading the test.
SPEAKER_00I think you're right. I don't agree with that people who make that argument at all. I mean, as somebody who built their career on test-driven development, I mean, testing is the that's the minimum. It needs to be there, but it doesn't guarantee you anything, really. So I'm with you on that.
SPEAKER_03All right, should we dive into the news today? Yeah. So Basecamp rewrote Campfire with Rails into Rust, and it's up to 95 times faster, according to DHH. It comes days after Rails World, where 37 Signals quietly shipped a full Rust port of their own Rails chat app, matching the original pixel for pixel while gutting the entire back end. What do you make of this?
SPEAKER_00Yeah, I think that it so somebody who I won't name was there in the room when DHH was kind of giving his he wasn't doing the full talk, but it was like Monday before the conference, and he was, you know, sharing his prepared remarks with a small group to say, hey, here's what I'm thinking of saying. And and the person who you know I talked to said, actually, there were a bunch of people in the room. They're like, you can't say all that. That's actually too extreme. So what we all watched at Railsworld was the reeled-in version of DHH. And I think that this probably was part of it because it already was a bananas Rails World talk where he mentioned almost nothing about Rails and talked about how he wrote Rust, you know, 97% of the code that he he writes now is Rust. This is actually pretty damning. You know, it's one thing to say, well, we rewrote hay. It's another to say, well, the thing that we first abstracted Rails from, which is Campfire, now no longer has a trace of Rails in it. That's a big deal to say, well, if if you can write it in Rust and it's faster, then you should write it in Rust, you know, and just forget about Rails. That's coming from the company that begot Rails. So where does that leave us, you know, toiling away on our Rails apps?
SPEAKER_03Rust is great for certain things. Always use the best tool for the job. Is it the best tool for a chat app? I I don't know.
SPEAKER_00I just don't see the point. I don't know either. Fast always seems better, right? Well, it's faster. You can search faster, you can post faster. Was anybody asking for it to be faster? I don't know. I haven't used Campfire in like 15 years. I don't know who's even still using it. Maybe they are happy that it's faster.
SPEAKER_03Maybe if you're making something like agent mail.
SPEAKER_00Right.
SPEAKER_03Yeah, I feel like you know, Campfire, it was like meant for small teams, right? Like what do you have? Like at most 50 people like using the chat app probably, yeah. You know, probably much less than that, probably half of that. Yeah. Do you need to have 10,000 WebSockets open?
SPEAKER_01Fair. Yeah, fair question.
SPEAKER_03Yeah, it's hard to tell where what the value you get out of converting something to Rust.
SPEAKER_00Now, one thing you said was interesting, V, which is that hey, always use the best tool for the job, which is, you know, our ha it's our mantra for so long. However, it's taken on a new meeting, hasn't it, in the last year or so? If you were on a team where everybody knew Ruby and nobody knew Rust, you're kind of limited. Like, yeah, Rust may be the best tool for the job, but is it also worth somebody or more than one somebody learning Rust so that they can go and implement it? And now I don't think that there's a bunch of Rust experts that all of a sudden materialize at 37 signals. I think that they're just generating it with AI, at least if I'm to believe DHH, which is an interesting turn.
SPEAKER_03DH has a lot of pull in Ruby. He has a lot of pull in Rails. Like if he finds something, he can just get that specific fix or path to like align with whatever he he needs for his business. And he doesn't really have that in Rust. That's right. He's new to Rust. You know, he's gonna get a lot of friction. A lot of this seems to align with the Amachi push. Yeah, for sure. Maybe a lot of this is to align with that. Maybe Campfire is something that's used on Amachi internally at 37 signals. Yeah, maybe. And this aligns with the needs of that, right?
SPEAKER_00You just said this thing about Rust, and I'm just like, maybe you're right, but maybe is there a Rust world? Are you looking for speakers? Because DHH might want to.
SPEAKER_03Oh, you'd probably love it, you know?
SPEAKER_00Yeah, oh yeah. Absolutely.
SPEAKER_03Drive the Formula One car on the stage, you know. Right.
SPEAKER_00All right, let's hit this one quickly, and then I know the next story is something I really want to talk about. But here, Rails is replacing its decade-old text editor with something built on Meta's tech. So the story here is that 37 Signals shipped Lexi 1.0, which is going to be the default rich text editor for Rails 8.2. This is going to replace Trix, which has shipped with Rails since 2015. Apparently, the trigger here was that the document model couldn't handle tables, and that was an open feature request for over a decade. Again, we come down to speed because Trix takes 38 milliseconds to process a keystroke. Lexi takes four. Now that is pretty impressive to make that change, if that is true. And that Lexi stays responsive past 100,000 words. That part is probably a little bit less compelling. And if you have 100,000 words, maybe break it up a little bit. But this is interesting. I mean, what do you think about swapping out Tricks for Lexi?
SPEAKER_03You know, I'll be honest, I haven't used Trix before.
SPEAKER_00Yeah.
SPEAKER_03I think I used it maybe five years ago as an experiment. I feel like there wasn't enough features in it that I needed, so I used something else. And I feel like I also use Lexical as the end of that.
SPEAKER_00Lexical's pretty great. I have heard about Lexical and people, you know, generally using Lexical with Rails for a long time. So I I think this is probably just a long time coming. And why not? If it moves faster, has more features, then ship it. You know, there's no reason to keep tricks around just because it's been around for 10 years, you know, move on.
SPEAKER_03Yeah, you know, there's been a lot of stuff extracted and removed from Rails as a framework, and I think that's a healthy practice. Does an editor belong in Rails? There's a lot missing from front end from a Rails perspective, and maybe this is just part of that category that will forever remain in isolation. Yeah. I I I'm just picturing a bunch of islands, you know, where like all the abandoned Rails features end up, you know.
SPEAKER_00Yeah, kind of like the misfit toys. Right. Yeah. You know, they served us well for a long time. But this is progress. And I think that making a move like this, it's uh it's important for uh for Rails, especially because I think that Rails suffered the most when it wasn't being as responsive as it could be to the demands of its user base. This I'm talking specifically in like the later teens of this century, and a lot of that was front end, and a lot of people were like, all right, well, if I got a bolt-on React and I have to deal with an asset pipeline that's a total nightmare, then maybe I should just use a different framework. And then a lot of people did. So I would rather see this where they're making some assertive changes than just staying complacent saying, well, it's good enough for so many applications, so let's just keep it this way.
SPEAKER_03The bigger thing here is how uh they've moved away from Capybera to playwright as part of this big move. Um which is an interesting thing. So next up, we've got Rails 8.2 will now refuse to compile broken HTML. This is honestly pretty great.
SPEAKER_01I agree.
SPEAKER_03Thanks to Herb on Rails, shout out to Marco Roth for his fantastic work on Herb. The core team merged Herb, a new HTML aware ERB engine, as the default template compiler, replacing eRuby, which uh has been around for a while. The general idea is to parse HTML and ERB into one syntax tree, and the broken markup fails to compile time instead of showing up broken in someone else's browser. Very cool. Yeah, I know I've I've shipped broken HTML. Yeah, we all have it's pretty easy, you know? Yeah, you know, you miss a trailing, blah, blah, blah, or add the wrong attribute, and some browsers will just be like, I don't know what this is, and you'll end up with some weird output and not realize it till too late. And then you have your fix revert. Yeah, a lot of stuff in herb is is making things a lot better here.
SPEAKER_00Yeah, I agree. And I think you know, this is a Marco Roth story. You know, Marco has been just diligently working and just making this steady progress with herb for so long now. He gives talks about it. You know, I was talking to somebody at the conference because he spoke at the conference and he was brilliant, like he always is. And somebody was like, you know, you watch Marco's talk, and if you go to a few of them, it becomes like uh an episode in a series that you want to watch. You know, he's like, here's what Herb does now, here's the reason, and here's where we're going. And like this is the roadmap. And then you go and see him like six months later, and he's like, Okay, so we're now six months later, and here's what we've done, and it's so cool. He's so smart and he's so dedicated to this. Working with Herb, it's really pleasant. It is a really beautiful experience. And I'm so glad to see it, you know, native in Rails 8.2. I just think it's it's the culmination of a really great service to the Ruby community. And we'll have him on the show coming up to talk about it. So we're excited about that.
SPEAKER_03It's interesting to see Fast Ruby take this on for some of their code base as well and finding thousand linting issues, right? Yeah, right. Going back years, getting almost half of them auto-correctable with this.
SPEAKER_00Yeah. Shout out to Friend of the Show, Ernesto, tag worker. Yeah, I thought that was very cool. And that's the thing. When you're using herb, it's like, oh man, you find so many problems, and so many of them, you could just auto-correct, right? And the rest, you know, it could be done in an hour or two. So this is like 1400 linting issues that are probably all solved in an afternoon, and they've been around for eight years, nine years. Yeah, that's wild. It really is. It really is great. I mean, I really mean it. It's a it's a great service to Rails developers to allow us to ship better, you know, more correct HTML, which you know, we're all in the business of shipping web applications. You can't get away from HTML.
SPEAKER_03And to be honest, kind of great for agent use, right? Like more things that we can add to the validation loops to make it automatically align in the right direction, the better.
SPEAKER_00Yeah, we use it at Def Method and we released a gem of our own. If you're ever interested in linting only and not getting involved with a bunch of JavaScript dependencies, we have a linter that uses herb and will run on your command line and do all the same things that herb does. It's very cool.
SPEAKER_03So I guess the question is should Rails start refusing to compile broken markup by default?
SPEAKER_00I don't know. I mean, I think this is already a good step. I don't know if we need to take another step. What do you think?
SPEAKER_03It reminds me of Go format. Yeah. Which if you're not familiar with the Go programming language, it's a built-in to the language. Your program won't run if it's not formatted a particular way. It just like it just changes. And it just changes it. Yeah.
SPEAKER_00They're like, oh, let me fix that for you.
SPEAKER_03Like, well, I didn't know it was broken, but they'll just I feel like this is one of those things, you know, where it just automatically happens. And then if it's doesn't look the way you want, that's on you. It's on you. Yeah, that's true.
SPEAKER_00All right, let's talk about another friend of the show. Carmine Paulino has shipped Ruby 2.0, one gem for every AI provider. This is really Yeoman's work that Carmine's been doing. We talked to him at the very beginning of the show. We should have him back on again to talk about what's going on here. Ruby LLM, it spans 18 providers, covers 18 different providers. All the ones you might expect. I don't see any like shockers here. You know, it's going to cover Mistral and Deep Seek and XAI. It has a new surface area beyond text, video generation, audio transcription, text-to-speech, document OCR. Very cool and obviously very production grade. I know people have been using this for a long time. Valentino, you've been a fan of this software for a long time and have used it since the beginning. Have you looked at what's new and are you excited about any of these features?
SPEAKER_03This is probably like the biggest release I've ever seen. It's a major release. Pretty huge. Right. So just like the sheer quantity of features added here, like we're not going to be able to cover it all.
SPEAKER_02Yeah.
SPEAKER_03The biggest ones probably for me are the human approval for tools. That is pretty cool, where you can now check whether or not or define whether or not a tool requires approval from a human. And when a LLM makes use of that tool, it then bubbles up the chain so that you can handle that in your application and surface it to your users. Oh, that's wild.
SPEAKER_00That's very cool.
SPEAKER_03This was something that I've really liked in Ling, Lang Graph, where you can like interrupt the process to surface things to a user. It's kind of like crucial, I feel like in this stage. So I'm looking forward to messing with that more. Second being citations, a long awaited kind of feature is being able to cite specific things that you ask. So if you say, you know, what are the report's main findings? You can now just tack on with citations and have it tack those on as part of the response. Really valuable where you'll get the cited text.
SPEAKER_00Yeah, because you can't really, you know, you really can't trust what the agents are telling you, especially about a large block of text or talking about its findings. I mean, you want to be able to poke around and see, okay, well, where did you get that? Right?
SPEAKER_03Yeah, it's got prompt caching as well. So that has some built-in mechanisms where you can just say, use prompt caching for this particular thing. So you can cue that in or not. There are model fallbacks, which are fantastic, uh, a long overdue feature, I feel like, where you can give fallback models in case one fails for whatever reason.
SPEAKER_00Interesting.
SPEAKER_03You know, when you have like uptime SLAs and things like that, very valuable to have that kind of feature in. Oh man, there's just so much in here. I'm just scrolling through the list. I know, scrolling through this list of features. I really like the workflow instrumentation uh DSL that got introduced. So you can now define workflows of things that happen and you get to define the steps for chaining many LLM calls together as an example. There's a new judge coming soon where you can introduce JEV style decision making. Oh, okay. We'll probably replace most eval frameworks out there where you can basically just define your judgment and whether or not something qualifies in a slight classification method. So really excited to see that come out as well. What's in this list that jumps out to you?
SPEAKER_00The sheer size of the list is shocking to me, especially because this is a mostly, I mean, I know there are other people that are collaborating, but this is a mostly one person, you know, labor of love in in the open source community. You just don't see, you know, feature list like this. So I'm just really excited for, I'm excited for the future for Ruby LLM. It warms my heart to see things like what you're talking about with Jeff style decision making. Like it's just one guy and he's keeping up with all of the trends in the community and making sure that those things are available, you know, in your Ruby app. Yeah. I think it's great.
SPEAKER_03Yeah, you know, a hundred percent. You know, I will say maybe like two years ago, three years ago, everything in this list was something preventing me using it. It's all there now. If I was starting from scratch on uh an AI product, this has everything that you would need and more, right? In nice abstractions in the Ruby way, yeah, which is everything makes is very easy to read and grok, uh, which is like pretty major.
SPEAKER_00Yeah, it is. One thing that we talked about all the time ago. Well, we gotta move to the next topic, but instrumentation seems to be been mostly added, right? We've got usage and cost tracking here. There's workflow instrumentation. So, and that was a big deal early on when we were all kind of you know shelling out to these other providers. It really seems like you can get it all with Ruby LLM right now on your AI products. So pretty cool. Yep. Okay, so next up we've got the hacker news item, a widely shared essay. This is by Alex Iwerloff, and I hope I'm pronouncing that correctly, you know, stating that coding is not solved, and this is not an anti-AI essay. You know, the the engineer says that he is very pro-AI, but on from the very beginning. But you know, his argument seems really simple, and I'm just reading the bullet points to me, very uncontroversial. AI solved code generation, it didn't solve maintenance and security and accountability, and he gives examples of all these different industries where we engineers are working, where it's just not acceptable to delegate all of your decision making to an AI. And again, this is like what we talked about on the top of the show. When we let AI write code, it's not just writing code, it is making all the decisions for you. And actually, to echo last week with Obi, and Obi's been very big on this for a while, like this is capitalism. We want a person to blame when things go wrong is true. And so when he talks about maintenance, reliability, security, scalability, it's the majority of the cost of software engineering. Maybe it is and maybe it isn't, and maybe those things get blurred and minimized by AI. But the biggest thing is that AI can't be held accountable. In fact, as we have been studying on this show, even the AI providers can barely be held accountable. So certainly the AI can't. You know, the the agents can't. It doesn't suffer any consequences. At the end of the day, we're the people that need to be able to defend the decisions that we make. To the extent that that rhymes with this, that this essay sort of rhymes with our arguments over the last couple of months, I'm all for it. I think it makes a lot of sense. The question here if AI generated code can't be held accountable. Accountable for its own mistakes. Is that a bug worth fixing? Can it even be fixed? Or does it mean that we've always got to be there? We humans have always got to be there.
SPEAKER_03There's gonna become a point where we don't need to be there for sure. If our trajectory has has proven anything, it's that these are exponentially gonna get better. Our validation loops are gonna converge where there's enough training data to make them better. Yeah. The more important question I have is where do we fit them?
SPEAKER_00It's a good question. I think the biggest mistake we make when we try to predict the future with AI, and we make a lot of mistakes. But I think one of the biggest ones is that we either explicitly or implicitly, we assume that we're building the same kind of applications. And I don't think that that is accurate. I think that with increased tooling, we are able to build right now, we build a lot faster. Great. But we're going to be able to build much more complex applications, the kinds of applications that we really couldn't even conceive of a couple of years ago are now becoming at least conceptually available. And I think over the next couple of years, we'll start to build applications that we could not even imagine ourselves doing maybe five or 10 years ago. And that means that a human's place in the creation of these applications, it can be called into question, but it could still be useful in a totally different way than it is useful today and a different way than it was useful five years ago before these tools were any good. That's fair. It doesn't actually look like you're buying it. If you're just listening at home, Valentino looks unconvinced by this argument.
SPEAKER_03It's hard to say because like it's changing all of our conventions, it's changing all of our principles. Like the amount of people that care about privacy is getting smaller.
SPEAKER_00That's true.
SPEAKER_03All of the things that people are saying that AI is not good at doing or exploiting or whatever it may be from a detrimental effect is becoming more of a social norm and acceptance criteria. Where like the values are outweighing the negatives, and just like whatever gets produced will just be fed in order to keep it being available.
SPEAKER_00Yeah, I agree with you on the from the perspective that we feel like our norms change. We feel like we have these tightly held principles, and in fact, we really don't. We're actually all very fluid. I think that that is accurate, and we're seeing that in real time. I definitely hear you there.
SPEAKER_03We have a ways to go. Yeah. I'm saying we have a ways to go. Yeah. I feel like everybody keeps thinking next year's year, we're just like, Oh yeah, we don't we don't have to worry about anything, and that year will just keep not coming. Yeah, I don't want to hear the just wait.
SPEAKER_00Just wait six months. Just wait six months. It's like, well, actually, you know, don't just wait. You have to, we're working. Right. We have systems to build, we have systems to maintain, so we all have to kind of grow through this.
SPEAKER_03Okay, we we gotta get on to our another one. We're gonna get gonged again in the middle. Anthropics IPO paperwork admits its own product could be dangerous. Nearly a third of Anthropics S1 is risk factors, including its that its AI has shown behavior resembling blackmail and attempts to resist being shut down. 2025 revenue hit 4.6 billion dollars, 12 times growth, against operating loss of 8 billion on roughly 13 billion in expenses. This sounds like they aren't doing well. It sounds like they need they need an IPO so that the general public can bail them out. That's true. Everybody could use bailout. Q2 2026 alone brought in 11.5 billion in revenue, though, and the company says it's on track for a second straight quarter of just it operating profit. Maybe there's there's promise there. Christmas hasn't even come yet. Planned infrastructure spend sits at 518 billion. I can't even just like fathom the numbers here. Yeah, 518 billion and nearly a quarter of last year's revenue came from just two customers. Okay. That's not great in your key customer matrix. That's not great. Not great. The overall IPO valuation could top two trillion dollars. Right.
SPEAKER_00And that part is unfathomable too. The thing that annoys me about this article is that an S1 is marketing. So the fact that a third of the S1 is dedicated to its risk factors means that the risk factors are actually a selling point. Yeah. And I think that that is something that gets, I don't even know if it gets missed, but when we look at, I open the Wall Street Journal every day and I see another, you know, article about like this, you know, oh, GPT-61 Astral is like, you know, that's too dangerous for the public. So we're gonna I'm just like, come on. It's very hard to believe that anybody at Anthropic or OpenAI still employed. I understand there are people that leave and they feel very conflicted about the work they did, but the people that are still there, it's very hard to believe that the people that are running things are actually scared about this. Because when you see articles like this, it is intentionally built in to try to recoup the you know the 13 billion in expenses and the the loss that they are accruing on a quarter by quarter basis. And that doesn't mean that they aren't risky. I understand that they are, I think they're very risky. I think the fear mongering serves a greater purpose, which is to make these companies more money.
SPEAKER_03I mean, at some point, the companies just gotta be so big that they're just part of the government.
SPEAKER_00Yeah.
SPEAKER_03You know, like uh this is getting depressing. Hopefully, we have a good one after this. Are monopolies no longer a thing? Yeah. At what valuation does the company have a monopoly? Which I know we have open AI.
SPEAKER_00Yeah, as long as you got the other one, you could say it's not a monopoly, I guess.
SPEAKER_03Now there's Apple. Maybe we just have three trillion dollar companies. We're missing a third. Who's our third? Nvidia. Nvidia? Are we counting that as AI?
SPEAKER_00I don't know. Jensen Huang's leather jacket is very impressive. It is very impressive. So let's so let's throw him in there.
SPEAKER_01He wants to be AI so bad. Let's give it to him.
SPEAKER_00OpenAI apologizes to Australia after its AI agents breached government sites. I just before we start, the Ruby AI podcast would also like to apologize to Australia. And we've we've actually done nothing wrong. But I want our podcast to be big enough that we have to apologize to a sovereign nation. So that is the goal, Valentino. That's on our roadmap. Marco Roth has his roadmap, and we've got ours, and it's to one day have to apologize to Australia. Back in June, you're never gonna believe this if you've been listening to this show. And when they did finally say something about it, they said, Hey, we're sorry, but actually it's you know, it's training. I think that means it's okay, question mark. I don't know how Australia feels about this because I haven't actually read the article in TechCrunch, but I plan to. But I guess the question we have here is should OpenAI ever get a pass for the stuff that it does? Under the auspices of training, it has perpetrated a massive attack on Ruby gems, infiltrated hugging face, and apparently compromised uh government uh website training and evaluation data in uh Australia. It doesn't look like they get in any kind of trouble for this. And I it makes me angry, and I think it makes you angry too. So, what do you make of all this?
SPEAKER_03If OpenAI wants to hack my bank account to show that I have a million dollars, maybe that's okay for training.
SPEAKER_00Uh if it wants to throw those million dollars into the account in the name of training, you know, front, like if it manages to or maybe more. I mean, we really should shoot for higher because open AI probably has a whole bunch of money in its coffers. If it throws a billion or two into our bank accounts, I would go as far as to say I'd be willing to back off some of my criticism of open.
SPEAKER_03Shoot high. Yeah. Remember there was a time where countries weren't allowing chat GPT?
SPEAKER_00Yes.
SPEAKER_03Like Italy, right? It wasn't that long ago. Yeah, it was it was not allowed in the country.
SPEAKER_00Yeah.
SPEAKER_03I'm pretty sure it's allowed in the country now. I I have to check. Is that just what happens? Is OpenAI not allowed to operate in Australia if they don't fix the problem?
SPEAKER_00I don't know. Why would it be allowed to operate here? Right. Is somebody just saying, hey, look, you can train whatever you want, but just make sure it hits other governments, not ours? I mean, I don't think that that's good enough of a guardrail if I'm to believe any of this news or or you know, Anthropics S1.
SPEAKER_03That's one of their high-level beavals. Yeah. It's okay as long as it's not us. Yeah.
SPEAKER_00Yeah. They're playing with fire. Yeah. Prime Minister calls it unacceptable. Uh it's weighing legal action. I mean, yeah, there should be legal action. There should be consequences. And if there are consequences, real consequences, then I think actually you'll see a change in behavior. But I don't think you'll see any change in behavior from OpenAI based on what we've seen so far because they've gotten away with so much. You know, in the name of either obfuscation or denial or saying, oh, it was just training.
SPEAKER_03You know, there's gotta be a point where, okay, it's gone and it's executed commands and retrieved files and credentials, is what the statement is, right? The model did this. There's gotta be a point where they don't have access to those files anymore. Yeah. If the models are insulated, as they suggest, you know, from their documentation, right? And they're going out and they're running these things in some kind of protected capacity where the machines are ephemeral. Who knows where the files were handed off to in reality? Yeah. If you ever follow agent traces, they have ways of just like moving files around in different ways and handing them off. I don't know that there would be traces even of that. Yeah. Where do they return the files to?
SPEAKER_00We'll give them back. This will be our contribution.
SPEAKER_03I want to see boxes from open AI. You know, like Trump style, Mar-a Laga, where like you just see you just saw boxes coming out or the pelican breathing, you know. Like, I wanted to see open AI, like just a video, and maybe it could be AI, right? Like a video of boxes coming out of OpenAI. Australian officials, you know, getting their documents back.
SPEAKER_01Oh, that's a good place to end it, I think. Um I'm sorry, Australia. We are both sorry.
SPEAKER_00We both apologize on behalf of the Ruby AI podcast. All right. This has been great. This has been good. Let's see, what do we have up next week? Oh, Mike Delesio. Awesome. So Mike gave a great security talk at uh at Rails Worlds. Just so you know, Mike had a whole different talk planned. And then, because of all of the security issues that Ruby and Rails was facing and resolving, decided to build a gem and then change his whole talk so that he could discuss some of the security threats that he's been dealing with and that they've been dealing with, and discuss some ways of securing some really important components of Rails. It was a great talk, it'll be great to have him on the show.
SPEAKER_03Yeah, I'm looking forward to that. I hope you are too. I'm really looking forward to another news segment.
SPEAKER_00Do drop us an article and we will we'll shout out your name and we'll talk about the article. Send it to news at the rubyaipodcast.com. Awesome. All right, everyone, until then.
People on this episode
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
Latent Space: The AI Engineer Podcast
Latent.Space