Hello, I’m Haruku, a freelance developer.
After recently starting my own company, I’ve found myself thinking more about what kind of web framework fits the age of AI.
I entered the world of computer science through Ruby, and since then I’ve launched side projects using popular technologies such as TypeScript (Next.js, Nuxt.js), Go, and Rust.
But in the end, I realized that Ruby and Ruby on Rails fit my use case best.
And that judgment has not changed even in 2026, when AI coding has become far more advanced.
In this article, I’d like to explain why I decided to keep using Ruby in the age of AI.
For context, I plan to use Rails for every business I start through my company going forward. Please read this as one perspective from someone who is, in a sense, a “Rails believer.”
Why I Use Rails
A Strongly Opinionated Community
Many of you have probably heard the term CoC. Yes, “Convention over Configuration.”
When starting a new Rails project, the framework forces many decisions that developers would otherwise have to make from scratch. Developers simply follow those conventions.
Developers who use Rails always code with this concept of CoC in mind.
For example, if you want to create a new model tied to a database, you only need to type:
rails new model Post title:string body:text
in your terminal, and Rails will automatically create the table, the model layer, and the related tests.
When I first learned programming and touched Rails, I wasn’t particularly impressed by this.
But when I later tried Next.js and Nuxt.js, I was shocked to realize that this was not the norm.
In many other frameworks, even the ORM for connecting to the database and the testing library are things you have to introduce yourself.
I genuinely wondered why so few other languages had truly “batteries-included” frameworks.
Even worse is that there is often no correct answer for “architecture,” including file structure.
Where would you place the file that defines a User model?
In Rails, of course, it goes in /app/models/user.rb.
But in TypeScript, Go, or Rust? Where do you put it? Do you just create your favorite location???
When hundreds of these decisions pile up, developers feel stressed even just reading the code.
Eventually, they set off on a journey to discover “what good architecture is,” spending time and mental energy on things like Clean Architecture or Onion Architecture that produce no profit at all. (Yes, that was me in the past. lol)
Rails’ strong philosophy is sometimes criticized as “inflexible” or “not suitable for certain cases.”
But unless you are planning a very large-scale project from the beginning, it probably won’t be a problem.
DHH, the creator of Rails, has pointed out that most modern web development is CRUD—that is, applications of simple database reads and writes—and has openly stated that Rails is fully capable within that scope.
This is highly compatible with AI coding.
For example, suppose an AI goes off the rails and writes logic inside the User model that sends an HTTP request. (They do this often.)
In terms of whether it runs or not, it probably will.
But sending HTTP requests is clearly not the responsibility of the model layer. The role of the model layer is to handle database reads/writes and relationships.
The more rotten code increases, the harder it becomes for both humans and AI to maintain the code or add new features.
And AI takes zero responsibility for the code it generates.
That is why, in the age of AI, a strongly opinionated Ruby on Rails becomes a strength.
Specialized for Small-Scale Development
You may have heard people say, “Large companies like GitHub and Shopify use Rails! That’s why you should use Rails!”
That is true, but I’d rather argue that Rails’ real strength shines in smaller, elite teams—say, one to five people.
DHH wrote a book called Rework.
It argues that you can make enough profit with a small team without raising huge amounts of VC funding or hiring employees at scale.
This book influenced my life more than any other.
And I believe this approach of pursuing profit with a small team fits perfectly in the AI age.
Since LLMs became widespread, people have started saying that “a one-person unicorn company will emerge within a few years.”
Going forward, I believe engineering teams will continue to shrink, and the default competition will be about how quickly and how many products you can build and launch until you find PMF.
In other words, we are entering an era where small teams launch many products.
Rails is a framework DHH created for himself.
It is specialized for quickly launching from a business perspective, adding features, getting market feedback, and rapidly repeating that cycle.
The rails g scaffold command is the clearest example of this.
About three weeks have passed since I started my company, and by using only two free days per week—roughly ten days total—I was able to build a product and now have a realistic path to release it next week.
This is possible precisely because of Rails’ strong philosophy based on CoC and the community that supports it.
I don’t think it would have gone that way with something like Next.js. (I can imagine days spent fighting server components and caching.)
As a framework for a small elite team using AI to run the PDCA cycle, I don’t think there is anything more suitable.
And as shown by the large companies mentioned earlier, Rails can also scale properly when used appropriately.
More Than 20 Years of History
Ruby on Rails was released in July 2004. It already has more than 20 years of history!
As you know, for generative AI to produce more accurate results, the quality and quantity of the training data are prerequisites.
As an engineer, I fully understand the desire to build products with “modern” technologies.
But from the perspective of getting a business off the ground, you should absolutely avoid that. The reason is that the probability of failure increases.
When reviewing AI-generated code, haven’t you ever replied, “That was true for an old version, but the latest version is different”?
Rails has been used with consistent rules for more than 20 years, so it almost never outputs wildly incorrect code.
This high level of trust is one of the reasons I love Ruby.
Simple and Easy to Understand
Take a look at recent release notes from well-known frameworks:
- “Server Components added?” Weren’t you the ones generating HTML only on the client side?
- “Caching is now easier to handle?” Why do I have to think about caching in addition to what I’m eating tomorrow?
- “We fixed a vulnerability!” Oh no, my company’s server was used for Bitcoin mining.
- “This rendering feature is only supported on ◯ercel!” What a wonderful challenge to the open-source culture.
Honestly, I think many people are tired of recent web trends.
If that sounds like you, please come to the Ruby and Rails community. It’s quiet here.
For those who know nothing about Rails, here’s a quick summary of recent Rails trends:
- Hotwire (Stimulus and Turbo) becoming the default: You can implement SPA-like UI experiences with the familiar Rails development style, while writing almost no JavaScript.
- Hotwire Native: By applying WebView technology, you can build native-like iOS and Android apps simply by writing normal Rails.
- Kamal: If you can prepare your own computer, such as a VPS, you can deploy in just a few steps. (It’s very easy and cheaper to operate than AWS or GCP!)
- Production-ready SQLite and Solid Stack: Rails has moved closer to a setup that can be operated without relying on external infrastructure like PostgreSQL or Redis. (Of course, not relying on external services also makes it cheaper!)
These trends are extremely consistent: “Less is more.”
Despite its overwhelming history, I truly love Ruby on Rails as a framework that continues to evolve in a simpler and smarter direction.
Responses to Common Criticisms of Rails
I’ve talked about my love for Rails so far, but finally, I’d like to summarize my own responses to common criticisms of Rails.
It’s not a statically typed language. The lack of type completion is painful.
→ Whether a language is static or dynamic does not change the value delivered to users. Of course, each has its pros and cons.
But I believe Ruby’s flexibility supports Rails’ “OMAKASE for now” culture.
As for type completion, I don’t think you need to place too much importance on it. The existing ruby-lsp works well enough, and DHH himself apparently doesn’t use editor completion in the first place.
Today we also have completion through GitHub Copilot, so from the perspective of “starting a new business,” I don’t think this is a problem.
Ruby code tends to get messy.
→ This can be said of any language. Engineers with low development ability can write messy code in Ruby, TypeScript, Rust, or anything else.
The reason people often claim that “Ruby code gets messy” may be because Ruby is one of the relatively beginner-friendly languages.
Rather than turning it into a language issue, I think we should focus on how to write readable code, how to design databases appropriately, and how to name variables properly.
Also, based on my experience, senior engineers actually tend to write more verbose and harder-to-read code.
I don’t know why, but one hypothesis is that executives and managers throw unnecessarily complex requirements at “reliable senior engineers,” and the code that satisfies those requirements becomes messy as a result.
So rather than Ruby code itself being dirty, I think the unnecessary complexity and ambiguity of business requirements creates the impression that “Ruby/Rails code is somehow hard to read.”
But it’s not popular these days, right?
→ That is a painfully valid point. Ruby’s popularity is steadily declining.
If your goal is to “learn a programming language and increase your salary,” TypeScript is probably the safer choice.
I hope Ruby will be reevaluated.
Because from a business perspective, it is the best language and framework.
Ruby’s poor performance is terrible!
→ Do you want to drive an F1 sports car to the nearest supermarket?
I’m fine with a used compact car.
Twitter escaped from Rails!
→ And then it became Elon Musk’s toy!
I’m Developing a Rails Boilerplate for Solopreneurs
Because I love Rails, want to succeed with my own business using Rails, and want to launch as many products as possible, I’m developing a Rails boilerplate for solopreneurs that specializes in MVP development.
It will be released soon.
If you’re interested, I’ll distribute it for free to testers, so please send an email to haruku.maniwa@laicos.tech with the subject “Template Request.”
(Update)
The beta version is no longer available!
The official version can still be purchased at super-rails.com.
Super Rails | Rails Boilerplate for Solopreneurs
A production-ready Rails boilerplate with Devise, Avo, Stripe, ViewComponent and more. Skip the setup, ship your MVP in days.
super-rails.com
Have a great development life!
Top comments (0)