loading . . . Ruby Didn't Die in the Age of AI When I first encountered Ruby on Rails back in 2010, it changed my life in ways that are hard to put into words. Meeting a framework sounds like a small thing but back then, Rails showed me how quickly I could bring my ideas to life. That realization made me want to share what I knew with everyone around me. I've been doing that ever since.
Years have passed. We've entered the age of AI. Many of us assumed that the era of
💡
****Ruby makes things easy****
was quietly closing. And in some ways, it was. But a new door opened at the same time. The era of doing things _even faster_ with Ruby and AI is just beginning.
## Why Ruby?
Fair question. Python dominates AI. JavaScript is everywhere. Why would anyone look at Ruby when building AI-powered applications?
Here's what I kept noticing: the developers who were moving fastest weren't necessarily using the most popular AI frameworks. They were using the ones that got out of their way. And Ruby, it turns out, is exceptionally good at getting out of your way.
A few months ago, the Sinaptia team built a fully-featured coding agent in 250 lines of Ruby. [1] A CLI with history, slash commands, subagent support, save and resume all in 250 lines. When I first heard that, I thought: "_Sure, but you could do it in Python too._ " True. You could. But there's something different about doing it in Ruby. And that difference compounds.
## AI tools don't write every language equally well
Last month, Steve Clarke ran an interesting experiment. He tested the same prompts across different frameworks and the result was clear: AI tools produce far more accurate and usable code in frameworks with strong conventions, like Rails. [2]
Why? Because there's very little left for Cursor, Claude Code, or Copilot to _guess_. In Rails, everything has a place. Authentication works a certain way. Background jobs are set up a certain way. Decades of convention mean AI doesn't need to fill in the blanks.
In practice, this means Rails projects need fewer corrections, fewer "no, that goes somewhere else" moments, less going back. The code comes out right more often on the first try.
Miles Woodroffe wanted to add a new feature to a meal planning app he hadn't touched in almost a year. He dragged two screenshots from the Vitality app into Claude Code, explained what he wanted. Claude interpreted the rings in the image as 3, 5, and 8-step completion goals, added monthly pagination, suggested a summary section he hadn't even thought of, designed the database changes, wrote the model and controller, and set up a nightly job using Solid Queue. It worked. 30 minutes. A feature he had been putting off for 6 months, shipped to production. [3]
> That's not magic. It's Rails conventions telling Claude exactly where everything belongs.
## The "research problem" is over. The "integration problem" has begun.
This was the line from Sinaptia's post that stuck with me. Before LLMs became widely available, building a coding agent was a genuine research problem. Now it looks like this:
1. Write two utility functions for the LLM. One for editing files, one for running bash commands
2. Connect to an API
3. Put it in a loop
That's it. That's the skeleton of a coding agent.
So why does this put Ruby in a strong position? Because the "integration problem" is exactly where Ruby shines. Rails has spent years doing one thing: abstracting complex infrastructure decisions and giving developers a clean interface on top. LLM integration fits that exact mold.
Look at RubyLLM. OpenAI, Anthropic, Gemini, Ollama. All through the same interface. Switching providers is one line. Defining a tool is one class. Setting up an agent is five lines.
> This isn't Ruby magic. It's good design. And Ruby is exceptionally good at expressing that kind of design.
## The numbers back it up
RubyLLM supports 800+ models across 12 providers. It has over 4.7 million downloads on GitHub. Companies like 37signals are using it in production. [4]
"Ruby has no AI libraries" is no longer a valid argument. Yes, PyTorch and NumPy live in Python, and if you're training models, Python is the right choice. B**ut we're not training models. We're _using_ them.** And for that layer, the Ruby ecosystem is mature and growing fast.
## What does "powerful" actually mean?
We've all heard "Ruby is a powerful language." But what does that actually mean?
Sinaptia put it well: power isn't just capability. **Power = capability / effort**. And Ruby maximises that ratio.
Think about it this way: the less code you need to set up an agent, the less time you spend _writing_ code and the more time you spend thinking about what you're _building_. That gap feels small at first. Over a project, it compounds.
Add AI tools to the mix and the advantage doubles. Ruby's readable, expressive syntax also makes it easier to understand what the AI produces. When Claude writes a Rails controller, you can see immediately what it does. Easy to change, easy to debug. The loop speeds up:
💡
****write → understand → adjust → move forward.****
Miles described this well: Ruby's clear syntax means that when you review what Claude delivers, you can quickly grasp the output and know what to do next. Compounded over a two-hour session, this is a massive boost to flow.
As Garry Tan put it
> _Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends. _[_5_ _]_
## Disposable code — and why that's liberating
This was the concept from Miles' post that hit hardest: _disposable code_.
When ideas can come to life this quickly, the way you work changes. Open a branch, try the idea, if it's not working, delete the branch and move on. We used to labour over code because it was expensive. Now code is just the way we present ideas to users. The idea itself is still what matters.
For Ruby and Rails, this is particularly meaningful. Rails was built on a culture of fast prototyping. With Claude Code, that culture reaches a new level: a prototype is now minutes, not hours.
## Conclusion
250 lines. A fully-featured coding agent. 30 minutes. A feature that had been sitting on the backlog for 6 months, now in production.
These numbers don't make me ask "how little code?" They make me ask:
> "if this much gets done with this little, where does the real work go?"
The answer is clear: the real work shifts to thinking about _what you're building_. What problem are you solving, what should the experience feel like, how should the system behave.
That, I think, is Ruby's best gift in the age of AI. The language is expressive enough, the ecosystem mature enough, the AI tools compatible enough — that you can focus entirely on what you're building.
So, how are you using AI tools in your Ruby projects? Have you tried Claude Code yet? I'd love to hear your experiences? Please drop a comment below. These conversations are what keep our community moving forward. https://enderahmetyurt.com/ruby-didnt-die-in-the-age-of-ai/
