I love going to conferences. It's easy to get stuck in your own bubble at work and in side projects, especially as a parent. So I was really looking forward to Rails World this year. I wanted to spend time with coworkers I usually only see on a screen, meet new people, see cool products, and talk about random nerdy stuff. I got a good mix of all of it.
What I really wanted to hear was how other teams are using AI. During his opening keynote, DHH asked the room who was still writing a meaningful amount of code by hand each week. About five people raised their hands. After that, AI took over almost every conversation. Developers earlier in their careers asked how our jobs are changing. More experienced developers were excited about how much they can automate, and some questioned the whole workflow: Are humans the bottleneck? Do we still need PR reviews?
I'll be honest: some of what other companies do is hard for me to picture. I work at a consultancy, where every client's app is different, and I still work pretty locally. AI writes the code, clicks through it in the browser, runs the tests, and runs a few review skills. I decide which findings matter and read the code myself at the end. I'm not ready to one-shot a feature and walk away.
Shipping Is Your Heartbeat — Ryan Sherlock (Fin)
Watch the talk: Shipping is your heartbeat: Rails in the agentic era
Our job is to make that loop as fast as possible."
This was the talk I came for: what's working for one developer, and what's working for a whole team. Ryan shared that 40% of Fin's PRs are now approved by an AI reviewer, with only one human in the loop. That shocked me. I can picture it for small copy changes on one of our client apps. But we also support a large online store, where an unreviewed data change could hurt sales all day.
So what would get me over that line? I'm still figuring it out. Fin has a safety net: when monitoring catches a problem, production rolls back on its own, with no human involved. That works because their changes are small. The AI reviewer only approves PRs under 150 lines, and their median PR is 68 lines. On the app I have in mind, about one in three of my PRs change more than 250 lines, and a deploy took about an hour. With a one-hour deploy, there's no room for an automatic revert. If something leaks, you don't want to wait an hour while it gets worse. Fin drew their line at 150. Maybe ours is low-scope requests: few files, few lines, plain view changes. We're not there yet. But we're closer than I thought, and that's because of the next talk.
The Most Valuable Engineer Isn't Shipping Features — Robby Russell
Watch the talk: The Most Valuable Engineer Isn't Shipping Features
You do not need permission to do your job well. If you, your co-workers, or your little AI agent buddies … are repeatedly encountering friction, it's part of your job to try to alleviate that."
Yes, I'm biased. He's our boss. But as someone more hesitant about AI than most, this one hit home. Robby talked about makers, who build new things, and menders, who repair and improve what already exists. It made me ask which one I am, and how much mending is waiting in our apps. We've all had the "oh yeah, that app is weird, just run this command" moments, or found a monkey patch and wondered if anything even calls it. With AI, why aren't we fixing them?
In Practice
I've always been careful with client budgets, so these fixes kept getting pushed back. After Rails World, I said screw it. On one app:
- Tests: The full suite took 50 minutes on a good day, and up to 90 on a bad one. So we only ran "related" tests, on an app where unrelated changes break things. With parallel processes and less shared setup, it now takes 20–30 minutes.
- Deploys: About an hour. While digging, I found a check that waited 10–15 minutes before asking AWS if the deploy was done. Updated it to check every few seconds, and now our deployments take 30 minutes.
- Front-end tests: There were none for the 4–8 main user workflows. Now a Playwright suite walks through them for me. I'd wanted this for a year.
On another app, I finally removed a strange SCSS setup that needed its own PR for every style change, and that was after actually making the changes to the CSS files. This functionality turned out to exist for designers at the previous agency that maintained this application.
None of these are where I want them yet. But here's what I didn't expect: this mending work is exactly what moves us toward the future Ryan described. Fast tests and fast deploys are what make auto-merge something you could actually trust.
Mending isn't only for the apps, either. It applies to how I work with AI, too: don't fix the mistake, fix the system. Tools like Matt Pocock's /retro and Anthropic's /insights look back at my sessions and point out hooks I didn't know I needed. A notable mention here is Joël Quenneville's talk from thoughtbot, Harness Engineering on Rails. He showed how to move quality rules out of prompt files and into real tools, like custom RuboCop cops, generators, hooks, and focused review skills.
From the Hallway
One line stuck with me: "Use your previous PRs as data." AI-written PRs had gotten long. I was reading a thesis when all I wanted to do was change the color of a button. Instead of writing rules from scratch, let the AI learn from the PRs our engineers already wrote. The first skill I built was for PR descriptions. It isn't magic, but reviews are MUCH easier.
Client tickets have the same problem. A client once read a whole AI-written ticket and still had no idea what to test. For clients, less is more: Did the button get fixed? Does the workflow still work? What do they need to test? I still write those myself first.
What I'm Still Thinking About
There was a strange feeling at Rails World, a job fear we were all feeling together. I got into software during the React boom, when everyone wanted to solve every problem with one framework. AI writing our code is my first truly big shift, and I struggled with it. I'm a lot more comfortable now. I'm getting paid to experiment every day while still delivering to our clients.
The bigger question for me is open source. Everyone is building their own version of everything to drop a subscription, and small gems are harder to sell when anyone can generate their own. I think many people will learn the hard way that maintaining software is the expensive part.
Takeaway
Don't spend your energy worrying about AI taking your job. Enjoy this moment. People are doing incredible things, from decompilation projects bringing old games to every platform to personal assistants that help manage everyday life. Things move fast, but it's still easy to jump in. Build the project you've wanted to build for the last ten years. We're in a fun, crazy time.
Thanks to everyone I talked to at Rails World, and to the coworkers I finally met in person. I love this community.
If your team has found where its auto-merge line is, I'd love to compare notes. Find me on LinkedIn.