Valentino Stoll  00:00
Hey everybody, welcome to another episode of the Ruby AI podcast. I am one of your hosts today, Valentino Stoll, and I'm joined by Joe.

Joe Leo  00:09
I'm Joe, I'm the other guy, I'm just stepping over Valentino's lines now. Nice to meet you all. It is a heat wave here in New York, and I think it is really just here to train us New Yorkers that are going to RubyConf to deal with the heat, because it's going to be like 125 degrees in Vegas in a couple of weeks. I don't even know if I'm going to leave the hotel.

Valentino Stoll  00:28
I think they just hose you down with, like, slushies, right?

Joe Leo  00:31
Yeah, yeah, that would be nice. You know, we were going to roll out our new swag, our new hoodies. The Death Method hoodies are legendary. I was kind of of two minds about it. It seems really strange to give people a hoodie in 120-degree heat, but then again, if you never leave the hotel, it's probably going to be cold. But either way, we didn't get them off in time, so sorry.

Valentino Stoll  00:52
They have those new, like, cut-off sun hoodies. I don't know if you've seen those.

Joe Leo  00:56
Oh yeah, that's true. That's true.

Valentino Stoll  00:57
You know, that's a good idea.

Joe Leo  00:58
I see golfers wear those a lot. Yeah, yeah, yeah. I'm going to think about that. We can get a couple of new options. Anyway, we've got somebody here with us. Why don't we introduce to everybody Ernesto Tagwerker. Ernesto, say hello.

Ernesto Tagwerker  01:12
Yeah, hey everybody. So great to be here. I've been a listener and happy to join Joe and V for the first episode.

Joe Leo  01:21
That's right.

Joe Leo  01:21
So we have had a representative of Anbu Labs on before, and we went really, really deep into the weeds into AI, which was cool because especially at the time, a lot of people, and I guess even still today, a lot of people say, "Hey, yeah, we do AI," which basically means we use

Joe Leo  01:39
an API to get Claude or ChatGPT to do things for us, which is not really the same thing as being, like, an ML engineer or working with AI at a deeper level. But Anbu Labs definitely does. You want to tell us a little bit about that?

Ernesto Tagwerker  01:54
So yeah, Amanda is our head of AI. She was in a previous episode, and I'm sure you guys talked about machine learning, Gen AI, LLMs, RAG, all that stuff. And at Anbu Labs, what we do is basically custom AI solutions, like, yeah, predictive machine learning model, Gen AI solutions,

Ernesto Tagwerker  02:13
and the other side of our business is also, like, AI strategy for small businesses. A ton of businesses here in Philadelphia are reaching out because FOMO, basically. They know they need to use AI to make their processes more efficient, but they don't want to go about it just winging it. So usually,

Ernesto Tagwerker  02:32
like, safety and compliance are top of mind for some of our clients, so they engage with us so we can guide them into what tools and what set of tools are best for them.

Ernesto Tagwerker  02:42
And on the Ruby side, we also run a product I serve is called fastruby.io, and on that one we also are using AI and open sourcing some AI tooling to help companies make upgrades faster and get all the way from RELS 2.3 to 8.1 if they wanted to.

Joe Leo  03:01
So the open source contributions are awesome, and I've heard you speak in the past about Next RELS, which is a really cool dual boot gem so that you can sort of understand what's going to break when you upgrade. So why don't you tell us a little bit about that, and then tell us a little bit about some of the sort of next generation AI tools that you've been building.

Ernesto Tagwerker  03:21
Yeah, sure. So Next RELS is, like you said, a really cool tool that you can use to dual boot any bundler-based Ruby application. So it works for RELS, but it can also work for Sinatra or Sidekick. And we like to use it to basically test one version and another version very quickly by just flipping on and off,

Ernesto Tagwerker  03:43
like an environment variable. And it works very well from, like, development to test to production, even if you want to do, like, gradual deployments and you don't want to do, like, one big bang deployment for RELS 5.2 or something like that. Then on top of that, we started using Claude a lot recently.

Ernesto Tagwerker  04:02
We actually kind of went in on Claude about three months ago, and we said, "Okay, we need to build the tooling on top of Claude to use Next RELS." And it all came out basically as a rant that I had where if you ask Claude to upgrade RELS from X to Y, it will make a case against dual booting.

Ernesto Tagwerker  04:23
And I get it. You know, if you have, like, a monolith that's been around for more than 15 years, you have a ton of lines of code, yes, there are going to be, like, many if-else statements that say, "If current RELS do this, if Next RELS do this other thing." So Claude was like, "No, I don't want to add this thing because it'll be,

Ernesto Tagwerker  04:42
like, too many conditionals." From experience, I know that I want the conditionals because it will make it easier when things get tough. So that's how three different sets of skills came to be. It's basically, get Claude to dual boot, get Claude to use the test suite as much as possible,

Ernesto Tagwerker  05:02
and then at the end of the upgrade, flip the RELS defaults to use the last one, the most current ones. So that's a little bit about, like, the AI tooling we've been using. And then another part is, like, we built an automated AI-assisted roadmap for anybody who wants to generate a roadmap from RELS 2.3 to 8.1,

Ernesto Tagwerker  05:23
but that one hasn't gotten a ton of usage, so we're thinking about what to do with that next. For now, I think our focus is on better tooling for Claude or Copilot. So yeah, that's a little bit about what we've been doing lately.

Joe Leo  05:38
So it's interesting, and we were talking about this just before we started the show. First, this resistance comes from somewhere, presumably a bunch of Stack Overflow discussions about adding conditionals, right? Because the LLM didn't come up with its own ideas about adding conditionals. But it sounds like there's some element of,

Joe Leo  05:58
you know, you have to lower the resistance and make sure it says, "Hey, actually, this is a good idea." Right? And so is that just added context, or is it done through repetition? How does that work?

Ernesto Tagwerker  06:07
Yeah, I think we've only seen it work without conditionals with really small RELS applications. So our own experience is based on really big engineering organizations that need to upgrade RELS. Power Home Remodeling was one of our clients in the past, and they have a huge ERP that has a big team behind it,

Ernesto Tagwerker  06:29
so upgrading their RELS application wasn't a trivial thing. And most of our clients have those sort of applications that are really big. So I find, like, when you use AI, like, the best thing is to combine it with some human experience, to be honest. So you don't want AI to make those decisions for you. Like you said, it's basically,

Ernesto Tagwerker  06:48
like, taking the averages from Stack Overflow, Reddit, open source projects. So I see it as a way to encode our experience and our process into a skill that's, like, readable and easy for Claude or other Gen AI tools to interpret in. There's, like, no gray areas. You dual boot,

Ernesto Tagwerker  07:08
and if you don't want to dual boot, that's cool. Just don't use the skill.

Valentino Stoll  07:11
Yeah, you know, I remember first seeing dual booting at one of the RELS comps. I think maybe it was Shopify folk. I don't really know. What was it, the Bootloader gem or something like that? And it made so much sense, right? Yeah, boot boot. That's the best way to just, okay, like, as you're going and making updates to your app,

Valentino Stoll  07:32
you just in the background run your whole test suite against the dual booted RELS app, and then you can, like, catch bugs that may be in the latest versions. It made a lot of sense. And so I get why you're, like, focusing on that. To upgrade RELS, because it's, like, the easiest way to just see, "Am I prepared to upgrade?" Right? Which I think is,

Valentino Stoll  07:51
like, probably one of the biggest things when you're upgrading any app is, like, is this going to cause any problems when I try and upgrade it, or am I just going to have this, like, massive PR at the end that's going to, like, then be broken? I'm curious, like, did you take that approach to, like, do incremental upgrades with this Next RELS? How does that aspect of things work within Claude?

Ernesto Tagwerker  08:12
We see it also as a way to detect backwards compatible changes as well. You need a conditional if it's not backwards compatible. But another thing that's cool about Claude is that you can write code that's basically like monkey patches or little RELS shims that are like, "Okay,

Ernesto Tagwerker  08:31
this is not going to pollute the entire code base in, you know, the whole thing." Like, "Oh, this every model no longer extends, like, active record base. Now it extends, like, application record or whatever." Or, like, the RELS migrations now take brackets or something like that. Now for those things, instead of,

Ernesto Tagwerker  08:49
like, doing, like, if-elses in, like, 170 files, you can just basically write a little RELS shim that kind of plugs into the library's directory. And back in the day, without Claude, I think that was, like, a little bit too complicated to do, so maybe we would default to, like, if-else statements. But now with Claude, it is quite good at generating those shims.

Ernesto Tagwerker  09:11
And I know it's, like, not great, and I would definitely not advise people to start monkey patching everything. I'm just saying, like, for this particular case of upgrading RELS, it's a really good fit.

Joe Leo  09:21
Yeah, I remember replacing active record base many, many times by hand, right? And so that's not fun. I'm curious, either with the shims or with conditional logic, are you tearing those down at the end of the upgrade, or are you keeping some of them in? Is it not all or nothing?

Ernesto Tagwerker  09:38
No, at the end of it, you get rid of them. And usually, like, the best practice for a shim like that is to actually use, like, if RELS version is current, do this, otherwise do this other thing.

Ernesto Tagwerker  09:49
So even if you flip the switch, set the environment variable in production to use, like, the latest RELS version, that shim should have logic in it to not run in the wrong RELS version. So that's usually how we do it, very defensively.

Joe Leo  10:06
Yeah, because you're putting these things in, how do you know what to clean up when it's over? Presumably, you're not going to do it immediately. You want to make sure that everything's running and have it in production maybe, I don't know, a week, you know, a month, and then you're like, "Okay, good, we've made it." So how do you know what you're going to rip out?

Ernesto Tagwerker  10:23
That's actually one of the learnings we had as soon as we started using the Claude skill in, like, client applications. Juan, one of my teammates, suggested a cleanup job. So now I don't know if it's, like, a specific skill we have, but it might be, like, one workflow we have within the skills to clean up all these RELS upgrade-related code out of the code base.

Ernesto Tagwerker  10:45
So we are using Claude for the cleanup as well. And I don't know about you, Joe, but we are seeing really good speed-ups on upgrades.

Ernesto Tagwerker  10:56
Up to the point where, you know, now it is a reasonable case to say, "Oh, we could have one human and one agent or one Claude basically working on an upgrade and get comparable results to maybe two humans working on an upgrade." I'd love to know what your experience has been using AI for upgrades,

Ernesto Tagwerker  11:18
because you also run a consultancy.

Joe Leo  11:20
We do. So we don't offer this as a service, but we obviously we upgrade RELS for clients we're working on. And yeah, the results, it's both faster and it feels more sturdy. So our engineers are moving with more confidence. Presumably, that's because or not presumably, I mean, I've talked to them.

Joe Leo  11:39
It's because they do have Claude or they have any of the other AI tools doing the majority of the work, so they spend much more of their brain power ensuring that what is happening is logical rather than typing everything out and spending time doing that. And so even if they're spending more wall-clock time analyzing the results,

Joe Leo  11:59
what comes out is, yeah, it's happening faster and it's happening with more confidence. The biggest thing I've seen in Ernesto, and maybe you see this too, this year it's been pronounced. Last year it was not like this as much. All my engineers are beating their estimates every time, which is a thing, you know, I've been leading teams for, like, two decades, and that's not a thing that has ever happened.

Joe Leo  12:20
We're just, like, we just famously underestimate all the work that it takes, and now we're actually beating our estimates on a consistent basis, which has been really an interesting shift. I don't think that'll last, because pretty soon we're going to get overconfident and then we'll start underestimating again.

Joe Leo  12:34
But for this year at least, it's been this interesting thing where it's like, "Well, I think it's probably going to take three months." And it's just from lived experience. It's like, "Yeah, I know this thing will go fast, but not that fast, and it's not going to be that good, and we're going to have to go back and clean this stuff up." And that's true to an extent, but it's also true that we're overshooting it a little bit.

Ernesto Tagwerker  12:53
I think I've seen that as well on the upgrade side. Then on the custom AI solution side, I haven't seen that so much. And I think, like, it's just us being, like, overly optimistic that we can deliver, like, a non-deterministic solution to this client in this amount of time, and then there's always, like, things that come up.

Ernesto Tagwerker  13:13
And part of it is, like, managing expectations, right? Like, people who are getting custom AI solutions expect a deterministic solution. And sometimes there is, like, the part of non-determinism that is like, "Hey, for this particular use case, we want it to use an LLM, and it's going to generate content." And sometimes there's going to be something that's off,

Ernesto Tagwerker  13:32
and it can't be 100%, but it can be close to that.

Joe Leo  13:36
It can be close, yeah. I have this experience with my assistant who's using Claude Cowork every day, and we have this process internally. I have this sales engine that we built, and so she has a part in it which is, like, she's using Claude Cowork to basically search through LinkedIn and look for these people and add them to this particular list, and it keeps getting it, like, 90% right.

Joe Leo  13:57
And it's basically, it's like, there's other parts where it just, it doesn't fall over. It just puts, like, LinkedIn URLs that are non-existent. And she keeps saying, like, I keep coming back to her and being like, "Hey, it's better." Because I'm like, "Hey, this is really good. Like, 90% is correct, 10% isn't." And she keeps being like, "Well, why is it doing this?" Yeah, this is kind of a learning experience.

Joe Leo  14:16
It's not anything you're doing. This is just non-deterministic software. It's going to do it right a lot, and it's going to mess up sometimes, and that's where we come in. Sorry to keep you up.

Valentino Stoll  14:23
The edge cases are really funny.

Joe Leo  14:25
I know, I know.

Valentino Stoll  14:26
It doesn't matter the task. It's always the edge.

Joe Leo  14:28
No, it is. I look at it and I'm like, "This is just, like, LinkedIn slash in slash John. It's not a real thing."

Valentino Stoll  14:34
I'm curious. I automate all my RELS upgrades at this point because they're all just personal projects. In the background, I'll just be like, "Hey, go upgrade RELS." And then I realize, "Oh, things are broken," and I fix them because they're just for myself.

Valentino Stoll  14:48
But, like, if you had to draw a boundary, what should the AI upgrading agent be allowed to automatically do versus, like, where does the human take the wheel?

Valentino Stoll  15:00
I'm curious, like, where you're seeing kind of, like, the things fall apart versus, like, what's for sure, "Yeah, I trust this thing is going to just do this specific thing."

Ernesto Tagwerker  15:09
Basically, the deprecation warnings, I would say those can be, like, on autopilot. RELS, especially if you're using, like, modern versions of RELS, like, the deprecation warnings are way more complete and present, and there are not that many things that are undocumented. So addressing a deprecation warning,

Ernesto Tagwerker  15:28
I would just say, like, "Yeah, go and do it," and maybe submit, like, a pull request per deprecation warning if you want to review it and have a human in the loop there. For anything that's front-end, I would want a human to review it and to QA it thoroughly before it ships to production.

Ernesto Tagwerker  15:48
Because I don't know about you guys, but I have noticed that Claude, Copilot, and all those things, they're great, but then at some point they're like, "Okay, this is done." And then you look at it and it's like, "Oh, this looks terrible on the screen." And the robot might be like, "No, no, this looks fine. This is fine." So for anything that's,

Ernesto Tagwerker  16:08
like, client-facing, maybe, like, in the UI, I would want to have a human in there. But yeah, I would make those big distinctions on that front.

Joe Leo  16:18
One thing that I find routinely that AI thinks is fine, this is Ruby-specific. It might be like this in other languages, but a couple of things that it routinely thinks is fine that is not fine, really long classes in Ruby. It kind of doesn't seem to sense, no matter how many different ways I prompt it, that you don't want to add another method here.

Joe Leo  16:40
There's already enough methods. And it does not seem to really do much object orientation or object individuation beyond what the framework itself gives you. Right? So unless I tell it, "We're going MVP," or "We're going with a separate service library," or "We're going with," you know, it doesn't tend to do it. I don't know if that's matched your experience.

Ernesto Tagwerker  17:00
One area where I wish it added more value, and I'm sure Joe has, like, a lot of insights on this, is the writing tests or increasing tests before an upgrade. I know you worked on Phoenix DEF Method, and I don't know, I just would love to see a tool or a set of,

Ernesto Tagwerker  17:20
like, skills that basically feeds off, like, data from production and it writes test suites that are based on, like, reality, which is production usage. And of course, like, for V, that is easy for, like, a side project or a fun project because you can just give it access to production and it's fine. For client projects that are,

Ernesto Tagwerker  17:40
like, in regulated fields, which are many of our clients, we would have to have some sort of, like, layer to make sure, like, any sort of, like, PII or sensitive information never makes it to the GenAI engine.

Ernesto Tagwerker  17:54
But I can see, like, a future where it's like, "Okay, you have a robot that is slowly and gradually increasing code coverage for some of these actions in production that are getting called over and over again and have, like, very little code coverage." But I'd love to live in that future where it's like, "Oh, I have an agent that's submitting pull requests,

Ernesto Tagwerker  18:12
and the pull requests are not based on some hallucination or just increasing code coverage for this class.

Ernesto Tagwerker  18:20
They're actually based on real usage." It could be, like, APM data too, to say, like, "Oh, these actions are called all the time and you don't have tests for it, so I'm going to submit a pull request to add a test for that."

Joe Leo  18:33
Yeah. I mean, one thing we learned in building Phoenix is that the differences between application test suites are vast, even on code bases with seemingly very similar characteristics. I love the idea of sort of a sanitizer layer that pulls production data, sanitizes it,

Joe Leo  18:52
and then sends it to an LLM to build tests. I don't think, frankly, we're at the place where that can be SaaSified, right? Where it could be like, "Oh, okay, let's build a one-size-fits-most solution here." But I do think it could be a great service that's offered by companies like yours, Ernesto.

Joe Leo  19:12
So go ahead and do that for us.

Ernesto Tagwerker  19:17
Okay. I'll think about it. The problem with AI these days is that all of my side projects are doable. And of course, it's, like, combined with my.

Joe Leo  19:27
Now you're speaking about engineering.

Ernesto Tagwerker  19:27
Wishful thinking.

Joe Leo  19:28
Yeah.

Valentino Stoll  19:30
I know. I just wish I worked for one of these companies and had unlimited tokens, and then I would just, like, do them all at once.

Valentino Stoll  19:38
But I have budgeting concerns.

Valentino Stoll  19:43
What you're talking about, it sounds like in this RELS next project too, it reminds me a lot of the GitHub Scientist Gem.

Valentino Stoll  19:49
I'm not sure if you're familiar with that, but it was, like, a way to test critical code paths to, like, basically try to execute code in two different blocks and then, you know, measure the outputs to make sure that they were exactly the same or the outcomes.

Valentino Stoll  20:05
It's not exactly, like, 100% because how do you measure side effects or database transactions and things like that. But what do you think about that style of, like, reinforcement learning-ish processes, right, where we have these two paths that we want, like,

Valentino Stoll  20:24
an app to take, and we just want to make sure that they do the same thing eventually? And it seems like that's kind of the path you're taking with next RELS. Is there a reasonable next step to that where the agent can do a step function to automatically handle all that, or do you not see that future?

Ernesto Tagwerker  20:45
I like the idea of keeping libraries small and, like, very focused on certain things. And like you said, there's, like, the Ruby Scientist Gem. I haven't really used it, but yeah, it is really cool if you want to test, like, "Oh, maybe this particular query could be more performant if I structure this Active Record query,

Ernesto Tagwerker  21:05
like, in a different way." But for next RELS, I think that the scope that it has is okay, and it solves the problem really well. And I think where it adds the most value is with gradual deployments where you can basically set it up to basically, if you have, like, Kubernetes infrastructure,

Ernesto Tagwerker  21:24
you can have, like, 10% of the pods run on the next version of RELS and then the rest of the traffic use what you've been using so far. And that way you can keep track of, like, the error rates in your exception tracking service. And if there's, like, an elevated number of errors or new errors happening, it's like, you know that 10% of the traffic is likely causing those.

Ernesto Tagwerker  21:45
But yeah, for experimenting, I think probably, like, the Ruby Scientist Gem is still, like, the best thing to do.

Valentino Stoll  21:53
I was kind of, like, setting you up a little bit. My real question is, how do you stop getting too excited about the thing that you're making, right, where all of a sudden you have, like, a million features that you could potentially do and realistically do if you threw enough tokens at it? How do you, like, personally, like, pare that back and keep things well-scoped?

Valentino Stoll  22:16
You're mentioning you kept it very well-defined, so it did this very specific thing that is helping you. Where are you value-shaping the excitement and paring it back to keep things focused for what you're doing?

Ernesto Tagwerker  22:28
Again, with AI, you have no boundaries anymore. And I'm the owner of Fast Ruby and Ombu, so I don't have anybody saying, like, "Oh, no, you can only use this amount of tokens, so I should probably have that." Maybe Amanda should do that for me. But yeah,

Ernesto Tagwerker  22:47
I think the problem that we have on our end is that we've been doing engineering as marketing for so long that we have so many tools now. We maintain Ruby Critic. We have this idea to basically have a backend server to basically send your Ruby Critic reports to.

Ernesto Tagwerker  23:06
I haven't done it yet, but I might have, like, Claude do it for me and basically offer it for free for, like, open-source projects. We also have relsbomb.org that we inherited from Manuel, a software engineer from Germany, that basically tests compatibility between, like, so many RELS versions and so many Ruby gems.

Ernesto Tagwerker  23:27
It's basically kind of like rubygems.org, but it adds compatibility with different versions of RELS and it has, like, different check techniques. And we have, like, the automated roadmap that generates an action plan. We have the Claude skill. And my problem right now is that they're not talking to each other.

Ernesto Tagwerker  23:45
So one of our goals for this quarter is to basically get Claude to talk to RELSBomb, get the automated roadmap to talk to RELSBomb. Next RELS itself has a way to calculate compatibility, but I don't trust it as much as relsbomb.org. So should we even have that in the next RELS Gem?

Ernesto Tagwerker  24:07
I don't know. Those are the questions I have right now. It's like, we have so much code right now to figure out compatibility and the upgrade path and integration with AI tools that I'm having a really hard time, like, integrating it all to not do the same thing in three different places.

Joe Leo  24:26
I've been reading about some people experiencing this. Are you getting a ton of new pull requests that are almost entirely AI-generated?

Ernesto Tagwerker  24:37
Yeah, yeah.

Joe Leo  24:39
Is that helpful or is it annoying?

Ernesto Tagwerker  24:41
I have actually seen them, and I have found them quite helpful most of the time. There's, like, one out of ten that it's kind of like a hallucination, and it's like, "Please don't do that. Go away or review your work." But no, one thing that we have been seeing on the consulting space, and I don't know if you're seeing this,

Ernesto Tagwerker  25:00
but it's basically these AI-generated scams that reach out to build some sort of tool for you. And then it's like an elaborate scheme to, I don't know, get you to leak data to them. I don't follow them. We kind of have, like, an ear or an eye for that. And it's like,

Ernesto Tagwerker  25:19
"Okay, this project description looks like way too good for it to be, like, a real project description." So I'm like, "There's probably a robot, some sort of scam." Do you get those too?

Joe Leo  25:29
I have, and I've read about them too, and they're proliferating all over GitHub. There's some report on Hacker News, which Hacker News is where you go to find all the people complaining about the AI pull requests. It's nice to hear you say, "Actually, they're nice. They're usually helpful." But yeah, I read some report.

Joe Leo  25:44
I'm going to forget the percentage, but some significant percentage of open-source GitHub libraries right now are scams that are trying to steal your data. So be careful out there, folks.

Valentino Stoll  25:55
They're getting pretty progressive. I saw one lately in the Ruby AI Discord. Somebody posted a screenshot of them receiving money for this free deal for having signed up for some crypto thing. And they're like, "Oh, look, I just got $1,500 transferred to my bank account." And so I was just having fun, and I went through and, like, tried to sign up for the process.

Valentino Stoll  26:15
And you get the final stage, it's like, "Okay, it's like some weird casino in virtual casino in Curaçao." I don't know how you pronounce that. But, like, in order to get your account verified, you have to pay $200 so that you can verify your bank is, like, legit and who you are. That's how they, like, framed it. And I'm just like, "Man, what a great scam and elaborate," right?

Valentino Stoll  26:36
Like, because there was more than one person posting this. Like, "Oh, yeah, me too. Like, I got this thing," right? Like, and I was just like, "Wow, like, it's really getting elaborate." Like, they had clearly, like, just an AI setup website that had the signup flow, and it even had, like, an AI.

Joe Leo  26:50
With AI support.

Valentino Stoll  26:50
Like, customer a service.

Joe Leo  26:52
Service available, right?

Valentino Stoll  26:52
Yeah. Well, they had, like, a customer service agent set up, right, where it was a chatbot. So you, "Oh, I had problems, like, setting up my account. Like, what is."

Joe Leo  27:00
Oh, yeah. That's good.

Valentino Stoll  27:00
And so it, like, made it seem more and more legit. And I'm just like, "Wow, like, somebody really spent a lot of time on this thing."

Joe Leo  27:07
Now, I think a really smart thing to do, not that I am a purveyor of any of these scams, but you would actually want it to work for a few prominent people, right? Like, "Oh, no, I actually did get $1,500," right? That it worked for, like, three people that you know, and then it just scams the other thousand people to try it.

Valentino Stoll  27:22
Well, you know, that's that whole Facebook thing where they're like, "You know, it has a special thing where you enter your password and it automatically replaces it with asterisks," right?

Joe Leo  27:31
Oh, yeah. Right.

Valentino Stoll  27:31
A whole bunch of people comment, "Oh, yeah, me too." Look, and it, like, just asterisks.

Ernesto Tagwerker  27:36
Yeah, you got to be careful out there. So many scams on I don't know if you guys have seen the video of, like, the video. Even, like, in video calls where the person is like, "Okay, now I need you to put your fingers in front of your face." And it's like, "Oh, like this?" And they put the fingers, like, not up there. Yeah, you can't even trust video these days or video calls.

Joe Leo  27:59
Definitely not. You shouldn't even trust this video call. You definitely shouldn't trust this podcast.

Valentino Stoll  28:03
I've also heard that of interviews where companies hiring now get a lot of people interviewing virtually that are not people or are not who they say they are.

Joe Leo  28:14
That's freaky. And that actually leads me to my next question, Ernesto, which is you had mentioned Amanda, who we've seen on the show, we think, and I think in reality also. So I guess we're going to rule her out. She's a real person. You mentioned Juan. Is that an actual human being?

Ernesto Tagwerker  28:30
Yes, yes.

Joe Leo  28:31
Are you sure?

Ernesto Tagwerker  28:32
Every picture we have on our website is a real human. I have actually met all humans in my team except one, Francois, in South Africa, but I also believe he's a human and what it can.

Joe Leo  28:46
Well, you believe so Francois is still maybe, though. And you've got, at least according to you, some actual humans. Okay.

Ernesto Tagwerker  28:54
It is getting harder and harder to filter and to do security checks on people that you hire remotely. So yeah, I think that's one of the struggles we have.

Ernesto Tagwerker  29:06
But yeah, one of the things we recently launched, and this came out of, like, conversations I had with clients, is we launched staff augmentation services because my conversation with clients would be like, "Oh, do you guys do, like, feature work?" And I'm like, "Yeah, we do more than RELS and Ruby upgrades.

Ernesto Tagwerker  29:24
We would be happy to work on your product roadmap." And I had that conversation so many times that I was like, "Okay, maybe it's not clear in our branding that Fast Ruby can also do product development." So for many years, we focused on Ruby and RELS upgrades, but now that AI-generated code is,

Ernesto Tagwerker  29:42
like, more and more present, we also see, like, a ton of pull requests. So it does feel like the workload is basically shifting towards, like, code review and QA and rework.

Ernesto Tagwerker  29:56
So this is, like, our idea to say, "Okay, you need a human in the loop to basically help your team either with code reviews or product development, and you need them to be real humans that you can point to when they mess up. They're humans. They've been working with us for years.

Ernesto Tagwerker  30:14
So now you can hire them to do product development for you or assist with code reviews or anything you need a human for."

Joe Leo  30:23
You know, it's good to know. Of course, being a consultancy owner myself, I mean, I look at it and I'm immediately like, "Okay, yeah, that's a leader into the organization," and then you can do product development and things like that. But others may not see it that way.

Joe Leo  30:35
And so it's good to make it obvious and apparent because obviously the team that can provide a steady pair of hands and upgrade your RELS application is likely going to be the team that you want to steward some of your product roadmap. And it reminds me because I saw this post from you a few weeks ago that your ideal client has a stable test suite,

Joe Leo  30:56
knows where tech debt lives, wants slow and steady progress. Where do you find these companies? Because I've been running consultancy for 12 years, and I don't know if I've maybe I've stumbled into a couple, but that didn't tend to be the work that we get.

Ernesto Tagwerker  31:09
Yeah, I think the test suite is the main one, right? I think a lot of companies, especially startups or companies that started as startups, and they just needed to move fast. They never stopped to write the test suite or to keep it up to date or even to upgrade RELS and Ruby. So that's why they end up reaching out to us. The good thing is,

Ernesto Tagwerker  31:29
like, when we work on our Ruby on RELS upgrade, we kind of get a taste of what it is working with this client. And like everything, there are good clients, great clients, and bad clients. So it is a funny fact, like, in the past year or so, we've had way more repeat customers than new customers, which is a new thing for us.

Ernesto Tagwerker  31:50
Last year and maybe, like, two years ago, it was more like, "Okay, new projects, new clients, new upgrade work." But now it's with AI shifting things and with people using AI for upgrades more, I feel like only the people that value the human touch of working with us are coming back and saying, like,

Ernesto Tagwerker  32:08
"Oh, I actually had a good experience working with Fast Ruby, so I'm going to reach out and work with them again." But yeah, it is hard. So that's why I think we invest so much in, like, technical debt and code quality tooling, like Ruby Critic, Skunk, RELS Stats, Next RELS, RELSBomb.

Ernesto Tagwerker  32:27
All these tools are available usually for free or free as in open source. So anybody who has played with these tools and cares a little bit about code quality has probably heard or used some of our open-source libraries. That's usually, like, a good vector to find good clients. And sometimes it's hard to find good clients,

Ernesto Tagwerker  32:48
but you do end up finding, like, good engineers within, like, a poor culture or poor engineering culture. So then you basically have to talk to them as a system to try to get, like, upper management and non-technical decision makers to say, "Oh, okay, it does pay off to have, like, good quality guidelines so that not just humans,

Ernesto Tagwerker  33:10
but AI are writing code that's going to be, like, easier to maintain in the long term."

Joe Leo  33:16
I can understand your point. I also would say that we've had really good clients that don't have stable test suites, right? That's not really what we're after. They may be, like you said, maybe, you know, sometimes teams inherit code that's crazy, and sometimes teams move really fast in search of what they're after. I had an engineer a long time.

Joe Leo  33:35
He was a great engineer. And anytime we would talk to people, because a lot of times teams, they can get a little self-conscious about because they kind of know where the bodies are buried, and they're like, "Oh, I wish it wasn't like this," right? And, you know, he always would say, "You know what? The greatest marker of your success is that you're here talking to us," right?

Joe Leo  33:52
Because you did what you needed to do to build a successful product that's successful enough to pay the people that are working on it, to pay other people, drive a business, you know, to pay us to come in. And so we always want to be really respectful of that. Anyway, but I'll get off my soapbox. That's an interesting way of kind of framing it.

Joe Leo  34:11
When you're looking at these engagements, are you doing, like, a set, like, "Okay, we're going from RELS 5 to RELS 8.1, so we'll just quote you a price," or are you kind of going time materials based?

Ernesto Tagwerker  34:27
Yeah, we usually quote a price. We like to do, like, ballpark estimates, like, worst case, best case scenario between X and Y months to get you there. And of course, the more information we have, the better the estimates. So sometimes when we're having, like, an initial sales call, we will ask our customers or potential customers to send over stats.

Ernesto Tagwerker  34:49
And stats are basically like, "Yeah, what's your code coverage percentage as reported by SimpleCov? What are your RELS stats as reported by our GEM?" Our GEM kind of integrates with Bundler Stats. That basically gives you an idea of, like, the dependencies they have and how hard it's going to be to upgrade. And we have,

Ernesto Tagwerker  35:08
like, a historical database with more than 60,000 dev hours invested over the past eight years on upgrades all the way from 2.3 to 8.1. So we kind of use comparable data to give our potential customers ballpark estimates, and then they make a decision there.

Ernesto Tagwerker  35:26
Or sometimes they get a roadmap that's basically like a $12,000 audit where we invest about two weeks in their code base, learning more about it and seeing kind of, like, where the bodies are buried and stuff like that. And also, like, to complement the other question or the other answer I gave about,

Ernesto Tagwerker  35:46
like, how to find, like, the best customers, like, I'm still trying to figure it out. I just want to make it clear. I don't have a solution for that. I post to LinkedIn to try to find them for sure. But in the sales process, I can quickly tell when some clients are not going to be great clients. And it's usually,

Ernesto Tagwerker  36:06
like, the people that care way too much about the money and the budget and the hourly rate, and they just want to get, like, three or four bids from Death Method, Fast Ruby, Test Double, and they're like, "Okay, cool. We have the numbers. Okay, let's go with this one."

Joe Leo  36:22
Well, if they care about the money, they're picking the wrong three.

Ernesto Tagwerker  36:25
Yeah.

Joe Leo  36:25
But I know exactly what you're talking about. Yeah.

Ernesto Tagwerker  36:28
Yeah, yeah. But they don't really care about the craft, and you can tell in the conversation they just want the number. So I still send the number, but I also, like, can write down in our CRM. It's like, "Okay, this is, like, a 10% likely to convert lead."

Joe Leo  36:44
Yeah, I'm curious if you, like, have found a metrics template to translate to business owners. Okay, if you apply this, you will see this stability, which has this kind of customer impact or outcome, right? Do you have anything that you've,

Joe Leo  37:03
like, been ruminating about, like, where you can, like, help them calculate numbers as, like, "Okay, if you invest this in this, you'll see this kind of outcome"?

Ernesto Tagwerker  37:13
I mean, it sounds like a really cool side project that we should work on, and I'd be happy to give you tokens for you to just go watch what's happening.

Joe Leo  37:22
Yeah, okay. All right. Hey, I'll take you up on that.

Ernesto Tagwerker  37:24
That sounds amazing. And no, I don't have it, and I should. I should have. But yeah, some clients are still trying to understand why a test suite or an automated test suite is a good idea.

Joe Leo  37:38
I think about this too, even just for AI spend. Okay, if you as a business owner, you spend, I don't know, $50,000 in a month for AI tokens, what is that outcome? Like, I'm sure, like, you'd have a bunch of artifacts. It's got to be more than the artifacts, right? Like, what is it generating for you as a business?

Joe Leo  37:57
I don't know that there is that, right? Like.

Speaker 4  38:00
I think the answer for every

Joe Leo  38:00
business owner is not enough.

Ernesto Tagwerker  38:02
Right, not enough.

Joe Leo  38:04
That's mostly what I hear. I mean, maybe if they get rid of an employee, like, they save some money on that. I don't know how much. That's actually, I think, like it or not, I'm having conversations with clients, and I spoke with somebody just last week about this where, you know, he's a high-up executive level. The company got a huge investment from a PE firm,

Joe Leo  38:24
and the question very quickly became, "Okay, how many roles are we eliminating with all the AI that we're putting in here?" I do think that that's the wrong question to be asking, but it's not up to me, right? I think the question to be asking is, "What more can we do?" And I think that's what you're getting at too, Valentino. Like, "Hey, what's that return on investment so that we can do more?" rather than,

Joe Leo  38:44
"Hey, where can we cut corners and save?"

Ernesto Tagwerker  38:46
I see this all the time. I was in consultancy for a long time, and, like, it's always like, "Okay, it's very layered. Yeah, you can go and you can, like, upgrade a RELS app, but then, like, that's not really necessarily addressing any of the tech debt that's there, right? It's just, like, one aspect of the tech debt, right? And so, like, tech debt is, like, a very layered problem.

Ernesto Tagwerker  39:07
You have to balance that as a consultant for your clients. Okay, how much tech debt is worth addressing? Upgrades included versus, like, "Okay, we have new features and we have bugs and things like this that you're helping them realize and balance." Because I imagine you want more of that stipend, right, to help them see more value out of you as a consultancy, right?

Ernesto Tagwerker  39:27
And so I wonder, like, Ernesto and Joe, right, like, as these kind of consultancies, where do you see that layering fit best? Is an upgrade an easy entry point to just, like, helping address the management of those concerns? Where is AI, like, providing the most leverage outside of just automating some of these low-hanging fruit?

Speaker 4  39:47
What I like about the RELS or Ruby upgrade work is that the finish line is very clear. It's in production, and it's running the target Ruby and RELS versions we talked about, and we delivered it on time and on budget. I love that. The problem I see these days is that people,

Speaker 4  40:07
especially, like, non-technical folks, are looking at the hourly rate way too much. In this day and age of AI, the hourly rate doesn't really mean much. It's like the same of using lines of code to measure developer productivity. It's a waste of time to say,

Speaker 4  40:26
like, "We generated all these lines of code with all these tokens and all these people." Doesn't really say anything about value. So, like, time and material, soon a lot of these folks are going to have to learn that the hourly rate is, like, a terrible way to make a decision because you could get,

Speaker 4  40:44
like, 20 hours of Death Method and their hourly rate, or you could get 40 hours from some other shop that's, like, way less expensive per hour. But at the end of the day, you care about value, and you care about keeping the engineers and making sure that they're delivering value. So it is very hard these days to say,

Speaker 4  41:06
"Oh, yeah, it is this much per hour, and you get X amount of value." So I wish there was actually, like, an industry standard for value per hour in the consultancy space, but we don't have it.

Joe Leo  41:19
Great idea. Great solution to this problem. Ready? We're going to solve it all right now. Just everything is tokens.

Ernesto Tagwerker  41:26
Everything is tokens.

Joe Leo  41:26
Right? So, like, yeah, Ombilab's tokens, which represent the hours that are put in, right, are more expensive than OpenAI's because you can do things that it can't. If everything's a token, people stop looking at hours, and it's just like, "Okay, as you're operating LLMs, you're paying for intelligence levels, right? Some intelligence is more than others.

Joe Leo  41:46
Your consultancy's employees are specific tokens of intelligence that are going to outperform any AI agent that they can get, any LLM." I wonder if that's maybe the answer is just like, "Okay, let's bucket humans in the same AI worker category and just say, 'All right, you're going to get the OmniLabs model,

Joe Leo  42:07
and, like, these are our tokens, token rates.'" Depending on who it is, I mean, I'm just thinking about getting that argument passed to CFO, but maybe just thinking about people in units, that might be the way to go.

Ernesto Tagwerker  42:21
Yeah, well, I think there is a point for, like, a new metric that's tokens is a part of it, but for me, it's like experience times tokens or experience combined with tokens. Let's say X tokens is, like, the value you get from these engineers. And then, I don't know,

Ernesto Tagwerker  42:40
maybe that is the metric we need to get to.

Joe Leo  42:42
Yeah, because you think if you're hiring a law firm, right, like, the senior executive lawyers are going to have, like, some astronomical hourly rate compared to, like, some junior. And, like, if you're hiring them and have them on some kind of retainer, you're going to say, "Hey, like, give them more hours." Sure, it might take longer, and they might do worse work, but, like, I just don't want to spend that much.

Joe Leo  43:03
And so I don't know if you can apply the same thing and still uphold the quality of work that outputs for you. But I wonder if there's something there where you could just say, "Okay, this level of person on our team is going to be, like, an extra bump in the allotment of units."

Ernesto Tagwerker  43:19
But yeah, I also agree with Joe that getting the CFO to buy into this whole idea is going to be the hardest part.

Joe Leo  43:27
Valentino brought this up before the show, and we've got a few minutes, and I'd love to just get your take on it, Ernesto, which is why now that we have AI and it can do any language, it can work on any framework, why stick with Ruby? Why recommend it? Why even upgrade it? You know,

Joe Leo  43:46
why not just say, "Well, you know, you're all the way behind at version 5. Just blow it up. Just start over with a Python application or something like that." All the AIs love Python, so why not just use that?

Ernesto Tagwerker  43:58
We still choose Ruby for a lot of our custom AI projects. We might not use 100% Ruby for that particular solution. It might be, like, a combination of Ruby and Python. But at the end of the day, I think Ruby is still more readable than Python and is still focused on developer happiness.

Ernesto Tagwerker  44:20
And we're not quite there where it's like, "We are just going to let the agents run everything in production and fix bugs and yada yada." I know we might be close to that, but a lot of companies out there that still need a human in the loop that's basically approving the changes.

Ernesto Tagwerker  44:39
So if that human has experience with Ruby and can go in and, like, figure out, like, what the AI is trying to do, and many times the AI is trying to do something that's, like, way too complicated for something that doesn't need to be that way, I still want humans that know Ruby and can go in and,

Ernesto Tagwerker  44:58
like, debug and, like, sort out what's the problem. And basically driving GenAI tools to write better Ruby and more sustainable Ruby. I know you guys were talking about, like, Ruby Central in a past episode, and I like the way it's going now with Ruby Central,

Ernesto Tagwerker  45:18
and I know, like, they have an idea to be more present in the AI world. And as a company, we want to somehow support that. I don't know how, but at some point, we want to collaborate and, like, contribute to the community so that we can make Ruby more AI-friendly. And if anybody has ideas on how we can do that,

Ernesto Tagwerker  45:39
we're always happy to entertain them. They can reach us, like, on BlueSky, LinkedIn, and but for now, I like the initiatives that are happening at Ruby Central, and I am hoping they can make Ruby, like, a better citizen in this AI world.

Joe Leo  45:55
I'm not sure I agree with you on the Ruby Central side, but, you know, we're a supporter, and I definitely want to see Ruby Central succeed. To me, it seems like they're trying to spread out in too many directions, and what they really are is a very small group of unpaid volunteers. And I think there's an engineer's inclination, like I was talking about before,

Joe Leo  46:15
to overestimate what any group of us can do. And unfortunately, I think that's what's happening here. I also think that the AI thing, I mean, I'm actually going to reserve judgment on that because I do think it's interesting, and I'll be there at RubyConf to talk about any of these initiatives. I think that's what they're using, right? They're using the conference to gather some like-minded folks and talk about it.

Joe Leo  46:36
So I'll be interested to hear what they have to say on it. But to me, I want them to keep putting on a good conference. To me, that's the most important thing. I think the second most important thing is maybe supporting conferences that are regional, which they've done for a very long time. And to me, we build software that is great at one thing.

Joe Leo  46:55
And if they were great at that one thing, and they have been, right, or they continue to be great at that one thing, I'm happy. All the other stuff, I think, is gravy.

Ernesto Tagwerker  47:02
I see it as a marketing problem with Ruby and AI. It's the Coca-Cola method. You see everybody drinking a Coke, and you want one. And I feel like that's kind of what we're seeing with Python and TypeScript is that's what's used. They see other people using it. You're starting up a project, and, like, the AIs are using that.

Ernesto Tagwerker  47:22
And I would love to see some of these organizations, like Ruby Central, like, focus on that, trying to solve that particular problem. Like Joe mentions, like, conferences. That's one aspect, right, of many. And I think the whole RELS world thing that Amanda has been focusing on, fantastic. Getting RELS out there and advertised worldwide,

Ernesto Tagwerker  47:43
an aspect that has, like, I think, seen positive results from people. And I think the more that we can get that, the easier it's going to be to solve, like, the tooling layer, which I think is more like Ruby Core team. Dump money into that. They're really solving those problems, I would hope. Like, I know Matt has talked about this before the, you know, RubyKaigi conferences.

Ernesto Tagwerker  48:05
The Ruby Core team is going to focus on, "Okay, how can we make Ruby AI-friendly and AI-supporting tools?" And I don't know. That's my take.

Speaker 4  48:14
I agree with that.

Ernesto Tagwerker  48:16
I also understand, like, Ruby Central messed up with RubyGems and Bundler and all that, and I think they're trying to, like, reform the organization and, like, basically take it in the right direction. But yeah, now it's, like, still, like, too soon to tell whether it is the right direction or not.

Joe Leo  48:36
When I hear about supporting AI in open source, I think about, you know, like our friend Karma and, you know, friend of the show, you know, Ruby LLM. I think about things like Next RELS, right? Like, tools that are either AI-enabled or AI-focused that work really well with Ruby.

Joe Leo  48:55
Is that the kind of thing that you're talking about that you'd like to see support for those kinds of things?

Ernesto Tagwerker  48:59
Yeah, I guess I'm torn, right? Like, because we have, like, this dichotomy of, like, Ruby tooling and ecosystem infrastructure that has historically been, like, Ruby Central focused. Okay, and conferences on top. And, like, what we're seeing over time is, like, conferences are, like, a big commitment, right? And they end up eating up a lot of resources. Should those two layers coexist,

Ernesto Tagwerker  49:19
I feel like that's where a lot of the friction happens. And so I'm wondering, like, Ruby and AI as, like, a concept together is really a marketing problem, right? And seems better suited for that layer of conferencing and marketing and, like, I was saying the Coca-Cola method of you see everybody drinking a Coca-Cola and you want to drink one is the mentality of,

Ernesto Tagwerker  49:39
like, where programming languages fit in the AI landscape. As far as what people reach for, what the AI reaches for, those are all those marketing problems that have different solutions, right? Different paths, different people that would be better at solving those. So I wonder if it's a disconnect of that more than anything.

Joe Leo  49:56
That's an interesting perspective.

Ernesto Tagwerker  49:57
I don't know. I'm excited for conferences. So, like, I always get great takeaways, meet great people. I don't know if I'm going to be able to make this particular conference. I would love to. But I did make the last Ruby or RELS Conf, which was fantastic in Philadelphia. And it was, you know, it's just great to connect with people and, like, see what they're working on. And,

Ernesto Tagwerker  50:16
like, I feel like you come away and build something new because of that, right?

Joe Leo  50:21
You almost took the words right out of my mouth. I mean, for me, I just it energizes me in a totally different way. And I go to the local meetups for the same reason, right? They'll give me, like, a little charge every month, and I go to a big regional or big national conference, and I get kind of a bigger charge. You know, and it sets me up for months after that. And I'm looking forward to this one for the same reason.

Joe Leo  50:40
And I'm actually I bought a ticket to RELS World for the same reason. I haven't been to RELS World. And lo and behold, there's no more RELS Conf, so RELS World is here in the US this year. And I think that's great.

Ernesto Tagwerker  50:50
I'll be at RELS World too, and it's going to be my first one as well. Couldn't swing going to both of them, so I had to pick between RubyConf and RELS World. And I've never been to Austin, Texas, so I think that was one of my main reasons to go. But yeah, I'd love to see if people want to talk about Ruby and AI at RELS World. I'd be happy to talk about that.

Joe Leo  51:13
Just a plug for these conferences, and I know, you know, I think Ruby Central is not sold out yet, so you can still get tickets. And I think we're publishing this before the conference. And I don't want to toot our own horns too much here, but, you know, the three people on this podcast are three very successful Rubyists that have been around for a long time. And part of it is I see you guys at every conference.

Joe Leo  51:32
You know, Ernesto, you've run Philly RB for, I don't know, it feels like 100 years. And yet, you know, you live out there in New Jersey. You still come over here for Artificial Ruby. Valentino, you and I met at Artificial Ruby. You're a speaker at conferences. You both are. You go to conferences all the time. You support the community, but you do it because you get something out of it. And, you know, that something is it's not always easy to pin down,

Joe Leo  51:53
but it's easy to see in retrospect that it really has a large positive impact on our careers.

Ernesto Tagwerker  51:59
I actually prefer to hang out in the hallway track. I can catch the talks later. I can watch them online. But I get the most energized when I talk to other people and I hear what they're doing in Ruby and RELS land.

Joe Leo  52:12
Yeah, except when we're speaking. I know you come to those.

Ernesto Tagwerker  52:14
Oh, of course. Yeah. I never miss your talks.

Joe Leo  52:19
Yeah, I know what you mean. I mean, because, yeah, these days, I do a lot less coding. And so can I go to the talk and learn about the next gem or about the next thing? I could. And it's always interesting to me. But yeah, I love talking to people in between. I love seeing people I haven't seen in a year. It's great. So we're coming up on time here. It was really great to have you on the show, Ernesto.

Joe Leo  52:39
Great to learn, you know, about the evolution of Fast Ruby and about Anbu Labs as well. Anything you want to plug or say before we sign off?

Ernesto Tagwerker  52:47
Yeah, I think it would be great if anybody wanted to give our Claude skill a try, especially if you're running, like, a really old RELS version. We'd love to know if it worked for you. If it didn't, we don't have any sort of, like, telemetry code in there. So the only way I have to know whether people are using it,

Ernesto Tagwerker  53:06
if people are starring it on GitHub or telling me, like, at meetups, like you said. But yeah, I'd love people to give it a try, open issues if they find any, and hopefully, it'll make their next upgrade project easier.

Joe Leo  53:21
And thanks also for the great work you're doing with open source. I mentioned Next RELS, but you mentioned Ruby Critic a couple of times, and I just want to give a plus one for that. That has been a fantastic gem for years and years. And, you know, we're really happy that you steward it. We still use it. You know, to this day, it's a really excellent way of just getting to understand your codebase and what you need to do to improve.

Ernesto Tagwerker  53:42
Yeah, it's a pretty cool evolution to MetricFu. I remember the first Goruko I ever went to, I sat next to someone, and they were talking about MetricFu, and I was like, "Oh, that is so cool."

Joe Leo  53:53
Is that in a basement in a Delphi?

Ernesto Tagwerker  53:55
I think it was at Pace University.

Joe Leo  53:57
Oh, Pace. Right, at Pace. Pace Pace, yeah.

Ernesto Tagwerker  54:00
And it was around the time, I think, when RELS 2.3 and 3.0 were merging. So I remember MetricFu was such a cool thing. And we actually are the maintainers of MetricFu, but a lot of the tools that it used are kind of dead. So we might just focus on Ruby Critic from now on. But yeah,

Ernesto Tagwerker  54:19
and if anybody loves Ruby Critic or wants to give it a try, it's, like, a great tool to learn where the complexity of an RELS application lives. So happy to maintain it, and thanks for your words, Joe. I appreciate it.

Joe Leo  54:33
Yeah, a plus one to that too. I have used Ruby Critic for years as well. Fantastic.

Ernesto Tagwerker  54:39
Oh, and a small announcement. Now JRuby is officially supported by Ruby Critic. I made sure of that last week.

Joe Leo  54:46
Oh, excellent. Oh, that's awesome.

Ernesto Tagwerker  54:48
Yeah, Charles Natter and I have been talking consistently, and he's helped me be a better JRuby citizen. So quick announcement there for you.

Joe Leo  54:58
Good. Good. JRuby is fantastic. I've used that before on projects. And. Yeah, me too. Yeah. If you have a Java world organization that you're supporting. Yeah, stop writing in Java. There JRuby exists.

Joe Leo  55:13
The Well-Grounded Rubyists, it's long-awaited publication date is imminent. So maybe by the time this goes live, but probably about a week later. So check it out.

Ernesto Tagwerker  55:22
That's great. And thanks for all your work on that as well. That's one of my favorite Ruby books, so it's awesome to be.

Joe Leo  55:29
Yeah, thanks. That is a labor of love. And it was great to be able to hook up with David Black again and work with him on this. He's just brilliant, and his writing is incredible.

Ernesto Tagwerker  55:37
Yeah, I've got one small announcement. It's just kind of fun. My bot Minerva has created her own website, minerva.codenamev.com, to journal our progress and reinforcement learn off of that. So if you are interested in what my bot is doing for me, you can go there and find out.

Joe Leo  55:56
Oh, awesome.

Ernesto Tagwerker  55:57
She brought it up. She it brought it up. And I thought, "Eh, that's a great idea."

Joe Leo  56:01
Give the lady what she wants.

Ernesto Tagwerker  56:04
All right, well, thank you so much for coming on, Ernesto. This has been fantastic.

Joe Leo  56:08
Yeah, thank you.

Ernesto Tagwerker  56:08
Hopefully, we get to meet in person and we can talk about all kinds of stuff. Thanks for having me. It's been a pleasure. Have a good one.

Joe Leo  56:15
All right, guys. Thanks.