Why I Bet on Rails — and Why I'm Building Maquina

I’ve been writing Ruby on Rails for over fifteen years. That’s not a statement of loyalty — it’s a statement of repeated choice. I’ve looked elsewhere. I’ve worked with other stacks, followed trends, and evaluated alternatives each time one gained momentum. And I’ve always come back to Rails, not out of habit but because it keeps proving itself.

Every framework promises productivity. Rails actually delivers it — consistently, across projects, over years, throughout the entire span of a career. The reason isn’t magic. It’s a specific set of decisions that build on one another.

One Framework, One Mental Model

Rails compresses complexity in a way that’s hard to fully appreciate until you’ve built something substantial with it. When you run rails new, you’re not just getting a scaffold. You’re getting a complete, opinionated answer to every structural question a web application has to answer: where models live, how they relate to the database, how controllers connect to views, how background jobs queue, how email sends, how tests are organized and named. These aren’t defaults you’ll eventually override — they’re decisions that hold across the entire lifecycle of the project.

This exemplifies what “convention over configuration” really means. Not that you can’t change things, but that you rarely need to. The conventions are good enough, consistent enough, and widely understood enough that the framework becomes a shared language. Any Rails developer who opens my codebase knows where to look, and I know where to look in theirs.

What keeps me here is that Rails has continually compressed complexity while expanding points for extension. Application templates allow you to codify your setup choices and replay them. Generators enable you to produce deterministic, project-specific scaffolding aligned with your patterns rather than generic ones. Concerns, service layers, rich models—the framework offers structure and room for extension. Rails 8 builds on this: SQLite in production, Solid Queue for background jobs, Solid Cache, Solid Cable for WebSockets, and Kamal for deployment. A single developer can now manage the entire stack—from first commit to live server—with a unified mental model, without Redis, or separate worker infrastructure, or Node.js for assets.

The ActiveRecord DSL exemplifies this on a smaller scale. A has_many :posts, dependent: :destroy declaration is not just a relationship—it’s packed with validation logic, query methods, lifecycle hooks, and referential integrity, all in a single expressive line. A handful of these declarations can form a complete domain model. The complexity isn’t eliminated; it’s compressed into something still understandable yet capable of doing all the work.

That’s the framework I keep returning to. And it’s the framework I chose to build upon.

What rails new Leaves Open

Here’s the honest part: rails new gets you to a great starting point. It doesn’t get you all the way to your starting point.

Every developer has a set of steps they follow immediately after creating a new Rails app. Configure authentication, set up request throttling, wire up a job queue and a dashboard to monitor it, add error tracking, and install UI components they’ve already used on previous projects. Write the configuration. These steps aren’t gaps in the framework — they’re workflow choices. However, they are repetitive, time-consuming, and vary from project to project, including how and when to set them up.

This is where Maquina generators came from. Not to replace Rails — to extend it in the same spirit: deterministic, opinionated, no magic.

$ rails new myapp --css tailwind
$ bundle add maquina-generators --group development
$ rails generate maquina:app --auth registration
$ bin/rails db:migrate
$ bin/dev

That sequence creates a fully configured application: authentication with account models and user roles (passwordless or password-based), Rack Attack for request protection, Solid Queue with a Mission Control dashboard, Solid Errors for error tracking, and a mailer setup — all following consistent patterns every time. The gem is for development only; the generated code resides entirely within your app and has no runtime dependencies. Delete the gem when you’re finished. Everything it produces is yours.

Read the full announcement for Maquina Generators to learn more about what’s included and how to get started.

Maquina Components extends the same idea to the UI layer. Rather than rebuilding Tailwind patterns from scratch on every project — or reaching for a JavaScript-heavy component library that pulls you away from Rails conventions — Maquina gives you 20+ ERB partials styled with Tailwind CSS 4 and Stimulus. Forms, tables, cards, alerts, sidebars, pagination, comboboxes, and date pickers. The full vocabulary of a production web app, in the format Rails already uses, is ownable and modifiable like any other code in your project.

Both tools answer the same question: how do you make the post-rails new setup as deterministic as the framework itself?

Rails Was Always Human-Centered. Now It’s Agent-Ready.

DHH described Rails as “a toolkit so powerful that it allows a single individual to create modern applications upon which they might build a competitive business.” That framing — one person, real business, no compromises — has always been what the framework is optimized for.

The Rails website recently sharpened this even further, updating its tagline to: “Accelerate your agents with convention over configuration. Ruby on Rails scales from PROMPT to IPO.” That’s not a marketing pivot — it’s a recognition of something the community has been discovering in practice.

Garry Tan, president of Y Combinator, made it explicit in February 2026:

“I think people are sleeping a bit on how much Ruby on Rails + Claude Code is a crazy unlock — I mean, Rails was designed for people who love syntactic sugar, and LLMs are sugar fiends.”

The reason goes deeper than syntax. When Claude Code opens a Rails codebase, it already knows where everything is. Models in app/models/, controllers in app/controllers/, has_many and belongs_to following standard patterns, migrations with a specific DSL, and tests in test/ with predictable naming. It spends almost no tokens figuring out the project’s structure — it just writes correct code. Compare that to a JavaScript project where the AI has to reverse-engineer whether you’re using React or Next.js, how state is managed, and what build pipeline you’re running. The tokens spent on orientation are tokens not spent on your product.

Ruby also turns out to be one of the most token-efficient languages for LLMs. Research analyzing programming language tokenization shows Ruby near the top — its idioms pack enormous semantic density into minimal tokens. A has_many :posts declaration carries relationship semantics, query methods, and lifecycle behavior in five tokens. More of your codebase fits in the AI’s working context at once, which means it can stay coherent across larger features and run longer without losing the thread.

I’ve experienced this directly, building Resto — a personal finance app based on the Japanese Kakeibo method — and Recuerd0, a versioned knowledge base for AI tool context. Real applications, built by one person, shipped to production. The convention didn’t slow the work down. For the AI, it was a precondition for the work to be possible at all.

Making Rails AI-Aware

Recognizing this, I started building a second layer of tools for Maquina — not just to extend Rails for humans, but specifically to extend it for AI-assisted workflows.

Rails MCP Server connects Claude directly to your codebase through the Model Context Protocol. It browses your project structure, inspects models and their relationships through static analysis, reads routes with filtering, examines your schema, and executes sandboxed Ruby code against your app. Instead of pasting context into a chat window, Claude reads your project the way you do — with full visibility into its existing structure. Everything else in the Maquina AI toolchain builds on this foundation.

Rails Simplifier is the tool I reach for most. It’s a Claude Code plugin that enforces 37signals patterns and the One Person Framework philosophy on generated code. Left unchecked, AI gravitates toward service objects when a model method would do, custom controller actions when a CRUD resource would be cleaner, and boolean columns where state records belong. Rails Simplifier pulls the code back: service objects become rich model methods, custom actions become CRUD resources, N+1 queries get includes. It’s code refinement, not code generation — the difference between AI-generated Rails and idiomatic Rails.

Maquina UI Standards provides Claude with a working knowledge of the Maquina component library. When I ask it to build a view, it reaches for maquina/card, maquina/form, and maquina/table rather than inventing HTML structure from scratch. The UI stays consistent from the first scaffold to the last.

There’s also a Rails Upgrade Skill for navigating version upgrades — breaking changes, deprecations, and step-by-step migration guides across Rails 6.0 through 8.1 — which becomes essential when you’re maintaining applications across multiple versions over time.

These tools form a closed loop. The generators give you a coherent Rails foundation. The MCP server gives the AI visibility into that foundation. The Simplifier pulls generated code back toward the conventions on which the foundation is built. The UI Standards keep the interface consistent with the components you installed on day one. Each layer reinforces the others, and together they reinforce the conventions Rails already provides.

The Bet, Fifteen Years Later

I built Maquina because I needed these tools myself. The generators came from being tired of spending the first two days of every project on setup I’d already done a dozen times. The AI tools came from watching Claude Code produce technically correct but non-idiomatic Rails — and wanting a way to close that gap automatically.

Both sets of tools come from the same conviction: Rails is worth extending, and the right way to extend it is in the same spirit in which the framework was built — deterministic, opinionated, human-readable, and owned entirely by the developer using it.

The one-person framework was always the vision. With AI tooling that understands Rails conventions, it’s the working reality now.

Fifteen years in, I’m more convinced of this bet than I’ve ever been.