Brian Scanlan: Building AI-First at Intercom

**Robby Russell** (0:05)
Welcome to On Rails, the podcast where we dig into the technical decisions by building and maintaining production Ruby on Rails apps. And I'm your host, Robby Russell. I run Planet Argon, and for over 20 years, we've helped teams maintain and evolve long-lived Rails apps. So I tend to approach these conversations through that lens. In this episode, I'm joined by Brian Scanlan, who's a Senior Principal Engineer at Intercom.
Brian's been working on something pretty wild lately, turning Claude Code into a full stack engineering platform inside of Intercom. We're talking about a system that has over 100 internal skills, hooks that enforce engineering workflows, and even read-only access to production Rails data, used not just by engineers, but for product managers, support and design teams. In our conversation, we also dig into what happens when your CI pipeline starts to melt and how that led to rethinking the entire development lifecycle and what it actually takes to build world-class AI-assisted workflows on top of an existing Rails codebase. Brian is from Dublin, Ireland, but happened to join us from Intercom's San Francisco offices. All right, check for your belongings, all aboard.
Brian Scanlan, welcome to On Rails.

**Brian Scanlan** (1:10)
Cheers, Robby. It's great to be here.

**Robby Russell** (1:12)
So I have to start off the conversation like I asked all these conversations is, Brian, what keeps you On Rails?

**Brian Scanlan** (1:19)
Sure. Well, Intercom is a 15-year-old B2B SaaS with millions of lines of code. And so, you know, most of this is in the Rails app and it's a lot of efforts to break it up into microservices. Obviously, this would be something we would love to do.
No, I joke.
You know, we love the expressiveness, the ease of use and just the normal reasons why people love Ruby On Rails in that it's so easy to get started. It's kind of meeting you where you are and not through a loaded boilerplate. And it allows our developers to really focus on building product and not learn gigantic frameworks, build complex microservices and things like that. You know, we think the Rails philosophy and like having a single application where we put most of our logic. We think it's very consistent with our approach to engineering in general. We're a principled organization and what has worked well for us over the years has been to be technically conservative. And the way that this comes out in practice is that we end up with large applications where we inject all of the smart stuff that we put in place to make sure that people are as productive as possible and they have to think as little as possible on all of the gunge and undifferentiated heavy lifting and they can spend their time considering and shipping great product.

**Robby Russell** (2:43)
I like that. There's your case study for Ruby on Rails there. I don't know if I've heard that technically conservative. Yeah, I like that framing.
Where do you distinguish that between, say, boring?

**Brian Scanlan** (2:57)
I love boring.
Yeah, Dan McKinley, he's ex-ETC. He wrote this blog post a good while ago at this point called Choose Boring Technology. And that was a deeply influential piece of writing. He's also written a bunch of other great stuff that I refer back to constantly. It's like one of the blog posts or series of blog posts that every so often I just remind myself, I need to read that as a refresher. It's like, this stuff is gold. But yeah, Choose Boring Technology came out of Dan McKinley's experience at Etsy, where you just build things on top of a bunch of boring, well understood components. You don't really need to think about it after that point, in that somebody else will probably scale it. The work will be absorbed as part of the greater efforts to say, keep the MySQL layer running well, or the Rails app running well. Whereas, if you're on a team, you're making a choice around what technologies to use, and you're using some pretty cool, bespoke, or custom, or unique technology that's really well suited to the problem at hand, then it's like owning a pet at that point. You now have to maintain that thing and feed it.
It's not the worst approach in the world, as in it's better than doing nothing, but I think that in most businesses, sticking with a well understood set of technologies that you invest in deeply and understand them well, that just gives everybody back more throughput, more time to build product, but you get to do things at a higher quality as well. It's hard enough to scale one database. I can't think of how hard it would be to scale three different databases if all your teams picked different databases. So the way we articulate that in our environment is being technically conservative. It's like the articulation of what we have done that has served us so well in the last 15 years of enterprise.