Lets say a team is starting a new project, someone suggests Rails, and the room goes quiet in that particular way that signals polite disagreement. The assumption behind that silence is that they think Rails is legacy, that the modern stack is TypeScript and React, and that choosing Ruby is a nostalgic indulgence rather than a technical decision. That assumption has aged poorly in the age of AI.
The AI coding era has changed the calculus in ways that are only starting to become clear, and Ruby On Rails benefits from those changes more than almost any other framework. To understand why, you need to think about what actually happens when an AI coding assistant like Claude Code or Codex works inside of a codebase.
When a language model starts working in a project, it has to spend part of its context budget just getting oriented. Where do things live? What patterns does this codebase follow? How is state managed? In a JavaScript project, those questions have no universal answer. The ecosystem is fragmented across React, Next.js, Express, Nest, Remix, Bun, and Vite, with state management handled differently in every shop and folder structures that vary by team preference and project age. The model has to build a mental map of your specific setup before it can write anything useful, and that map costs tokens.
Rails eliminates that cost almost entirely. The convention over configuration philosophy that David Heinemeier Hansson built into the framework in 2004 turns out to be exactly what a language model needs. Models go in app/models. Controllers go in app/controllers. Associations follow has_many and belongs_to. Migrations have a specific DSL. Tests live in test/ with predictable naming. Claude already knows all of this. It does not need to spend a single token figuring out where things go because there is only one right place for them to go. It can skip orientation entirely and start writing correct code immediately.
Garry Tan, the president of Y Combinator, one of the most successful startup accelerators in history with more unicorn companies and successful investments than any comparable institution, put it plainly in a recent post:
That framing is more than a clever line. It reflects something real about how AI tools interact with opinionated frameworks, and it carries weight coming from someone whose organization is currently advising the next generation of AI companies on how to build. Gary now advises new YC startups to choose Rails.
The token efficiency argument extends to the language itself. Consider a simple user service: in TypeScript, you need an interface declaration to describe the shape of the object, a class definition, typed method signatures, and explicit return types on every function. In Ruby, the same service is roughly half the code, expressed more directly, with less ceremony around what the types are and more focus on what the code does. That gap compounds. Across a large project with hundreds of models, controllers, and service objects, the difference in tokens consumed per feature implemented is not trivial. One analysis found that implementing features in TypeScript can cost roughly three times as much in token usage compared to the equivalent Ruby implementation. For teams that are running AI coding assistants continuously across a full development cycle, that is a real operational cost.
None of this means TypeScript is the wrong tool in every context, but the streaming UI argument that often gets raised in its defense is weaker than it sounds. Rails ships with Hotwire, which handles real-time, reactive interfaces without leaving the Rails stack. Turbo Streams lets you push live updates to the browser over a persistent connection, and Stimulus handles the client-side behavior that would otherwise require a JavaScript framework. The argument that you need React for a modern, dynamic UI simply does not hold the way it once did. Rails covers that ground natively now. The argument is not about TypeScript being bad. It is about Rails being unusually well positioned for a world where AI is doing a growing share of the implementation work, with no meaningful gaps left for the other stack to fill.
I build in Rails because I know it well and trust it for the kinds of products I work on, which tend to be data-driven web applications with real business logic, background processing, and integrations. I have built RAG pipelines on Rails, AI chat interfaces, webhook processors, and multi-tenant platforms. The tooling holds up. But the reason I feel more confident in that choice now than I did two years ago is that the AI coding era has turned Rails’ most underappreciated virtue, its rigidity, into a first-class advantage. The framework’s insistence on doing things one way is exactly what makes it legible to a model that has read every Rails codebase on GitHub and can now navigate yours without a tour.
The room might still go quiet when you suggest Rails. That is fine. Let the results do the talking.