Why Use Ruby on Rails during this AI Era

Most people know Rails for one idea, convention over configuration. That basically means Rails decides a lot of things for you before you even open your editor. You don't spend your first week picking an ORM or arguing about folder structure. You just follow the rules that are already there.

In a lot of other frameworks, you have to pick your own ORM, pick your own test runner, and decide your own file structure. And there's rarely one clear answer for where things should live. Where does a user model go in a layered app? In Rails it's simple, it goes in app/models/user.rb. In TypeScript, Go, or Rust, you're often just picking your own favorite spot and hoping it holds up. Multiply that by a hundred small decisions and even starting a new project gets tiring before you've written any real logic.

Generators do the boring setup for you

This is the part that gets overlooked. Need a new model that's connected to the database? You type one command in the terminal, and Rails creates the migration, the model file, and the test file for you, already named and placed exactly where Rails expects them to be.

Compare that to something like NestJS. You have to pick your ORM yourself. You have to pick your test setup yourself. You have to decide the folder layout yourself. None of that is wrong, it's just more decisions, and for a small startup team those decisions add up fast. Every hour spent deciding where a file should live is an hour not spent building the actual product. Rails just skips that step for you.

Conventions make AI write better code

David Heinemeier Hansson (also known as DHH), the creator of Rails, has said most web development is really just CRUD, create, read, update, and delete. For that kind of work, Rails is strong, and it turns out to pair really well with AI coding tools.

Here's a concrete example. AI will sometimes write an HTTP request straight inside a model, because the code technically works. But that's bad design. A model should deal with the database and relationships, not go making network calls on its own. Code like that is hard for a human to maintain, and it's hard for the AI itself to reason about later too, since it never really has to answer for what it wrote.

Rails has more than twenty years of clear, consistent rules about where things belong. So when AI writes Rails code, it tends to put things in the right place far more often, simply because the convention already exists and is well established. That consistency is exactly what makes Rails feel steady in the AI era.

It's great for small teams

Some people point out that big companies like GitHub and Shopify run on Rails, so it must be good. That's true, but Rails is even stronger for small teams, the one to five person kind.

DHH also wrote about small teams doing big things. The idea is simple. You don't need a pile of VC money and you don't need to hire a big team to build something that makes real money. After tools like these became common, people started predicting that a single person could run something close to what used to take a whole company. What matters now is how fast you can build, how many products you can actually launch, and how quickly you find something the market wants.

Rails was originally built by DHH for himself, to launch fast, add features fast, get feedback, and improve fast.

Twenty years of history helps the AI too

Ruby on Rails came out in 2004, so it's had more than twenty years to settle. AI needs good training data to give good answers, and both the amount and the quality of that data matter a lot.

If your actual goal is to make a business work, it's worth being careful. New tools come with a real chance of things breaking in ways nobody's seen yet. Have you ever had AI write code and then tell you it's using an outdated pattern that changed in the newer version? That happens constantly with fast moving frameworks. Rails has stayed consistent for over twenty years, so AI rarely produces strange or broken Rails code. That reliability is a big part.

It keeps getting simpler, not more complicated

Look at the release notes of a lot of popular frameworks lately. Server components got added, but now you have to think carefully about caching just to render some HTML. A security patch goes out because someone's server got hijacked for crypto mining. A rendering feature only works on one specific hosting platform. Some of it starts to feel like it's working against the whole idea of open source.

Honestly, a lot of people are tired of how fast and complicated web development trends have gotten. If that's you, Rails is a quieter place to be. It's also not standing still. Hotwire is now the default way to build interactive pages without writing much JavaScript. Hotwire Native lets you build iOS and Android apps using Rails and web views. Kamal makes deploying to your own server simple, so you can run on a plain VPS for a lot less than AWS or GCP. SQLite support and the solid stack are improving too, which means Rails needs fewer outside services like Postgres or Redis to run well. The pattern is clear, Rails keeps getting simpler and smarter instead of piling on more complexity.

Answering the usual criticisms

Ruby isn't statically typed, so it's harder to catch bugs at compile time That's true, but static versus dynamic typing doesn't change the value you deliver to users. Both have real tradeoffs, but Ruby's flexibility fits how Rails is meant to be used. Sorbet already exists if you want types, and today you also have AI to help catch mistakes. If your goal is getting a business off the ground, this usually isn't the blocker people think it is.

Rails code turns into a mess easily That's true of every language. A weak engineer can write messy code in Ruby, TypeScript, Go, or Rust, it's not unique to Rails. People blame the language because Ruby is easy to pick up, but the real issue is usually somewhere else, like unclear business requirements, unclear naming, or a database that was never really designed. That's not a Ruby problem.

Ruby isn't as popular as it used to be That's true, if your goal is purely to learn the language that gets you the highest salary right now, TypeScript is probably the better bet. But from a plain business point of view, Ruby and Rails still holds up really well.

Ruby is too slow Would you drive an F1 car just to get to the nearest supermarket? For most projects, a small reliable car gets the job done, and Rails is that car.

Twitter moving off Rails gets brought up a lot too. Rails is be known for shipping more products and shipper them quicker.