Julian Rubisch

Why Ruby Is the Best Language for AI-Assisted Development

Ruby topped a benchmark of 13 programming languages run by Yusuke Endoh across 20 iterations each: 73.1 seconds median completion, $0.36 median cost, 100% pass rate. Fastest. Cheapest. Most consistent. Across every axis that matters for AI-assisted development, Ruby came out on top.

That's not a fluke. It's a consequence of design decisions Yukihiro Matsumoto — Ruby's creator, known as "Matz" — made thirty years ago, and it changes the calculus for anyone building software with AI today.

The context window is the new bottleneck

AI coding agents work within a context window — the amount of code they can see at once. Every token counts. When your agent runs out of context, it loses track of your codebase, hallucinates, or simply stops working.

Martin Alderson's analysis of token efficiency across mainstream languages — later expanded on by Ivan Turkovic — found that Ruby is the second most token-efficient mainstream language. Compared to Python, Ruby uses 15–25% fewer tokens to express equivalent logic. Against Go or Java, the gap widens to 40–60%.

What this means in practice: your AI agent sees more of your codebase per request. It costs less per task. It works longer before losing the thread. If you're a founder watching your AI bills climb, this is the most direct lever you have — your language choice literally determines how much each AI interaction costs.

Expressiveness keeps your AI on track

Token efficiency alone doesn't explain the benchmark results. Ruby's advantage runs deeper.

Obie Fernandez argues in "Ruby Was Ready From the Start" that Ruby's three decades of investment in expressiveness give AI agents something they desperately need: grounding. When a codebase reads like prose — has_many :posts, validates :email, presence: true, before_save :normalize_phone_number — an AI agent doesn't have to guess at intent. The code declares what it means.

This matters because the biggest failure mode in AI-assisted development isn't speed — it's drift. The agent starts confidently, generates plausible code, and gradually wanders off course. Ruby's expressiveness acts as a guardrail here. In most languages, the gap between what code does and what a human meant is wide enough for an AI to misinterpret. In Ruby, that gap is unusually narrow. When the codebase is expressive, agents stay anchored to what the code actually does rather than what they imagine it should do.

Rails means less to explain

This is where my own experience building AI-powered Rails applications connects. When I work with founders who are using AI agents to build their products, I see the same pattern repeatedly: 90% of what you'd detail out to the agent is already built into Rails.

Need to send emails when a user signs up? Rails has that. Need to process payments in the background without blocking your app? Rails has that. Need to store uploaded files, handle user sessions, or push live updates to the browser? Rails has all of it — built in, batteries included, following the same conventions across every Rails application on earth.

This is what convention over configuration means in practice: Rails makes thousands of small decisions for you — how to name your files, where to put your code, how to structure your database — so that neither you nor your AI agent has to. Every Rails convention is a piece of context you don't have to provide, a decision you don't have to explain, a potential misunderstanding eliminated before it starts.

An AI agent that's trained on thousands of Rails applications already knows these patterns. It doesn't need a lengthy prompt explaining your project structure. It can just read the code and get to work. This is why the free skills I publish work — they teach AI to lean on what Rails already provides rather than reinventing it.

Security defaults matter more when AI writes the code

Here's a dimension that rarely appears in language benchmarks but keeps founders up at night: security. Rails ships with CSRF protection, SQL injection prevention, XSS escaping, encrypted credentials, and strong parameters — all enabled by default, all requiring zero configuration. An AI agent generating Rails code inherits these protections automatically.

The JavaScript ecosystem tells a different story. High-severity CVEs in npm packages appear weekly. Every dependency is a surface area decision, and AI agents are notoriously undiscriminating about which packages they reach for. A Python or Node agent that installs a compromised or outdated dependency has introduced a vulnerability that might not surface for months. A Rails agent working within the framework's conventions is operating inside a security perimeter that's been hardened over two decades.

When AI is writing your code at speed, the question isn't whether you can audit every line — you can't. The question is whether the defaults protect you when you're not looking. Rails' answer has always been yes.

Speed without structure is just a faster way to get lost

There's a necessary counterpoint. AI makes development dramatically faster — Jellyfish reported a 260% increase in AI-assisted coding tool usage, alongside a 20% increase in unplanned work. Speed without direction produces more code, not better products.

Ruby and Rails give AI agents the best possible foundation. But a foundation isn't an architecture. Someone still needs to know what "good Rails" looks like — which patterns to reach for, which abstractions are premature, when the agent is generating technically correct code that's architecturally wrong.

The language choice is a competitive advantage. What you build on top of it is what determines whether that advantage compounds or collapses.

References

Why Ruby Is the Best Language for AI-Assisted Development - Julian Rubisch