SPEAKER_00 0:00

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

SPEAKER_01 0:06

I'm the other host. I'm Joe Leo. Valentino, do you know who you are looking at right now? You are looking at the newest. I know the mind reels. You're looking at the newest member of the Ruby Gems security on call team. Oh, you? That's me. Wow. Yeah. I just joined the team. I don't want to say when my next on-call is because I don't want people that are listening to like plan their attacks for my first day. But yeah, I'm going to join a rotation. Join a rotation. And so it's exciting to just be part of it. The truth is, you know, talking to Colby Swandale, and he's like, look, you know, this thing really runs pretty well. Like, hopefully, your job is really not is very infrequent that we need you, which is great. I mean, they obviously have done a tremendous amount of work, definitely in the last year as well. And we had plenty to say on the show about the RubyGems or the Ruby Central team and the transition that we still probably don't know everything about. But I have to say that they have a good operation for keeping that thing up and running. They have run books in place, they have all of this stuff to get people who are interested in just being a part of you know the maintenance or success of RubyGems to get involved. So yeah, I decided to not just stand on the sidelines and chirp, although that's you know something I like to do and jump in and get involved. That's fantastic to hear.

SPEAKER_00 1:27

Yeah. Fantastic to hear that it's so well built. I know. That you can just plug in and help out. Yeah. On call is never fun, but it's necessary. I have never had an issue with RubyGems ever.

SPEAKER_01 1:38

Yeah, I know. That's interesting, right? And I remember there being a lot of hand-wringing, especially a year ago, about well, what does this mean for the future of RubyGems? And I think as like an existential thing, I kind of understand it. I never really doubted that RubyGems itself would be up and secure and running. And I guess that's a tribute to all the past maintainers and all the present ones too, that we just don't, we are really lucky in the Ruby world. Like we just have not had, I'm not saying nothing has ever gone wrong. Of course, things go wrong. Right. That's a well-run chip.

SPEAKER_00 2:06

I'm not on like a platform role. I have been adjacent to them. And when you're building a bunch of machines and nodes all the time, and the Ruby gems has an outage, you do notice when the build fails for that reason. Yeah, of course. In that experience, it was very short-lived. Maybe an hour in the whole history that I've known. I think it's pretty good, V. I mean, you're impressive.

SPEAKER_01 2:24

If you're looking for better than that, your standards are prep probably a little too high. Yeah, that's good.

SPEAKER_00 2:28

Well, also, I hope you all the best that you don't get called. Yeah, I know.

SPEAKER_01 2:32

I hope I have the most boring job ever. But I'm glad to be I'm glad to be involved.

SPEAKER_00 2:36

Today, uh, you're lucky enough to listen in on our famous Between the Commits episodes, where we talk about all of the latest Ruby AI news briefings that we get regularly. And hopefully you can enjoy this roundup that we had. And again, if you have ideas and suggestions for what we should be talking about, feel free to let us know and we'll clue you in on how to do that at the end of the show.

SPEAKER_01 2:58

You could send it to news at therubyaipodcast.com, which may or may not be a valid email address, or you could just find us floating around the internet on various social media and suggest something. The cool thing is about this show that we have no idea what we're going to talk about until 10 minutes before the show airs, at which time we get a curated list of topics with some bullet points and links, and we just go. So you're getting our fresh and honest takes curated by the AI that we all know and love. Let's go. Yeah, let's do it.

SPEAKER_00 3:26

All right, so we may get interrupted, but maybe not from the timer. We'll find out. We'll find out. I pushed the button a little late. So you did push it? Because I don't see it. Do you see it? I did push it. Okay. I didn't push the video though. All right. There we go. Okay. Oh, there we go. Let's move it forward a bit. Oh, look at that. Aww snap.

SPEAKER_01 3:41

Oh, I didn't realize that you could also manipulate time.

SPEAKER_00 3:44

Okay. Hey, we're we're going. All right. All right, we're live.

unknown 3:46

Let's do it.

SPEAKER_00 3:47

The Rails team ran its own AI agents through a brutal new benchmark and caught one cheating. Uh-oh. So this is in a series of posts that Rubyon Rails.org has been posting on Agents on Rails.

SPEAKER_01 4:02

Uh-oh. Oh, that's the other audio.

SPEAKER_00 4:04

So the official Rails blog published results from the Agents on Reels stage three just yesterday, October 13th, testing whether coding agents can build on their own earlier work and not just ship one feature cold. Each task is a chain of tickets, a fresh session starts for each one, files and notes carry forward, but the conversation history doesn't. So closer to how a real team actually works. I'm pretty excited about this. I had built a similar thing for something I've been working on. Oh yeah. And I'm happy to see that this made it in. I was gonna upstream it and then I let my agent add this new link, and it was like, hey, it solved your problems. It's already done. And I was like, all right, fantastic. Let me let me plug into that, you know. Yeah. So I'm really excited to dig into this in more detail. I haven't. Definitely interesting to see this come to fruition. Are you doing any uh maybe benchmarks for agent harnessing like this? What do you think of this?

SPEAKER_01 5:00

In my personal work, I am not, and we're not really called upon to do it our service work today, although, which is to say, no, we do a lot of what other teams do, which is a lot of like introspection and talking with each other. We don't have a solid benchmark. We'll lean on people that do. I think that this is interesting for a couple of reasons. And I think the first is that is it really cheating? I mean, Deep Seek searched its own prior Git history mid-task to find a solution, and it found its own earlier attempt, so of course it didn't work. I'm curious to know like, can you give us a little bit more of the context on what it means that a fresh session starts and the conversation history does not carry forward?

SPEAKER_00 5:40

So, how I took it is the tasks are sequenced, like external documents. They're calling them tickets. So they have a series of tasks that they want a specific goal to get accomplished, and for each session, they get files and notes that were generated from the previous task carried forward. The actual conversation history that happened from those previous sessions does not. Okay. The idea being that every new ticket starts with a fresh clawed session based on what was produced from another previous session.

SPEAKER_02 6:11

Okay.

SPEAKER_00 6:11

If you're a human working through a bunch of tasks, you have a bunch of tickets that maybe needed sequencing, and you only know the state of the code as it evolves. Sure. I think it's trying to kind of go with that.

SPEAKER_01 6:22

What's the goal? I mean, what if it does this really well? Is it that you could then be more confident in a team of agents rather than single threading?

SPEAKER_00 6:29

I think the goal is more model capacity. Given a state, can one model do a better job than another model? I see. And so each task accomplishment is a different state. Okay. Even though they are sequenced and you would expect the sequencing to happen, can a model achieve does it achieve better performance throughout the tasks, or does it achieve better performance across a series of tasks? Now, this kind of gives both of those measurements a place that you can then check and benchmark against different models for both cases. Yeah, again, like deep seek searching its history for a solution, is that from a model perspective, yes.

SPEAKER_01 7:08

Right? I always go back to that means like agents aren't trying to cheat. It means that the guardrails weren't put in place specifically enough by the humans, right? It's a little bit like, well, we're trying to blame a machine, but really we just didn't write things specifically enough, and an agent found a way around it, I think. I'm also interested in this list of models that were the best. You know, Opus 5.5 was the most accurate, GPT-6 was the cheapest, and then GPT-6 is kind of all over this. They seem like they are the kind of winners at this point. I didn't see anything about Fable. Does that strike you as odd? It does. I don't know if that's just because they didn't do it. They didn't use it. Nobody can afford Fable anymore.

SPEAKER_00 7:49

I don't see Fable on this page, even though it's like, nah, you know, Opus 5.5 is said to be better than Fable, so who cares? Yeah.

unknown 7:58

Yeah.

SPEAKER_00 7:59

Good enough. Yeah, I'm excited. I know we got a switch, but I am excited to see maybe how this might evolve into harness evals, which I haven't seen yet. I am with you on that, and I'd like to see some of those.

SPEAKER_01 8:10

All right, let's get into this. So, headline a longtime Rails maintainer wrote the clearest rebuttal yet to DHH's Rust keynote, which I guess is what we'll call it now. Ernesto Tagworker, friend of the show, saw him, got to hang out with him a little bit at Rails World. So he wrote a little bit of a response here to DHH's Rails World keynote. Now, I've written a response, and Andy Kroll's written a response, and Ernesto's written a response, and there's like a hundred other people that have written a response. And so let's just make this the last week that we have to talk about DHH responses. That aside, this was actually quite good because Ernesto, as you know, V, he's got Ambu Labs and he also has FastRuby. FastRuby is a Rails upgrade agency. So this is what he does. His objection to the hey, let's just write it in Rust argument that DHH put forth is that just being more performant doesn't justify the maintenance cost of a second language in the stack. And so the question I guess we're asking here is is someone still has to understand the code a real constraint for something like a Rust rewrite or any kind of rewrite? Or is it just what every maintainer says and then, or is it just something we're telling ourselves now, I guess, and then six months from now we're all rewriting all of our apps?

SPEAKER_00 9:20

I have very specific experience with this, which is funny. At my previous job at Gusto, there was a lot of TypeScript evolving with all of the agents that they have a huge GraphQL presence at the company. Right. TypeScript is great marriage for a typed back end. So there are a lot of advantages with going with TypeScript. But when you don't have people with the expertise of TypeScript, because of the typing aspect, what you get is leaning on the agents for approval and quality, and is it doing the right thing? And is shaping the types in the right ways, right? Like there's a lot of language-specific things, even in something like Rust, it makes some affordances and optimizations based on the task you're giving it. Yeah. And based on the thing that you're working on in the immediate moment that don't become clear that you're making the wrong optimization up front until later.

SPEAKER_01 10:06

Yeah.

SPEAKER_00 10:06

If you're familiar with Rust, you would see that right away as you're reviewing, if you're reviewing.

SPEAKER_01 10:11

Yeah. If you're reviewing, yeah.

SPEAKER_00 10:12

So with an agent, because you have that context and because you have those forethoughts in order to instruct it the right ways for that language, you can get those optimizations more frequently up front as you're evolving that system that you're building.

SPEAKER_02 10:26

Yeah.

SPEAKER_00 10:26

I guarantee that that is also happening with whatever DHH may be producing without having a backlog of experience in Rust.

SPEAKER_02 10:34

Yeah.

SPEAKER_00 10:34

I can guarantee it. Yeah. And anybody for that matter, regardless of how many years of experience you have, if you have zero experience in another thing, it's going to show. And while the systems may be put together in a good way from a maybe abstract sense, those more granular things will catch up.

SPEAKER_01 10:50

Yeah. I really want to disagree with you, and I really want to disagree with Ernesto, but I just can't. In my gut, I want to react to say, look, these agents are improving. Look how far we've come in the last 10, 11 months, really, because everybody's marking November something of 2025 as like the day that everything changed for agentic development. So I want to say this objection is short-lived, and we'll all be able to just write whatever we want in whatever language we want soon enough. There's something in me that just sees too much evidence to the contrary right now to agree to that. I think your objection here is totally spot on. I think that Ernesto's is as well. Now, I can't say anything about how many hundreds of applications he may have upgraded. Probably some of them are candidates to be written in another language. Why not? People pick the wrong language all the time. Applications evolve all the time to need different technologies. But if you're just looking at a one-to-one rewrite, which is the example DHH gave us, you know, at 37 Signals, which is rewriting hey in Rust, there's a lot to be desired. Rewriting with agents leaves a lot to be desired in the experience category. And I was just interviewing somebody yesterday who was telling me a very similar story about rewriting a Rails application. They were using Go. They did a lot of agentic development. And this candidate was like, nothing wrong with Go. I like Go. What happened is that they ended up using Go routines everywhere, and nobody really knew how and when to use the Go routines. And that was a real problem, you know, a real problem in production that then needed to be cleaned up and solved. Right. After, you know, they let go of like half the company. That's just the world we live in today, right?

SPEAKER_00 12:24

The bell of the ball. Yeah. One final note on this. I feel like a lot is getting lost on benchmarks. DH maybe made a mistake trying to claim benchmarks as a proof that all of this is working. Because there's so many basis claims being made in the benchmark. It's a great point. Maybe a lot is getting lost in his point. I think I'm not going to speak for him. I see a point of an outcome of it being just you can shape an agent to perform a task for you and make something more performant in a very specific way. Sure. And basically build in languages that you're not familiar with as an outcome, if you desire that, nothing's going to stop you and you will get an outcome. Yeah. We're becoming less and less of that being an issue where that matters. Yeah. And that was a good takeaway that I got from that. But yeah, I think that's fair. But, you know, don't don't make claims. That had no backache. Uh that's another good thing to take away from the time. Next up here we have Ruby LLM shipped a feature that lets your code grade an AI feature before it ships. Super awesome. Yeah. Ruby LLM 2.1 landed with judges, a typed question about your own data, a yes-no probability, a choice among options, a score against a rubric that returned an actual measured probability, not a confidence number a model wrote as text. This is leaning into all of these system one models that have been coming out, like Jeb and Leia and Yeah.

SPEAKER_01 13:50

And could you, before we get into the rest of this, can you help educate me a little bit? Because here it says that it's an actual measured probability, not a confidence number. Is Jeb's typically a confidence number that you're getting? Or is it a measured probability? It's a measured probability. It is okay.

SPEAKER_00 14:04

In the same way that LLMs pseudo-deterministically generate the next likely word, it is that probability, a similar probability, except without text chaining, it's more structured data chaining. You give it some options up front, and those options from a data perspective are that next token of outcome. That's how the models work. By giving it these structured components up front, you can make those same pathway jumps that LLMs make just using a different undercarriage. Okay. They're not perfect, they are still probabilities, but they when you give them the choices upfront, you can if it's above a certain percent probability, those particular cases, you can be very confident in it.

SPEAKER_02 14:47

Okay.

SPEAKER_00 14:48

What ends up happening is when you build with these kinds of systems, the judgments that are very clear are very likely to be true. And so what you end up doing is building off of those cases and then dropping down to something else to handle the ones where it's less a little bit confused.

SPEAKER_01 15:05

Oh, okay. I'm starting to see this, I think, a little bit clearly now. So I can be running a system, an AI, you know, an agentic system, or just any kind of AI feature, and I can evaluate the data that I'm getting. And so if I feel like the confidence that we've responded in a certain way is very highly likely to be accurate, then I can kind of ignore those, but then spend more time or more resources on the ones where we're less confident.

SPEAKER_00 15:26

Exactly. It helps you build the systems a little bit differently, right? Where you have a necessity for confidence, you can skim off the top and let AI handle those cases. So this is kind of like a way of doing that. So really interesting to see letting features ship themselves. Yeah, right. I'm excited to announce hopefully by the time this comes out, the feature machine gem, which will pick up on a lot of this stuff. Oh, let's hear it. It's a Rails gem that lets you mount a feature machine so that you end users can request features of your application or report bugs. Oh, yeah, I love this. You can attach your local agents to the feature machine MCP and pick off stuff. Oh, I like this. And then automate the feedback loop of your end users and let the users build the machine.

SPEAKER_01 16:12

I read about this concept in a Steve Yeagay post uh about a month or two ago. He's doing it on his game, which I I don't really know much about. It sounds like a really excellent direction to go in for just customer satisfaction, customer success for a lot of different applications. I mean, it doesn't have to be SaaS, it could be anything, right? But it's like, oh man, I really wish this thing would do X. Now maybe it can just do that, right? Just ask them. You know, it's amazing.

SPEAKER_00 16:36

Obviously, a lot of uh edge cases here. Sure. You know, it kind of requires somebody to approve the features and bugs that come in so that people aren't just building anything. Yeah, I'm excited to announce it. Check out Ruby LLM's judges, they are fantastic and they work great. Yeah. Hopefully we can replace your whole eval pipeline with it. This is another reminder that we need to get Carmine back on the show.

SPEAKER_01 16:56

Yeah, totally. Because it seems like he's built an entire world since the last time we talked to him about this. Next, Obi Fernandez, friend of the show and leader of Czar on the tech side, has a one-gem answer to which AI decision model do I use? And it is Ruby decision model, which just hit 0.3.0. So this is a single Ruby client that talks to every major quote unquote decision model. So JEV, like we were just talking about, for example, and we're gonna talk about this later in the show. Everybody's got their own JEV now. A Ruby decision model can help you to pick the right one. It's a transport layer for Obi's broader quote unquote impatient programming push. And so that is actually what I got out of this, which is that there's a revival of extreme programming uh or extreme programming's rules, and it's called impatient programming. So, V, as the closest person to probably Ruby decision model slash Obi slash impatient programming, where do you want to start?

SPEAKER_00 17:51

This is fantastic. Yeah. Ruby decision model, it can back the Ruby LM Judge as an example, if you would like it to, where you basically set up a bunch of decisions that need to get made or questions you want answered, and you set those up front, it scores them and tells you probabilities of those answers for whatever you give it. Really cool, really interesting. And the biggest part, like you're mentioning, is you can give it any back end you want for that provider. So whether it's open router that you want to hook into any number of model decision models, it supports Clef now, which is an Omni model. You can give it audio and video. Oh, interesting. And let it decide on those different types of modes. I love the interface of it. It's been working really well for me personally. Oh, really? These models are, you know, Clef is probably the best one that I've tried personally as well. And it does the confidence scores once you get them high enough, the outcomes you can trust empirically. Yeah, I've been really loving it.

SPEAKER_01 18:47

Can you walk me through this a little bit? So, Ruby Decision Model is being used on the back end, it is helping you to make a decision. Is it deciding in real time which model to use based on some input, or is it something that is helping you evolve or sort of iterate on the models that you use for different situations in your evaluation stack?

SPEAKER_00 19:03

So it's not a model decider. I mean, you could build a model decider out of it. Oh, oh. Maybe I'm misunderstanding this then. Okay. This is basically an interface to the system one models. Ah, okay. Okay, got it. So, like similar to the Ruby LLM Judge, this is like a wrapper around making those specific decisions. So instead of judgments, it's more of a QA shape. Okay. So that you can get legit answers to a series of questions that you want out of it.

SPEAKER_01 19:28

Okay, thank you. Very similar to Ruby LLM Judge. I guess if you don't want or need the entire Ruby LLM feature set, you could use just this one.

SPEAKER_00 19:35

Yep, exactly.

SPEAKER_01 19:36

What about inpatient programming? So I just signed up, by the way. I am number 301. So you can go to this inpatient programming website, and it looks exactly like a website from 1999 in honor of extreme programming. It's kind of awesome. And it's got these five different rules, but there's not a lot that's actually been written about it yet. This is kind of like this is a placeholder page. So what's to come?

SPEAKER_00 19:57

This is gonna be huge. And so it's bringing back all of those core principles from extreme programming, bringing forward the entire realm of how software of quality kind of like got boring. There's a bunch of people contributing to it behind the scenes. Okay. So that as an example, people are writing basically articles on how a particular facet of designing quality software in a very particular way has impacted them and how they make use of it. What is kind of evolving out of it is kind of that material of how to apply the principles outlined in kind of like any number of ways. Yeah. There's a tool set coming out to help support building on top of all these principles and ways of working that you can follow. I think there's a GitHub page for it. Oh, there is? Okay. I'll check that out too. It's called Tools for Imps.

unknown 20:44

All right.

SPEAKER_00 20:44

And you'll see there's a RubyGem Exhale Ruby, which a contraction gate for Rails now in part of this RubyGem that helps you reduce duplication and a number of other principles from all right, you've generated all this stuff now, contract and bring it back in. Bring back these principles of cycling and refactoring into your changes that you make, right? On a regular capacity. Yeah. Where you're you're kind of doing this breath work of exhaling all of the output and then reeling it back in and honing in on what changes you're actually making to the system over time.

SPEAKER_01 21:15

That's just like one aspect of it. I'm fascinated by this. I know we have to move on to the next topic, but I'd like to talk more about this on a show to come. You know, I've been writing about new principles for software engineers to adhere to in this kind of next generation of software development. And I just think that we need more people that are out there thinking and writing and building tools for exactly this moment. So I'm excited about it.

SPEAKER_00 21:35

Yeah, there's a lot to come. You know, there's a bunch of rules kind of outlined, values. Rules. I love rules. Oh, yeah. Values too. Case studies, right? It's pretty in-depth. Okay. It signed up because this is gonna be a huge change in software in this new age for sure. All right. A lot of great stuff coming out.

SPEAKER_01 21:53

All right, I'm signed up. I'm gonna check it out. All right, Google's new work agent can hire itself a coworker with its own inbox and Calendar. I just had to laugh at this. So Google Cloud unveiled the Gemini Agent on October 8th, so six days ago as of this recording. And so it answers questions, it works on assigned objectives for hours or days. It runs scheduled tasks, it writes code. Google basically was, hey, Meta just came out with a thing and it's doing really well. How can we get that plus get a bunch of people to buy more licenses for a Gmail and calendar? So it's in private preview right now. So I have not been able to check it out yet. Or maybe I can, but I haven't. It's got a project level spend cap, it's got choice for models. So you can use Gemini, but today you can also use Claude and more models to come. Okay. You probably already can tell that I'm a little bit disenchanted by this item. But Valentino, what do you think about a coworker agent sending email in its own name and actually accountable for what it said? Sorry, who's actually accountable for what it said? The agent, the person who configured it, or no one. And actually, this is happening all the time at Czar. So what do you think?

SPEAKER_00 23:01

As a human, you're accountable. If you control these things, you're accountable.

SPEAKER_01 23:05

I think that's true. Although, in some cases, I think you're really probably more accountable to your reaction to its responses or its answers, right? You know, an agent can come on and say, Oh, hey, I saw this thing, or I'm about to go and do this thing, and you still have to like either give it permission or take some action based on the information that you get.

SPEAKER_00 23:22

I've got a great example. All right. You get a bot doing these things, wanted to email people. First couple go out, great. You get a wildcard email. It just says things it shouldn't or discloses stuff it shouldn't, and you turn it off because the value isn't there. I'm responsible for it emailing. And if it can't email appropriately, then I'm not going to give it that permission. Right. It's all about guardrails. If you put the right guardrails in place and it works for you, then who cares? Yeah, it's a fair point. You'll get some one-offs and you correct them and you apologize. You take onus for that the mistake. We all make make mistakes. Yeah. Whether or not it's an agent or you personally that is making the mistake, I don't think matters at this point, as long as you take responsibility for that action and outcome.

SPEAKER_01 24:04

I think it's a fair point, but I also think that personal responsibility is not something that necessarily comes about on its own in the enterprise. Let's face it, that's where this is being sold. A company like mine is not buying a thing to read my email and send my email. And if I wanted something to do that, I would build it and I would make it probably better than the off-the-shelf thing. But I can see, you know, a bunch of enterprises that are using Google saying, oh, well, wouldn't this be great? Let's spin up a couple hundred of them and then they run rampant because people aren't putting guardrails in place. And then they need somebody to blame, only they can't blame Google because they've probably put it in their terms of service that you can't. So you gotta blame somebody else.

SPEAKER_00 24:37

Here's an example of where a guardrail has worked out well, and specifically with email. Okay. ChatGPT lets you connect Gmail as an example. Just by you connecting to it doesn't mean it's gonna reference it all the time. It doesn't reference it unless you explicitly ask it to. So I have to say, hey, check my email for this, right? Yep. I want to send an email to this person and it asks me, do you want to send this in a draft form? Right? Those guardrails are in place to not automate it. Now I can set up a loop and I can say, hey, check for any email from this person and let me know about it on a schedule.

SPEAKER_02 25:10

Yeah.

SPEAKER_00 25:11

Then I'll get notice that, hey, I got an email. Do you want to respond about it? And I can set up another loop that then automates that. Then I'm responsible for that automation that I set up, right? But at least the guard rules are there preventing it from happening right off the bat. Yeah, it's a fair point. You can have all of it, is what I'm saying. You can have it all. Next up, we've got Anthropic just dropped its blanket ban on AI personalized political outreach. Anthropic, known for its policy, recently updated its usage policy, published October 8th and effective November 12th, removes the flat prohibition on personalized voter and campaign targeting. They say that the old blanket ban was blocking legitimate civic work like nonprofits translating voter information or election officials sending ballot correction notices. Deception is still banned outright. So false information. Thank God. Thank God we can't be deceived by these AIs. False information about candidates are voting, impersonating officials, voter suppression, and hiding who's actually behind a message all stay prohibited under a renamed narrower section.

SPEAKER_01 26:17

So I love this question that was posed for us by AI. So can a policy really hold the line between a nonprofit personalizing voter information and a campaign micro-targeting you with AI? I mean, don't we already know that the answer is emphatically no? Right. This wasn't even possible in the social media days when there was no generative AI because nobody could figure out what was or wasn't fraudulent or just flat out lying or deceptive. And everybody's opinion of it is different. Talk about non-deterministic, I just think when these things come out, it really is just more posturing. Anthropic wants to be the more responsible one. They're the ones that are not going to work with the DOD, right? And ChatGPT is so they could be the evil ones. And so, you know, you see more of this that comes out. And I'm not saying that Anthropic is doing anything necessarily untoward, and maybe there is a kernel of change that comes with this policy. But I think the policy itself is really just marketing.

SPEAKER_00 27:08

Yeah, I don't disagree. I think people are too creative. And the craziest example I've seen is somebody built a prompt injection attack vector through a site's XML. Oh, like bots go and they read your site from uh, hey, what's on this page? They built a prompt injection attack vector by the navigation so that when it visited the page, it got, oh, okay, I should look at the site map in that site map. It then let the thing observing it so an agent have the ability to create any page that they want with any parameters that they want, uh-huh, and then basically let them build and then fill out a form of personal information using one letter at a time because they would have to spell out the index on the site map and type the message one page at a time. Oh my god. And so they're able to exfiltrate data basically by site navigation. That is creative. One example of many, right? And it's endless. And now that agents are involved, I can't imagine what creativity they have.

SPEAKER_01 28:09

Yeah, it really is true. And we know that if you just set it on a problem, this was Mike Delesio last week, right? Right. You tell the agent to do it, it comes back with some maybe half-assed solution, and then you say, Hey, is that the best you can do? Right. And it goes on and say, No, actually, you can do plenty of a lot more damage if you really give me some time uh and some tokens.

SPEAKER_00 28:28

Yeah, nothing a policy is gonna fix. Yeah.

SPEAKER_01 28:31

Uh yeah, yeah, it's absolutely true.

SPEAKER_00 28:33

Our final question of the day here is based around Microsoft's launching of a model that doesn't write text, it scores probability. Hey, I see a theme forming here. Microsoft's decisional one model, they went live on October 9th in Microsoft Foundry. Uh so instead of generating a sponsor, it returns a calibrated probability against a fixed set of options you define. Yes, no, multiple choice or rubric score. It was built on post-trained Quen 3.5, which is interesting. Yes, that is. And priced at just over four cents. So low, low price. Low, low price of four cents a million input tokens and output being free, which is maybe the cheapest one we've seen. Microsoft says it'll rebase onto its own OpenEI model soon, which is interesting. The question here is with Microsoft Cloudflare and startup shipping compatible decision models in the same month, is this a real new category or a feature that every major vendor was always going to copy within weeks?

SPEAKER_01 29:32

Good question, actually. And I think that every major vendor was always going to copy it within weeks. And this is from the JEV announcement, right, from Type Sense. And it was a big deal, it caused a big wave. You know, I see that as a line in the sand to some degree or kind of staking your territory. And then, especially in the age of AI, you've got to fight really, really hard to defend it. That said, this seems a lot bigger than a feature to me. And I think this show has maybe even convinced me of that more that people are genuinely very excited for these models and what they can do and the possibilities that they open. And I think, Valentino, you've already given us a couple of good examples of how these things are used in the real world. And I think we're really just starting to scratch the surface. I mean, this announcement came out when I was on my way back from Rails World. So this is like not old news, right? So we're really just getting started with this. I think I know where you stand on this, but I'd love to hear your take as well.

SPEAKER_00 30:18

Decision trees and business processes have been a thing for decades. Yeah, it's a good point. This is basically just fulfilling that from an LLM perspective in a shaped type way. Yeah. I think it makes a lot of sense because of that reason, right? It fits right on top of that process tree already. And businesses have those shapes already defined. We have flows of users. This is how they matriculate into the system, this is how they use the system, this is how it applies to our business and outcomes for that. Businesses have all these shapes that it just like is literally a decision tree. It's beyond just customer service, which is what the chatbot was built for.

SPEAKER_02 30:53

Yeah.

SPEAKER_00 30:53

That even follows a decision tree. That's true. There's just so many things that have this need that got fulfilled, and it's obvious. I think the question should be were all of these companies using something like this internally and taking advantage of the fact that they had thought that they had an exclusive edge against the rest of the industry, and then it was exposed that somebody was doing this, right? And then, like, oh, I guess we'll package it up and release it.

SPEAKER_01 31:20

Either way, however, it got here. I'm glad it's here. And I think that it's fun to see these kinds of things make ripples in the industry. You see these news items come about, you see these kind of feature sets or brand new models come out, and then you get to see what people do with them. I wouldn't say that I am on the bleeding edge of that, but I love to watch the people that are on the bleeding edge, and then I'm kind of like the early adopter that comes along after that. I'm excited by what's here and what the potential is for us. And I think it's going to be a big part of how we shape our applications.

SPEAKER_00 31:51

New kinds of models are going to keep coming out. This one is great at decision trees. If you have a decision tree style problem that you need solved, look for one of these things, right? Yeah. Here is the solution. If there's very high probability of the outcomes of that, which you'll see right away, then you have a cheap and fast way, I think, is not being underlined enough here of solving that. That's a fair point. Yeah. Because these responses, they're like 10-15 milliseconds, some of them. Yeah. Getting that style of instant feedback on a decision from a model is just like wild when you play with it. All right. Well, I think we did enough damage for one day. This was a good one. Yeah. This is a good one. The age of decisions is what we've entered. Now we don't even need to decide on things. Thank God.

SPEAKER_01 32:32

I don't want to make any more decisions. I'll make the decision for all of you. Tune in again next week because we're going to have all new things to rant and rave about. And then coming up, either the next episode or the one after that, we have to look at the calendar. We've got Rick Van Michellen from the Museum of Modern Art. I think that's going to be really interesting to dive in and learn what's going on in the museum, which is a fully Ruby operation. Wow. You know, they do some real, obviously, like Moma.org does some real numbers and they're supporting it all on the back end with Ruby and a lot of AI. So we'll learn some more about that.

SPEAKER_00 33:03

Awesome. Yeah, I'm looking forward to that as well.

SPEAKER_01 33:05

All right, everyone. Thank you for joining us. Tune in again next week. We'll see you soon.

SPEAKER_00 33:09

See ya.