DEV Community

SHIBATA Hiroshi
SHIBATA Hiroshi

Posted on

What Active Rubyists Are Using in 2026: A Maintainer's Read of the RubyKaigi Survey

#ruby #programming #survey #community

I'm Hiroshi Shibata (hsbt), a Ruby committer and the maintainer of RubyGems and Bundler.

TL;DR

At RubyKaigi 2026 we ran a 7-question survey on what Ruby developers are actually using: Ruby version, editor, coding agent, version manager, local dev environment. Around 400 responses. The headlines: Ruby 4.0 adoption is already on par with 3.4 less than six months after release, Claude Code is used by around 80% of respondents, VS Code + Cursor dominate the editor space, and mise / asdf are catching up to rbenv. This post walks through the numbers with a maintainer's commentary on each.

About the Data

The survey was collected at the ANDPAD booth at RubyKaigi 2026 (April 2026). Around 400 unique respondents, out of a conference crowd of well over 1,000 attendees. Q1 and Q2 were single-select. Q3 onward allowed multiple selections. Bar heights below represent the absolute number of people choosing each option, not market share. Charts are in Japanese; the bullet list under each chart translates the labels.

This is not a global Ruby survey. RubyKaigi is held in Japan and the audience is Japan-centric, though it includes a significant number of overseas Rubyists who travel in for the conference. Compared to the Stack Overflow Developer Survey, this population skews heavily toward actively-shipping professionals who attend in-person Ruby events. Read it as a snapshot of "Rubyists who still show up in person in 2026," not a representative cross-section of all Ruby users. One more caveat: I maintain several of the tools discussed below, so this is my read of the numbers, not a neutral analysis.

Q1. How Many Years Have You Been Using Ruby?

Bar chart of years of Ruby experience: 0-2 years about 115, 3-5 years about 95, 6-9 years about 65, 10+ years about 100

  • 0–2 years: ~115
  • 3–5 years: ~95
  • 6–9 years: ~65
  • 10+ years: ~100

A U-shaped distribution: newcomers and 10+ year veterans are both large groups, with a thinner middle. Ruby is past 30 years old now, and the fact that both ends of the experience curve are this thick suggests the community is renewing itself while keeping its long-term core intact.

Globally, AI coding tools have made small teams pick Rails again ("let's build it in Rails one more time"), while large-scale users like Shopify and GitHub keep pushing the upper end forward. The "I just started writing Ruby" voices I heard at the booth match the survey shape.

Q2. What Ruby Version Is Your Main Production Project On?

Bar chart of main production Ruby versions: 3.2 or earlier about 60, 3.3 about 50, 3.4 about 145, 4.0 about 140, 4.1 or later about 15

  • Ruby 3.2 or earlier: ~60
  • Ruby 3.3: ~50
  • Ruby 3.4: ~145
  • Ruby 4.0 (stable): ~140
  • Ruby 4.1+ (master / dev): ~15

This was the result that surprised me most. Ruby 4.0 was released on December 25, 2025, less than six months before this survey, and it's already on par with 3.4 as the primary production version. As a maintainer team we deliberately kept the 3.x → 4.0 migration cost small even though 4.0 is a major bump, and gem compatibility moved fast. Many projects are already making 4.0 the primary version in CI. That design call appears to be paying off.

A meaningful number of teams are still on 3.3 or earlier, which is the practical reality of long-running services. For context, Ruby ships a new minor version every Christmas, and each series is supported for roughly three years. Ruby 3.2 is already EOL, and Ruby 3.3 moved to security maintenance in March 2026, meaning it receives security fixes only. If you're on either, plan your upgrade to 3.4 or 4.0 within that window. If something specific is blocking the upgrade, we maintainers would love to hear about it.

Q3. What Editors Do You Use at Work?

Bar chart of editors used at work: VS Code about 200, Cursor about 110, Neovim and Vim about 70, RubyMine about 45, Zed about 15, Emacs about 10, others a handful each

This is the first multi-select question, so the counts overlap. Some respondents run VS Code alongside Cursor, or pair Neovim with VS Code for completion. Even accounting for that overlap, VS Code is the clear top at ~200, followed by Cursor at ~110.

VS Code has been the top editor in JetBrains' State of Developer Ecosystem and the Stack Overflow Developer Survey for years. What's new in 2026 is the rise of Cursor and Zed. Editor choice is increasingly driven by LSP support (notably ruby-lsp) and the quality of built-in AI assist, rather than by editor traditions.

Q4. What Coding Agent Do You Use at Work?

Bar chart of coding agents used at work: Claude Code about 325, GitHub Copilot about 85, Copilot Workspace about 60, Codex about 25, Devin about 10, not allowed or not using about 10, others a few each

This was the most skewed result of the entire survey.

Claude Code at ~325 is roughly 80% of respondents. The takeaway is blunt. If you're using a coding agent in 2026, you're almost certainly using Claude Code. Among Ruby developers attending RubyKaigi, it's the effective default.

The "not allowed by company policy" cluster is small but worth naming. The practical questions are still not fully solved at every org: what code or customer data leaves the company, vendor lock-in, and contract language for LLM-bound data flows. The unglamorous work of "making coding agents usable internally" is going to be a real competitive factor for engineering organizations over the next year.

Q5. What Are You Building with Coding Agents?

Bar chart of what respondents build with coding agents: production code at work about 320, hobby projects about 165, internal tooling about 160, OSS used by your product about 50, other OSS about 35

  • Production code at work: ~320
  • Hobby projects: ~165
  • Internal tooling at work: ~160
  • OSS used by your product: ~50
  • Other OSS: ~35
  • Other: ~5

Total votes are around 735, which means each respondent uses coding agents for about two categories on average. Production code at ~320 is unsurprising. Essentially everyone using a coding agent is using it at work. What's more interesting is that "hobby projects" (~165) and "internal tooling" (~160) sit at roughly half the production-code volume. For myself, since I started handing maintenance of Ruby-adjacent tools (like all-ruby) and release/packaging scripts to Claude Code, I write less code by hand but ship more.

Combining "OSS used by your product" (~50) and "other OSS" (~35), roughly 85 respondents are bringing coding agents into OSS work. Even after deduplicating, that's around 20% of respondents using coding agents to maintain open source. That would have been hard to imagine a year ago. For the Ruby ecosystem this directly lowers maintenance burden, and I see the effect firsthand on RubyGems and Bundler.

Q6. What Do You Use for Package and Version Management?

Bar chart of version management tools: rbenv and other Ruby-specific tools about 200, mise and asdf about 145, Homebrew about 140, Dev Containers about 60, Nix family about 10

I'm one of the rbenv maintainers, so factor in my bias. Still, the rbenv family is the largest group at ~200, with mise/asdf catching up at ~145. As more developers move between Node.js, Python, Go, and Ruby in the same week, the appeal of "one tool for all languages" instead of "one version manager per language" is real. Some portion of the rbenv user base is clearly in the middle of switching to or co-running mise.

Homebrew (project-local) sits at ~140, the same range as mise/asdf. I suspect this is a signal that more people are running their project Ruby inside Docker or in a remote dev environment and simply don't need to switch versions on the host anymore.

Q7. How Do You Run Your Project Locally?

Bar chart of local dev environments: Docker Compose about 295, native macOS or Linux about 65, Lima and Colima about 35, OrbStack about 30, Kamal, Codespaces and Podman Desktop about 5 each

Docker Compose at ~295 is roughly three-quarters of respondents. For a Rails app, spinning up web / DB / Redis / job queue together with Docker Compose is effectively the standard local stack.

Lima / Colima at ~35 and OrbStack at ~30 are neck-and-neck for the "Linux containers on Apple Silicon" slot. I'm personally curious how Apple's official container command, introduced in macOS 26, will land here over the next year. Native (macOS / Linux) at ~65 is the segment that runs Ruby / PostgreSQL / Redis directly on the host. It's simpler and noticeably faster than going through a container layer, and I work this way most of the time.

What This Says About Ruby in 2026

Seven questions, and the picture that comes out is a community that's mature but tooling-wise in a very dynamic phase.

Ruby 4.0 adoption is moving faster than expected. Editors are converging on VS Code and Cursor, where AI assist is built in. Coding agents are heavily concentrated on Claude Code. Version managers are diversifying away from rbenv-only toward mise / asdf. Every one of these has shifted noticeably in the last 12–24 months. The actual experience of writing Ruby hasn't really changed in 20 years, but the tooling around it is in the middle of a generational turnover right now.

From the maintainer side, my job is to watch these shifts and keep Ruby and RubyGems / Bundler as the foundation that all this tooling can build on. Supply chain security work, like the cooldown discussion on RubyGems I wrote about earlier this year, is increasingly cross-ecosystem rather than Ruby-only. The maintenance work going forward is to pick Ruby-shaped solutions that fit into the broader picture.

If You Want Global Numbers

This is a Japan-centric snapshot. For a global view, the Rails Developer Survey run by Rails Foundation is the better reference, and Rails Developer Survey 2026 is open for responses right now. The more practitioners like the ones in this survey respond, the more its results reflect what experienced teams are actually doing in production. It takes 10–15 minutes. Please consider filling it out.

Top comments (0)