Results from the 2026 Ruby on Rails Community Survey, with responses from just shy of 1,800 Rails developers.
293 karma · joined February 1, 2010
Solid Cable, Hot Cell, Herb in Rails 8.2, Active Search, Ractor-safety, Lexxy, MCPs, sharding, custom generators… and a bunch more about where Ruby and Rails are heading.
Full playlist:
As code gets cheaper to produce, I think we have more room to wonder about the workshop around it. To unpack what we inherited, tinker with what’s getting in our way, and share what we learn with whoever comes next.
Human or otherwise.
Thanks to everyone who said hi, shared stories, and traded ideas throughout the week. A lot to keep wondering about.
A bit of a field report from #RailsWorld: the vibe here is far from doom and gloom. Quite the contrary. Wherever our industry is headed, most of us are still employed as menders… tending to systems that customers rely on and businesses are quite happy to keep paying for.
Most of us aren’t waking up to a blank canvas and designing the architecture of the future. We’re inheriting decisions made years ago, updating old patterns, working around constraints, and keeping this shit running reliably.
I think these newer tools give us an opportunity to wonder a little more about the systems we’ve inherited. To unpack why things work the way they do. To tinker with assumptions we haven’t had the time, confidence, or permission to revisit… and share what we learn so the next person, or agent, has an easier time.
That deployment model we picked eight years ago? Worth another look. Some of our web apps probably wish they were native apps. And there are plenty of architectural decisions we’ve been living with mostly because… well, we’ve been busy living with them.
There’s plenty of understandable anxiety about what these tools mean for our work. I’m increasingly curious about what they give us permission to revisit.
Once my keynote is published, I’ll share more about a little programming-language-adjacent framework I’ve been working on for approaching exactly this kind of curiosity.
In the meantime… keep showing up. Keep wondering.
Long live Ruby. Long live Rails.
p(bloom)
They’re generating over 95% of their code with Claude Code… and it’s not just engineers. Teams across the company are involved.
We got into how this is reshaping code review, who’s running production queries, and how they’re building guardrails to keep things from drifting. The part that stuck with me… knowing when to disengage the autopilot.
https://www.youtube.com/watch?v=ADBs2K5Tpz0 https://podcast.rubyonrails.org/2462975/episodes/19060786-br...
Wrote about why I think the job description already changed, and what I'd rather see teams do about it than have that exhausting conversation on repeat.
2006: Trey Parker and Matt Stone write "Oh My Science!" into two Season 10 episodes... a joke about replacing religious expressions with scientific ones.
2008: A coworker and I think this is hilarious. We build a Twitter side project called Oh My Science. It fetched tweets from the API and awarded gold stars to anyone caught thanking science for something they might have otherwise credited to a deity.
2009: I have a messy folder of Zsh configuration files. I want to convince a few coworkers to install it on their laptops so I don't have to remember all the verbose git commands we kept typing while pairing on their machines. I need a name for the repo. I glance over at our oh-my-science private repo. I shrug. "oh-my-zsh" it is.
Today, there are 8,400+ public "oh-my-..." repositories on u/GitHub.
There's a decent chance you've used one. There's a chance you've built one.
If you have, I'd love to know... did you know where the name came from?
The piece is about that “second act” of software. After launch. After early growth. When reliability and discipline matter more than novelty.
Curious how others here think about this.
So I’ve never been a “just build it” person.
But something has shifted.
Tell everyone a rewrite might happen “one day.”
So they hit pause, revisited the basics, and started stripping away what wasn’t helping.
This is a case study in technical maturity. A story of how slowing down just enough can help a fast-moving team go further. Worth sharing with your peers.
I’ve seen the same story unfold dozens of times:
One dev builds something useful. It ships. It grows. Then it outgrows them.
No docs. No tests. No plan for what happens next.
If that sounds familiar… you’re not alone.