[00:00:05.02] - Robby
Welcome to On Rails, the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. And I'm your host, Robby Russell, and I run Planet Argon, and for over 21 years we've helped teams maintain and evolve their long-lived Rails apps. So I tend to approach these conversations through that lens. In this episode, I'm joined by Joanna Wang, senior software engineer at Sixfold AI. Sixfold helps insurance teams analyze complex cases using a mix of document processing, automated workflows, and AI-powered tools. Joanna has worked across Java, Go, Python, Node, and Ruby throughout her career, which gives her a unique perspective on what Rails does well and where teams can run into challenges as their applications grow. We'll talk about what Rails has enabled for her team, the realities of managing increasingly complex workflows, and whether agentic coding tools are changing how developers think about Rails' famous magic. Joanna joins us from New York City. All right. Check for your belongings. All aboard. Joanna Wan, welcome to On Rails.

[00:01:05.06] - Joanna
Thank you. Thank you. It's great to be here.

[00:01:08.10] - Robby
I'm so glad that we were able to finally make this happen. And we think we had a conversation maybe 3 or 4 months ago and we're like, oh yeah, this would be a great conversation. So we're here. Let's do this. All right. So Joanna, let's start with this. What keeps you on Rails?

[00:01:23.01] - Joanna
Well, Rails has just a very almost completed ecosystem. There are just a lot of maintainers and it just has a really big community and dev base so that if you have any problem with it or anything, you're probably not the only one or you, you know, you're not the first one to encounter almost anything. So I think that's a really great thing.

[00:01:44.10] - Robby
Now we'll talk about Sixfold in a moment, but if I recall, you didn't work with Rails prior to your current position. Is that correct?

[00:01:51.15] - Joanna
Correct.

[00:01:52.02] - Robby
Just to set the scene a little bit, what technologies, programming languages, stacks were you kind of working with prior to Ruby on Rails?

[00:01:58.12] - Joanna
I started with Java in college. I was a computer science major and then I worked on Python for about a year or so. And then I was back on Ruby on Rails, which is actually basically just also a Java JVM language suite.

[00:02:17.13] - Robby
Did you ever, out of curiosity, work with JRuby at all?

[00:02:20.01] - Joanna
No.

[00:02:20.18] - Robby
Okay. Uh, I don't know. Do you know what that is? Nope. Okay. Uh, well, it's actually a way it's, it's a way that you can run your Rails like app within the JVM. So it's like a, it's a Java-based Ruby interpreter. So it's, uh, it was a way that a lot of organizations back maybe like 15, 20 years ago were able to kind of like sneak Rails into their Java environment and deploy it. I don't fully understand how it all works, but it's still, it's still a thing. Um, so for, for those listening out there, but All right, well great. So you have set the scene, you did work with Java, some Python, and things like that. So for our listeners who might not be familiar with Sixfold, can you give us a sense of what the company does and the kinds of problems you're helping solve with as an organization?

[00:03:02.11] - Joanna
Yeah, we are an AI underwriter. So basically when insurance underwriters have to underwrite cases, they need to do a lot of, you know, like basically data points gathering. They, look at the documents that are sent to them by brokers. Then they make a decision of like what the risk of this insurance, this company or person is. We kind of replaced like a lot of the human process in there. We basically streamline it from, you know, you have a case like with a name, with some, maybe some documents. It could be from like an email. You can forward us an email, then we'll basically just take it all the way to the end where we give you, okay, this is how much risk we think there is for this company.

[00:03:48.12] - Robby
With that workflow, is that, is like you're ingesting a lot of data. It sounds like kind of a lot of complex things to try to make sense of. And I would imagine with insurance, I'm still trying to wrap my head a little bit around the AI and how to describe this to like non, I'm air quoting, technical people in the sense of like non-deterministic output and like being able to like say, what's the risk level here? What sort of technology and tooling have you been able to use there to make that kind of happen there? And then, and then maybe tell us about how Rails kind of fits into that.

[00:04:20.18] - Joanna
Yeah. So the main app right now is actually on Rails. We're in this transitional phase where we were using the state machine, which is actually a gem on Ruby on Rails. And then we like are moving to Hatchet for basically like workflow management. And then on the AI side. For every kind of like evaluation, we use different models. We do evaluation with ground truths to like make sure your questions are being answered properly. Like this model is actually good. We do tune our prompts with evaluation to, to like try to give the most accurate result as possible.

[00:04:58.13] - Robby
Can you tell us a little bit about what's Hatchet?

[00:05:00.19] - Joanna
It's a workflow orchestration tool.

[00:05:05.05] - Robby
And so is that basically a way to move your state machine type logic into a different platform? Is that— Yeah. Now is that like some sort of WYSIWYG pull, map it all out that way? Or is a lot of like code orchestrate— you like write code to orchestrate that in their tool, but then you're kind of letting them manage that workflow?

[00:05:25.10] - Joanna
Let me just give you some background on how we did it. We have our code that orchestrates all the workflows with the state machine. The Rails like callback hooks like onCreate and stuff like that. Now we're moving to Hatchet where you just get to define, you know, this DAG where step after step, and then like, when does this trigger another workflow? When does this end? What's the condition of a certain next step runs? And then Hatchet itself will be the engine that actually orchestrates it.

[00:05:57.23] - Robby
I see. Out of curiosity, what does the engineering organization look like today? Like how roughly, how large is the team? On the engineering side?

[00:06:05.09] - Joanna
Uh, I think we have about 20 to 30 people on engineering right now.

[00:06:11.13] - Robby
I think you mentioned in our prior conversation that there's a lot of Python developers there, I believe, and working on Python things, and there's some folks working on the, you know, maintaining and working on the Rails app and stuff. So how much crossover has historically needed to happen between the teams?

[00:06:26.07] - Joanna
Um, quite a lot. We, we actually work very closely because like basically The Rails app is like the web application, the worker for like orchestrating the jobs for like database access, where the Python codebase is the microservice basically for any like AI interaction. So they're in charge of like making a request to OpenAI, to Anthropic. It will then report back to the Rails app.

[00:06:53.01] - Robby
What do you think Rails has enabled your team to do particularly well?

[00:06:57.13] - Joanna
It's a very, what's the opposite of verbose, I guess? Like, so it is really not verbose and like you can write very little code, which is really nice. Like it's a double-sided sword. It has its benefits, which is like, you know, yes, we write a lot of, a lot less of code, but then I think historically it had also created some problems maybe.

[00:07:21.05] - Robby
When you started working with Ruby on Rails, How people throw this word around a little bit, maybe a little overused, but did it feel like there was a little too much magic at all? Or was that, how would you have described it at the time when you say speak to the verboseness aspect of it or the lack of it?

[00:07:37.05] - Joanna
It was a lot of magic. I think to me it was a lot of magic cuz I came from Java, which is a very verbose language. So, for a little while it was I wouldn't say difficult necessarily, but it was a lot of like, oh, what is happening? I have to like keep jumping from this line to that line, jump all the way to maybe the library code to see, oh, okay. So then there is a helper because you don't actually need to define it, but it's just like under the hood, it's already defined. And then you kind of see that, then you understand, oh, where this like specific method call is coming from.

[00:08:17.05] - Robby
Yeah. What about for like your, your peers? What was that? Did many of them have a Ruby on Rails background prior to...?

[00:08:26.03] - Joanna
Some. I think they expect or they kind of know a lot of the under the hood stuff. But I also think especially for the team that works mostly on Python, when they ever have to touch the Rails side of code, they like have a lot of troubles because like a lot of it, or at least before like agentic coding, like, you know, like we can't avoid that now, but like prior to it, like they were definitely having a lot of trouble understanding what is going on because almost nothing is like explicitly defined.

[00:08:58.19] - Robby
What parts of Ruby on Rails do you feel like have been most beneficial or did you appreciate the most out of like relative to other platforms and things you'd worked with in the past?

[00:09:09.07] - Joanna
I do like how dynamic it can be. As an example, like one thing is like with Ruby, you could literally dynamically construct a class and then make a class method call. That is really, really cool. And like a lot of things like that. And then like you can just be having like, oh, .compact and array, and then it does everything for you. The easiness of using it is really great. And then the easiness to make things dynamic is also really great. You know, like I think that, again, like I feel like it has two sides to it. I think it benefited us a lot, but it also creates some like confusions and like frustration when people are not so familiar with the codebase or with like Ruby on Rails.

[00:09:59.04] - Robby
So maybe for folks that are kind of just jumping in and out of it and aren't working on a regular, but like they don't, Do you feel like it's one of those things where like, where's this defined in the codebase and, and not being super obvious or something? Yeah, I can appreciate that. So what has Rails allowed your team to accomplish during this important phase of your company's growth over the last few years?

[00:10:18.20] - Joanna
I think not having to write code, like as much code was very important. Being able to make things more dynamic, that accelerates like an early just setup of an initial app. Where we can sell, where we can like actually enable our customers to do the AI underwriting. That was very important because we had very few people. It wasn't an agentic coding era of time. You actually had to handwrite code to not have to, like, for example, list out every line in your database, every column in your database. Don't have to list out every like response to the front end, that was actually really like acceleration.

[00:11:02.04] - Robby
Now has Rails been used for like a lot of the customer-facing views and things like that, or is it kind of more of the behind the scenes tool?

[00:11:12.12] - Joanna
Yeah, so we use it for the REST API as well. Uh, we don't use it necessarily for views. We do use React for front end, but the REST API responses. All of that is still handled by Rails.

[00:11:26.16] - Robby
What about from like a database perspective? What have you been running that in? And then is everything kind of running historically through Rails or does everything touch their own databases?

[00:11:35.14] - Joanna
Yeah, the Rails app is also the entrance to the database, like the only entrance to the database. Other microservices do not actually touch the database.

[00:11:44.03] - Robby
Interesting. Can you give us a little bit of background more on the, the migration to using something like Hatchet, but like Historically, you mentioned you're using like state machines. So if you weren't going to be migrating to like a new platform, could you just, could you tell us a little bit about like some of the pain points that you found by using what, and out of curiosity, which gem were you using? Was it just like access state machine type of thing or?

[00:12:05.18] - Joanna
Yeah, it was, yeah, it was mostly just state machine. I mean, we were also using ActiveJob, uh, we were using Faktory, which is like a basically Sidekiq, but can be used in like other languages, because then we also started using Faktory in Python for like the job handling.

[00:12:23.20] - Robby
Interesting. What were some of the limitations of like using the gem? Was it just that it was too consolidated within the Rails app? Or did you want to like kind of leverage that elsewhere? Or were you felt like maybe from an architecture perspective, was it, were you relying on feeding too many jobs to the Rails app to then have it do something when maybe the microservices could be just dispatching their own? Jobs, so to speak?

[00:12:46.08] - Joanna
Yeah, a couple of things. One is like on the Faktory side, I think under like severe load, we were having problem with scaling. It gets backed up, but like, it's hard to see or to like quickly resolve it when it's backed up. So that's like, that's one problem that's more or less on Faktory. But then on the other hand, we built our in-home, like orchestration with the state machine and the callbacks. Um, for like, you know, after create, stuff like that. So that becomes very brittle as the workflow becomes more and more complicated. It's very, very scattered how we like manage states. It's very reliant on, you know, your database transaction is actually, you know, completed. All of that is working well to be able to like transition. Then that transition itself, then we have some other side effects that comes with the transition. So that, you know, we can push for next workflow to start. But then that also makes it very brittle because like sometimes you create a lot of racing issues. And then to handle those, you add more logic, then making the logic even more scattered.

[00:13:58.19] - Robby
Out of curiosity, off top of your head, are you able to kind of like walk us through like an example of some of that at a high level of what the orchestration might look like in for like an actual use case, just for our listeners?

[00:14:10.04] - Joanna
Yeah, for example, we do like web ingestion for like a company, which means like we would go search for information about the company online. Then we like scrape those websites, create those documents, and then process those like web content. But the problem came as we realized like sometimes when we're scraping the web, it's very hard to say like this is actually the correct website because there is sometimes different names for the same company or like same name company, but they're different, actually not really related. So we started doing this thing, which is like after we scrape the web, we ingest the documents, then we're going to check if like every one of them is relevant. That means there is a fan out, then there is a fan backing while we could also have documents for this company, like user uploaded. So these are all running parallel. So now by a time where you want to fan all of them back in to say, okay, now we are done with this like document ingestion or like web ingestion, we can like move on to the analysis. That step became very brittle. Like we see so much like racing with it because they're all spread out, they're fanning out, we are starting a job.

[00:15:31.11] - Joanna
On the microservice that's doing, you know, like the AI stuff to decide if it's relevant, then it fans back in. It's a, it become a nightmare. Like it's just every, at every possible place there is a race condition.

[00:15:46.09] - Robby
That's, that sounds like a fun challenge. Like to reach out for like a platform to maybe assist with that was part of that. Do you feel like, uh, like just like outside of like the capacity of what your team could try to solve and keep figuring out amongst yourself without needing to bring in some more external or additional help out for a while on that sort of thing. Because I know there's companies that are doing really complex things within their apps from time to time, but also it's, it's an interesting thing to be like, maybe we should reach out for a platform that might be able to assist with that and like, let them figure out some of that stuff. I would imagine it doesn't solve all of the problems, right? But it maybe addresses like enough of it that it becomes like, oh, let's, let's experiment with that. Do you remember some of the conversations or was there any like hesitation? Like, why would we pass this off to someone else? We can figure this out ourselves type of thing. Or, or, or what does your team have like a culture of like, no, we're gonna like use the best tool for the job and we'll move off and try something else if that's gonna solve the problem for us.

[00:16:43.21] - Joanna
Um, I think both are true for us. One being like, I, I think we do try to buy over build if there is a better tool out there. We would try to use the better tool. On the other hand, we did have the whole conversation about maybe we just rewrite this whole thing because, you know, to some extent it was also because as we add more complexity, we maybe didn't think through the architecture that well. So there was also the side, you know, maybe we don't have to do this. We just like rewrite, like, to be fair, the rewrite of these workflows has been on the table for a while, even before we even knew, or like even before Hatchet became like available at all. But at the time it was also like, okay, there is Hatchet. Let's like maybe just try. We did have some other internal tooling that started using Hatchet as like a pilot to see like how well they do with workflows. And then we started like moving smaller things onto Hatchet to like solve some of the problems. And then it's proven to be like possibly more efficient and easier to maintain because, you know, They give you this whole dashboard where you can like cancel jobs, like look at jobs, and like, you know, that decision was made on like both ends.

[00:17:58.21] - Robby
Nice. This episode of On Rails is brought to you by ApplicationController, where all roads lead and no logic escapes. Do you need to share a method across all controllers? Add it here. Want to run a callback before every action? You know where to put it. Do you need a place for auth logic, Flash helpers, and a little panic code, it's waiting for you. ApplicationController is the one file that's holding your app together and also maybe holding it a little hostage.

[00:18:26.21] - Joanna
Side effects may include confusion, long scroll sessions, and blaming something in here for half of your bugs.

[00:18:30.17] - Robby
ApplicationController, because if you don't know where it goes, it probably goes here. When we were preparing for this conversation, you mentioned, I think it was JSON API resources. Could you tell us a little bit about that and like what type of problems has that been helping your team solve since it was introduced?

[00:18:48.07] - Joanna
It's a gem that gives you JSON API spec response for your like REST endpoints. It hooks almost directly to your database, to your controller layer. It's all the way. So you don't need to write anything that's like, like a create endpoint. Our controllers are like almost 100% empty. The files are there and you still need to create those files, but that's fine.

[00:19:13.00] - Robby
Sounds like a bunch of magic.

[00:19:14.12] - Joanna
Yes, it's a lot of magic. It's great. It's great in the sense that like whenever you have a new model, you have a new entity or data model, you barely need to write anything and it already gives you back a very, you know, like it's JSON API standard response.

[00:19:32.23] - Robby
Interesting.

[00:19:33.20] - Joanna
You don't need to write serializer either.

[00:19:35.17] - Robby
So is it everything on the, like within the Active Record and Active Model? Where your business logic can kind of live and kind of protect everything? Or is there some, some interesting layers where you do have to, is there like a DSL that it has to say like only these things are exposed so you can't like update certain columns or attributes or something like that?

[00:19:56.21] - Joanna
So we do use ActionController. We do use Pundit for authentication and some of the authorization. We do define rows of like RESTful Routes. Read/write, and then we do check for, you know, if they have the read/write access. And then with the JSON API resource, you also get to define if you want a create, you want a read, you know, like index, list, anything like that.

[00:20:26.14] - Robby
Was that introduced prior to you joining the organization, or was that— did you run into any interesting challenges for that, or has that in general been actually been done its job pretty well?

[00:20:36.23] - Joanna
With the magic comes the rigidness of it. It's like, it's very rigid in like what you can do with it, like how the errors can be handled. For example, if you want specific errors when you're doing, for example, you do a create and then you do like model checks, right? So generally with JSON API resource, you don't need to do anything. Like you don't even write like a query. You don't write the ORM query either. You don't write none of that, but you can still define, you know, like my error classes with ActiveRecord, right? Like the validation errors. But then with JSON API resource, those errors are very hard to then surface in the way you want it because it has its own very defined list and way of how it populates errors.

[00:21:30.08] - Robby
I see.

[00:21:30.13] - Joanna
So then, yeah, whenever you want customization to it, It's a little bit of a pain 'cause you try to add to it. On the other hand, the other thing is this gem is now not maintained anymore. So issues that comes with it just isn't gonna be solved. So like we kind of have our own forked version of it where we solve some issues.

[00:21:55.04] - Robby
What's your team's approach to picking and deciding when you'll bring in like an external dependency, do you feel like your team's philosophy has changed much in the last 6 months or so now that presumably that LLMs, maybe agentic development is a little bit more prevalent in teams now?

[00:22:14.11] - Joanna
The introduction of Hatchet is actually kind of an example of how we deal with like vendors. Like I think we generally would like to find, especially if like, for example, Hatchet is like a bigger tool, right? Like you gotta pay, but if there is like open-source gems that do things for us, we would definitely try to, you know, look for tools that are already out there. Like, I guess the mentality is that our value is not in creating those like, like smaller tools, but in creating this like overall system for insurance underwriting.

[00:22:46.19] - Robby
The reason I asked about that is I feel like I've talked to some people where they feel like their teams are trying to, are, are revisiting that approach a little bit, especially when it comes to like bringing in a let's say a Ruby gem or some open source library, like, and you use that example of like JSON API resources, maybe not as actively maintained. And I just looked at their web, their GitHub, it was updated 3 months ago, but it was to fix a Ruby 2.6 logger compatibility thing. So, uh, for, and for Rails 6.0. So yeah, uh, it's a little behind. Um, anyhow, but the, I think the, um, But when it comes to like with security in particular has been a thing that I think where, where we're pulling in external dependencies in particular, there's a lot of other, uh, attack, uh, surface levels, things that everybody's being a little bit more mindful, like RubyGems, like they just announced a new version of Bundler and RubyGems will have like a cooldown feature. And so that we're not automatically upgrading things too quickly and bringing in a potential security risk because maybe an LLM just like installed the gem or what have you.

[00:23:49.21] - Robby
Hopefully people are more thoughtful and catch that stuff. But yeah, I was just curious if that has been at all a discussion there about how your team's thinking about that, even maybe beyond just your Rails app.

[00:24:00.20] - Joanna
Uh, for sure. The security issue has been a problem. I mean, not on Ruby on Rails, but like, you know, the npm attacks that, cause we also use, uh, we use like TypeScript for, for frontend. So like the npm attacks has definitely raised our like awareness on like security vulnerabilities. So we do have a lot of like automatic. Tools that are monitoring it, you know, new security vulnerabilities. And we put on a lot of emphasis on like fixing them as soon as possible. And then with like bigger, larger updates, especially for example, Rails  or like any Rails related, like ActiveRecord got a major update or anything like that. We actually don't do the general Dependabot like upgrade. We like make sure like we do a proper upgrade or migration, like having someone to like, even like in the age of AI, like we're like having someone to like make sure that everything works.

[00:24:54.21] - Robby
Nice. Out of curiosity, what sort of testing tooling has your team historically been using from the Rails side?

[00:25:01.15] - Joanna
We use RSpec and then FactoryBot for Faktory items. And then we also use Capybara for some end-to-end testing.

[00:25:10.18] - Robby
Any other interesting tooling? How are you like APMs or observability tools that your team tends to rely on?

[00:25:17.22] - Joanna
Yeah, we use Datadog for like basically all monitoring.

[00:25:21.23] - Robby
Has your team been able to like leverage some of like the LLM tools to— with Datadog at this point? And out of curiosity, are you using much LLM tooling day to day in your coding activities?

[00:25:33.23] - Joanna
Uh, yeah, so much. We have basically every MCP. We are migrating to like, well, at this point, I think the migration to full agentic coding is done. But at one point we were like just like really being really aware of this like change and like really trying to bring everyone in the organization up to speed with agentic coding.

[00:25:55.05] - Robby
What were some of the challenges that you've found through that process? Regardless of the Rails part of it, I'm just kind of curious about that.

[00:26:04.06] - Joanna
Yeah, sometimes it doesn't do what you ask it to do. Or rather you have to ask it in a very specific way for it to do what you need it to do. And I do see it also sometimes being overly defensive when it's coding.

[00:26:19.13] - Robby
Tell me more, like what do you mean by that?

[00:26:22.23] - Joanna
Sometimes there are things that it's like, oh, we need to prevent for like this string being not not empty or like not having any weird characters, but we know if that string is fed from an upstream of code, it's never going to happen. But then Claude would be sometimes overdefensive and just try to be like, hey, writing just 20 extra lines just to be like, oh, let's just make sure that we catch every possibility of the format of this string.

[00:27:00.09] - Robby
I can appreciate that. And when you mentioned you're fully agentic at this point, what does that mean for you right now at Sixfold?

[00:27:10.05] - Joanna
Um, we almost, well, not almost, we pretty much, we don't write code anymore. We don't hand-write code anymore, basically.

[00:27:19.11] - Robby
Like, like in the 80, 90% plus perspective of most of the code, or even more so, is almost entirely written. Are you orchestrating a bunch of agents right now at this point in parallel, or is it, is that all happening kind of in your local environment? I know by the time we record this might change by the time it gets published, but it's kind of getting a sense of where your folks are at the moment.

[00:27:39.21] - Joanna
Yeah, we are fully agentic, or like we are basically not writing any code. I think we're at a point where some people are still reading the code, but some people like are fully on the point where like, if it works, then it's good. I don't care if it, I don't care like to read the code anymore. I guess like this is where the org is at, but like in general, like nobody's writing code anymore. We don't review other people's PRs mostly. We do have agents also review the PRs. So a lot of the work is actually putting in the harnesses for the agents instead of like just writing code.

[00:28:19.22] - Robby
Can you tell us a little bit about like what's maybe what some of the, what those harnesses look like?

[00:28:24.01] - Joanna
Yeah. So one, we have CodeRabbit that like is reviewing every PR. We do tune CodeRabbit. We do give guidelines of like, what you need to be aware of. And then we do ask everyone to basically have documentation, have like an agents.md file, which is for, you know, these are the pitfalls I've had. This is how this is designed. This is the general architecture. This is the pattern. So that then when an agent is coming to make more addition to a feature, it has all these guidelines that it that it needs to follow.

[00:29:00.23] - Robby
How has that been for you as a software developer? Are you embracing it? You're excited, optimistic about this, or has it been kind of an—

[00:29:10.11] - Joanna
I think it's an exciting time. It's like, to me it's like, oh wow, what a time to be alive and what a time to be working in this industry actually. 'Cause I think it's completely changed what it means to be a software developer. In the past, writing code is like, some people might say it's like an elitist thing almost. But nowadays code is cheap. I don't think the value of a software developer is gone. I actually think it's more like the value of you is not about writing code. It's about thinking through a solution to a problem. It's about how you architect something so that it is it is not brittle, that it is robust and you are solving a problem, you know how to scale it. I think that's really where now the value of a software engineer is at. It's not so much so about code. Like, to be honest, I myself never thought it was about writing code because syntax is always online. Documentation was always online. Code is like, you know, like your library is always there. But I think now it's very explicit in that way, such that, you know, like code is cheap, it's easy to write.

[00:30:29.12] - Robby
Do you think that AI-assisted development changes how teams might be thinking about those Rails abstractions? Do you feel like you've noticed much with how it's mean— like the using AI to help maintain the Rails app in particular has, has been a, a positive thing you've seen and like, oh, it seems to actually work really well with Rails, or what's that, what's your experience like?

[00:30:49.15] - Joanna
Yeah, I think it's especially useful for Rails because of the magic. In the past, you have to go through the code. You have to go through very deep in the line. Because other verbose language, you see it. You do a global search, you see that method. You see the definition. But with Rails, a lot of times you don't see it. Sometimes it's maybe constructed. Sometimes it may be just a Rails helper method that is not obvious. But with Claude Code, that's not a problem anymore. You know, like it knows, like you ask it, it can actually trace for you.

[00:31:24.13] - Robby
That's interesting. You mentioned earlier that there's people that kind of jump in and out of Rails with other toolsets that you're working with there, that agentic development has been able to make that a little bit easier for them because they didn't understand the magic.

[00:31:37.09] - Joanna
For sure. For sure. Like they can actually do the Rails stuff. Like in the past it was more like, okay, we have like, you know, like we kind of have this. Ask of like how we want the Rails side to be, and then they kind of hand it off to like a Rails, you know, like the engineers that are working on the Rails side, but now they can actually take it to done.

[00:31:56.21] - Robby
Out of curiosity, with, with the Rails app, has your team built any interesting tooling to help historically with like onboarding or just developer experience? Like any interesting little tools that are very, very specific to like ramping up things so you can have like a, let's say for example, like do you have a pretty healthy seed system or how does your team debug production level type things in a local environment within the Rails application part of your platform? Or is that a kind of a challenging thing for you?

[00:32:27.06] - Joanna
I think we did have some tooling for just getting things up. Like we did have, you know, clear instructions and like commands that you just run to start your dev environment. And then we also did. Do a lot of like CLI commands to be like, okay, you know, you're— it's production. Like there are some specific things you need to do. You can't just like run this. You don't need to necessarily go into the Rails console. And then we have sometimes have like customer support requests where they need a specific type of export or something like that. So like we had a lot of like CLI commands that were built for this reason. Now we kind of like also have a set of like Claude skills to be like, you know, especially for setting up dev, like there is a whole Claude set of things that you can just run and then it'll take care of like setting up dev environment for you.

[00:33:25.16] - Robby
Oh, nice. That's cool. And is your, your Rails codebase have a bunch of like, uh, dead pieces of like, like rake tasks or you mentioned like you're doing customer support and needing to generate some weird reports. Like how is your team typically? Manage that type of work historically, and do you feel like that's a little bit different now in your codebase?

[00:33:44.23] - Joanna
So in the very beginning, we used Thor for writing CLI commands. So like most of the time we would like, you know, if a customer request keeps coming, we just, we then write a CLI command. You just type in what you need, then it, you know, like it does what you need to do for it. Then we actually started this internal tool completely for handling like the mass majority of like the customer requests, which is just completely like its own, it's like hosted, um, and it does a lot of like exports, like the playground for the customer support.

[00:34:20.04] - Robby
Interesting.

[00:34:20.21] - Joanna
Yeah.

[00:34:21.22] - Robby
And then is that just connecting back straight to the same database then? Kind of bypassing Rails or does it go through Rails at all?

[00:34:28.07] - Joanna
It actually just goes through Rails.

[00:34:30.16] - Robby
Okay. That's cool. Yeah, I was talking to a couple of people recently and they were talking about how they've even been building Uh, I don't know if your team, your organization done that, but they've been building tools for like Claude skills that allow their customer support people to actually run Claude skills against the Rails, like Rails console when they have like a protected version of the Rails console, other things like that. So they can kind of like let it be more natural language and stuff like that. It seems like there's a lot of teams trying to figure out how to like take advantage of some stuff. And I think Rails recently came out with a, was it Rails Query or something? I forget the name of it, but it basically, uh, kind of a little bit of a wrapper for like the Rails Runner things you can pass. It'll generate queries for you or something like that. I'm like, that's kind of, kind of neat and interesting right now. I'm curious when it comes to like AI and the state of things at Sixfold, uh, I'm, when it comes to, you know, the Rails app and you, you talked, you shared a little bit about the orchestration and the, uh, underwriting process.

[00:35:28.12] - Robby
Out of curiosity, is, is there anything about the data that, uh, Sixfold manages that's— is there any, any interesting challenges you've had to do with like keeping segmenting data? Or do you have to do like a multi-tenant type thing? Or is like, is the data that's being shared in this system very, very important that you need to compartmentalize it from different customers and different clients? I think that beyond just being like, here's a row in a database with a column, or tell us a little bit more about that.

[00:35:53.06] - Joanna
Yeah, we are multi-tenant because we deal with insurance. We have to be HIPAA compliant. We have to be SOC 2 compliant. Compliant. Our clients, sometimes if they're in a specific region, they actually have compliance where like you, your data can only be retained in that specific region. Um, so with all of that, it just made more sense. And also we do have a pretty big load in terms of like data processing. So with all of that, I think like the multi-tenant just makes more sense.

[00:36:24.03] - Robby
Is it the infrastructure then distributed across several regions then at that point then? Yeah. To make that, make that work. That's interesting. Okay. Say like, how does that then work with like, uh, something like Hatchet? Is that then also needing to be isolated in different regions as well?

[00:36:39.17] - Joanna
Yeah, we have specific, like basically for every, like for example, EU, like for every region, like that where it needs to be, there is like one for every, like one of those hosted things.

[00:36:52.15] - Robby
And is the app basically then deployed out to each of those regions in parallel? And is it the same deploy or do you, do you phase deployments out to different regions at different points? And it's kind of like a one by one, or you can be selective about that approach.

[00:37:07.03] - Joanna
We could be selective, but like in general, we just like deploy all at once. Yeah.

[00:37:12.06] - Robby
Okay. Do you lean on a lot of like feature flags or anything?

[00:37:17.16] - Joanna
Yeah, that's, that's actually the other thing is like a lot of like our different clients actually want to use different features. So that also plays into the multi-tenancy is like, you know, we get to turn only certain things on for a specific client.

[00:37:33.07] - Robby
And what sort of tooling do you use for that?

[00:37:36.14] - Joanna
We started with PostHog. Yeah. But then we actually started doing our own internal— we're just like env vars and then we have this internal tool for flipping them.

[00:37:49.09] - Robby
Have you found like a good pattern for how to do that? Is that across your different stacks as well? So it's not just like something in your Rails app, but if you're using environmental variables and flipping switches somewhere, like what does that kind of, what's the architecture of that kind of look like a little bit if you don't mind sharing?

[00:38:07.11] - Joanna
Generally, most of the features are maintained on the Rails side. If it's a feature, you know, that we want to turn on for some, some clients, but not the others. For example, maybe like a prompt or like some specific things are on the AI side, then it would be an env var on that microservice. We do have an internal platform that handles it. You know, maybe a set of customers have a specific feature, so we also have that to be able to apply to just a set.

[00:38:37.20] - Robby
Do you use any, any of that tooling to like roll out new feature ideas to a subset of clients before you roll them out to everybody, or? To test things out before you fully roll it out to everybody?

[00:38:48.14] - Joanna
Yeah, we don't do the, you know, like 50% of customers on a place. We don't really do that. We generally roll it out 100% to a group of like maybe alpha or beta customers, or we roll it out into like the UAT and sandbox environments first, and then we would roll out to like the actual production.

[00:39:07.15] - Robby
You mentioned like things like Capybara, but does your team have like a like QA type team there that is always some humans doing that, or is that somewhat automated at this point?

[00:39:17.02] - Joanna
It's somewhat automated. We do have frontend testing as well. Um, and then, but then the full really like, you know, QA testing used to be completely human. We went through a couple iterations, I guess. We had like a dedicated QA person. We're now using QA Wolf, um, to do the QA for us.

[00:39:41.08] - Robby
Nice. So Joanna, I want to ask you something. So let's, let's pretend we're gonna do a little exercise here. Let's pretend it's your last day at Sixfold and someone else is going to come join the organization and you had 5 minutes with them and you needed to quickly say, hey, this is a typical Rails app. Well, you mentioned, you touched on the JSON API resources. You don't need to go too deep into that, but let's say here's 2 or 3 things you should probably know about this Ruby on Rails application that might be a little atypical from other Rails apps. What would you tell them as you walk out the door and say, good luck?

[00:40:17.08] - Joanna
Um, we have a lot of race conditions in the current state of workflows. Things are moving to a better state is our goal. Be on the watch out. And then most things are documented somewhere in Notion. If you have your Claude, just like try to read them all, will be good. I think that's it.

[00:40:43.10] - Robby
Okay. All right. That's fair.

[00:40:45.21] - Joanna
All right.

[00:40:46.09] - Robby
Joanna, is there a technical programming-esque type book that you've historically found yourself recommending to your colleagues?

[00:40:55.10] - Joanna
Yeah, historically, I would usually recommend Clean Code and Clean Architecture by Uncle Bob.

[00:41:02.12] - Robby
Okay.

[00:41:03.07] - Joanna
But I don't know if it's still relevant as of today with the agentic coding. Maybe messy code is okay as long as it works.

[00:41:13.12] - Robby
Do you think there's still some value in trying to corral the agents into It's interesting because it is so much about, I think it's an interesting thing about like, when are we opening up and having to look under the hood and do these things ourselves versus relying on the agents to sort these things out, but also needing to know how to corral them in a cohesive way so that we can keep things maintainable. Right. So otherwise we'll be potentially burning a lot more tokens in the future to do things in the same way we burn human hours on being like, this is a mess. This is taking too long to do this. We're still paying for this stuff, supposedly. And we're also living in this, uh, slightly subsidized token era of development. So see what that looks like. All right. Um, but great recommendation. I'll include links to both of those in the show notes, uh, Joanna. And with that, I want to thank you so much for just stopping by to talk shop with us on Rails.

[00:42:09.03] - Joanna
Thank you for having me.

[00:42:10.15] - Robby
Yeah, it's been a delight talking with you as well. Thanks so much. That's it for this episode of On Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.