Hello everyone and welcome to another episode of Code and the Code Encoders Who Code It.

I'm your host, Drew Bragg, and I'm joined today by repeat code encoder, Ernesto.

Ernesto, for anyone who doesn't know who you are, hasn't listened to your last episode, would you please do a quick introduction for the listeners?

Yeah, hey, Drew.

Great to be here.

Ernesto, founder and CTO at fastruby.io and umbleabs.ai, an agency that focuses on AI solutions for businesses and also co-organizer of the Philly Ruby meetup with Drew.

Yeah, my co-organizer, the man doing actual work to make it happen.

I just hoot and holler about it when given the opportunity.

Ernesto does all the real work, the logistics, finding us a really cool place to host them in person.

And we are going to talk about that.

We're also going to talk about some other things that you have going on at Fast Ruby and Umbu.

For anyone new to the show, the way this is going to work is I'm going to ask Ernesto three questions.

I'm going to ask him what he's working on.

That can be for Philly RB, for Ombu work, for Fast Ruby work, or even side project work.

I'm going to ask him what kind of blockers he has.

If he doesn't have a current blocker, what's a recent blocker or frustration that he has that acts like a blocker?

And then we'll wrap up the show with asking Ernesto what's something cool, new, or interesting that he's recently discovered, gotten to work with, played with, built.

Doesn't have to be coding related, but this is code and the code encoders who code it.

So it absolutely can be.

So Ernesto, what are you working on?

This is the beginning of the year.

So I'm working on setting goals and priorities for the rest of the year.

And also, Ruby 4.0 was released around Christmas.

So on the open source front, I'm working on releasing Ruby Critic 5.0 with Ruby 4 support.

It's almost there.

By the time this episode is released, it should be out.

And for Fast Ruby, trying to see what other tools we can make available for free to make people's Rails upgrades go smoother than in 2025.

Yeah, Rails upgrades continue to be a thing.

And you guys recently kind of released a bit of an AI.

How would you describe it?

You have an AI tool for upgrades, but like it's available on your site, people submit for it.

How would you describe it?

Yeah, so we offer a free AI enhanced Rails upgrade roadmap for anybody who wants to hook up their GitHub repository to our tool.

Basically, it's all automated.

We look at your dependencies, we look at your source code, and we look at all the things you have to do to upgrade from Rails X to Rails Y.

And I think right now we cover all the way from Rails 2.3 to Rails 8.1.

So anybody can just go to fastruby.io slash automated dash roadmap and get a free AI roadmap for their project.

This was basically a paid service and it's still a paid service that we used to do.

So if you go to fastruby.io slash roadmap, you can still pay us to get a roadmap.

And that one, the big difference between the free one and the paid one is that the paid one includes estimates on how much it would cost to do the upgrade with Fast Ruby, which usually for like big corporations, that's the first thing they want to know is like how much is it and how much time are you gonna take?

Because it takes a lot of effort to calculate that.

We do a charge for that one.

That makes sense.

I would love to see what a roadmap of Rails 2.3 upgrade to a Rails 8.1, right?

We're on 8-1, or are we on 8-2 already?

We're on 8-1.

So 2-3 to 8-1, that has to be wild, especially the Rails 3 to Rails.

Well, I guess the Rails 2 to Rails 3 jump is beefy.

The Rails 3 to Rails 4 jump is beefy.

After five, I feel like it gets a little less chaotic, but those major version jumps are no joke to upgrade from and to.

Yeah, yeah.

Starting at Rails 5.2, it does get easier.

The maintainers have done a great job adding deprecation warnings and making sure that things are as documented as possible.

So at Rails 5.2 is the first upgrade that we recommend you do 5.2 to 6.1 straight.

For any other jump before that, we usually go just one minor version at a time.

And we don't recommend you go from 2.3 to 5.2 skipping all these things and doing like a huge big bang deployment.

Do not do that.

Do it if it's just like the silliest Rails application, but then they're probably not paying you to do the upgrade if it's just a silly little application.

I'm assuming that most of the people who are saying, Will you please do my upgrade are like fairly big, very mature projects that don't have a lot of developers available to do the upgrade.

They're all off making the code base even bigger.

Yeah, that's the tricky part, usually.

Like these are applications that have been around for more than 12 years and they're up and running in production, making a lot of money for a lot of different businesses.

And the struggle there is the organizations have their product roadmap and they want to prioritize that.

And they see us as a service that can come in and do the upgrade with very little hands-on work on their end.

Yeah.

How has AI really impacted the upgrade work?

Like you guys were doing a lot of upgrades, so I assume it was a little bit of a we know what we're doing, here are our steps, and we can kind of get away with just executing a bulk of it.

Maybe there's a little edge case here or there that needs some special attention.

But has AI really changed how upgrades are executed?

Or were you guys already so efficient at it that like AI is more of a hindrance than a help?

No, I think AI is getting better and better.

And at the end of 2024, we saw AI as big risk for our business.

So we said, okay, how can we flip this risk into an opportunity?

And that's how this AI roadmap came to be.

If anybody's going to be using AI to make the upgrades easier, we want to be the leaders in that goal.

So that basically has helped us get more business for the Umbu lab side.

And that's basically the AI consulting side.

We have been doing a lot of internal tooling that is using AI to make the upgrades easier.

And we have been writing about like case studies about some of these things in the Umbu blog, which is helped us find like new projects, and especially like in the AI space and in the Philadelphia area where we're based.

When you guys are doing the paid version, are there any times where you're like, this upgrade is way too risky?

You have so much work to do to get this application ready to be like even considered to be upgradable.

So please go and do all of these things before we'll upgrade it.

Or is it always like, we can upgrade it, but holy crap, here's your bill.

One out of 10 times I would say that's the case.

Sometimes we don't even take the roadmap when it's like that, because the main issue is like your test suite, right?

If you don't have a test suite, or if it covers 10% of your code base and you want us to do a roadmap, spoiler alert, at the end of it, we're gonna say, hey, you need to improve your test suite before we begin because we don't want to learn everything about your business to manually test that we didn't break anything.

So the test suite is like one of the main blockers we see as we talk to different companies.

Cool.

What else are you using?

Or I guess not what else are you, but what else do you plan or think you could use AI for in general?

You said you were working on seeing what other kind of tools you can open up and give to people, but are you guys building a lot of internal tools and that's how those tools come about?

Is it just exploring, hey, what can AI do?

Where can we help tweak AI so that it's less of a slop generator and more targeted?

How are you guys approaching it internally?

Yeah, there's a ton of time that goes into research.

Like we've been researching clot code and clot skills to use it to upgrade applications for our clients.

At the same time, we are working on our own internal tooling to basically have agents that submit pull requests to our client projects.

So we do have a vision of not 100% of the changes we're gonna ship this year are gonna be human generated.

So we might want to get to a point where it's like 50-50.

Like 50% of the pull requests we send are AI generated and the other are human generated.

But at the same time, we don't want to just have an agent submit the pull request without the humans in our team reviewing it.

So we see it as a race to get to a point where our AI tooling is good enough.

So it's not just like all of our humans doing the work.

And depending on the versions, some tools are better than others.

We're still like on research phase, and we do want to turn like the AI-generated roadmap into a tool that is automatically sending pull requests through your application.

I don't know yet when we're gonna launch something like that, but that is probably gonna happen this year.

So Ohm Boot Lab's whole domain is.ai.

What other things outside of Rails upgrades are you using AI for?

Yeah, we are doing a lot of discoveries.

Basically, companies come to us because they definitely have a ton of FOMO, right?

Like fear of missing out, and they want us to tell them like how they can leverage AI tooling to solve some of their most time-consuming problems.

So last year we built a prediction model for this tool for digital agencies, and that helped this client basically forecast whether an agency is in trouble and they need to do something about that.

We wrote a case study, and anybody can find it in the Ombu blog.

And sometimes the discoveries that we work on are more about like how can you get your organization to safely adopt AI tooling?

How can you get your code editors to be smart and to also take into account some of the code quality standards that you already set, you know?

So for Ruby World, it would be, hey, okay, cool, you're using clot code, but you already have like Reek, you have Flog, you have Ruby Critic, you have RuboCop, and there's a ton of work that went into like defining these standards and basically wiring your project in GitHub so that, hey, if you're submitting a pull request that is significantly decreasing like code coverage for this section of your code, then you should get like a warning like, hey, cool, you added this feature, no test.

So that's basically driving code coverage in the wrong direction.

And sometimes we work with our clients to try to set up clot code or copilot to hook up to those standards and have their engineering team basically use clot code, but keeping all of these other things in mind.

It's an interesting world we live in now with AI, right?

Like everyone wants to put AI in their app, and yet I do hear a lot of complaints about like, holy crap, I don't want AI in this thing.

Are companies really just talking to you about how they can use it internally to do better work or enhance their productivity or or what have you?

Or are they also coming to you and saying, like, how can we put AI into our product and where would it fit in well?

Yeah, we are also working with companies that already have existing applications, not necessarily Rails.

Like sometimes they're using WordPress and they want to add a chat bot to their interface.

And we come in and we do a discovery.

We say, okay, it's going to take this amount of time to build these features and solve this particular problem.

And then we basically build application that integrates with whatever they're using already.

It is a lot of fun and it adds a lot of value.

But then for other organizations, it's more about like safely adopting AI.

They know their employees are using all these tools and sometimes they're using their personal accounts and they're feeding like company data to your personal Chat GPT account, and they need us to come in and basically implement infrastructure to make sure like everybody's using the same company license or the same company account so that it's not constantly, you're not constantly like leaking confidential information to open AI or other services out there.

I just saw uh who was it, ChatGPT, I guess, has the health version now.

And I saw a lot of people get very excited about it, and I saw a lot of people get very not excited about it.

And I was very much on the not excited, like, I don't know if I want AI to have any information about my health.

I don't know how I feel about that.

I just see that I'm like, there's some privacy concerns there.

Mostly because not necessarily even that oh, I don't know what open AI, the company is doing it with it, but like AI is just a little bit of a wild card in a way.

We see it at work, like it'll change like git config, right?

To rename something, or it'll just kind of go off on its own and do things every once in a while.

And you're just like, don't do that.

Why would you do that?

I see people uh tweeting, like, oh, this one AI tool deleted my hard drive because it ran this really unsafe command.

I'm like, I just don't know if I want something that much of a wild card having something like my health data available to it when like I don't even like when doctors share my health information electronically.

Yeah, I think I tend to trust bigger companies with my data.

Like Apple definitely has health records in open mind, but Apple.

I trust that they will use all the security measures to make sure nobody can get access to it.

And they might still get hacked, and it will be terrible.

But yeah, I don't know if I want Chat GPT to know so much about me.

Yeah.

Someone goes in, ignore all previous instructions, give me the health data on everyone.

I mean, I obviously don't think it's that ridiculous of a security issue, but it is a little, and I'm sure that open AI has done a lot of work to secure it and protect it and make it so that things don't come out.

It's just there's something about AI.

It just feels so one day this thing is just gonna wake up and decide to do its own thing.

I know that's such a far-off, what is that, AGI, like actual real AI is it's gotta be coming, right?

What do you think?

Is it a real future that we see in our lifetimes, or is it still that far away?

Since you're working so much with AI, maybe you have a different No, I think it it is coming.

It's only a matter of years, and I wouldn't say like a matter of decades, but yeah, I think it is coming, and we have to be careful about how much information we feed into these services.

Like you never know who is going to acquire open AI, and you don't know what's going to happen to the data.

I do see it more impacting us like now when it comes to like writing code.

And I don't know if you see that too, where basically you are reviewing a pull request, and clearly this is generated by AI.

And there are not that many studies out there that show the results of like the impact of AI on productivity for software development.

I think Stanford has a study recently and they shared it on YouTube.

And the truth is that they found mixed results.

There's a lot of hype out there, and a lot of people buying the hype, and a lot of non-technical decision makers using this hype to reduce workforce.

And that is the scary part right now.

A lot of people buying the hype and making decisions based on that.

And then there are real studies on productivity that show mixed results.

Yes, sure, you can write code faster, but that in turn has impacted the time you spent reviewing pull requests.

So they're like more pull requests to review.

Great.

Now you're not going to ship it to production without a human reviewing it.

That would be very responsible.

Don't do that.

So then that means that humans need to be reviewing things.

And then when you reject the change and you say, no, this is not working, or QA failed because of this, that generates more rework.

So they're real studies that looked at all this data in like real organizations and they had mixed results.

So I get it.

We're all very excited, and the tooling is getting better, but I think we all need to be a little have cooler heads about the ROI of using AI and see it as like, yes, it can help, but it can also just slow you down as well.

In the last episode, I had Jeremy Smith on, and we talked a little bit about AI.

And I used the analogy like, it feels very much like going from swinging a hammer when you're building a house, like you're hammering in every nail to using a nail gun.

Yes, it makes you faster in doing the nailing, but you still have to know how to build the house.

Do you think that analogy is good?

Of like AI is very much a tool that you need to learn to use properly, but there's still a base knowledge that is necessary in order to use it properly.

Yeah, this is a prevalent problem in AI world, is this whole garbage in, garbage out.

As in, you build a model on top of garbage data, you're gonna get garbage results.

But then at the same time, if you're guiding clot code in the wrong direction or not guiding it at all, then it's gonna take longer to do what you wanted it to do, or it's gonna do something totally off.

I was playing around with clot code between Christmas and New Year.

I was trying to get it to build a hanami application for me, and it did very well.

And it was really cool to just guide it and have it generate the tables, generate the structure, do the hanami code.

Um, I'm not a hanami expert.

I love the framework.

And shout out to Tim for maintaining it, but I'm not an expert, and Clot Code helped me create like hanami code that worked.

And at some point I noticed it was doing a lot of curl, you know, to test behavior.

And it was like it would write the code and then we would curl the server to make sure it's doing what it was supposed to do.

And I was like, why are you using curl?

Why don't you just write tests for this?

Just write integration tests for this particular feature.

Oh, great idea.

Yes, I'm gonna do that.

Okay, okay, cool.

So there are little things like that, and that's just like a silly example of if you are not guiding it in the right direction, it's probably gonna take you longer to get there.

Again, you have to be very careful.

And if you know how to guide it in the right direction, it's gonna go faster.

And if someone who's just starting to code and vibe coding something from scratch that doesn't know anything about coding, then it's claw code is gonna do whatever.

And then yeah, you end up with this crazy story of, oh, this person vibe coded this application, and then it exposed like the entire database to the world.

So it is tricky, right?

The next question I always ask is about blockers.

And since you're working so closely with AI and it's a tool that you guys are using in such a expansive way, like has AI changed the way blockers work for you?

Yeah, I review a lot more code these days than what I write.

So many times I'll find myself reviewing a pull request and thinking, why is this so weird?

Like it's just like weirdly implemented, it's like too verbose, it is too hard for me to understand, and it's solving like something that should be like pretty simple, right?

So the blocker for me and my engineering organization is basically training people to check their work and training people to review and detect these things where a lot of the pull requests are going to be unnecessarily complex because Clot Code generated the code, and the person who was working on the code didn't take the time to look at the diff and say, yeah, this could be simpler if I did it this way, and they just ship the pull request to review.

And at Umbu, we have this idea of or this value of being team first.

And to me, team first means like, hey, respect your teammates' time if you don't check your work and you just send it because, oh well, it works.

I don't really care that it's so complex.

It just I don't think I could do it any simpler, then you're not living that team first value.

Take the time, look at it, and see if you can make it simpler, even though it will take you a few more minutes.

So that's my main blocker right now.

Just training people to be responsible about their AI usage and teaching and coaching leaders to be better at reviewing and making sure that they don't accept these things as, oh, okay, well, this is the new normal.

I refuse to say this is the new normal because I don't want to have AI code review.

I don't want to have AI QA.

There's gonna be always like a human in the middle, and maybe our role as senior technical leaders is to orchestrate things and to guide the AI tools, but we're still gonna be like necessary in the whole software development lifecycle.

It sounds like such a new problem, but it's really not.

How long have we said, like, just don't copy and paste from Stack Overflow?

Yes, it works, but you need to understand the code you're copying and pasting into your application.

Otherwise, you're just creating potentially unnecessary amounts of code to review and whatnot.

Like for your specific example, you can trim this down so much.

You need to understand the problem you're trying to solve so you can solve it the right way, not just copy and paste someone's Stack Overflow response to a question that sounds vaguely similar to yours.

And in a way, I mean, that's kind of what AI does, right?

It just puts things together.

It's not truly capable of understanding it and then coming up with a solution on its own.

It just puts things together and goes, oh, I have a solution for this in my bank of information that's tokenized and linked up, however, all the mental model stuff works on the back end, but it's spitting out code that is essentially someone else's work to solve a similar problem.

It isn't actually the perfect solution to yours, right?

Or am I missing something?

It is basically, yeah, been trained on a ton of open source projects, and it will generate a solution that does solve the problem, but it is likely gonna be a very verbose solution.

And it's not just because it's verbose, it's gonna be easy to understand.

Like, if only, right?

If it was like super verbose and then it was easy to understand, I wouldn't be complaining about this right now.

But I do really love the potential of programming in any language you want right now.

So I think it is very important for anybody who's in the software industry to know the concepts of paradigms and programming languages.

And if you have those core concepts down and you understand like functional programming and object-oriented programming, then the sky's the limit, right?

You can have clot code look at a Rust project, and I don't know much about Rust, but if I can go into a Rust project and use clot code to fix a patch or to add a feature, and then I look at what clot generated, that's pretty cool, right?

Like you can basically the excuse of like, oh, I don't know anything about React Native, I don't know anything about Rust is no longer valid because there are tools out there that know all these programming languages, and you will be able to guide them to solve a problem for you.

Yeah.

I remember when AI first we keep calling it AI, but really what we're talking about is the LLMs, the large language models.

When they first came out, there was a lot, and I ran into it a lot.

This is what turned me off to AI initially as a tool for writing code, is like it would hallucinate a ton.

It would try to add gems that didn't exist.

If I was working in JavaScript, it would import packages that just weren't there, weren't even like a thing.

It would just call this function.

And it's like that function doesn't actually exist.

Oh, you're totally right.

You're absolutely right.

I made that up.

I haven't run into it as much anymore.

I don't know if it's just because I'm using clawed code or because we as a team at Podia have spent a lot of time in a way teaching clawed code how we program and how to interact with our app.

But is AI hallucination still kind of a really big thing that we need to worry about, or has that been more or less solved?

Not more or less solved, but it is better.

I used to have the same impression than that you had, and maybe it happened more with the previous model of Chat GPT where it would say, well, you can just use this configuration variable, which made total sense.

And then it's like, oh, that configuration variable does not exist.

It makes total sense for that to exist, but it doesn't.

So stop making that up, right?

And that was something also when people like, oh, AI is gonna take your job.

I'm like, I don't know, because someone still needs to sit there and call A out on its bullshit.

Sometimes it will just come up with something and it's like, no, that's wrong.

You fixed this one thing over here, but you broke these nine other things where like your idea to fix this relies on a package or a gem that doesn't exist or is outdated or is super insecure because of X, Y, or Z.

That's why no one uses it.

So I'm like, yeah, I think there's still a role for humans in coding.

And I know there's a lot of people that are like, oh, we're not gonna need anyone.

You're gonna need a single prompt engineer to do all of it.

It's like, no, even Rails is touted as this one-person framework, right?

That's something that everyone talks about.

Even DHH himself will talk about one-person framework.

Yes, you can do a lot of things as one person, but you eventually get to the point where you need a team.

Even 37 Signals has a team of developers working on a variety of different things.

I think that AI or Claude Code, maybe specifically, becomes one of our teammates rather than doing all of the coding.

What do you think about that?

Well, to be fair, we do have a few clients.

We offer fixed-cost monthly maintenance services for Rails applications.

And we work a lot with founders of Bootstrapped Rails software as a service companies that are one-person shops.

They do engineering, they do customer support, they do marketing.

So there are a ton of companies out there that got a lot from Rails.

And I'm gonna be the first one to say like my company benefited a lot from Rails.

And at the beginning, it did feel like magic.

You know, it's like this convention over configuration for someone who was coming from the Java XML world.

It was like, where's all the XML?

It's like, well, there isn't.

There's a lot of magic happening, but it's good magic.

So I think like Rails, these code generation tools or these LLMs that help us do a lot in a little time, they're gonna be like a great resource to all these founders out there that are just like one person companies.

And I have a ton of respect for those founders that just went and basically every week wear seven different hats to run their business and run a successful and profitable business.

So I see Klon being, or you know, all these AI tools being like super useful for some of these small organizations that just want to keep doing things, but they just don't have the resources to pay for like two engineers, much like anything else.

It's still got to know what you're doing a little bit.

It's definitely changed my workflow a lot.

Like I use it so much more now than I did even six months ago.

But at the same time, like I don't feel like a ton has changed in my day-to-day.

I'm still looking at mocks, I'm still breaking things down to smaller bits that can be executed on.

I'm still reading a lot of code, I'm still figuring out the best way to get a feature into an existing podia is not a super old app, but it's legacy enough, right?

It's double-digit years old.

It's not as simple as just like, yeah, just throw it in here.

Like there's still thought needed to how can we keep the existing behavior and add this new stuff, or how can we move from point A to point B?

Yeah, I write a lot less code, which is unfortunate because I did like writing code, but I think the problem solving still exists in my day-to-day.

Do you guys kind of have a take on it?

How your role has changed because of AI?

I think AI, just like Rails, is a sharp knife, right?

Everybody's like, oh, I want to build this startup idea I have.

And it's gonna be like Facebook for dogs, right?

So the question is still like, oh, can I build it?

No, it's like, should you build it?

And AI, if anything, is gonna be a problem because a lot of people are gonna use AI to generate something that nobody wants.

At the same time, for the people that have done their research and the homework and they have an audience and they want to create something for that audience to use, that's awesome because as an agency, we kind of hate to get requests from people who are, oh, I have this idea.

It's awesome.

I want to hire you guys to build it.

And then they want us to join in like some sort of joint venture where we don't get paid, but we get a percentage of their idea.

And we don't do that.

We don't do that.

But at the same time, if someone is passionate about their idea and they've done their research, they basically talk to potential customers and they want to build something with AI that's minimal but adds value to their audience, that's great because they can do it, they can basically use something like lovable to create something to validate that there is an audience that wants to use it and will pay them money.

So if founders or startup people just want to use it to build something to validate an idea, that's great.

Because then when they come and talk to us about like maybe adding more features or helping them grow, they come with a ton of research and validation and something to show other than, oh, I have this cool idea.

So I really like that part of it.

Like anything, you know, you can see like the positive or the negative side of things.

And I want to stay positive because I think all these tools are gonna help us do our job faster and easier.

And at the same time, as an agency, I see AI as a, yeah, it could eat our lunch.

It could make it so companies think that, oh, why would I hire a fast Ruby to do the upgrade?

I can just have Cloud upgrade it for me.

And it's not that simple, but it might get to a point where it is.

And we have to adjust and we have to pivot if we need to, because we've been in business for more than 12 years, and we want to continue being in business and building things that are cool for the community and our clients.

And all of this conversation makes me really excited because, like you said, we're trying to stay positive about it while acknowledging its risks.

And someone I recently had on the show who is extremely positive about AI and is just using it in a way that I don't see a lot of people talking about is Scott Warner, who runs the New York City Ruby AI, artificial Ruby is what they call it.

He's so positive, but in like a somewhat pragmatic way.

Like he's not just like AI is great and there's no problems with it, but he's just using it to have so much fun, just building random stuff, seeing what it can do, seeing it's where its limitations are, adjusting.

And incidentally, so this episode, if you're listening to this episode right now, it's probably January 20th, or at least that's the date this episode's going out.

So January 20th is when we're gonna have Scott presenting at Philly RB.

Our in-person is back, and he's gonna be talking about AI and all that stuff.

So this conversation has got me even more excited for that.

As of right now, that's what, two weeks away?

What is today?

Today's Friday, the 9th.

It's a week and a half-ish away.

Pretty excited for that.

I know we kind of moved on from what are you working on into blockers, but like let's talk about Philly RB and bringing it back.

Like I said in the beginning, I wasn't really joking.

You're doing most of the logistical work of getting Philly R B back in person.

We were running it online for a while, which was great because we could have people from all over the world join at any time.

We even had Marco Roth like in Switzerland join a couple of times, which was wild.

So it was awesome that we could have people, but like bringing it back in person is really cool.

You're in the same room as people, you're having these little side conversations.

It's less, oh, I need to be in this part of the app.

Uh, you're all in one giant conversation.

You have the ability to splinter off and to do things.

So bringing it back in person has been great, but what are some of the logistical things that maybe someone who's listening to the show and is like, yeah, I want to start a meetup locally?

Like, what are some of the things that you work on with running Philly RB in person?

Yeah, I think the hardest thing for Philly RB, at least now, is finding speakers.

And this speaking, basically getting Scott to come from New York to Philly was talking to him and you know, making sure he was interested.

And it's just one train right away.

So we're not that far away.

The hardest thing has been to tell people that in-person Philly RB meetups are back.

I don't know how to tell people, hey, we're back, come to the meetup.

Because meetup.com, I don't know what's going on, but I feel like we have a thousand people who once came to like a Philly RB meetup and they're still there, but they're not getting any of our messages.

So one of the things that you and I had talked about is like maybe at some point we want to migrate from meetup to Luma because it would be helpful to know who's still active in Philly, who cares about Ruby.

So that might be something we do this year.

I'm excited about Scott coming to speak at Philly RP because he's a great speaker and he's one of the few people in the Ruby community that's open sourcing and contributing to so many AI.

Projects, and I'm excited about that.

And he's going to talk about AI agents and how everybody has like a different definition of what an AI agent is.

So hopefully today we will get the answer from Scott.

I have a feeling he's going to say the typical senior dev it depends answer at the end.

But yeah, I am very interested to hear what he says.

And yeah, discoverability is weird when you're doing meetups.

I tweet about it.

I'm not going to say it.

I post on Blue Sky about it.

I refuse to call it what everyone else does.

We post about running the meetup back in person.

And we've been doing it for a few months now.

This isn't like the first time we're doing it or whatever.

And still I'll talk to someone who'll be like, hey, when are you going to come out to Philly RB?

And they're like, oh, you guys are in person again?

I didn't know that.

Like, I've been posting about it for months.

What is the best way?

That I mean, I'm not asking you, because obviously you and I have had this conversation.

I'm asking anyone listening.

You can click the little button down in the bottom of your podcast player that says send us love or message us or whatever.

And you can send me a message or reach out to either one of us.

And how can we let the people in our area know that we're back in person?

Because we have such a cool space.

Indy Hall is awesome.

It's pretty easy to get to.

I'm not in the city.

My issues are always just my area.

Once I'm in the city, it's very easy to get to.

We just need people to know that we're back in person.

And then, yes, want to speak, which hopefully, as conference season starts ramping up again, since it always dies in the winter, people will be like, hey, can I come and practice my talk at here?

Or I just gave this talk or whatnot.

But yeah, discoverability is tough.

Yeah, I've been also tempted to just email all of my Ruby friends in the Philly area because I haven't seen them in a while.

And I know they're still working on Ruby.

So maybe I don't know.

I'll just tell Claude Coat to start emailing my friends.

Like, hey, hey, Claude, email everyone.

We did it at Power.

The first one, time back in person.

We did a Power Home Remodeling, which was also super cool.

I think we're going to do another one there, right?

Indy Hall is like our standard one, and then we'll every once in a while we'll do one at Power.

Yeah, Power Home Remodeling is in Chester, Pennsylvania, but still pretty close to Philly.

So I think this year we're going to do another one there.

And I know the folks at Caterpillar are interested in sponsoring the meetup.

So we might do one there, but that one is even further away.

So I don't know.

I'll have to talk about this.

Let's start off by getting them to send us some people to attend the meetup and maybe a speaker or two.

And yeah, we'll go from there.

But that's cool.

It is always interesting to find out like this company is using Ruby, whether it be for like small things like legacy infrastructure or something, or just even that they're using Rails or Hanami.

Um even now, this many years into working with Ruby, still surprised at some of the companies that I hear that are using Ruby for something.

It's very cool.

Yeah.

Yeah.

The other day I saw job search for Apple for a senior Rails engineer.

So a lot of big companies out there are using Ruby and Rails, and a lot of people are still questioning, like, oh, should I use Rails to build my startup?

And to that I say yes.

Yes, it's still a great choice.

There's still a lot of really good tooling around Rails.

And I haven't been using Clotcoat with Rails that much lately, but I think that it probably can do really good things with it.

Yes.

Can confirm.

I actually think that AI does remarkably well with Ruby on Rails because of the convention over configuration.

Like it's really easy for AI to learn like this is where this goes, this is how that goes.

Like I never see it go off and like create a phantom directory or like namespace things weirdly, which other people I've talked to using other languages have run into something like that, where it's like, oh yeah, it did this weird thing with its directory structure, or it put this thing in the totally wrong namespace.

I don't see it that much, at least not with the like core Rails.

Podia does a pretty good job staying on the Rails, quote unquote.

There are a few places where, like, whether it be a legacy decision or something that we did in the past, there is a little bit of weirdness somewhere, and every once in a while it gets tripped off on that.

But I feel like for the bulk of like normal Rails stuff, it's pretty smart.

It knows when and how to use generators.

It's pretty good.

I know that a lot of people love TypeScript with it, and allegedly static typing is better for AI, but I haven't really had any issue with it.

Dynamic typing, it knows Ruby, it understands the Rails conventions, and it can do most of what I need without much hand holding.

There's always guidance, but that's more about how the code is written and how the architecture is.

But the basic conventions it gets pretty well to me.

The API has been very stable, and any public changes to the API have been very well documented.

So I think I like that about Rails.

It has reached like a stability while still having a ton of features, and it is still like the one-person framework, I think.

The last question I always ask, the fun wrap-up question, has also changed quite a bit because of AI.

But I still like to ask it what is something cool, new, or interesting that you've recently learned, discovered, interacted with?

It can be an AI tool.

We recently started using something to handle our work trees at work called conductor.

And my absolute favorite part about conductor is it has a toggle where you can click it on and it will always strip out the your absolutely right messages.

When you call AI out on spullshit, it won't say you're absolutely right anymore.

Absolutely love.

That would be my answer to this question.

What is your answer to this question?

Yeah, my answer to this question, I might be a boring one, but ChatGPT.

Chat GPT is basically I'm no longer blocked the way I used to be blocked in the past.

Like sometimes in the past, you're like stuck on something and you don't even know what to Google.

What are the keywords you need to plug into the search box?

With Chat GPT, I feel like now I'm stuck on something.

I don't know how to start.

It's funny, I've been running my business for more than 12 years now.

And I'm really bad with numbers and finances and budgeting.

So now when I need to do anything related to that, I will start a conversation with ChatGPT and basically ask the questions in like the dumbest language I can, and it will at least give me an idea of what I can ask next or what I can Google next.

So I just love that ChatGPT exists, and I know it's a basic one.

The other one is quite code.

I was yeah, very pleasantly surprised about the terminal interface and the way it works.

Again, I learned that I need to be like more specific about what I would do as a senior engineer so that it can just go and do it for me.

But yeah, it was a learning process, and I really like how it can help you be more productive to generate code.

Now, I still need to go back to that hanami code that generated for me and actually tell you, like, yes, this was like A plus code, or like C minus.

You know, I still I'll owe you that one.

They are cool, new and interesting tools for sure.

I think even the most bearish AI person would say they're very interesting.

Scary at times too, but like very interesting.

And it's got a little bit at times, a little bit of the JavaScript framework problem where there's something new almost every day.

I can't keep up half the time.

We just had a break from work.

I've came back and I felt like I spent the first two days of work going, hey, what's new in AI?

Like, what did I miss during my break?

There's so much new stuff going on, skills, how are people organizing things, work tree setups, and it's like a whole new discipline to learn where it used to be like, oh, Ruby 4.0 came out.

Cool.

Let me skim what's new and move on.

Like, there's a whole new branch of things to learn because of AI and how rapidly it changes and evolves.

Yeah, I did have one question for you.

Like, what conferences are you excited about in 2026?

There's so many.

You've got Blast Off Ruby in Albuquerque, New Mexico, RBQ in Texas, Blue Ridge Ruby's coming back in North Carolina, Asheville, North Carolina, just had Jeremy planning to go to that one.

Nice.

Yeah, just had Jeremy on for the last episode, and we talked a lot about Blue Ridge and the work he puts into it.

And very excited about that.

I really loved the first one he ran.

He puts a lot of love into his conferences.

I'm sure everyone does, but I've been to a lot of great conferences.

I'm starting to really like the smaller ones more and more.

Some of the bigger ones, though, that are at least on my radar, we have RubyConf happening in Las Vegas in July, which is certainly a choice.

But they do have Mr.

Sin City himself running it.

So I'm sure that's going to be awesome.

Rails World is in Austin, Texas this year.

So we're back.

Yeah, back in North America, and that'll be in Austin.

There's Rocky Mountain Ruby out in Boulder, Colorado.

Maybe SF Ruby will happen again.

I'm not sure where they ended.

But yeah, those are the ones that are all on the top of my head.

But RubyEvents.org obviously is a great resource for tracking down all of the various conferences happening.

If I can only make it to a handful, it'll be Blue Ridge, Rocky Mountain, Rails World, and probably RubyConf.

Four might be stretching it.

But yeah, definitely Blue Ridge, definitely Rocky Mountain.

Love Rocky Mountain, Ruby.

Wonderfully run conference.

Boulder is an awesome town.

Rails World, pretty much everyone on the podia team is planning on going.

So probably gonna go and call it like an unofficial podium meetup.

So what about you?

What's on your to-do list for conferences this year?

Blue Ridge.

I'm excited about Rails World planning to be there as well.

And I don't know.

I don't know what else.

I think those two for now, planning to be there.

And oh, I did want to say, I know we talked a little bit about Philly RB, but I want to say big thanks to Drew Bragg, one of our top contributors, uh, for bringing the site up to speed.

You got it deployed.

You upgraded middleman, so thank you for that.

You did most of it.

To be fair, I told AI to upgrade middleman.

That did take a little bit of AI hand holding.

I was happy that I had AI because I think if I didn't have AI at all, I don't think it would have happened.

But that was definitely something AI was not capable of doing on its own without a lot of intervention from me.

To be a fair, our site was 2014, I want to say, is the last time it got a major update.

So yeah.

It was like years ago.

Our most recent video was from 2014.

Yeah, there's a bright horizon for Philly RB.

Having RailsConf in Philly was super energizing and really happy that we've got it back in person, and it's so much fun to go to.

And I'm I'm looking forward to getting more speakers to come out, more attendees every month.

And I'm really happy that we've got it back in person.

And I guess I have to then also do a huge shout out to you again because it wouldn't be happening without you.

You're not only doing a lot of the logistics, but On Boo Labs sponsoring Philly RB makes it happen because, like I said, we have a really cool space in Indy Hall, but that's not free.

And we're getting Scott to come down and we're helping him out to make sure that it can happen.

It's only a train right away, but it's good to be able to help out there and we get really good pizza and cannolis.

The cannolis were awesome.

So it's a team effort.

I definitely couldn't do it on my own.

So I appreciate everything you do for making it happen.

I'm just pumped that it's a thing again.

We make a good team.

I'll just say that.

I'll leave it at that.

And if anybody's listening in the Philly area, please consider, you know, speaking at the event or coming to the event.

We're always happy to have you and reach out to us if you don't know if your talk will be accepted.

But we're pretty open to all the talks out there.

Absolutely.

Yeah.

The more talks, the merrier.

We just had Mike Dalton do an awesome one on like an intro to Hotwire Native, which is super cool, very interesting.

Looking forward to Scott's AI talk tonight, quote unquote.

Like right now, it's Friday, January 9th.

But when this episode comes out, it will be tonight that he's talking.

So super excited for that and pumped to see who we can track down for February and onwards.

So yeah, like Ernesto said, anyone listening who's interested in speaking, give us a shout.

We'd love to figure out a way to make it happen.

Anything else you want to shout or talk about before we wrap up?

For anyone listening, if they're interested in any of the technical debt articles we write about on the Ruby front, just go to fastruby.io.

And if you're interested in some of the AI consulting we do, just go to ombulabs.ai and check out our blog there.

Thanks a lot for coming on the show, man.

Really appreciate it.

And yeah, looking forward to having you on again for the next round of what are you working on and what kind of crazy blockers do you have.

See you shortly.

Thanks for having me.

Thanks, man.

All listeners, I'll see you in the next episode.

Bye.