RubyConf 2026 - Opening Keynote by Obie Fernandez transcript

[music] [music] We're kicking things off today with someone who's helped shape the Ruby and Rails community for more than two decades. >> Our opening keynote speaker is a developer, entrepreneur, educator, best-selling author, >> DJ, >> and DJ and >> vocalist. >> Vocalist and really cool person. [laughter] >> Yeah. Handsome, too. Uh, get some devil. >> Yeah. >> All right. So, today as CTO of Zar, he's created a new way to pay and get paid.

Throughout his career, he's challenged developers to embrace change, keep learning, and think bigger about what's possible. Please join us in welcoming Obie Fernandez. [applause] >> [cheering] [snorts] >> Thanks guys. Hi everyone. Good morning. Hopefully you're having a great Ruby comp. I know I am. So I'm Obie and I write Ruby at a bank. Um that hadn't happened in a long time. But today I want to talk to you about being audacious. um and why I associate being audacious with Ruby.

[clears throat] In order to set some context, I need to tell you about what I'm currently doing. Uh the guys mentioned that I'm CTO at Zar. Zar is a is a startup. It's a couple years old and we are a stable coin banking platform that provides people in developing nations like uh Nigeria and Bangladesh and Pakistan with access to US dollars and a US dollar bank account in addition to other things that we do. But basically in those countries there's a lot of inflation and remittances can eat up a lot of your money.

So in those countries people depend on relatives abroad sending the money and sometimes the fees take up 10 to 15%. So being able to apply the good parts of crypto um namely stable coins uh to be able to move money around the world more efficiently and without those uh exorbitant fees is a really big win for our customers. So we're talking about real money, significant sums of money and kind of one of the underlying um foundations of the talk and one of the reasons that audac audacity comes into it is because there's real consequences if we write bad software.

So keep that in mind kind of as as I describe some of the things I'm about to describe. Um, I want to kick this off by telling you about one week this past June and then I want to spend the rest of the hour convincing you um about the theme of Audacity. So, back uh for for a while now, we've had a referral program and our referral program pays a dollar on every site of a new sign up. So like basically if you refer someone to use Zar when they sign up and they get verified as a real user they get a dollar and you get a dollar.

So you know for you in this room that's probably not that big a deal. You're not going to run out and start referring people to Zar for a dollar. But if you're somewhere like Bangladesh or Nigeria, this is extremely appealing for you. My clicker is not working. Oh, there we go. So, anyway, as word of this referral program got out, thousands of ordinary people started taking us up on our offer for a dollar. And it turns out that some of them were YouTube influencers and some of them ran Telegram groups with up to 40,000 or more members.

So, as masses of people started signing up for our referral program, this kind of took off. All of a sudden, we started noticing that there were YouTube videos popping up, not only telling people about the referral program, but telling people how to sign up over and over again and run things like app cloners to set up multiple instances of our app on their phone. And our phone uh uh our app does include biometrics. You have to scan your palm in order to prove that you're a human.

It's pretty cool technology. Um so we have evidence that um in some of these places people are literally running around their entire home or village or you know city block or whatever it is just grabbing random people to scan their palm. Now needless to say this works against the interests of Zar. Um, just leave it at that. So, before this wave and this, you know, viral burst, we were getting about 150 accounts per day and that shot up to 160,000 approximately at its peak in a single day.

Uh, so that's a quarter million signups in one week and 7 and a half signups per second, which was six times our previous peak because we had had some like marketing events and things like that. Um, in some cases we had device fingerprints that were carrying 60 accounts or more at a time. Uh, one physical phone verified 126 different palms. That's so it's literally one person running around with a phone and 120 different uh, people.

So anyway, I'm proud to say that our system did absorb a thousandx spike in traffic without going down. But Rails doesn't scale. [laughter] Uh so that was kind of cool. And I'm not going to pretend that we didn't have any issues uh you know dealing with this. Obviously there was agitation over the fact that people were abusing our system, but for the most part uh the humans did okay. Some of our AIs had a rough time with it.

I'm going to talk to you a little bit about how we use AI agents and uh how they're how they're humanized in certain ways. And uh our customer service agent uh his name is Vinnie. you'll meet him in a little while. And he handled the inflow of people uh started you know as this came up our intercom who uses intercom by the way can like by show of hands not that many people but it's a customer service app it's one of the most famous uh big scaling rails apps and congratulations to them for just getting uh I think bought for a lot of money.

Uh but anyway, if you have the intercom um interface open, it does a little sound effect every time that a new case comes on. So heard someone say, "Yeah." And that's how we knew something was going on actually because all of a sudden we heard bing bing bing bing just started going off. So anyway, that was that also represented our customer service agent going crazy and as pe as we started blocking people who were like grossly abusing our referral program, they started complaining a lot.

And uh our customer service agent didn't necessarily get it. So he started uh escalating all over the place um and screaming in all caps about people who were threatening to denounce us for fraud and things like that. But anyway, 10 engineers wrote this out. I wanted to show you a little bit of what Zar looks like just so that you can get a mental image of what I'm talking about uh as opposed to just imagining what it might be.

But anyway, this is our core app. Um it's a mobile app. It's backed by modular monolith. Um I think I have some stats here. Um oh, I'll get to that in a second. But anyway, the third screenshot there, um is representing one of our ground ground partners. our go to market since we hate giving Mark Zuckerberg money uh is that we actually recruit people on the ground in these places like Pakistan to go and sign up shops to bear uh merchants and so on and so forth.

So there's like a ground force aspect to it. There's commissions. It's pretty complicated thing. Uh this consumer app is written in React Native. We actually rewrote it from Flutter to React Native in a couple of weeks. So if that's your jam, if you work in that space and you want to know how we did that, I wrote a blog post about it probably about four or five months ago. Uh the back the back end is a big REST API, Ruby on Rails monolith.

Um that's pretty boring actually. I wouldn't get up here and like tell you about that Rails monolith too much. Um and the development of it, it doesn't look that much different than it did maybe six months ago because a lot of the things in that core monolith touch money. So they have to be carefully kind of crafted and reviewed and there's PRs and whatnot. Um yeah, so it's got u I don't know 190,000 lines of Ruby, 180 models, 10 domain specific Rails engines.

That's why it's a modular monolith. Um when I joined Zar as CTO in January, the monolith was already built and the mobile app already had hundreds of thousands of customers and was already doing its thing. What was wide open and possibly one of the biggest green fields that I've ever encountered in recent memory is the bigger and deeper layer that's underneath the customerf facing product which is the operations of the company itself.

We're not we're not a big company. We've been around a couple years and right now our headcount is probably at around 25 or something like that. Uh and we have runway for about three years. pretty good, you know, decent backers, but everything was very, very informal in terms of the operations. It was basically an app with a bunch of people running it. So, when I came in, uh, one of my co-founders, Sebastian, was kind of the lead architect of the core monolith.

And I said, you know, you keep running that part of the house, and I'm going to run a plat I'm going to create a platform for automating everything that can be automated about the operations of this company. >> [snorts] >> So that bridges me into the rest of the talk which is that I want to show you what imagination and audacity in six months and Ruby can actually uh come together. Uh and I'm specifically even though we have half a dozen apps internally that we've developed to run the business uh and to run different aspects of the business, I'm mostly going to be talking about three.

And if you listen to some of my comments in the panel yesterday, uh you would have heard me talk about kind of like three uh core elements to being able to have an uh agentic future or whatever it is I was talking about. Uh one is a knowledge graph and we call that nexus. One is an orchestration platform called Agora and one is an event mesh called Aventus. So I was writing this stuff by myself. I think even a year ago, maybe even seven or eight months ago before everyone kind of collectively over Christmas realized, holy cloud code is like this real thing.

I think anytime before that, if you had looked at the scope of these apps that I'm describing and said to any reasonable person, what would it take to to write any of these things? Any single one of those things could have been six to 12 months effort with like traditional team or teams of people doing it. And in fact um even though it never occurred to me to buy any of these things, I know for a fact that to some extent uh at least two out of the three things I'm going to describe to you, there are viable commercial offerings for them.

And there's like dozens if not more startups that are focusing specifically on these things, right? Like have raised money for it and everything. But that never crossed my mind. I was really excited about building something as a whole. Um so anyway, I handrolled the infrastructure. Uh Nexus is a knowledge graph like I mentioned before. Rich uh and I got excited talking about how Nexus is backed by an RDF triple store uh called Oxygraph. you query it using sparkle.

These are words that if you are not familiar with right now, you might want to investigate because I think it's part of the future of where we're going. Uh because it lets you build a memory or in some cases, you know, you could think of it as a brain uh for these upcoming systems. Importantly, Nexus as our knowledge graph lets us fire off events into our entire system when it detects that certain things have happened.

So, it's kind of like when your brain realizes that something is not what you expected, that's kind of an exception case, or it detects that a particular thing you were expecting to happen has now happened. It's able to detect that from a description of that thing and fire off an event into the mesh for someone uh in this case as not a human, but rather an AI to do something with that. So, we got Nexus, we got Agora, which I'm actually going to show you some screenshots of, so I'll skip past that.

Uh, and Aventus is our nervous system, our event mesh as I call it. So, Claude helped me write this talk. I'm not going to pretend that it didn't. And they helped me make these beautiful uh slides. And it told me that at this point I should make a confession about how um you know this was all kind of crazy and I you know had doubts about like whether I should go this way and you know I wasn't actually going to confess anything.

I mean I never heard that voice. I've been making audacious and kind of potentially stupid decisions regarding technology for 30 years. It was not smart to go all in on Java in 1995. It was arguably not the wisest thing to do to go all in on Ruby in 200 late 2004, early 2005. Um, but I've been making these kinds of like decisions my whole life. So AI has only increased uh to some degree my audacity. And one of the reasons that my brain works that way is because really early on in my career, I internalized the philosophy behind Kent Beck's expression.

Make it work, make it right, make it fast. Priceless, priceless words, right? Like I got involved in the XP user group u mailing list back around late 99200 when it started and this was the mentality of original agile, right? It was like basically stay close to the stakeholders, make some sort of solution that satisfies them that works, but it doesn't have to be perfectly planned right up front, right? I'm not going to spend a lot of words on that because I think you're kind of familiar with what I'm going at.

But the thing is that with AI, make it work is often now one afternoon. The the space between having an idea and actually coming up with like your initial solution that might be bugridden, that might not scale, uh that might be you know actually wrong for some, you know, a lot of the edge cases. um you can still get that done very very quickly, right? And where you earn your keep um as the people in this room who get paid hopefully decent amounts of money to do software engineering is in the judgment uh that comes into this stage which is where you you know you make it right so to speak.

So then you consider how this thing's going to break uh how it's going to perform under load where the bugs where the edge cases you iron out the bugs. Sometimes that means uh figuring out the correct abstraction, sometimes it means a rewrite. Um but in any case, here you're applying the knowledge that you have from production incidents and from seeing things in the past that worked or didn't work. And our new reality is that make it fast can actually wait.

Right? So in a lot of cases because we're able to be so responsive. I lived this time and again over the last six months, including when we had those big viral bursts, right? So, a lot of the things that we had weren't actually ready for thousandx traffic, but in some cases, it was 5 10 minutes on cloud going, okay, [snorts] you know, this particular instance of something is falling down. We need to improve it. And then little while later, it's fixed.

There's kind of an evolution, I think, um, of those nine words. make it work, make it right, make it fast. Um, and I think potentially I propose we use this instead of like the oneman framework, uh, you know what it is, but the whole owner style is where you take ownership for those three stages, right? So like it used to be that maybe you needed specialists at every stage, right? So like maybe you needed specialists in terms of product managers and and designers in terms of the make it work coming up with some sort of viable solution and then you needed senior engineers for the make it right and then you needed like super high-end specialists for the make it fast like people with very specific experience but now you can kind of just do it that all yourself.

So anyway, let me get into the actual implementation of this Audacity that I'm talking about and I want I want to focus specifically on these systems uh that we built. Right? So act one is the event mesh. I didn't mention them in this order in the beginning but I want to talk about the event mesh first because it's actually I think one of the coolest parts of the system. [snorts] So um think of Kafka or Rabbit or something like that something that processes pub uh style uh computation.

So I had something like that in mind and I was I also had in mind like ingesting all our web hooks through one system because one of the pain first pain points I ran into is like we had web hooks over there and over there and like you know it's kind of chaos. Um but the ingestion was the table stakes if you will. Um, what ended up being super cool is that once I tied this event mesh to things that wanted to use the event mesh or event bus or whatever, do the pub sub, instead of writing a specific DSL or making it um coupled to like maybe channels or event names or things like that. uh I came up with an intentionbased subscription and what I have here on the screen I don't know how readable it is looks like it might be readable is the description of the MCP tool that is used when an AI agent wants to subscribe to an event on the event bus and the part I want to highlight here is that it's a dialogue our agents when they when we tell them via chat or whatever to listen to a particular event, something that's happening in the business.

And literally anything like we can key off almost anything in the business. It can be do something, wake up if someone is out for the day, wake up if a transaction exceeds $10,000, uh wake up if we're having an active production incident, stuff like that. So that subscription instead of happening like with parameters, it happens as English. And there's a back and forth um because in some cases the aventus will say hey I need clarification so it will send questions.

Um a classic clarification is would you like um to have events echoed back to you that I think that you caused. So a lot of our events have to do with our ticketing systems and project management for instance. So like if one of our AI agents files a ticket and is listening for ticket events, the event bus for instance can say, "Would you like to hear about your tickets?" Probably not. And then the agent can say, "Yeah, no, I don't want to know about my own tickets.

Don't wait for that." Um, here is a little bit of code related to the service that um actually does the translation of the intent as it comes in. So there's a process that turns the English of course using an LLM into some sort of logic. Um but what comes down what gets compiled out of this is basically cheap SQL. Everything's backed by Postgress in this system anyway. So as the events are coming in they're getting filtered and channelneled to the different places that they need to go by SQL that is generated by those intents.

And some of you might be thinking okay do like do you have to run lms for every single you know you need to burn tokens for filtering some of these things that you can't do in SQL and the answer is no because we actually generate Ruby code on the fly and this is a key part of what makes event special. So at the different layers of the event system at the very top of it when events are coming in and we need to write uh essentially classifiers that figure out what those events are that's generated Ruby code.

We transform every single raw event that comes in uh every web hook everything that happens in our core monolith into a standard shape to make it easier to reason against them. So that's a that's a transformer that's generated Ruby code and like the example on the screen right now if someone actually if a you know subscribes with an intent that has some sort of criteria in it that can't really effectively be uh expressed in SQL because maybe it's digging into some JSON payload then uh some Ruby code is written in there and the Ruby code is not eval.

It's actually loaded uh at runtime in the production system. >> [snorts] >> It's sandboxed. It's stateless. It's very fast. Um, when the LLM is writing the code uh to load, you know, to handle this stuff, it actually has self-healing properties in the sense that, um, we use instruction sequence to compile the code and figure out if there's errors and then we loop. Uh, and this is actually what a lot of the code that you write in Ruby and AI looks like.

It can actually be surprisingly very very short and effective. It's one of the reasons I love Ruby for this kind of stuff. Uh this was something that I got a cool uh thumbs up from Prag Dave yesterday. So I've considered that to be a feather in my cap. So um we do things that would be I think un literally unimaginable in the sense that you would get a blank stare or uh an aggressive response from other programming language people.

I think uh in terms of the meta programming that you can do in Ruby to actually make things like this possible, right? Like I I was I asked Dave I said can you think of any other language that you could do this in? And he said well maybe JavaScript. And then we scratched our heads and thought about it for a while, but you know, maybe maybe not. Um, so that's Aventus and the event mesh and generates code. And ACT 2 is the fleet of uh agents that we run.

They're they're not chat bots like [snorts] my first uh AI startup a few years ago were was AI employees. This was way before it was feasible with the state-of-the-art. Uh but those were chat bots that you would talk to and now what we've been able to realize is actually um autonomous agents very much that that work kind of like people. So we we call them legates and I want to show you the uh let's see the dashboard uh that the Rails app that runs the the agents is called Agora.

You can see kind of some of the basic statistics there. I wanted to give you an idea of like how much token spend we're talking about. So almost $25,000 in the last 30 days. Uh how many active legates there are. Uh how many missions are running. Those are roughly equivalent to cloud code sessions. Uh how often they succeed. The one in the top right corner there is kind of interesting. Interleate DMs. So, we use um our we use something called Mattermost, which you might have heard of.

If you haven't, it's a really cool Slack clone uh because I don't like Slack. And um the way that our agents talk to each other is essentially they slack each other over DMs. Um and in some cases, they get blocked. If you see the little red letters there, there were seven conversations blocked in the last 30 days where one agent was like, "Thank you very much." And the other one's like, "No, thank you." And then, "Thank you." And this just keep going.

So, we do have logic in there to block that. Um, other interesting things, um, that feel kind of Ruby adjacent at the very least. So, whenever a legate is born, um, we give it a personality. And I went back and forth about whether I needed this, but I but I did notice that, um, if you have more than one agent in play and you're talking to them on a regular basis in chat, it is actually helpful from a practical standpoint for them to have different personalities because you you start to like kind of ass blur together.

And if you have one or two agents, that might not necessarily make sense. But if you have 37, uh, then there's a whole bunch of subconscious processing that goes on when you look at a chat that I think at a subconscious level, you kind of recognize who's who you're talking to. Uh, so there's also evidence uh, and there's some white papers that suggest that this actually makes them smarter to to have personalities. You might say, "Well, that's weird because isn't this a distraction from their context?

Isn't this like extra tokens?" And turns out it actually works pretty well. Uh, and this is my crew. So, they all get cool pictures uh that are autogenerated. Um, some people don't like personalizing AI agents. They don't like humanizing AI agents. I think it's the bomb. I think it's really cool that I can recognize Vinnie or Lana. Len is the one in the middle. And if you could zoom in uh to her picture, she's got a whiteboard with like little uh story user stories up and you know, things like that.

And her mug says Zar, you know, whatnot. So, a lot of cool fun you could have with this. Um you know, this is not a swarm. We we do think about them as people on the team. This is Vera. She ensures the integrity of our growth partner network. So if you flash back to the screens where I said, "Hey, we we recruit people." So when we recruit people on the ground in Pakistan, in Bangladesh and whatnot, they have to submit a fairly long like nine or 10step application and then they have to post a video of themselves actually going out and doing something.

We use this to screen candidates to say, "Are you actually going to go out and do the thing that we want you to do?" We get hundreds of these a day. So if we had to have people kind of sitting there and evaluating them, it would be expensive and it would be slow and it would be errorprone. Uh but Vera actually do does a really good job and she can watch the video by using a Google LM and uh she can apply rubrics that we change on the fly not by deploying anything but simply by talking to her and she model she changes the skills uh that govern her behavior.

Uh so the the reason I'm talking you through this is so you get a sense of like what this future that I think a lot of you are destined for looks like you know where we're working with these kind of artificial uh entities. Um so uh also backed by by Ruby um an event you know the the events as they come through the mesh the reason I talked about the event mesh first is because a lot of the useful ways that the agents wake up so to speak and do something is because they get triggered by an event.

So, in the case of Vera, who I just showed you, she gets triggered when someone finishes sending a uh an application through the process that fires off an event and its payload has like a link to the video and the answers that they put in the form and whatnot. Um, so I wanted to show you some code for that. Uh, but I think that's a little boring and I want to go a little faster. So, [snorts] um, the leg wakes up. it does a run.

Uh we we do lean on cloud code for a lot. If you're thinking, hey, this looks cool OB, I want to work on some of this stuff myself. You don't necessarily have to write your own harness. Um one of the ways you can accelerate development of this kind of thing is just to lean on cloud code. So a run um meaning that a legate woke up especially if it's waking up to follow up on something that happened before you can think of it as kind of a continuation of the same conversation in a claude code session because literally in the in the background of Agora that's what's happening there's a cla code session that keeps getting continued resumed uh you know to do to do more stuff.

So um a legate can also schedule itself to wake up in the future. Uh we have we called our autonomous agents legates. I'm sorry I didn't say that before but like if uh if a legate is working on a PR and um it wants to wait uh you know to see if the PR was actually reviewed by someone and accepted before continuing. It can schedule itself to wake up like let's say an hour in the future. This was actually one of the first things that we used the scheduling the self-scheduling for and it led to a funny situation where one of the first PRs that one of our legates wrote uh he actually put it out there and then he posted in the Slack and was like hey I did this PR I'm really proud of it something along those lines actually I'm not exaggerating and it was like can I get a review on it and then two hours passed by and he was like I'm still waiting for a review on this uh PR I really hope that someone can look at it day and then like an hour later he's like really really need to ship this.

So you get some really funny emergent behaviors from it. Um so anyway this this is happening through mattermost uh which is our chat. Um, and escalate. I I I wanted to to sneak in here that the reason that I can sleep at night even though there's so much stuff in my company that's being handled by AI is because they escalate, right? So like if there's something that they can't handle, uh I have Len as a project manager, right?

So she escalates to me all the time. Hey, so and so is not responding to me. just like a typical kind of project manager, you know, it's ignoring my DMs uh and whatnot. Uh escalation is a tool that is used that keeps humans in the loop. Um, [snorts] but there's also other things that you can do which unfortunately I don't have time but find me if you're doing this sort of thing where if some of the processes that your autonomous AI agents are doing are mostly deterministic that doesn't mean that you should disqualify an agent from actually working on it.

There's ways that you can actually give the agent the ability to create deterministic scripts to handle the events that it's responsible for. And when those scripts execute and they have some exceptional case that now needs to be escalated uh your agent can actually detect that that happened and take over. We do this with um Vera who handles our growth partner applications. In many cases a lot of the growth partner applications can be just sumearily dismissed by deterministic scripts by programming.

So we tell Vera, hey, take the parts of your job that don't require tokens and write a script to handle it. And if that script fails because of whatever, then you handle it. It it means that there's a lot more potential to using agents in this way than you might realize at first blush. Um, how much time do I have? Doing well. So, I have a little war story that's kind of funny here. Um, so we had a semaphore that was guarding how many times uh a legate, an autonomous AI agent could wake up at the same time.

So, one of the cool things that legates can do that us humans can't do is that they can clone themselves in the sense Vinnie handles a lot of customer service requests. So, up to 42 Vinnie instances can run at the same time. in the same workspace. But the first version of this, the make it work part uh used a semaphore and it was probably not a very good logic, right? So it would decrement um when one thing would start and then it would increment on finish and whatnot and that's how it kept um track of the limit of how many things could run.

The thing is that those are hard to keep from drifting from reality, right? So the make it right part which involved you know probably an hour or so of cloud code uh was to make sure that when a deploy killed our runner process or you know something blew up um we weren't actually trying to keep track of that with a bunch of like counters and stuff like that. The correct way to do that is actually more like Kubernetes which I don't want to dive into the details here but is basically to let reality dictate what it is like look at okay how many things are actually running uh and go through it.

So going to run through some of this a little faster. So, so far act one was the event mesh. Act two was uh Agora where our agents live, our legates, and act three is to make the company remember. Now, even though I put this as act three, if some of you follow me on my blog or if you go look on my blog at December of last year, this was the very first thing I I wrote when I joined Zar. Uh we called it Nexus and I talked about in the blog and how cool it was.

But basically, I knew that if we were going to do any sort of aentic vision, I needed to capture as much information about what was happening every day at ZAR right away. It was like the first priority. So, um, sorry. Second, uh, Nexus, it's about 90,000 lines of Ruby. It's a Rails app. Um, like I mentioned before, it's it's on top of a graph. Um, essentially everything that happens that's written down in the company and that includes every single cloud code session that all of us work on every day.

Uh, every single Google meet uh, meeting transcript, every PR in GitHub, every chat conversation and thread in our Slack and uh, many many other things including like web hooks and and whatnot. They all flow into this one knowledge graph. And as they flow in, we use an ontology that defines classes to detect things, if you will, entities in the lingo of anttologies that we care about. So examples of things that we care about are decisions, features, bugs, goals, and then we have some generic ones too like concepts.

And at one point we realized, hey, we really want to be able to describe things that aren't features, but that are a thing, if you will. But concept was a little too broad. So we're like, oh, what we're talking about is abstractions. So now Nexus captures abstractions and it logs those, right? So abstractions can correspond to like, let's say, patterns in your code and whatnot. So all that stuff gets remembered, but it doesn't only get remembered as they are detected and they're added to the graph, they also fire events.

So it means that as they fire events, you can let wake up AI agents to process those events. Um, so anyway, super super cool stuff. If you're not already using something like this, I can almost guarantee that you will at some point in the next couple years. Um, again, it's a Rails app. Uh in this case um I wanted to show a little bit about what an ontology looks like uh you know in terms of Ruby. Uh if you haven't worked with RDF and triples some of this might look a little bit strange.

Uh but you can also think of it a little bit as like schemaless classes in the sense uh that exist in a graph. So for a particular class in this case decision uh it's got a description and it's got certain properties. We try to not go crazy with the properties um and it's got certain relationships which are the arrows in the graph for how this uh relates from one thing to another. The anttology compiles itself to al you heard Rich yesterday say hey tell your kids to learn AL or something along those lines.

But yeah Al is really really cool. every version of Nexus uh Nexus's ontology is captured as owl. This is essentially like almost like the DDL of that uh database. Uh so because Nexus is used very very uh extensively by all of the AI agents in our system. Uh it would get very expensive to just have to be calling a lot of meth tool calls like over and over again. Every time that the AI hits Nexus and says, "Hey, I want to do this query." and it gets a bunch of stuff back and then it filters through some of the things it gets back and then it drills down again which is the most common way that it works.

It burns a whole bunch of tokens. Right? So at some point I was like, okay, what would be really cool is if the agent was able to send up Ruby code to get executed on the Nexus server side and do whatever it wants to do and then send the results back. So that approach is called code mode. The most famous I think code mode implementation that's been described on the internet so far is from Cloudflare. If you use Cloudflare, you know that their API is really really big.

And they claim that if they were to do an MCP interface to their um entire API, just describing all of the tools that are available in that API would consume two million tokens, which wampwamp is bigger than the context that you have uh on almost all the models and certainly the models that we use. So code mode uh lets you circumvent that and we take advantage of it and Ruby happens to be a really really good language.

It's funny, you know, I I don't have scientific proof of this, but from time to time I do end up having to write some Python or maintain some Python and try not to stab my eyes out. But um Chad was kind enough to give me a a program thing, a repo uh for building presentations and I and he wrote it in Python for some god unknown reason. And I as I as I was making some changes to this thing, I actually noticed that on more than one occasion, Claude made syntax errors that it didn't that it then had to fix with Opus 48.

And I was like, hm, that's really funny cuz I thought Python was like the language for the LLMs. And I swear to you, again, I don't have scientific evidence of this, but I swear to you that Opus 48 for me never makes syntax errors with Ruby. I don't know. So, that's code mode. Um, I'm about to make you guys cringe perhaps because code mode does run through Eval, doesn't deploy code. And you might say, "Ruby that an AI wrote on a production system eval.

[laughter] What the Are you crazy?" No, I'm odacious. [laughter] Um, obviously there's some techniques here. You know, you run on basic object and whatnot. But there's a takeaway that I want that I want you to take away that I learned from this in the stage from make it work to make it right which is that um if you're if you're going to do something like this don't try to do a deny list or blacklist you know do an allow list like basically limit the Ruby that's gets sent up to just very very specific things and the way that you can do that very effectively is by scanning and I'm pretty sure that I have an example of the scanner here.

The reason I realized I needed to do this is because is kind of a funny story. So, I went through a couple of iterations and this is what happens when you're going from make it work to make it right. I went through a couple of iterations and one of the first things that I did for security of this approach was to have an LLM look at the code that was being sent up and say, is this safe or not? uh which is kind of a naive uh but you know fun approach to see what would happen and the thing was that there's reserved words that I had told the LM don't let the Ruby code include some of these words but those words existed in the queries that were being sent up in Sparkle so they were getting denied so I had a bunch of frustrated agents that were trying to use this interface and they were getting denied not because they were trying to hack the system with Ruby but because there were reserved words in the queries.

So, it's really fun to watch emergent behavior happen and these things remember and they share the the agents share memories with each other. So, what actually started happening is that one of those agents figured out, oh, if I base 64 encode my query and then I unpack it on the server, I can get the payload up. And it was doing that very authent like very innocently like it know it knows that it's not trying to hack the system but I happened to be watching when a bunch of this stuff happened and I was like oh that's probably not great.

They're just trying to get their job done but that's uh you know I needed to to do it a different way. So rejected by default with an allow list is the way to do it. And the nice thing is that Ruby gives you Prism and it gives you really really easy ways uh to do you know a uh evaluation. So you really can't talk your way past the grammar the fact that we're analyzing that code in that way. Um right so let's go here go through this.

So when you connect these things, this is where the systems become, if you will, one machine and uh becomes really really powerful. Um and it's hard to explain this like you you almost have to sit through uh you know hopefully an abbreviated version of what I've just been telling you to like kind of get how this is really really powerful. Uh I alluded to it earlier. Essentially, if you have something that's able to observe and detect everything that's going on in your company and you're able on the fly without having to write code or deploy systems say, "Oh, you know, we'd like to start observing uh a particular customer behavior." And you describe it in an ontology or the one that I'm about to roll out probably next week is that sometimes we talk about production incidents in our Slack.

So, I want Nexus to be able to recognize that there's a production incident going on. So, I'm going to add it to the anttology. I'm going to define this is what a production incident looks like. And Nexus is going to start recognizing that we're talking about a production incident. when it recognizes that, it fires off an event that goes through the event mesh and it wakes up an AI and we can tell that AI, hey, if there's a production incident going on, um then you should not treat um customer service events that are coming in in the same way as if we had normal uh situation going on.

In fact, maybe you should hit the intercom API and actually put a little banner up or whatever the case may be. Now, normally doing some sort of process like that, and in fact, I'm willing to bet a dollar that, you know, at least one of you sitting in this room has done something like that at some point. You know, it it would normally take programming and deploying and TDD and tests or something, you know, whatever, and like getting it out to production, that's actually valuable time.

But what I just described to you, I could literally sit down at Slack and type it out and it would just happen. that applied across pretty much almost every operation uh that's happening in your company. That's pretty audacious. So in June 2026 uh we finally connected Aventus like you know basically been in the process of making the whole thing work and our events went up 10x and we started spending a lot more in tokens but it also unlocked a bunch of things that we had been wanting to do like the growth partner application process like checking things for fraud a lot more with 22 people including 10 engineers we're actually operating at a level that I think realistically in the past would have taken probably hundred or more uh people to do.

So, it's pretty insane. One of the reasons that I'm able to do this um and one of the reasons I think Zar is so special is because Brandon, our CEO, does a lot of vibe coding. And one of the main takeaways I want you to take away from this talk is that having a vibe coding CEO, is actually really cool. It's not something to be afraid of or cringe or leave the company for. and it doesn't represent necessarily a pain in your ass, right?

Um Brandon is not a programmer. He would not say he's a programmer. He's very much a CEO. He had a he he had a successful bank in in uh in Pakistan, which is the reason that we're ZAR. Uh but he loves vibe coding and he's I from the very first day I came in, he was like, "Look at this ad manager I vibe coded up." Now, if an average person fires up cloud code and starts vibe coding stuff, chances are it's going to be Nex.js and Verscell kind of defaults to that.

And there was no there's no different here. Uh so he was building kind of apps and things um to do business uh things that we needed. One of the great things about vibe coding when you said not in a derogatory way is that it it's literally shrinking the distance between the business stakeholder having an idea to the implementation of it to to zero. Right? So, a lot of things that we learned and internalized, uh, those of you that are were around and kind of really bought into extreme programming and scrum and agile and those kinds of things were about trying to faithfully and uh, you know, iteratively capture what the stakeholder actually wants and deliver it on it.

But in this case, the stakeholder is actually giving you what they want, you know, as as a thing that's real. And I did cringe at first because he was writing this in Nex.js. And to the extent I have a little bit of NexJS uh experience, I don't really want to remember it, but the the things he was building were significant to our business, right? So, like we have a creative team that makes ads and they're making a bunch of ads and he built a video processing pipeline to automate the creation of ads and uh to uh narrate them and to render them and like all this stuff.

He created uh a fraud analysis thing which I'll show you in in a little bit uh to detect clusters of referral networks and mules and sweepbacks and things like that. Really really fancy stuff. Um, one that we really needed that was literally nine days between the time that he vibecoded it to the time that it was fully in production checking every single uh person that signed up. Uh, is called Indicium. Um, and this is a little bit hard to see, but uh, and unfortunately I didn't have time to make a video, but this is like a full WebGL graph navigator where you can click all the little uh, clusters or you know dense dots there are little fraud networks where people are signing up and sending money back and forth to each other.

And uh, using this uh, forensics lab, we can like go in there and actually figure out who the worst culprits are and focus on them. um WebGL and you know be able to navigate it is cool but of course this also had an MCP interface and the MCP interface lets bidding for instance go and check when a customer complains about something are they part of a fraud network because if they're part of a fraud network then we don't want to spend time servicing their customer service requests right [snorts] emergent behavior that either simply wouldn't have happened or would have cost, you know, in some cases hundreds of thousands of dollars to implement with real teams.

Tying it back, this is Ruby comp after all. If I haven't convinced you so far about why Ruby, uh, I did want to just like take this home, you know, uh, the reasons. So, code is so cheap and we keep having panels. This is not the first panel I've sat in where we've talked about the future of programming and is it even going to matter or like Dave said, where's Dave? Uh he said, you know, what is programming, you know, or whatever.

But I think language choice is alive and well and it does matter. Uh and I do think that we have the best language in the industry for all of this stuff that I'm showing you for. And I and I have actual reasons, not just feels for why Ruby is the best language for this moment. Uh so the first is the machine side. Um as many as you know a handful of you here might hate to hear this rails is the dominant thing in Ruby right and 20 years ago when Rails was born convention over configuration was about sparing you decisions and it turns out that by you know I guess by historical accident that's the perfect approach to take with an LLM powered coding agent. you narrow the path uh that can be taken by your agent and you get much better results.

You get much higher intelligence and Rails apps are usually I'll add that excla you know that disclaimer the least surprising kinds of apps that you can find in the world. Practically every Rails app looks pretty much the same, right? They all follow the same formats. I hope um you know they all have models. They'll have controllers and if you tell a model you know an LM model coding agent only practice strict restful architecture it will do it like it knows what that means in the context of a Rails app and it does it really really well in the context of a Rails app.

I haven't tried but I'm guessing that it wouldn't do it as well in terms of a Nex.js JS app or you know something else. It it really really understands those guardrails are there. And second um and I I feel like giving thanks to Matts every time I see him for this readability is now a safety property in a way. And it's not just about the joy of programming or whatever. is because of a reality that many of us are actually having trouble and having indigestion about, which is that we spend much more of our time reading code now than writing code.

We sit there and we review PR after PR after PR. And the fact that Ruby is so readable is actually part of why that doesn't drive us out of our freaking minds. It it is harder to read uh other languages. It is harder to I can tell you from experience it's harder to read Typescript right where you have a React Native mobile front end. I do sit there and have to read some of those PRs. It is more difficult to figure out what's going on.

That expressiveness um really really paid off. So Matts, I don't know if you're in the building, but uh thank you again. Let's let's round of applause for for Matt's [applause] 30 years early in optimizing for AI. Amazing. Um, of course, the theme is Audacity. I just wanted to throw this in there. I couldn't fi find a place to to fit it in, but um, we don't use staging on our internal apps. We I had a staging environment for our for agent for Agora, our agent platform, and I ended up deleting it.

Uh because you can go from make it work to make it right so quickly. It just turned out that it was it was an obstacle. Um yeah, I'm going to go through this a little fast so I can have a little more time. The oneperson framework became the oneperson platform in a way. So, those of you that just hate DHH with a burning intensity of a thousand sons, uh, you don't have to use that expression anymore. You can say the oneperson platform.

Um, yeah. So, um, couple more things. Audacity is not recklessness. I I said in the beginning and I'll say it again. Our core monolith, the processes behind it, pretty boring. uh the parts that deal with money still look very similar. Sometimes people say, you know, is AI going to change programming completely in the next year or two? I'm like, no, still a lot of things in the real world that deal with money, people's lives, you know, safety, whatnot?

I think those things are going to look pretty uh similar. I was talking to Dalma yesterday and she works uh at at a government agency. I was like, can you use AI? And she was like, no. So I think a lot of that inertia will will continue and and still be very necessary. And um another thing I want to touch on is that when I say 47 artificial employees, you know, autonomous AI agents, some of you and right probably rightfully so will say, well, what happened to the h what happens to the humans?

You know, like are we going to lose our jobs? And I think in this group, we're actually really lucky. Most of us are not going to lose our jobs. In fact, I think there's going to be more work for us than ever before. But I do think this is going to decimate white collar jobs in a lot of ways. Uh because even though our fleet is doing a lot of work that I would just say, you know, that I would say that we wouldn't be able to hire for anyway, uh because it just wouldn't be in the budget.

There are things that we could hire for that we are using autonomous agents for. So customer service, project managers, uh extra development hands, so on and so forth. So it's a thing to reflect on, right? A little bit sobering. Um yes, there's cost to this. Um not everyone's going to be able to afford to take these kinds of approaches, especially not now with what tokens cost. That's also a little bit sobering. If you remember the dashboard I showed you, it's like I think it was like at 25,000 for the month on spend.

That's probably going to double in the next quarter easily. It's not something that everyone can can do, but um yeah, real briefly, uh I want to plug the fact that I wrote a book about this stuff. It's called Patterns of Application Development Using AI. And uh even though no one reads books anymore uh so it might be a kind of a dumb effort. I did I am upgrading it to the second edition. So if you're interested in the kinds of things I talked about and the way that my brain works on these themes in a lot more detail, there's a second edition of patterns of application development using AI coming out actually on Addison Wesley.

So I'm back to my original home of the Railsway. And by the way, thank you if you bought the Railsway back in the day. I feel like I wouldn't be up here if it wasn't for you. So, okay. Uh, since I just plugged my book, I want to give back to you guys, uh, and girls and furries. Can we laugh about that a little bit? Okay. Um, so yeah, I wanted to tell you about open-source um, projects that we're creating at Zar. Uh, I didn't try to put QR codes up here because it would ruin my artistic slides.

Um, if you go to GitHubzarp and you look at the open source projects, I'm going to show you the majority of them here. This is probably the coolest one. So, what PRAIS is is a llinter and a compiler for your code. So essentially if you've if you've ever thought there I wish I had a step up from rubocop like a Robocop or something like something that actually could lint my code but in a smarter way that wasn't just based on syntax.

This is what practice is. So what it lets you do is to drop a readme into any of the folders. And this doesn't have to be even uh just code. You can drop this into any folder. or it can be documentation or or whatever your novel maintain character consistency. But basically, you drop a readme into any folder and then you run the practice CLI llinter on it and it will go through and it will use an LLM as judge to make sure that the contents of the folder actually adhere to the rules that are expressed in the readme.

So, I'll let that sink in for a minute. And it it's actually pretty well uh architected. is the brainchild of my co-founder Sebastian who is a really really bright person and it caches the results and it does a whole bunch of smart things so that this is not slow because that would be the downer about doing this on every single file uh in your codebase. So that's practis and the other cool uh really really cool thing [snorts] is that uh it's not only a llinter you can also turn around and use the same information that you put in those those readmes to compile an agent profile that you can then load into cloud code or into your autonomous agent uh network that conveys the information that's uh captured there.

So if you go through the effort of creating readmes, let's say for some complicated part of your codebase, you can use it for linting that codebase to make sure that it's accurate and you can also use it almost like a skill uh in the form of an agent profile in your uh cloud code. Gravis some of you might have a use for this today. Uh, in fact, so um, Agora spins up, um, a bunch of things and sometimes they're heavy.

Um, we do video processing and video processing is super heavy. Uh, and we use the solid trinity, I think is what you call it. So solid Q, etc. And what we wrote Gravis for is so that every once in a while when we have a job that's actually like requires a huge instance instead of having to size for that or go through autoscaling and whatnot, Gravis lets you like dynamically scale from zero to like a huge instance just to run one particular queue and then it goes away.

So it's like super simple uh you know kind of brain deadad concept but uh tricky to implement. If you work on AWS it spins up an ECS Fargate uh you know but check out Gravis and a couple more. Um I feel like there's a divide like some people really like services in their Rails uh code uh and some people really don't like services in their Rails code. We actually like services and we think one of the ways to actually provide really cool guard rails for agents working on your your Rails apps is to really really regularize the shape of your service classes.

So these service classes basically do almost all the business logic in the Zarore uh monolith. Uh in some cases they're the steps in the workflow or the event handlers that are built into the monolith. And what service gives you is is a way to to make those really really tight. So they're always called in the same way. They have a JSON schema associated with them so that you can uh define you know type make type safe basically input and output of them.

A lot of benefits. So check out service if that sounds interesting. And finally amounts uh which I think is just like notably missing from the ecosystem. Probably should be rolled into Rails or or maybe even Ruby itself. Um what amounts lets you do sorry got a little lost here is to um define quantities of fungeible things. Uh so for us given what we do fungeible things are dollars or landports or satoshi's or ounces of gold whatnot.

So amounts gives you a way to very very easily portray that in your database in ways that are resistant to bad conversions, right? So like if you're using amounts, it literally does not let you convert from one unit to another so that you don't treat LAN ports as dollars because that would be really bad. Uh so basically gives you a type registry for the converters. And finally, and this is my this is my favorite one.

I just open sourced it uh this week specifically for Rubicon for you guys and girls. Rails template is what I built for my CEO. So if you remember I said my CEO was vi coding a bunch of Nex.js stuff. So after the second app that I rewrote from Nex.js to Rails, I said, "Hey, why don't you just do Rails instead?" Uh so I made a template and what this template gives you um is Rails Edge Ruby 401 solid trinity and it's agent native out of the box.

So it includes 32 curated cloud skills uh 17 path scoped rules meaning that they apply to specific parts of the Rails app. Um and the the scaffolding is all set up uh with our house style. So service everything oth is pluggable. Uh really really cool. Uh it's kind of ready to to roll out on AWS CDK. Um yeah we call this Machina. Might want to watch this space because I think we might be doing some more things with that.

And actually I wanted to yeah I wanted to ask you guys so I've described Aventus the event mash nexus the knowledge graph um Agora the agent. So by a show of hands, how many of you would be not only interested but feel like you would actually uh clone this, you know, fork this and like run it in your company if I open sourced any of you know. So let let me do them one at a time. So Nexus, the knowledge graph, raise your hand if you would actually like fork this and use it.

Okay. And Agora, the agent orchestration framework. Few and Aventus the event mesh. A few more hands. Okay. So, I'm not going to open source it. Yeah. So, wrapping it up, um, be audacious. Your shelved idea is now a six-month uh that you thought was a six-month project is, you know, now practically free, right? The cost of doing the things that you dream about has dropped to almost zero. Um, depending what you're into, what you dream about might be reducing technical debt on the thing you use at work or it might be some silly project uh just for fun.

Um, why the lucky stiff was our patron saint for a long time might still be to some of you guys who remember. Um, you don't have to really ask permission, you know, to your engineering manager or to yourself anymore. There's a lot of these things you can do. The very very first project I ever did that I got paid for rather that Thoughtworks got paid for back in the day in early 2005. Some of you may have heard me tell this story over the years was a Java project.

I didn't have permission to write it in Rails. I had asked if I could write it in Rails. This was March of 20 2005. I said there's a new thing called Rails. It would be really good for this project. Could could I use Rails for it? and I said, "No, of course." So, I wrote it in Java, but I also wrote it in Rails at the same time. And then through one thing or another that I can't get into here, the Rails app ended up being so cool that the engineering manager said, "Oh, let's let's go with that." And that became the first Rails uh project that I know of that was actually rolled out at a Fortune whatever at John Deere in Atlanta uh in early 2005 because I didn't ask permission.

And that was back then where it was still, you know, some amount of effort like what what I did over the course of a week back then with a Rails app would have been done in a course of minutes with claude code today. There's literally no excuse for any of you to hold back on whatever you're dreaming about could could propel you forward uh you know in your day-to-day or your career. Ruby was never the fastest language or the most funded uh or the safest thing to have on your resume, but it was always the language for people that have more nerve than practicality.

And I think our moment is now. Amazingly, our language has been ready for like 20 years for this moment. So make it work, make it right, make it audacious. Thank you. [applause]