DHH at Rails World 2026: Agents, Rust and Why I Am Moving On

The most interesting thing about DHH's keynote at Rails World 2026 in Austin was not a Rails feature. It was the creator of Rails explaining why 37signals now writes almost none of its code by hand, and why the new backend for HEY is written in Rust.

I have built on Rails for most of my career: platforms for a UK computing education charity, a property inspection business and a breast cancer support app, among others. So I paid attention. This post covers what was said, which parts are claims rather than results, and why my own new work is heading the same direction, towards Rust and Elixir.

What DHH said

The keynote's argument, as reported by Anton Zolotov and Rustify, and available in full on YouTube, runs roughly like this.

Most of our practices were designed for humans reading and writing code, and that is no longer the main activity. At 37signals, hand-written code is no longer the normal way of working. An engineer describes the outcome, an agent writes the implementation, and the engineer comes back to evaluate the result. When someone finds themselves typing code by hand, the team treats it as a sign that the agent workflow needs improving.

When he asked the room who still wrote code by hand, only about five people raised their hands. He described his own output at around 60 times his usual monthly volume, measured in lines of code, while admitting that lines of code is a crude measure.

The concrete example was HEY, the 37signals email service. It is being rebuilt as six native applications backed by a mail server written in Rust. DHH described Rust as unpleasant for humans to read and write, but excellent when agents produce it: humans describe behaviour, agents write Rust, the compiler and the tests check it, and humans judge the result.

He also argued that agents make native apps cheap enough for small teams, that "English is the primary programming language" now, and that products should let users bring their own agent instead of forcing a vendor's.

What is still a claim

The headline numbers need care. DHH reported that the new HEY backend uses around 99% less CPU and 95% less memory, and that a rough calculation suggests HEY's peak traffic could run on a single Raspberry Pi. These are self-reported figures from a rewrite that was still under way at the time of the talk. There are no published benchmarks yet, and a like-for-like comparison between a mature Rails app and a new, narrower Rust service is hard to make fairly.

The Rails side needs care too. DHH did not announce the end of Rails. He said the web remains the right place for products that people use occasionally, and HEY's move to native apps is a decision about one product. The Rustify write-up makes a point I agree with: agents do not remove ownership of the code, they move it to whoever approves and operates it. Treating generated Rust as a black box can work for a narrow, well-tested service. It becomes dangerous when nobody on the team can diagnose what the agent wrote.

Why the language choice changes

Rails won on developer happiness. Its conventions, its readable Ruby and its generators made one developer productive across a whole product. That advantage is about the human writing the code. When an agent writes most of it, the trade-offs shift.

What matters more now is what the language guarantees after the code is written. A strict compiler and a strong type system catch a whole class of agent mistakes before a test runs. Low memory use and predictable performance lower hosting costs for years. A runtime built for long-lived, concurrent work keeps a service up without constant attention. Ruby's pleasantness to write matters less when a person is not the one writing it, and its costs in memory and runtime errors remain.

I have written before about treating tests as contracts for AI agents and about compound engineering with Codex. The same logic applies to the language. If the agent writes the code, I want the toolchain to argue with it as hard as possible.

Why I am moving to Rust and Elixir

My new work is moving away from Rails, towards Rust and Elixir.

Elixir is not new to me. I have been the main developer on a fostering profile platform built in Elixir and Phoenix for years, and on a judging app for a national schools competition built on the same stack. Both have been in production for years. The BEAM runtime was designed for services that stay up, and Phoenix gives me most of what I liked about Rails with better behaviour under load. For services that are mostly about people, state and messages, that is where I am putting new work.

Rust is the bigger change. For the kind of products I build, the cost of writing Rust by hand used to be hard to justify on a charity's budget. With agents writing most of the implementation, that cost falls sharply. What remains is a compiler that refuses a great deal of wrong code, small binaries and very low running costs. For background workers, data pipelines, integrations and anything that has to be fast and cheap to run, it is now a sensible default.

Readability still matters. Someone has to review what the agent produced and fix it when it breaks in production, and that person has to understand Rust, not treat it as a black box. That is the part of the keynote I expect many teams to skip.

Where Rails still fits

I still run Rails systems in production, including a platform that moved 14 years of inspection data off InventoryBase, and I will keep maintaining them. Rails is still excellent for server-rendered web apps, admin tools and products where the database is the product. A mature Rails app with good tests is not a problem that needs solving.

What has changed is the default. When I start something new, Rails is no longer the automatic answer. I now ask what the service needs to be in five years: cheap to run, hard to break, easy for an agent to change safely. For a growing share of the work, the answer is Rust or Elixir.

If you are weighing a similar decision for a live product, I am happy to talk it through. The honest answer is usually more specific than "rewrite it in Rust".