Ruby has been buried for so many years that the phrase “Ruby is dead” no longer stirs any emotion. Meanwhile Rails keeps getting new versions: Rails 8.1.4 was released on September 24, 2026. Rails has more than seven thousand contributors over its history, large companies keep running it in production, and some Rails applications have been alive for more than ten years. That is why the question “is Ruby dead or not” feels fairly pointless to me.
A different question is more interesting: who will be writing Ruby in 5 to 10 years?
Imagine a company in 2032 that needs a senior Ruby developer. The requirements are perfectly ordinary: 5 to 6 years of Rails, PostgreSQL, Redis, Sidekiq, experience with large systems. One small question remains: where in 2026 is that person supposed to start gaining this experience? And another one: will a developer with experience in a different stack even want to switch to Ruby for that position?
What the market looks like
I work with Ruby myself and I do not consider the language outdated. After working with Go, some things in Ruby feel unique. Ruby lets you turn an idea into a working product quite fast thanks to mature frameworks like Rails. The framework covers an enormous number of routine tasks, it has a powerful ecosystem and good documentation, and there is a ready-made solution for almost everything.
But if you look at the market instead of the technology, the picture gets mixed. There are mature Ruby projects that keep evolving and need developers. And they often need people who really know Rails and PostgreSQL well, who can find their way around a large existing application and understand the consequences of a change in a system that has been alive for years. In other words, they need middles and seniors, while the places where a person can become that middle or senior are noticeably fewer.
Even the job search results are telling. A query for “Ruby developer” returns not only Ruby positions but also openings for systems analysts, Go developers, DevOps engineers and other roles where Ruby is merely mentioned in the requirements. This is not a proper market study, of course, but the impression it leaves is a specific one.
The road into Ruby runs through Rails
Ruby has one more peculiarity. Historically the market has very often looked not for a Ruby developer but specifically for a Ruby on Rails developer. For comparison: a person can learn Go and then end up in web development, infrastructure, system utilities, databases, network software or tooling. In Ruby, for a huge number of people, the path looked roughly like this for a long time:
I want to do web development → I learn Rails → along with Rails I learn Ruby.
So Rails was not just one of the popular Ruby frameworks. For many people it was the reason to start learning the language at all. Even in openings titled simply “Ruby developer”, Ruby on Rails shows up quite often.
Ruby is not only Rails
There are Grape, Hanami, Roda and other projects. Roda, for example, keeps evolving and offers a completely different philosophy: a small core, a routing tree, plugins and a minimum of hidden magic. New versions keep coming out. Hanami has not gone anywhere either. The project offers a more explicit approach to architecture and dependencies than classic Rails. You cannot say that Rails is the only thing in Ruby, but in terms of ecosystem scale and market influence none of the alternative frameworks has come close to it.
On RubyGems, Rails has roughly 800 million downloads. That number includes updates, CI runs, reinstalls and plenty of other activity. But Rails has covered a huge class of problems so well that a developer often does not ask “which Ruby framework should I pick?”. The question becomes a different one: “why is this not Rails in the first place?” This is both the strength of the Ruby ecosystem and its peculiarity: in terms of the market and of growing commercial Ruby developers, Rails still plays the key role.
Rails and monoliths
Many well-known Rails projects are built as large monoliths. And here the word “monolith” should not be taken as an insult. Rails itself promotes this model rather openly. The Rails Doctrine uses the term Majestic Monolith: the idea is to keep the system integrated and not spread it across services before there is a real need for that.
You can build large systems on Rails. There are well-known examples: Shopify, the 37signals products and other companies that have been growing Rails monoliths for years and do not treat the mere existence of a monolith as a problem. This approach has obvious upsides. You do not have to maintain dozens of network contracts, separate pipelines for every small part of the system, distributed tracing and change coordination across a pile of services. A large Rails monolith can live for a very long time.
But I would not conclude from this that there are necessarily a lot of such projects, or that they are guaranteed to stay. The real installed base of Rails applications is hard to estimate. On top of that, I know people who were laid off after their company rewrote the product from Ruby to another stack. And that was not some unique Rails monolith with a complex domain. From the description it was a fairly ordinary CRUD application.
If an application is relatively simple and the company wants, for whatever reason, to unify the stack, simplify hiring, merge teams or move to a technology it already uses in other services, a migration can turn out to be a perfectly realistic option. And for the specific Ruby developers involved, the consequences of such a decision can be very practical: the project stays, the team is no longer needed.
Complex systems stay, simple ones can migrate
And this is where the situation with Ruby gets more complicated: two processes run at the same time. On one side there are mature Rails systems that are too expensive and too pointless to rewrite just to change the language. On the other side, some of the simpler systems may well migrate to other stacks over time.
So you cannot simply say: “there is a lot of legacy Rails code, therefore there will always be work. Look, PHP projects are still being maintained”. But you cannot say the opposite either: “everyone is about to rewrite Rails in Go”.
Reality sits somewhere between these extremes. At the same time, Rails is hard to call a project maintained by three people on weekends: Rails 8.1.0 had 2870 commits, and even a routine maintenance release like 8.1.4 included more than 300.
So the problem, if there is one, lies elsewhere: not in the ability of Rails to keep existing, but in the ability of the ecosystem to grow the next generation of developers.
Maybe this is not only a Ruby problem
Here one could fairly object that junior openings have become rarer in general, regardless of the language. Companies want to hire someone who can already work independently. AI pushes the market even further in that direction: if an experienced engineer with an agent can do more, it becomes tempting to hire fewer people at a higher level.
And that creates a convenient answer to the problem I describe above: why grow all these new Ruby developers at all, if in a few years agents will write most of the code?
Making that bet is risky. I can readily believe that agents will write more and more code and do it better. But there is a big difference between “an agent can write working code” and “an agent can evolve a complex system on its own for years”.
Every mature project develops a culture of its own over time: its architectural agreements, the accepted ways of solving problems, the places people try not to touch without a good reason, historical compromises and decisions that look strange from the outside. Part of that can be written down into documentation or into rules for an agent, but even a detailed description does not guarantee that the agent will read the context correctly every time and will not get it wrong.
Idiomatic Ruby code and the right code for one particular ten-year-old Rails monolith are far from always the same thing.
There is also another side of AI that may turn out to be less pleasant for Ruby. The usual reasoning goes like this: agents will let a smaller Ruby team maintain an existing Rails project more cheaply, and therefore extend its life. But the same tool can make the reverse process cheaper too. Rewriting an ordinary CRUD application from Rails to Go, Java or another stack used to be too expensive simply because of the amount of work involved; as agents get better, the price of that decision may go down.
That gives us an interesting paradox: AI can simultaneously extend the life of complex Rails systems and make migration away from Rails cheaper for simpler applications.
What if we apply SDD?
This is where another logical argument appears: spec-driven development, SDD. Instead of simply telling an agent “build this feature”, we first describe the requirements, the scenarios, the constraints and the expected behaviour, and only then hand the specification to the agent. I like this approach: the less an agent has to guess, the better.
But SDD does not solve the problem completely. The specification was written by a human too. It can miss an important scenario or state a requirement incorrectly. It can describe the happy path in detail and say nothing about partial failure, backward compatibility, load, existing data or the quirks of an integration. What is more, the more confidently an agent implements such a specification, the faster a wrong assumption turns straight into code, tests and documentation.
In The Specification Paradox: Rethinking Requirements Engineering in the Age of AI the authors describe a similar problem. In their view AI removes part of the cost of writing code, but it does not remove the complexity of development: that complexity shifts into understanding the domain, gathering requirements, producing specifications, verifying the result and evolving the system further. They specifically talk about ambiguity propagation and specification debt: a gap in the requirements can now be multiplied quickly across the code, the tests and the documentation that an agent produces.
The core idea resonates with me: AI does not remove complexity, it moves it from implementation into requirements and verification. A significant share of the effort used to go into writing the implementation correctly; now it is getting more and more critical to understand correctly what exactly needs to be built. As a result, we can generate the wrong code from the wrong specification very quickly and very neatly. And here we run into experience again: someone has to understand what exactly belongs in that specification.
Development does not start with code
There is also a human factor that is easy to lose in conversations about agents. Development rarely starts from a good, complete technical specification. Very often a task arrives as a couple of paragraphs, after which the developer starts asking questions, going to the business side, to an analyst or to another team, and working out what exactly should happen in different scenarios.
Take payments as an example. Suppose the ticket says: “add payment for the service”. It all looks clear, and then the details begin. What do we do if the money has been charged but the confirmation from the provider never arrived? Can the request be safely retried? How do we protect ourselves from a double charge? What happens on a timeout? When do we refund? What will the user see if the payment went through but the service was never delivered? Who is the source of truth if our service considers the operation successful while the external provider says otherwise?
These questions have to come up before anyone starts implementing. An experienced developer asks them not because the specification says “check idempotency”, but because they have already seen how systems like this break. AI is useful here too: it can suggest additional scenarios, read the payment provider’s documentation and review the specification. But an agent will not decide on the company’s behalf which behaviour counts as correct. That decision still has to be made by the product manager, the analyst, the owner of the integration and the developer.
Even if one day an agent is technically able to do that, the question of responsibility for the decision remains. People do not like being charged twice, or paying for a service that was never delivered. That is exactly why the staffing problem is not solved by AI learning to write good Ruby. A company does not need someone able to type Payment.create!; it needs an engineer who understands whether that Payment can be created at all in the current state of the system.
The cost of a mistake differs too
I would not claim that a mistake in B2C is always less scary than one in B2B. In payments, banking or healthcare a B2C bug can be entirely critical. But in an ordinary non-critical user-facing feature, a mistake often ends with a support ticket, a bad review or the loss of some users. In B2B the consequences are frequently much more formal: the company has a contract, an SLA and the client’s business processes that depend on the system. If our mistake leaves a client unable to run their operations for several hours, the problem no longer stops at a “something went wrong” message. The company can breach the SLA, pay compensation, lose the client or take a direct financial loss. This matters especially in integrations. A single incorrect operation can travel further through several systems, end up in reporting or block a process on the client’s side. That is why the approach of “the agent wrote it, the tests passed, so we can ship” is fairly dangerous for parts of a system like these.
Someone has to understand not only the code but also the business invariants behind it: why one operation must not be performed twice, when a refund is allowed, and whose state counts as true when our service and the payment provider disagree. Tasks like these are exactly where the experience that later allows senior-level decisions gradually accumulates.
Which raises another uncomfortable question: if junior tasks are now cheaper to hand to an agent, then on which tasks is a future senior supposed to learn how to check that agent?
We can lose more than new developers, we can lose knowledge transfer
A senior does not appear simply because they wrote code for five years. A significant part of that experience comes from other people: learning why a particular decision was once made, why an obvious refactoring was rejected, and why a specific integration does not behave the way the provider’s documentation says.
If a team of ten gradually turns into three experienced engineers and a dozen agents working in parallel, that can be very profitable for the current pace of development. But at the same time there are fewer people the history of the system gets passed on to. And in a few years the problem may not be that there is nobody to write the next endpoint, but that there is nobody to explain why the existing endpoint works the way it does.
For large Rails monoliths this matters especially. Such systems often live for years, gradually accumulating integrations and business rules. You can keep ADRs, maintain good documentation, add instructions for agents, but putting ten years of product history fully into text is practically impossible: part of the context still stays distributed among people.
If fewer and fewer people work with the system, there is nobody to pass that context on to. Today the team wins on speed, but in a few years it may turn out that there is nobody left to make the hard decisions.
Why this is not only a beginner’s problem
At first glance it all looks simple: if you cannot find your first job in Ruby, learn Go or Python. But a few years later this becomes the employer’s problem. If a technology is used in a business-critical part of the product, the company needs people who know it well.
You can hire ready-made seniors, but a senior is not a natural resource. They used to be a junior, then spent several years making mistakes, reading other people’s code, taking part in reviews, dealing with production, upgrading Rails, catching a race condition in Sidekiq and trying to work out why PostgreSQL suddenly decided to do a Seq Scan. They also went to the business side, argued about requirements, shipped bad decisions and gradually learned to ask the right questions before the implementation starts.
If you remove the beginning of that chain, the end of it keeps existing for a while out of inertia. AI can even extend that period, because the existing seniors will be able to serve more code with fewer people. But the underlying problem of reproducing specialists does not go away because of that.
Companies with large Ruby teams will most likely have to grow specialists themselves more actively: take backend developers from other languages and retrain them, run internships, or deliberately hire people without several years of commercial Rails. But that brings up another question: how do you convince someone who is only starting their career to invest their time specifically in Ruby?
I do not really believe in learning a language for the sake of the language: to me a language is a tool. So convincing newcomers with elegant syntax, or with the fact that Rails lets you write less code, is not enough. A developer needs to see which problems they will be able to solve, which projects they will work on and where they can grow next.
If companies only want people with five years of Rails, the ecosystem starts living off specialists that somebody else grew earlier. To keep that from becoming a closed loop, companies will have to stop explaining how wonderful Ruby is and start showing in practice that a person without a multi-year Ruby background can join, get real experience and become a strong backend engineer in a few years.
Conclusion
I still dislike the claim that “Ruby is dead”: it is too primitive. But the opposite extreme, something like “there are plenty of Rails projects, so everything is fine”, is too simple as well.
Some large systems really can live for another ten years. Some small CRUD applications will be rewritten in another stack, especially if the company wants to unify its technologies. And AI can push in both directions at once: make maintaining an old Rails monolith cheaper and, at the same time, lower the cost of rewriting it if the system is simple enough.
Betting on agents to close the staffing gap by themselves is too optimistic too. Even if in a few years AI writes almost flawless and perfectly idiomatic Ruby, there will still be requirements, the culture of a specific project, business invariants, responsibility for decisions and knowledge transfer between generations of developers. SDD helps make requirements more explicit, but it does not guarantee that someone asked the right questions.
And then the main risk for Ruby does not look like this at all:
one day everyone wakes up and rewrites their Rails applications in Go.
The real risk is different: some of the complex systems written in Ruby are still running, agents can generate code for them, but there are fewer and fewer people who understand the history of those systems and the business behind them. That is the kind of person who can notice that the agent completed the task according to the specification, while the specification itself is missing an important condition:
“You did everything right, but this does not account for a rule the client’s work depends on. We cannot ship it, because …”.
And then the question is no longer only who will be writing Ruby in ten years, but also where the people able to answer for what is written in it will come from.