PROMPT to IPO: Why Rails Won the Agent Framework War Nobody Knew Was Happening

On March 5, DHH changed three lines on the Rails homepage. The old pitch: "Compress the complexity of modern web apps. Ruby on Rails scales from HELLO WORLD to IPO." The new one: "Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO."

The Hacker News crowd hated it. "If I read this the first time I would think this is some kind of tool to manage your LLM agents," one long-time Rails developer wrote. "It seems like DHH is throwing all what made Rails special under the bus for AI hype."

I get the frustration. But DHH is right, and the evidence is already in the benchmarks.

The benchmark that proves Rails wrong

Martin Alderson ran a framework comparison in February 2026 that should have ended this argument before it started. He asked Claude Code to build a CRUD app from scratch in 19 different frameworks and measured token consumption.

The results look bad for Rails:

Express beats Rails by 11k tokens. ASP.NET Minimal wins by 12k. If you're counting tokens per task, Rails loses. The argument should be over.

It's not.

Why single-task benchmarks miss the point

That benchmark measures the cost of building something from nothing. In production, agents rarely build from nothing. They modify, extend, debug, and refactor existing codebases. Hundreds of times.

And that's where convention stops being a philosophy and starts being a cost multiplier.

When Claude Code opens a Rails project for the hundredth time, it already knows where everything is. Models in app/models/. Controllers in app/controllers/. Database schema in db/schema.rb. Background jobs in app/jobs/. Mailer templates in app/views/. Routes in config/routes.rb.

It doesn't have to read a single file to know this.

When it opens an Express project for the hundredth time, it has to start from scratch. Where's the ORM? Could be Prisma, Sequelize, TypeORM, Mongoose, or raw SQL. Where are the routes? Maybe routes/, maybe inline in server.js, maybe scattered across feature folders. What's the middleware stack? The agent has to read every file to find out, because every Express project is a snowflake.

Zylos Research published agent cost analysis in February 2026 showing that coding agents make 3 to 10x more LLM calls than simple chatbots. Each call adds tokens for reading files, reasoning about structure, and generating output. An unconstrained agent solving a single software engineering task can burn $5 to $8 in API fees.

Multiply that by the ambiguity penalty. Every time an agent runs list_files to figure out your project structure, that's tokens. Every time it reads a config file to identify your ORM, that's tokens. Every time it guesses wrong about where you put your validation logic and has to backtrack, that's tokens.

In a Rails project, those calls don't happen. Convention eliminates them.

One line of Rails does the work of fifty Express tokens

Here's the example that convinced me.

In Rails:

class User < ApplicationRecord
  has_many :posts, dependent: :destroy
end

That single association declaration tells the agent:

1. There's a posts table with a user_id foreign key
2. user.posts returns a collection
3. user.posts.create(title: "...") works
4. Deleting a user cascades to delete their posts
5. The Post model lives at app/models/post.rb

One line. The agent doesn't need to verify any of this. Rails conventions guarantee it.

The Express equivalent? The agent has to:

1. Open schema.prisma and find the Post model
2. Read the relation definition to understand the foreign key
3. Check whether cascade delete is in the schema or handled in application code
4. Find wherever you defined your query functions (could be anywhere)
5. Look for validation middleware (could be in the route handler, a middleware file, or a shared utility)

I've built production APIs in both. In Rails, I'd add that association and immediately start writing the controller. In Express, I'd add the Prisma schema, run the migration, import the client, write the query functions, register the routes, and add the middleware. The agent has to do the same thing, and it's paying per token.

Garry Tan said the quiet part out loud

In February 2026, the YC president put it plainly: "I think people are sleeping a bit on how much Ruby on Rails + Claude Code is a crazy unlock. Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends."

That's the insight. Rails wasn't designed for agents. It was designed for developer ergonomics: short declarations, sensible defaults, predictable structure. Those same properties make it straightforward for LLMs to reason about.

An LLM reading has_many :through doesn't need documentation. It trained on thousands of Rails projects that use the exact same pattern. The convention IS the training data.

An LLM reading a custom Express middleware chain has to figure out YOUR specific abstractions. Every project teaches it something new, and every lesson costs tokens.

The Rails agent ecosystem is moving fast

The clearest signal isn't DHH's homepage change. It's what's happening in the Rails AI ecosystem.

Active Agent launched with an MVC pattern for AI, treating agents like controllers. Your agent gets a model (GPT-4o, Claude), a prompt template (like a view), and database access (through ActiveRecord). It fits Rails conventions so naturally that the learning curve for a Rails developer is nearly zero.

RubyLLM::Agents shipped a full Rails engine for production LLM agents: DSL-based agent definitions, cost tracking, circuit breakers, retry logic, and a mountable dashboard. All using familiar Rails patterns.

A January 2026 engineering post from Chayut Orapinpatipat described what multi-agent Rails architecture looks like in production: specialized agents for SRE monitoring, code review, implementation, and triage, all working within the same predictable Rails structure.

The common thread: Rails conventions make agents introspectable. schema.rb is the source of truth for the database. Model files declare all relationships. routes.rb maps every endpoint. An agent can build a complete mental model of a Rails app by reading four files.

Try that with Express. You'll need to read the entire codebase.

The typing gap is real (and it doesn't matter as much as you think)

The strongest argument against Rails for agents isn't token efficiency. It's types.

TypeScript frameworks give agents explicit type signatures for every prop, every API response, every database query. When an agent generates Next.js code, TypeScript catches errors at compile time. When it generates Rails code, Ruby's duck typing means errors show up at runtime.

Rails has Sorbet and RBS, but neither works well with the framework's heavy metaprogramming. has_many generates methods at runtime through metaprogramming. Static type systems literally can't see them because they don't exist in source code. Sorbet's own documentation calls RBS support "experimental" and "second class."

But here's the thing most people miss: agents don't run type checkers. Claude Code, Cursor, Copilot, none of them are executing tsc --noEmit or srb tc as part of their generation loop. They're inferring structure from conventions and examples. And conventions are exactly what Rails provides in abundance.

TypeScript gives agents more tokens to read (explicit types everywhere). Rails gives agents less to read (conventions encode the same information implicitly). For generating new code, fewer input tokens with strong conventions beats more input tokens with explicit types.

For reading and understanding existing code? TypeScript wins. Type signatures are documentation. But that's a different task than what most agent workflows are built around.

Where Rails actually loses

I'm not going to pretend Rails is perfect for agents. It's not.

The metaprogramming that makes Rails conventions powerful also makes debugging brutal. When an agent generates code that calls a method that doesn't exist yet (because it only gets defined at runtime through a has_many declaration), the error messages are cryptic. TypeScript would catch this before execution.

Rails projects also carry more boilerplate per initial setup. Alderson's benchmark showed 38k tokens for a CRUD app versus 27k for Express. If you're building many small, independent services, minimal frameworks genuinely cost less.

And the Ruby ecosystem is smaller. There are fewer Ruby AI libraries, fewer Ruby examples in training data, and fewer Ruby developers to maintain agent-generated code. Python and TypeScript ecosystems are massive by comparison.

The framework your agent doesn't have to learn

DHH's homepage change isn't really about agents. It's about something deeper: the cost of ambiguity in an era where machines read your code more often than humans do.

Convention over configuration was always about reducing the number of decisions a developer has to make. With coding agents, every decision the developer DIDN'T have to make is also a decision the agent doesn't have to reverse-engineer. That's not a feature. That's a compounding advantage across every file, every task, every session.

I've worked across Rails, Laravel, Express, and Next.js in production. The pattern is consistent: opinionated frameworks where conventions are strong produce faster agent interactions, not because the agent writes less code, but because it asks fewer questions first.

If you're choosing a framework for a project where agents will do significant work, raw token efficiency per task is the wrong metric. Look at how many assumptions the agent can safely make without reading your code. In Rails, that number is high. In Express, it's close to zero.

"PROMPT to IPO" sounds like marketing. The underlying argument, that convention is a token multiplier, is engineering.