SPEAKER_00 0:00

Hey everybody, welcome back to another episode of the Ruby AI podcast. I'm your host today, Valentino Stull. I'm joined by my co-host Joe Leo.

SPEAKER_01 0:10

Hey everybody. And since we're not live today, I'm just going to tell you all that I am wearing the coolest Ruby programming t-shirt you can imagine. Just picture that. That's what I'm wearing. I've upped my game and I don't wear colored shirts anymore.

SPEAKER_00 0:25

Yeah, so we're joined today by Obi Fernandez. Obi?

SPEAKER_03 0:29

I'm Obi Fernandez, principal engineer at Shopify and all around, kind of done Ruby for 20 years and wrote books and stuff.

SPEAKER_01 0:38

Yeah, it's the all-around part that we want to get to. You know, like it's kind of hard to know where to start preparing for an interview with Obi. I guess the first thing I want to say is thank you for writing the book, the How to Use AI Architecture Ruby book. About half my team right now is reading it. And I'll make the other half read it when we're done. It's very good. We're really enjoying it. And I guess we'll start there. How has the process been for you to write it using Lean Pub and using Olympia as you know your guide?

SPEAKER_03 1:13

That book was written over a fairly short period of time, late last year, or was it early this year? I don't know. Everything is going so fast. Makes your head spin. The folks at Lean Pub are great. Peter and Len, known them for years. I was one of the first authors on the platform a long time ago. Proudly written in Rails. The process was great. I mean, it was very inspired, as everyone can tell now. I mean, we're in the midst of one of the biggest revolutions, I think, ever, you know, probably since machine code to assembler. Yeah. So we're in the midst of this huge revolution, right? Like, and I could totally see the writing on the wall in terms of what was going to happen. Obviously, not exactly what's going to happen. I'm not saying I was like an oracle or anything like that. But I mean, I could tell it was going to be big. And the last time that I felt like something was going to be really big was probably sort of serverless stuff where and I even started writing a book in that case as well, which I never finished. I'm so sorry if you bought that book on LeapPub. Okay. And that I never finished it. But I could tell this was going to be like orders of magnitude bigger. And I was like, okay, I want to jump on this wave. You know, it's what I've normally done in my career. The angle that I took with it, though, was not so much about agent assisting coded, you know, or copilot or like all this stuff that helps you write code faster. It was the angle, and the reason that it's called patterns of application development using AI is because there's this concept which was recently just validated. I'm having a brain fart right now, but one of the main guys talked about software 3.0 at the YC conference like three days ago. His name is escaping me. But he's talking about specifically what I cover in the book, which is using essentially black box AI components as discrete components in your code that sit there and replace dozens or hundreds or even thousands of lines of code by being this smart entity sitting in your architecture, right? That's the crux of the book. The book has a couple other, you know, kind of extra things, peripheral things, and it's got a little bit of like fundamental about LLMs and prompt engineering and stuff like that. But I think the really revolutionary and hopefully somewhat evergreen part of the book, and the reason that it's still a valuable book now, six months later, six time later, yeah, years later, you know, in AI time, is because that's still unproven and it's still kind of bleeding edge.

SPEAKER_01 3:44

Yeah, I think that's right. We dig into that a little bit more with respect to the black box. I mean, as the people that are building the box, what does that functionally mean? Like what is it replacing?

SPEAKER_03 3:58

I mean, I call it a multitude of workers. I use the catchphrase multitude of workers in the book to describe this sense that you have the ability to put near-human-like intelligences into your code, little workers that are sitting there, little clerks, you know, making decisions and transcribing things or passing on messages. Which is kind of retro, almost steampunky kind of thing. But in practice, I think it can be quite revolutionary, right? There's all sorts of objections you could come up to it. It's too slow, it's non-deterministic, stochastic parrot kind of thing. You know, it doesn't actually reason. And, you know, no one would ever put this in production and security concerns, and it's like, gee, this is now the third time in my 30-year career that I'm hearing these kinds of objections to a new technology. The first time was in the 90s, mid-90s about Java. And Java ended up being the biggest thing ever, which I owe my career to because I was in early on it. And then Ruby and Ruby and Rails came along, and as soon as it started to threaten the status quo, it's a toy, it doesn't scale. Why would you ever use that instead of the traditional way of doing it and it's not secure? I got that a lot too. But the whole doesn't scale thing, it's like, really? At this point in the game, we're still saying it's something doesn't scale? Like, do we not realize that human civilization is just an ever cycling, growing process of using more and more computation?

SPEAKER_01 5:34

Yeah, or at least recent civilization, for sure.

SPEAKER_03 5:37

Yeah, I was just looking at an article this morning about like cornfields in the Midwest that are Amazon's building these 50 or 100 hectare data centers, which are like going to be the biggest data centers in the world for anthropic. So yeah, it doesn't scale is not a valid reason to not do things that are really cool and amazing. Sorry if you're an environmentalist and object to the climate change implications of using all this energy and all this water and stuff like that. I totally admit that there are valid reasons to be concerned about that. But those objections aside, it doesn't scale has proven to be just a red herring whenever this comes up. A Ruby herring, if you will.

SPEAKER_01 6:21

Well, so you did bring this up, though, that I think is important. Because I think even people that are bullish about AI and the possibilities of AI, when they think about architecting with it or for it, the first thing that comes up, I think, is that it's not deterministic. And so I guess for people listening and for people who you know may read the book, maybe have not, what do you recommend? How do we handle this as we're engineers?

SPEAKER_03 6:49

Don't think of it the same as you think about your deterministic processes. That's why I refer to them as little workers. This kind of coding and this kind of architecture is truly greenfield in the sense that you can now replace operations of your company. There's different reasons why this is not necessarily appetizing, but I can tell you that to big enterprises, this is very, very appetizing because their biggest expense is human. Yeah. The operational expense of having humans kind of shuffling information around and making decisions. And that is literally what you can replace. And humans are not deterministic either. In fact, they're highly undeterministic. Yeah, absolutely. And yet things function with humans in the loop and sometimes function quite well. Why? Because in aggregate, systems work and can be reliable and can be predictable even if they're not wholly deterministic.

SPEAKER_00 7:53

So I've heard a lot of talk of like the comparison of microservices. You know, AI being like kind of like the blow-up of microservices everywhere, and they even maybe act a little bit the same with the encapsulation of the service and things like that. Like what are your thoughts with that drawn parallel? Is it much like microservices at this point? It seems more like it's something completely different to me personally.

SPEAKER_03 8:24

I mean, it certainly can be. I could imagine how they would be. The thing is that right now we seem to be in a part of the cycle that where microservices are shunned and it's all about monorepos and monoliths and bringing things together. Because I think a lot of big organizations had a bad time with the complexity and indeterminism of large microservice deployments, which I find to be a shame because in the right hands with the right teams, microservices, architectures, evolutionary architectures featuring microservices, I think are super, super powerful.

SPEAKER_00 9:04

Amazon's doing pretty well.

SPEAKER_03 9:06

Yeah. I've talked about this in other podcasts, but I was there when you know at ThoughtWorks, where some of these things were getting fleshed out and being experimented with at clients. Notably at some big finance operations, hedge fund kind of operations and things like that, where microservices were being written and shipped almost daily. And they lived and died based on performance, and things were not upgraded, they were just replaced, you know. So, like you had a thing, and you have a better way of doing it, and so you put the new thing out there and you know, start giving it some traffic and let the other one die out. And sometimes those old microservices were not even necessarily decommissioned for a long time. It's a completely different way of thinking about your big A architecture. Could we see something like that emerge with AI? Yeah, if you have systems that can be decomposed into agent behaviors and where you can have components of your system acting as microservices. And anyone who's got a grounding in like original OO, small talk style OO and message passing and that sort of thing, it's like, wow, now the messages are literally messages. They're literally language messages being sent. And in the talk that I give to go along with the book, on the slide where I talk about collaborating AI discrete components, I put little speech bubbles to represent like user ID, blah, blah, blah, has not logged in in a while as a message that's going out. And then you have a, I guess you could say, like Valentina mentioned, the microservice, you know, which is an LLM-based service that goes something along the lines, oh, oh, I should do something about that, you know, and then looks up their activity, tries to make a determination about how best to re-engage that user. And then maybe does it itself or sends out some messages like, hey, I believe user one, two, three, four should get an email. You got your email clerk, you know, who's got a queue. It was like, whoa, okay, need to send them an email. But now instead of being hard-coded, like a deterministic procedural kind of thing, you can write a system that's a hell of a lot more resilient, certainly a lot more innovative, in the sense that mailer, who's responsible for engagement emails, can be prompted to say, here are tools that give you access to the full breadth of information that we have on this user. And here are some guidelines about how to communicate with them. Do your thing. Right. And then it can go and look at purchase history. It can go look at login records and you know, anything it needs to look at to create a very, very personalized message, right?

SPEAKER_01 11:57

Yeah, you would trust it probably about as much as you would trust a junior to mid-level employee.

SPEAKER_03 12:03

That's actually not true, though. I'm gonna disagree with you. Yeah. You would trust it to the extent that you trust an expert marketer who has perfect recall, perfect accuracy, and perfect command of the domain of writing engagement emails. Properly done, obviously, for that caveat. But AI systems are not nearly as non-deterministic as people think. Right? That's a common misconception. And I call that out in some of my talks as well. I've seen this firsthand, you know, for the last couple of years. While prompt engineered, proper context, low temperature, you get very repeatable results, well within the margins that you want.

SPEAKER_01 12:47

Well, that's an interesting thing because although you mentioned that it's fundamental at the beginning of your book, I actually found it very interesting, even as somebody who does a fair amount of prompt engineering, because you do take a look, like you do dive into the details of like, what should the temperature be? You know, what are the parameters that I might want to edit while I am adjusting my prompts or why I'm trying to narrow the path as you as you talk about in your book, which I found to be really interesting. Yeah.

SPEAKER_03 13:16

It still doesn't seem to be common knowledge. I mean, I run into cases. So in my job, I help teams across the entire engineering organization with their internal AI jobs at Shopify and still find cases where people have the temperature turned way up on things where the temperature absolutely needs to be at zero or 0.1 or whatever, because you're just trying to get some sort of consistent results. Yeah, absolutely. A lot of the frameworks and tools don't do you a favor on that, right?

SPEAKER_01 13:47

No, I think defaults out of the box for chat GPT, it's at 0.7, I think, right? Or at least it was last I checked.

SPEAKER_03 13:54

Great for creative writing and for having fun with a chat agent. Not so great if you've loaded a bunch of MCPs and are trying to run some workflows.

SPEAKER_00 14:04

It seems like we're trying to make microassistance.

SPEAKER_03 14:07

Yeah.

SPEAKER_00 14:08

There are kind of two trains of thought here that I see emerging. One's like these agentic encapsulations where the agents are sort of kind of co-communicating and possibly with an overarching agent managing all of their workloads. And then there's another kind of train of thought where, okay, it's almost better to have like your orchestration planner and then delegating the tasks to the things without any overarching communication at that, then come to an agreement at the end and collaborate. I know there are different use cases for each, but it does seem to be a driving industry force of like trying to pick one over the other because of the system implications of managing it all. Where do you see like the orchestration layer evolving? And like where are the strengths of each as you start to build things out from Shopify where you have like these discrete units that are co-communicating in ways?

SPEAKER_03 15:13

The approach where you have an orchestrator that's leading a team with different experts is very, very powerful. And I see I believe that it's going to get used more and more as the costs come down because the costs do get exorbitant, especially using Opus 4, which is very expensive, but is, in my opinion, the most competent model. However, what you can accomplish with that approach is extremely powerful. Extremely, extremely powerful. And I've seen that up close as well. And the reason is fundamentally because you're narrowing the path more effectively than you can with just using one agent. So I've been really into using Claude Swarm by my colleague Paolo Aruda. Yeah, we just talked about that before the show. Super underrated and slept on at the moment. Maybe because you really need a max plan or a deep pocketed corporate expense count, you know, to use it.

SPEAKER_00 16:10

Yeah, I've got an impending pull request coming for a lama support thanks to uh the Claude Swarm.

SPEAKER_04 16:16

Yeah.

SPEAKER_00 16:17

This is pretty wild. I saw this ClaudSwarm.yaml file in the repo for ROAS. I was just like, oh, what is this thing? And I saw you had mentioned Claud Swarm somewhere else. And yeah, it was just a list of these members that were gonna be collaborating on the work of the ROS repository, it looked like, with like a testing person. And I have this little tool where I create ADRs for something that I want to do. And so I had it create an ADR for Olama support, and it just ripped through it all in like 45 minutes without any intervention from me at all. It was pretty incredible.

SPEAKER_03 16:56

It just works better. It just works. Yeah, it works better because of you get this collapse when the context gets too big. You sidestep that issue quite a bit with these agent swarms because the main context for the coordinator doesn't get as bloated as it would if it was doing all the work. Just a single agent.

unknown 17:20

Yeah.

SPEAKER_03 17:21

Yeah. If you just have a single agent, then everything that needs to be done is in that main conversational context. And every time that you run into limits, it has to be compacted. And then you lose detail. So you're getting screwed on both sides of that extreme. There's a happy middle where it works well, but there are these sad ends where you either have too much context and then the agent gets confused and you lose intelligence. And there's recent, you know, white papers about that as well that we could find and put in the show notes. But on the other side, post-compaction, you lose a whole bunch of detail. And some of that detail might be relevant. So by splitting out and delegating to individual experts, you can find this sweet spot where none of the individual expert contexts get too big and they're able to retain the detail that they need. And this is on top and above and beyond the other benefits that you get from splitting, you know, kind of like the mixture of experts kind of model in this respect, which is that your team can be composed of agents that have a specialty in a much narrower, again, narrowing the path, domain. Right. So at one point I made a swarm for roast and I had a ray expert. And the ray expert was constrained to just having access to the ray directory. Let's check that on my machine. But it has full reign of the ray source code. So it can answer any question really well about Ray. But it doesn't have to do anything else. And truly, the process of going through and reasoning and figuring out how to answer the question about Ray is irrelevant to the bigger architectural thing, you know, to the bigger process of trying to get a feature written.

SPEAKER_02 19:22

Yeah. Yeah.

SPEAKER_03 19:23

So why have it in the context in the first place?

SPEAKER_00 19:27

You know what? It's funny. I feel like this introduces the same problems that humans have. Yes. If you give like full domain scope to one person, like then that domain becomes wrapped up in that person, right? And it becomes difficult to tease it out and share the knowledge across the team in the same way, I feel like. How do you like kind of try to counterbalance those aspects of like locking in that behavior? What do you do to try and prevent these agents from consuming the context? So, like as an example, some other agent may not have the context that it was reasoning about for how to implement Ray, and it needs to use Ray in a certain way. And then it has to go and read about Ray, and they all end up consuming more and more tokens on their own, all kind of you know reading the same material.

SPEAKER_03 20:19

This is all pretty bleeding edge. I'm not going to claim that I'm an expert in it, but it's a way you configure your swarm, right? I don't think you want it too deeply nested, right? Like you pretty much want a coordinator, and there's got to be a sweet spot. Maybe there's like a LLM equivalent to a Dunbar number or something where you want at most like maybe five or six collaborating agents, or they start stepping on each other, or the communications overhead becomes greater than the benefit that you get from breaking it up in the first place.

SPEAKER_01 20:49

This is interesting to me because you know this is something that we've done for Phoenix. We've built out separate agents that all have discrete responsibilities. But what Swarm does is it abstracts the construction of all of that so that we can just write a single YAML file and have it do its thing from there.

SPEAKER_03 21:11

Yeah, and it used to be more difficult because you had to write the YAML file yourself, but now you can do cloud swarm generate and you know you can discuss the configuration in your team and it'll generate the swarm config for you. So the other thing I did this with, I don't mind saying this, you know, so I wrote a swarm, configured a swarm to write a book about roast. And I probably should do a blog post about that and post the swarm config for it. But I wanted to see what would happen and if I set it loose to write a book on roast. So I made a team and it included the lead who was prompted to write like me. And it included like a technical writer, kind of things you would expect technical writer, a Ruby, an experienced Ruby developer, a quality assurance person of some sort, I can't remember exactly. Exactly what it said. And an editor. So I configured it. I simlinked roast into the manuscript directory. And I said, here you go. You know, here's the roast thing. And go and set it loose to write a technical book. And almost $50. And an hour and a half later, I had a 500-page draft of the roast, including everything from the table contents to the preface to the figures and example source code and well thought out and a glossary.

SPEAKER_01 22:39

Who did it shout out in the acknowledgments? I'm curious. Yeah.

SPEAKER_03 22:43

So I went through it and it was really interesting because it generated since part of my profile is like, hey, really approachable writing, anecdotes, war stories, you know, things like that. So obviously it made those up. It was 2 a.m. and we were debugging production logs, you know. Yeah. Which is easily remedied because you can say, okay, go through, find all the war stories and replace them with TK. But the other thing, which was profoundly revolutionary and almost newsworthy, and I want to blog about it, is that it took it upon itself to decide that roast should integrate with Rails.

SPEAKER_00 23:26

Interesting.

SPEAKER_03 23:28

Because Roast is kind of configuring convention over configuration applied to this particular problem of orchestrating workflows. So given that it took that approach, it wrote about that, which is not something that I have really thought about too hard or introduced. And it also did a lot of work on the Rails integration. How you would write ROAS workflows that integrate in Rails using a Ruby API, which again doesn't exist. That's because ROAS is supposed to be cross-platform and you write your workflows in YAML. As I was looking at that, I was getting goosebumps because I was like, this actually makes a lot of sense. This is the way that I would do this, and this is the way that it should work. A little creepy. Would be really, really good. So at that point, I said, hey, this Rails stuff doesn't exist, but it's pretty cool. Meaning I chatted with the thing. Go ahead and look at the existing issues on the repo and create a series of epics that represent what you wrote about in the book that doesn't exist in the code base. So if you look at the latest issues that are filed in the ROAS GitHub, it should contain a bunch of things related to Rails integration and whatnot. That's awesome. And then after that was done, at some point I said, okay, so I generate a PDF of that because it's all in Lean Pub. And then I put it on a branch, which I intend, yeah, like a future branch. And then I said, okay, now go through and remove everything that doesn't exist, that doesn't actually exist. And if it's in the roadmap, meaning it's in the issues, then don't remove it wholesale. Just, you know, mention that it's in the roadmap sort of thing to get me closer to real. And I fully intend to do as little manual authoring of that particular project as I can. I mean, I've already started going through it. I could potentially have a roast book, you know, in a matter of weeks. That's crazy.

SPEAKER_00 25:32

I think we should put into perspective here, Obi, your last book was written in a similar fashion, I would say, where you had used AI to help you start to draft the book, which I believe took you much longer.

SPEAKER_03 25:46

Well, in that case, I was using completion, right? Like, so I wrote the book in Copilot, using Copilot and then Cursor, right? And I was putting chapters into Opus, Opus three, five in this case, three, whatever it was, the last version of Opus. And it did cost me quite a bit. Personally, I can't remember what the figures were, but I mean it costs enough where I was like, oh, okay, don't want to do this willy-nilly, you know, sort of thing. But like I literally had the whole markdown of the book in context, and I would say, okay, this is what I want to cover in this chapter, help me create a draft, and then it would create a draft, but then I have to rework it because it doesn't know what I know. And that model, even though it was insanely powerful, is not as powerful as the new one. It wasn't writing finished material. What it would write would not be fully fleshed out.

SPEAKER_00 26:40

In other words, I guess what I'm getting at is I feel like we'll know a good sense of the progress of AI by how quickly you can publish a book.

SPEAKER_03 26:49

Right. But ironically, no one will read the book. They'll just have a personal AI digest the book. Right, digest it, get the relevant bits to what they need.

SPEAKER_01 26:59

I've had it in my head for a while. I guess what I want to know is how much code do you write yourself these days? Like when you were writing in Ruby, you're writing def methodame at writing the code.

SPEAKER_04 27:16

Very little. Very, very little. Shockingly little.

SPEAKER_01 27:22

Maybe not as shocking as it was even a couple of months ago, but I'm starting to get this sense from a lot of very experienced, very forward-looking engineers. So what's your process like today?

SPEAKER_03 27:34

I think you just have to periodically so you either have to come up with a prompting regime, like in your Claude MD, but by the way, I hardly use cursor anymore. So I don't use cursor agent anymore. I pretty much use Claude Squad and I now have three, four, five, even six concurrent Cloud Code instances going, doing different things. Not necessarily at the same time, but they're sitting in different work trees at different stages of PRs. And so by default, it will cut corners and try to get you to what you're asking for as quickly as possible, even if that means making spaghetti code and God classes with hundreds or thousands of lines of code and things like that. And people use that as a reason to say that it sucks or that it's a junior programmer or that doesn't know what it's doing, which is completely and absolutely the wrong way to look at it. The problem is you have it narrowed the path. Your prompting sucks, essentially. We're just learning this now. You know, there's no shame in your prompting sucked right now because it's literally all of this is being invented right now. Yeah. So think of Sandy Metz, think of Uncle Bob, or don't, if you prefer not to. Clean code, think of Martin Fowler and refactoring, like think of all the knowledge that we've used to learn about what it means to produce good code. Okay. So picture that in your mind. You got bookshelves, you got YouTube videos, conference talks. Literally anything that is not been communicated to you one-on-one, literally from Ward Cunningham or Sandy or something like that, is somewhere out there in written form or video form and has been digested over and over again by these state-of-the-art models. It knows. In fact, it knows at a level that is not imaginable to the ordinary person or developer. It knows it arguably better than Sandy, better than any of these individual people. So all you have to do is just check yourself. You know, it's like basically, okay, you're making a mess. Realize you're making a mess. And this is why it pays to be senior, because you know you're making a mess. Yeah, that's a good idea. Senior person doesn't realize they're making a mess. But the senior person who's done it before knows they're making a mess. Okay, I admit it. And if you go back and you look at the history of the roast source code, for instance, it was a mess. I had a bunch of gut classes, log procedural code, not well tested, not well factored. I took a weekend because we were working on a team as a team on it, several people. I took a weekend of my own time. And I said, fuck it. And didn't do any personal stuff and took most of a Saturday and like a couple hours on a Sunday to refactor the roast code base using Claude Code by prompting it to say, okay, we're taking a long, hard look at this from the perspective of solid principles, the way that Sandy Metz would critique this code and like we need to break this up. No more God classes. I want everything well factored and tested. I want to apply design patterns where appropriate. Let's go. And that involved a lot of hand holding and a lot of monitoring and things like that. But we got through it. And if you look at that, there's a PR somewhere in there in the history where that refactor is presented. And that refactor was also vibe coded. I did not actually write most of that. You know, maybe I wrote 10% of it, 20%. I just guided the agent to do things the right way.

SPEAKER_01 31:15

But that's interesting because you're using vibe coding in a way that I think most people don't. Vibecoding seems to connote something to some people that is negative. But I think when you're the way you're using it is a little bit different because you started by saying that you've learned and are learning to narrow the path, prompt correctly, get the results that you want out of the vibe coding session.

SPEAKER_03 31:38

Yeah, like vibe coding, if you've got 30 years of experience and worked with Ward Cunningham and Martin Fowler and people like that, I guess is different than if you don't.

SPEAKER_00 31:48

It's really funny you mentioned the refactoring aspect. I've actually started using this as part of my post-generative pipeline. So, you know, you'll have a session where you're trying to accomplish something and make changes and it does its usual, like maybe touching on way too many things, and then just at the end, you get to somewhere that you want, and then just have it say, okay, let's refactor in place and go through and make the sensible changes and you know follow these principles, like you mentioned. It does an incredible job on that. And I'm wondering like, is that the solution to combating the spaghetti code? Yes.

SPEAKER_03 32:30

You can and will formalize it in the form of slash commands and of your clot MDs and your cursor rules and things like that. There will be best practices emerging that people use to do this. And there's a series of really good, just really powerful prompts, essentially, that you know, you can put together to do red, green, refactor, to do review, to you know, break it down, look for technical debt that's sprouting and squash it. You don't have to type it. Like you don't have to do the same prompting over and over again. You can codify this into custom commands, slash commands, and plot code.

SPEAKER_00 33:09

Yeah, and encapsulate just those specifics of it. Kind of it's an like an Islamic agent.

SPEAKER_03 33:13

Yeah, because once you have some prompts that are working well, you just use them over and over again. And there's no shame in not doing that right now because me literally figured that out. Like, was it yesterday that I was putting them in play? Like flash commands?

SPEAKER_01 33:31

Yeah, it is amazing. I mean, you said this at the top of the show. It's amazing how fast it moves. But I think it also makes sense. The corollary then is that if it moves this fast, then it really is time to jump in, right? For engineers, right? Now it's time to make mistakes and kind of figure out the kind of prompting and the kind of workflow that works.

SPEAKER_00 33:51

Which is the best development practice. So we've gone through phases in the industry like test-driven development, behavior-driven development, all these different ways of working through development. Book development. Yeah, yeah, right.

SPEAKER_03 34:05

Like it's like start a project, write a book, tell the book through the see what it writes about, go, yes, that makes sense, and then tell a swarm of agents to implement what's in the book.

SPEAKER_00 34:16

Amazing. So, like to that point, like have you found that like these workflows work better following these specific patterns, or is it kind of just like their own thing at this point? Like, are we creating a new kind of development?

SPEAKER_03 34:31

I think it's a new kind of development, right? Within sectors, this will not be universal, but within certain sectors, within parts of the Ruby community and within the community of people who are of, let's say, a certain generation, like my generation, your generation, who have the appetite to do things well, to write clean code, you know, the software craftsmen and craft people out there. I believe there will be an eternal September of being able to write clean code like that if you want to. That may or may not become part of the Zeitgeist. It probably won't. The dominant model is younger, faster, more vibey. When I did the big refactor on roast, I had someone tell me, why does it even matter? You can regenerate everything instantly if you need to. Like, who cares? Why are you slowing down progress to rewrite things when we can just write it over again? I felt like an old man, but I think I'm right. I was like, no, we're gonna do it right.

SPEAKER_01 35:41

I do like that as a quote, like an existential question. Like, okay, so well, you know, my answer would be, well, it's important for us humans to understand it. To which you would all again say, well, why? What does your brain matter in this in this? But I still think you're right. But the discussion is probably ongoing.

SPEAKER_03 36:00

It won't matter any more than it matters whether you understand the intermediary or machine code that's generated by our executables, by compilers when they Oh, that's interesting to think about. It won't. Yeah. I promise you it won't. And in fact, there are efforts underway, I'm sure, at many, many companies, including mine, to write tests with AI so that you don't have to write tests anymore. And I'm gonna put a line in, or my marker, or whatever you want to call it, my line in the sand. I said it here on this podcast first. It's fucking bullshit and it's a dead end, and it's not gonna work for anyone. And actually, what's gonna happen is that eventually we won't write any implementation code. And the only thing that we will do is essentially write tests, except we won't even be writing tests because it's really just the conversation that we're having that establishes the spec. So come hell or high water, you have to communicate the behavior that you want. There's no magical brain interface yet that extracts what you want, except maybe there is because I essentially did that with the roast book.

SPEAKER_00 37:17

So yeah, I know. If we're all logging all of our thoughts and persona, right, into some machine somewhere.

SPEAKER_03 37:27

I'm one of the lucky ones that actually has probably enough of my brain in the base knowledge that I can actually tell it to me.

SPEAKER_01 37:35

Yeah, I know. I was thinking that that is helpful.

SPEAKER_03 37:38

But okay, for mere mortals, there is no way to like just kind of magically get something that you want. You might get something that's useful, but if you literally have business requirements, you have to satisfy. Like you have to communicate them somehow. Yeah. And if you ever want any other humans to be able to review those, that has to be captured in some sort of artifact, right? Yes. And that artifact is, if you squint, is essentially some form of cucumber.

SPEAKER_01 38:09

Yeah, it's a test. It's a spec.

unknown 38:10

Yeah.

SPEAKER_03 38:11

It's a spec. Yeah. And if you have a spec and you have near limitless resources to implement that spec, why would you let a human try to implement it? There's no reason. There's no reason that you would let a human try to implement it. No more than the average project requires anyone to know machine code or assembler.

SPEAKER_00 38:36

You know, it's funny. Humans are terrible at optimization. They're terrible at it. You know, we keep creating new ways to try and be more optimal in our lives, like in our code in so many different ways. And we're really just like fine, it turns out that algorithms are better coded, encoded, and then like optimize themselves through math. Like machines that we're building, like they're better optimizers, and they're gonna create the most optimal code, the most optimal. As as long as we have these specs, like you mentioned, I feel like we're just kind of like edging out of writing code as we know it. So I'm curious, like, what your thoughts are on like the evolution of that in the Ruby space, seems like we're very well positioned because the code aligns so well with the spec writing, right? Because it's so close to natural language. Do you see like that kind of parallel thinking? Or where is your drop-off point of I need to hold on to this code for the life of me?

SPEAKER_03 39:35

To hold on to it, like still want to maintain it?

SPEAKER_00 39:37

Like, still want to maintain it, right? Like, because there will be a point where these things will be able to maintain code bases of their own. And they'll be able to optimize them and make sure that they're not gonna be able to do it. It's already here.

SPEAKER_03 39:49

It's already here.

SPEAKER_00 39:50

It's already here, right?

SPEAKER_03 39:51

It's already here. So, like, I have this new project, which is my test bed for what I'm talking about, not being the implementer, which is the disputy port. I have not written a single line of code in that project myself that is a hundred percent coded by agents. And I initially tried to go through and do like full code review of everything that it was doing. And after a while, I said, no, it's just too much. I don't have time, it's a side project, you know, it's not part of my core thing that I'm working on. It's just a fun side thing just to prove a point, right? And then once I gave up, I said, okay, well, what I'm gonna do is I'm going to write a bin console and then fire up the console and just start playing with it to make sure it works, does what it says. So I'm basically manually acceptance testing the thing. And roast has a certain amount of that going on as well, which is why we have so many examples. So pretty much any time that we're we, the royal we, you know, writes a feature for Rose, part of that is getting the agent to write an example so that it can run the examples and make sure it works. And then running all the examples functions as a kind of you know, integration suite, acceptance suite. I don't know. It depends on the use case, right? Like it depends on the situation. Like, you know, and the reason it's all over the map is because in some enterprise corporate situations, like by regulation and by threat of losing your job, a human has to review every line of code. Domains that have to do with finances or customer data or PII or you know, things like that. And even there, I'm aware, not at Shopify, but at other companies, that there are efforts to get rid of that. Because actually, the biggest backlog right now for companies bigger than Shopify, talking like 10x scale, so you can imagine what I'm talking about. The biggest problem they have right now, which is actively being discussed amongst us that work on these things, is that the number of PRs is exploding because everyone's using coding agents. And, you know, I've even heard of like 5x increase in PR volume, which means you can't human review, you know, it's like the whole system is breaking down. The whole like human PR GitHub, look at the thing, look at the chain set is breaking down. That part doesn't scale. And you have humans complaining, like all I fucking do all day is review PRs.

SPEAKER_01 42:27

Yeah. Which to be fair, they were already complaining about that, about their peers, and now there's more. Right.

SPEAKER_03 42:32

Now they're complaining more, right? Yeah. And so now it's like, okay, well, what's the minimum amount of human in the loop that we can get away with? Like, I'll give you an example. At Facebook, they have like eight million issues.

unknown 42:45

Jeez.

SPEAKER_03 42:45

Like eight million open issues, right? Like I don't care how big their engineering staff is, they're not going to get through that. They know they're not going to get through that, right? So you can imagine how they're planning to get through that.

SPEAKER_01 42:56

You know, I like that as a concept too, though, right? Like, just every single code base, ours, ours included, have more issues than we know we'll ever be able to get to because we know that they are they're ever growing. We can do 80% of the issues in our backlog right now. So some amount are just never going to get done until we finally do get to them. By that time, there's you know, twice as many issues.

SPEAKER_00 43:19

I had this thought the other day where it seems like where we're heading is like the point where, okay, you just host a repository, and somebody opening up an issue shows a price, like a cost associated with addressing that issue. Suddenly, GitHub just becomes an open marketplace for where sponsorships go. It seems like we're getting to the point where just you opening up an issue and somebody like tagging it the right way gets it integrated into the project. Like we're not too far away from that.

SPEAKER_03 43:53

Yeah, yeah, we're not too far away from that at all. I mean, there's people working on that right now. Right. I mean, I don't know about the market and the price.

SPEAKER_00 44:00

Yeah, the m not the marketing part, but like ultimately there's a cost associated with all of it.

SPEAKER_03 44:05

Yeah, what do you think roast is being used for? Yeah, right? Exactly. That's the kind of thing it's being used for, right? Yeah. Like people want and it makes total sense. I'm not saying it's something that you shouldn't want. Like you want what you want is that an issue, whatever form may take, pops up, and as quickly as possible, you have someone on it, quote unquote. That's some agents that are figuring out what to do. But at that point, you know, eventually we just become the supervisors.

SPEAKER_00 44:36

Now what I would love to see is like people's personas being the creative engines that also, you know, create all these things as well. So let's say we have Obi Fernandez, the agent scanning GitHub for ideas, and maybe Twitter, maybe just like, I don't know what your thinking process is. I probably had having a DJ session where your creative juices flow. Maybe it's just like something that, you know, it's an agent that does all of these activities to kind of gather up ideas and then opens up a you know repository and starts a new project based on all these different ideas. Then other people come in and they open up issues and maybe collaborate on the issue or oh yeah, this would be a great idea, right? Like it would be really interesting to see how that pans out. What actually gets created from all this stuff and how accurately maybe would it reflect reality? I feel like it would be closer than we might think.

SPEAKER_03 45:33

There's a timeline where very soon I become very wealthy because I'm right, I believe that I can lay claim to my literally intellectual property in the sense of, you know, hey, if you're a fan of mine and you want me to work on thing, then you can license my personal version of property.

SPEAKER_00 45:53

That would be great. You know, hey, I would like to pay for Obi to come and implement some of my issues, you know?

SPEAKER_03 45:58

Like Yeah, and hey, it scales.

SPEAKER_01 46:01

Yeah. This is like an only devs.com uh uh situation. I'm curious. I mean, V brought up the music and I really liked the music. I had you on uh your stuff on earlier, just listening to it while I was preparing for the show. And I am always curious because I've always looked at software development at its core as a deeply creative process for creative people. And, you know, and so lo and behold, you find so many people that are that are also artists. So, you know, I'm curious to know like about that artist developer crossover for you first. I mean, how do you see yourself? Do you see yourself as an artist first, an engineer first, and what kind of things inform your process when it comes to the art?

SPEAKER_03 46:55

I do see myself as an artist, and I try to bring that to my day-to-day. I don't like saying that I'm an artist in a professional setting because it feels like uh I like smelling my own farts kind of thing. You know, I don't know. It's a little bit something weird about it. But yeah, I mean, I think that's part of what makes it special, right? And like one of the reasons that I stay deeply committed to continuing to make music, you know, no matter what I'm doing or whatever, is that it keeps me in that zone. So to produce music on a regular basis, you have to be in touch with your muse and without getting too hippy about it or whatever. If you want to produce open source, if you want to stay relevant, and you know, that you always have a muse, like whenever you're doing these creative things. And there's parallels between the music and actually, even with the AI stuff. Yeah, I've been using Suno really, really heavily to produce. So I love writing lyrics. I've written poetry on a personal basis for years, and I've written tons more stuff than will ever get published. My kids are listening to this or that their AIs, like go searching, you'll find it, and maybe some slick or whatever, you know, there's good shit in there. But what I was getting to is that the music world is changing as well, even way more to the extent that people realize. I personally am friends with a DJ, you know, in my music niche that was at one time a top five DJ in the world and who is still very actively producing, and they're using Suno every day for hours. Yeah. Why would you not just like us? Why would you not use Cursor? I would never dox them or like I would never divulge who I'm talking about. And luckily there's you know a number of people I could be talking about, but I think it's scary to people, and especially the artists, way more than it's scary to your average developer. Because you are using in an unauthorized way intellectual property that is not yours. It's just that it's a thing that now exists in the world, so it's kind of like it's literally not going to go away. Like this is the timeline we're on, this is the way that it's going. And hopefully it just doesn't speak too badly of me, but it's like it's a tool, it exists. So I don't feel like it's putting people out of business per se. The world is evolving and jobs come and go, and that's the nature of jobs, you know, over his historical time anyway. So this is just the later technology is disrupting things. And, you know, if you lean conservative, not in a political sense, but if you lean in like, let's keep things the way that they were, you're not gonna like that. And if you're lean towards like, fuck it, Luna, let's see what comes next, you know, then you're gonna like it. And I definitely go that way, right? Like, I want to see what comes next. And like personally, as a I've been producing a lot more vocal music because I like writing lyrics and I like hearing my lyrics perform. And now I have performers at my fingertips whenever I want it. People are like, how do you do all this stuff? It's like, I don't watch TV and I try to limit my social media consumption and as much as possible, which means a lot of my spare time I spend on things like Suno and making music. But when I'm on Suno, I'm basically learning how to prompt engineer Suno and how to produce things that give you inspiration. And then in some cases, I've published music that is just really lightly post-produced, mixed, and mastered, but is like wholesale out of Suno. So I like I have a whole project called Saindra, which is that. But for my own music, which I take a lot more care of in many different senses, you have the ability to break to separate the vocals. And now you have really, really good stemming capabilities. You can break something that you generate with AI into like five, six, even twelve different quote-unquote stems, which are the individual components of the track, which means that you can integrate them and use them in your normal traditional music making process when you're producing music. And that's what I'm doing. And the results are mind-blowing. Unfortunately, the long-term effect, I think, is just to further entrench this log distribution, whereas if you were famous before, you're already famous, like you're going to continue to be famous. Everyone else will see the value of what they produced even further devalued. But that's literally happening across the board, not just with music.

SPEAKER_01 51:23

I read about this a few years ago in relation to Spotify. Like it democratized the ability for people to get music out there. And as a result, me as a music listener, I've it's a bonanza. I get to hear a million different artists, a million different genres. Like it's amazing. But for the individual artists, you know, your job got 10 times, 100 times harder to stand out because now everybody has access to the same tools. Do you see a is this a similar does this rhyme with that?

SPEAKER_03 51:53

It's a similar thing, but it makes the situation even worse because the people who are already established, it's even easier to create the output than it was before. So the parts of their job that were actually hard and that actually took talent are getting easier. But again, that's not unique to music or art or anything like that. That's literally happening everywhere. And you could look at me and you could say that's a case study, right? Because I have every intention in the coming months and years to start producing a ridiculous amount of product. I have a personal vendetta, a quixotic vendetta to prove against Python. I want to find every significant Python project that should be in Ruby and have a horde of agents rewrite it in Ruby and put it out there so that no Rubyist has to suffer the indignity of having to write Python again ever.

SPEAKER_01 52:49

Now we're talking.

SPEAKER_03 52:54

I'm personally offended. But I will be able to do that in part because I already have some. I'm no DHH or whatever, but I already have a measure of popularity to build on as a base, which means that it's exponentially easier for me to get coverage and visibility into whatever I do and get multiplying, you know, exponential returns on that. It's an unfair advantage, you know, even at my modest levels, because I don't think I'm a right.

SPEAKER_01 53:24

But you nonetheless, you want to press it. I understand.

SPEAKER_03 53:27

Yeah.

SPEAKER_00 53:27

You're also sharing the wealth of all your open source too. So in a way, it does have a trickle-down effect. We in your case, anyway.

SPEAKER_03 53:34

I don't want to sound like too conceited or whatever, but I mean, it's I'm trying to say across the board, you know, any domain that you're in, that's kind of happening, right? It's like happening with influences, happening with it's going to get harder and harder to break through.

SPEAKER_00 53:48

Yeah, I could see that. It's funny you mentioned like the breadth of production value that you personally get, like with Suno as an example. I remember this guy that had created the Echo Nest that Spotify built that now is like the recommendation engine. It's just like this brilliant guy. He had like found mathematically how to like split apart different aspects of the audio so that you can then take like John Bono's drum pattern and apply it to any song as an example. And so I wonder like if like there's a parallel to this style of creation that will evolve out of this, where because there's so much ease to generate and blend, that we'll kind of see like a new like hip-hop style evolution of all of this, where it'll just be so readily available to mix and extract and fuse together things that we'll see a lot more, not only uniqueness, but like the creativity explosion. And you know, maybe yes, the value of it may go down because the quantities increase, like it's a supply and demand kind of thing. I don't know. Maybe these platforms are the ones that lead the charge. Where do you see that creativity flow? Like, are we really looking at a future where creativity no longer creates monetary value?

SPEAKER_03 55:13

No, I wouldn't I wouldn't say that at all. In fact, creativity, true creativity, is gonna become the only valuable thing in this world. Because until the nature of AI changes, it is really only they're only statistical models, right? So they're only going to give you an average, you know, or an extrapolation of what already exists. Fundamentally, they can only give you an extrapolation of what exists. And if you get philosophical about it, you might say, well, everything already exists, but I don't think that's true. The latent space is unimaginably large, right? And very, very sparse. There's definitely lots of things that don't exist. You know, like if I combine a kumbia with Japanese folk music and give it a hip-hop, lo-fi hip-hop beat or something like that, some might say that's creative, but at the same time, that's still just putting together things that already exist. You can do that right now. The value of that is questionable. So that human curation, the creativity of like figuring out what is actually appealing about putting that knowledge together is the only remaining valuable commodity in this world, I think, is where we're going. Everything else that is ordinary in any way will get automated. And that, I think, will have such a profound impact that no one is even really talking about it in any sort of mainstream way. It is still far outside the overtime window. It will completely and utterly revolutionize everything about everyone who's working in any way with information. Because literally anything that you need and that goes on this screen can be instantly made. If the cost drops significantly enough for the kind of technology that we're working with now, and I went into this in Las Vegas in my originally talk I gave that led to the book. I said, software is gonna be completely different if for God knows what reason you actually need some new software, you're going to talk to an agent and you're gonna say, Hey, I think I need some software to manage my ledger of blah blah blah. And it's gonna go, oh, that sounds like this. It's A and B. It's like idiocracy style. Oh, it looks like A. Yeah. Right. You click on A and it goes, Cool, you've selected A. You know, after A, you would normally get C or D. You go, I think I want D. And like it's not writing specs, it's literally implementing your little choose your own adventure thing. Because if there's a model for what exists for what you need, it's already there. It already exists in the AI, the knowledge of what it is that you need. In that sense, the only thing that becomes valuable are the things that no one has thought of yet that they really need. And for that, I think fundamentally, based on the the architecture of the LLMs and the way that human thought works, only humans can do that right now. I happen to think that we're probably still a ways off from like true AGI, you know, ASI sort of thing, where they replace us in that way. Which is cool because if you're used to being an ideas person, if you're used to being creative and tapping into the muse and however metaphysical, the more metaphysical you get about it, the better. If you're used to dropping, you know, three tabs of acid and going totally metaphysical and figuring out what the next thing is and then going and doing it, you are way ahead of the game, my friend. Yeah. Because like you are already fundamentally operating at the level that will be the only thing of value left in the coming decade. Literally everyone else that works in knowledge is going to be fucked. And I don't take it all ascended. But I know where I want to be on the side of that divide.

SPEAKER_04 59:18

Yeah, yeah, right.

unknown 59:19

Me too.

SPEAKER_00 59:21

So, what stops people from just cloning the right personas and amplifying them? If we're talking like, okay, being these most creative, innovative, like in tune with your surroundings and the things that are getting created around you, at what point do you just clone somebody like that and have it corner the markets for you? Yeah, I guess what I'm saying is like, it seems like we're either like heading toward this crazy monopolistic future or one where like everything is decentralized and crumbled apart because nothing really matters anymore.

SPEAKER_03 1:00:03

I mean, I think it's gonna be the latter because your average person doesn't care about being creative whether they want to or not. They got bills to pay and they got crushing jobs and they have anxiety and they have kids and you have you know all sorts of things that keep them from tapping into the muse. And it does get metaphysical. You literally have to get philosophical and metaphysical to think properly about the implications of what this means. I don't think there's any other way. That's my opinion anyway. But I don't know. Think of a normie, think of your average person who just works a job and doesn't necessarily give a shit about what it is, you know, they're just paying the bills. How much creativity do they have? You know, how much do they have to really offer in the way that we've been talking about? I hate to say it, but usually not very much, you know, which is really sad. But we could work towards this utopian vision of the future where the fact that, you know, there's less toil due to these technologies means that the average person can get more metaphysical, can get more in tune with their creative side, can produce cool shit. I assume most of it's going to be artistic in nature, but hey, inventions. I'm 50, right? I'm Generation X. Like when I was a kid, it was super cool to want to be an inventor. You remember that? Yeah. Yeah. When's the last time you heard a kid say they want to be an inventor?

SPEAKER_00 1:01:28

My son, just the other day.

SPEAKER_03 1:01:30

Oh, that's good. But it's your son, but it's your son.

SPEAKER_00 1:01:33

Yeah, that's true.

SPEAKER_03 1:01:34

Like most kids have their face too so far buried in an iPad that the last thing on their mind is to be an inventor. You know, maybe people can want to be inventors again. When we were kids, we wanted to have patents, right? And like I know I was a nerd, but it was a little bit more of a widespread phenomenon. I feel like if you ask an average teenager nowadays if they would ever want to have a patent, they'd be like, what the fuck is a patent?

SPEAKER_01 1:01:58

Well, you know, in fairness, we spent a generation or so telling people, well, you have to learn how to code. And that doesn't suit most people either. But learning to code is, I think, as we've we've just kind of described, is not the same as learning to be creative and to get metaphysical. Although there are those of us that do that. It's not one does not go hand in hand with the other.

SPEAKER_03 1:02:20

Right. One does not merely become a software craftsman, you know. Yeah, right. That's true. Yeah, no, that's very, very true. And it probably goes hand in hand with the dumbing down of the American educational system and the death of liberal education and the liberal arts and things like that, because without that building block, you don't even you're not even aware.

SPEAKER_01 1:02:45

Right, of what's possible, the kind of thinking that's possible.

SPEAKER_03 1:02:49

You're like, what's a muse?

SPEAKER_00 1:02:52

You know, on that note, I feel like we're definitely missing the creative educational spirit of like why the lucky stiff era of people, right? Like, how can we like start circling back to that in preparation for this new giant change that's about to happen, right? Like, how do we start encouraging our kids and the the young people like graduating now that are getting into this stuff? Like, what can we start building now to like prepare it for a better situation?

SPEAKER_03 1:03:23

I reject the basis of the question. We're old. We're old. By definition, we don't get to decide what's cool. Yeah. We like the best we can do, I think, is to, to the extent possible, you know, kind of push for these foundational building blocks we've been talking about. Unfortunately, I think it's unfairly kind of cast into the political divide, and at least in the United States, one side represents liberal values and the other one doesn't. And it's a shame because it becomes a tribalist sort of thing, where in reality, it doesn't need to be, you know, it's really about human ingenuity and things that are equally applicable and attractive to a Jewish New York lawyer as they are to a farmer in Kansas, you know, working on their tractor or a mechanic working on a chopper in Orange County. I mean, you know, like the fundamental basis of creativity of tapping into the Muse, you know, the only reason that I'm not more utopian and idealistic about this beautiful future coming forward is because psychedelics are illegal, you know, it would seem to be that the powers that be don't want the masses to get so creative because they might get ideas about throwing over the current the way that the world currently works. Right. Yeah.

SPEAKER_01 1:04:41

Getting creative about how we live and how we relate to one another is also on the table. Exactly.

SPEAKER_03 1:04:46

But but as far as giving the kids tools, we already are, right? For better or worse, we all have diminishing attention spans, and especially the youngest generations. I saw this when I was trying to teach my son to code. Luckily, he's a software engineer now. My son Liam, he works in React and TypeScript, but he's doing well. And I tried to teach him to code. I had no idea he was going to be a coder because when I first tried to sit him down at a computer, he's probably like, I don't know, nine or 10. And like I was working on a command line thing. There was some Ruby runner or something where your little man, you made him run back and forth, and like we were writing scripts to do that. He had absolutely no interest in it because it was boring. Right. It was literally boring to write, you know, 50 lines of code to make a man run a little boss, you know. Yeah, left or right. Yeah. Run back and left and right. But now, you know, with bobcoding, I have seen videos of kids getting super excited about, you know, writing video games because you can materialize a video game that is at a high enough fidelity that it actually matches their expectation of what a video game is. The reason that my son, 15 years ago, was not interested in a command line man is because he already had a PS4. Yeah, that's a good reason. Yeah. So to answer your question, B, and to be a little bit more optimistic about it, we already are building those tools so that a future Y could come along, right? And work on it. So there's nothing stopping those of us that are older if other than time, right? To like kind of get crazy with it. There's so much greenfield opportunity right now for just completely reenvisioning the way that you go about creating greenfield software, like creating software from scratch. Why are we doing Rails new? Like, why aren't we doing something like, okay, what do you need? And then just materializing it, but materializing it in that way that we talked, you know, bring it full circle to what we were talking about earlier, where we're telling it what we want and it's kind of deciding what to make. Right? Like that's where you open up the opportunities for more democratized software. Unfortunately, the implementation details start to matter less and less to the user. And the implementation details, at least for this stuff that we write, is in Ruby, which means that Ruby starts mattering less and less. But also Python and also Go and everything else starts mattering less and less in this new era. So it seems that eventually that's all gonna go, you know, be forgotten. I remember when me and some of my friends that were nerds took pride in the assembler we were writing, you know, and like compared notes on how elegant it was or whatever. But you know, that's just the artifact of its time. You know, it's in the waste bin. And I think that the beauty of Ruby and Matt's is nice, so we're nice, and all that stuff is eventually, slash potentially very soon, gonna become irrelevant, right? Which makes me sad. But also, what comes next?

SPEAKER_01 1:07:49

You're a good example because you're kind of showing both sides, right? With music and with programming, less about is it, do I want it to be the case or am I afraid of it being the case? And more about, well, it is the case and we're handling it, right? In in reality today.

SPEAKER_03 1:08:06

Ultimately, the thing that you shouldn't be is afraid, because fear is paralyzing and fear is the anti-muse. It's literally the worst thing that you could do right now is to sit there and be like, man, I'm so cooked. I'm so screwed. This is all over. I'm gonna have to change everything, and that sucks. That's the worst possible approach that you could take because you're completely overlooking how much opportunity there is.

SPEAKER_00 1:08:36

You know, I feel like what we're missing out on the early days of the Pixar folks or Ideo, right? Like Tim Brown from IDIO. I don't know if he still does. He's all these sessions, creativity sessions. We're trying to like reset everybody to their childhood for inducing the creativity. And I feel like that's kind of what we need is like a way to induce creativity in people so that they will experiment in ways that aren't currently being experimented in.

SPEAKER_03 1:09:05

I mean, there's really good technology for that, guys. There's super good technology, it just happens to be legal in most countries. So yeah. One of the reasons I like Ruby is, you know, to the extent that there can be an alignment between being kind of this free spirit, artistic, creative, you know, kind of thing, we we have a good overlap with the Ruby community there, even in really innocuous, you know, ways like Aaron Patterson's shit.

SPEAKER_01 1:09:33

Yeah, I totally agree with that.

SPEAKER_03 1:09:35

Yeah. Like I don't know of other programming communities that actively encourage and celebrate that sort of thing. I think it's part of our legacy with why. Yeah. So yeah, you heard it here first. I want to like double and triple down on that myself because I think that's what we need, right? Like it's literally the only thing that's gonna matter. Yeah. Eventually.

SPEAKER_00 1:09:57

Yeah, it doesn't matter what you make. At this point, like it doesn't even matter if it's like productive or fruitful in any way, just the experimentation process and like trying something out can eventually become fruitful. It can eventually produce something, right? And I feel like a lot of people try and focus too much on I want to create this specific thing in the hopes that it makes my dreams like come true, or maybe it it like makes a big business. And really, like that's not where you should start.

SPEAKER_03 1:10:29

You just gotta put stuff out there over and over and over again. That's one of the reasons that it's good to do things like music at the same time, you know, and the reason that it carries over is because with music, you realize that 90% of what you put out is either crap or no one's gonna listen to it. And you do it anyway, and you just keep putting it out, and eventually you do get better and things start to hit and you start to get breaks and things like that because you get better. But if real artists ship, that will never get old. So, yeah, let's get our Ruby people fired up.

SPEAKER_00 1:11:05

We've gonna, you know, reinvigorate the strange Ruby crowd to, you know, like get them out.

SPEAKER_03 1:11:11

Maybe we should have a strange Ruby conference, you know, that's kind of like yeah build for weirdos.

SPEAKER_00 1:11:17

Totally. I think we've covered it all here, OB. We've gone from both ends of the spectrum here, all over the place. I think we've covered pretty much every base you can imagine in AI, where it's heading, where it's going. We did miss out on a bunch of your incredible projects. You just released Ray 1.0, which has some incredible features in it. I would recommend people checking that out. And, you know, also the Deseroo. Is am I pronouncing it right? Yeah. Yep. The D spy Ruby implementation. You know, soon people won't even need to write prompts, just specs. So I I have definitely been playing with it and that it's been working well. So I look forward to messing around more with that. Yeah.

SPEAKER_03 1:12:01

That's cool. And ROS is the big thing that I'm pushing down. So I'm seeing a pattern emerge with ROS, and I need to blog about it. So a lot of the production roast usage that I'm seeing feels like it's like 80% not AI tasks in the workflow. So it's a little bit more workflow orchestration, like typical workflow orchestration and scripting than you would think, except you can easily sprinkle little bits of prompts and AI smarts into it, which makes all the difference in the world. So that is new to me. I didn't realize that was going to be the case. We realized that we needed to put inline bash prompts, like, you know, basically commands. So we added that and then we start using it, and then we start using it more and more and more. And now I'm realizing that actually what's really valuable is being able to like easily do a script and put prompts in that script in a methodical way. It's that interleaving of deterministic and non-deterministic tasks. When you're talking about repeatable workflows that you need to run at scale or that you need to get the same results, kind of results over and over again. You have this process. And there's a quote from my colleague Sam Schmidt that I don't have in front of me, but it's basically he goes, you can start with a big prompt and you then you start to decompose it and you start to pull the parts out of it that don't have to be AI. And that's the power that Roast gives you. Right. It's like you can easily pick apart a bigger prompt, and you don't even have to start in Roast. Like you can just create your workflow, like and give it to Cloud Code or create as a command as your way of prototyping it. Or you put it into Roast itself as a big prompt, and then you run it and you kind of get the top of it running, and then you start decomposing, you know, you start picking it apart. And almost everything that I've seen includes a step where you go run this command. Anytime that you're saying run this command, you probably don't have to waste tokens on that. You can probably tell the previous step to prepare the parameters that go into the command, and then you can literally run the command in a script way. You don't need the AI to generate the command that you're gonna run. You just let the AI provide the input parameters, the command line parameters, whatever. A lot of these things involve GitHub. So you know you're quite often just using GH command line. Because the problem is if you let the agent generate the GitHub, it's gonna work while you're developing it. It may work, you know, in low volume, but you start running it tens of thousands of times a day or an hour, it's going to fail. It is definitely going to fail. It's not going to work. So there you go. That's in a nutshell, you know, why roast exists and why I think it'll be successful. Because that's very, very needed right now.

SPEAKER_00 1:14:49

I'm looking forward to messing around with the clawed code aspects of it as well. That it's like integrated into the workflow mechanisms. That's gonna be super valuable. I'm already thinking about a ton of stuff.

SPEAKER_03 1:15:01

It's all not gonna matter in the long run because of the bitter lesson, probably. You know the bitter lesson? What's that? Every time the AI takes a leap forward, it kind of like obsoletes all these workarounds. Yeah, because essentially everything I just described for the last 10 minutes or whatever regarding roast is essentially a workaround for the fact that you can't just give a workflow definition to the agent expect it to do it every time. So sorry, I take it all back. Fuck it. Right, yeah.

SPEAKER_00 1:15:33

All right, Obi, we're gonna have to have you back on to dig into some more you know ephemeral topics and metaphysical ones. I feel like we could talk to you about all different kinds of things all day long here.

SPEAKER_03 1:15:45

No, it's always a pleasure, Chris. Yeah.

SPEAKER_00 1:15:47

Yep. Is there any imparting wisdom you want to give or projects that you're uh keeping an eye on that you want folks to know about?

SPEAKER_03 1:15:54

Cloud Squad is awesome for letting you like quickly run Cloud Code on different work trees. I mean, I barely even knew work trees existed before like a month ago. Turns out they're a thing. There's this, I think it's open source called Claudeception. It's kind of like a Cloud Swarm sort of thing, but it it hits a registry of I don't know how many thousands of agents that this guy uh AI. So, like link in the show notes probably. Yeah, other than that, I'm not so sure. I mean, I'm going to be giving a lot of talks in the near future. I'm speaking at Yoruko, I'm speaking at Ruby Africa and Nairobi. It's mostly going to be on these same topics that we discussed on roast, et cetera. Not speaking at Rails World, but I'll probably give a lightning talk because I'll be there. And won't be in Philadelphia for the last Rails conf because they didn't ask me the keynote, so fuck them. Thanks for having me on the show. Appreciate it.

SPEAKER_01 1:16:54

Thanks, O.