One of the things we love most about the Rails community is how open we are to sharing how we work, what's challenging us, and how we're thinking and feeling about the evolution of software programming.
Since 2009, we've had the pleasure of checking the community’s pulse. The 2026 Ruby on Rails Community Survey's 9th edition is now LIVE and ready for you to dive into. While some data points may reflect what you expected, others may come as a surprise. Grab a cup of coffee, and let's dig into some highlights, shall we?
The obvious: AI is no longer on the sidelines
We added AI-related questions to the survey this year- how teams are using it, how they feel about it, and whether it's actually changing the way they work. About 57% of respondents said they've regularly integrated AI into their workflow, and 83% said it's moved past experiments and into their team's real work. This isn't surprising, you can't click anywhere online without running into a conversation about AI agents in programming.
Roughly half of respondents said the pace of AI advancement makes them anxious about the long-term value of their skills. That tension sits alongside another finding: 76% said they've made peace with AI being here to stay, and 74% of respondents say they've adapted and AI genuinely makes them more capable. Anxiety and acceptance aren't opposites; the data suggests most developers are holding both at once.

Workflows and team environments
About 46% of respondents agreed their team has clear policies that empower engineers to use AI, but that doesn't necessarily mean policies and best practices are in place. High individual AI agent adoption doesn't capture the full story because when we look at how people describe their workflows and team environments, we see a different pattern.
Individual developers are making their own choices about which tools to use, when to use them, and how much to trust them. But the team-level policies to support those choices are still catching up. That's not a negative thing, though- that's what early adoption looks like! When something proves useful, people start using it, and processes catch up later. That's where we're at right now.
We came across this same conversation over and over at Rails World 2026, too. The question most teams are asking is not whether people are using AI. It's how teams decide what appropriate use looks like, how they calibrate expectations, and who's responsible for the output.
The security-related responses throughout the survey point in the same direction. Respondents raised questions about reviewing AI-generated code, understanding what it does, and what happens when it's wrong- questions a careful engineer asks before relying on anything in production. The fact that people are asking them is a good sign.

Ruby 4 is here, and the tooling is moving
Another data point that surprised us: 49% of respondents are already using Ruby 4.x in their applications, less than a year after its December 2025 release- a fast upgrade pace for a relatively recent release. Plenty of teams are somewhere in between, with Ruby 4.x on some apps and 3.4 on others.
Version manager defaults are shifting too. mise went from 2% in 2024 to 38% this year, nearly tied with rbenv at 39%.
Deployment tooling tells a similar story. CD via CI leads at 60%, with direct Git pushes at 40%. Kamal is now at 24%, up from 2.4% in 2024, putting it ahead of Capistrano at 16%. That's a 10x jump in two years. Rails 8 made Kamal the default deployment tool for new apps, and the numbers show teams are going along with it.
On the JavaScript side: Turbo (Hotwire) is now the most widely used library at 65%, followed by Stimulus at 59% and React at 40%.
The direction across all of this is consistent: the community is actively choosing newer tools, and doing it at scale.

Open-ended answers
Open-ended sections tended to give us a little more context.
When we asked which gem people love and which one frustrates them, Devise topped both lists. Anyone who has maintained a Rails app for a few years will recognize that relationship.
People also added in answer options that we didn't provide. For example, Zed wasn’t listed as a code editor, and 10% of respondents wrote it in anyway. That’s enough to put it fourth overall, ahead of Sublime Text at 7%. Another 5% wrote in Cursor. When people have to add the tools themselves, it tells you how fast developer tooling is moving!
Hosting write-ins leaned toward smaller platforms. Hatchbox and Railway were the answers people typed in most often. Next to Kamal's growth, it looks like more teams want a simpler path from code to server.

Where are we headed?
Most developers regularly integrate AI into their workflow and have made peace with it. But more than half still worry about the long-term value of their skills. The most common uses of AI beyond writing code are code review and test generation, meaning developers use it to check work as much as to produce it.
Robby Russell, our founder, made a similar point in his closing keynote at Rails World. Every mature Rails app has its own local workshop: the patterns and unwritten rules a team learns over years, which AI agents have to rediscover every time their context resets. Producing code has gotten cheaper. Deciding what belongs, what can be trusted, and what should change still takes people who know the codebase and its history.
That framing and the curiosity framework he introduced, WUTS, struck us as a useful lens for reading the survey results overall.