Rails when an agent writes the code

On 23 September 2026, in Austin, the creator of Rails told a Rails World audience that writing code by hand is no longer an economically viable skill for most programmers at most companies. A day later the question in front of anybody running a small Rails product is narrower and more annoying than the one being argued about on X: if an agent writes the implementation, what is left to be good at, and does the Rails half of the stack still earn its place?

One note on wording, because "Rails agents" and "Rails AI agents" are both about to mean two different things at once. In this cocoon the words mean a coding agent working inside your repository, the Claude Code or Cursor session that writes the migration. They do not mean an agent your application runs on behalf of its users, which is a product feature and a different subject entirely.

What was said in Austin, and what the programme said

The Rails World 2026 keynote was the opening session of the conference, 23 September at 9:45 AM, and the official session page under rubyonrails.org/world/2026 still describes it as a keynote "highlighting what's new in Rails, what's coming next, and where Rails is headed in the future". Nothing in that blurb mentions agents. What arrived under it was this, from DHH's own post on X the same day:

It's pencils down, people. Writing code by hand is no longer an economically viable skill for most programmers at most companies. But the future of making software has never been brighter. Don't you dare black pill this beautiful moment!

The @rails account described the same talk as being "on the age of AI agents: why 37signals has gone 'pencils down' on handwritten code, why Rails' convention over configuration is built for this moment, and why the only play left is total optimism".

The video is at youtu.be/vDjW_dRyKXY and nothing here is taken from it. Every quotation on this page was read as text, on the account that posted it or in the Hacker News thread discussing it, and where an aside is reported rather than quoted the page says reported. What DHH actually said, and what was added afterwards separates the sentences he posted from the ones that were attached to him by the second day of commentary, because the gap between those two is already wider than the talk.

The half of this that is bad news for Rails

HEY 2.0, the keynote's own worked example of the new way of building, is a set of native apps on every platform with a Rust backend, which DHH said is efficient enough to serve HEY's peak traffic on a Raspberry Pi, all of it coded by agents directed by programmers and designers. Read that again with the framework in mind. The most visible Rails application in the world, built by the company Rails was extracted from, is moving its backend to another language and its client off the web stack Rails ships.

The line that got the laugh, reported from the room rather than quoted from a post: "I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself." That is not a joke about Rust, it is the whole thesis in one sentence. If nobody reads the implementation, the properties Rails optimises for stop being the properties that decide, and raw efficiency wins the argument it has been losing for twenty years.

The sharpest form of the objection is in the Hacker News thread on the keynote: "I think RoR's selling feature was developer ergonomics, which suddenly seems less of a benefit if developers aren't the ones writing the code." No page on this site is going to wave that away with a slogan about conventions. When Rails is still the answer takes the objection at full strength and defends the narrower thing that survives it: ergonomics for a writer and ergonomics for a reader are not the same property, 37signals has an engineering department that can own a Rust service, and you do not.

What changes on Monday in a two person product

Nothing operational changes. The queue still backs up, the webhook still arrives twice, the migration still takes a lock on a table with four million rows, and none of that is affected by who typed the code. What changes is one ratio: how fast code arrives against how fast it gets read. Every problem in this cocoon falls out of that number moving.

The concrete failure is already on the record. In the Hacker News thread on the keynote, a developer described finding an agent written API endpoint that had shipped with no authentication on it, because the agent had misunderstood how authentication was applied in that particular Rails codebase. That is the shape of the thing. Not code that crashes, code that runs, answers 200, passes a smoke test, and is wrong in the one way a reader would have caught in fifteen seconds and a green suite never will.

So the two skills that get scarcer are review and tests that mean something. Reading agent written Rails at the rate it arrives is about what to look at first in a Rails diff specifically, which is not style: before_action chains and what they skip, strong parameters, anything touching current_user, and the N+1 that appears when a helpful refactor drops an includes. Testing what an agent wrote is about the trap underneath that, which is that the same agent wrote the tests, and a suite built from the same misunderstanding as the code agrees with it perfectly and stays green forever.

Conventions are what an agent reads instead of guessing

The @rails account has been making one argument about this since well before the conference: "Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write, and still beautiful for humans to review." Stripped of the slogan, the claim is that strong conventions cost an agent less, because an agent that knows where a Rails app puts things does not have to read your codebase to find out.

The claim is plausible, it is the same argument this cocoon makes, and it is not measured. The one public measurement points the other way. Martin Alderson benchmarked 19 web frameworks in February 2026 by handing an agent the same blog application to build in each and counting tokens, tool calls and elapsed time; his conclusion was that minimal frameworks are far quicker and more cost effective for agents, with a 2.9x spread between the cheapest and the most expensive, and that among the full stack frameworks SvelteKit and Django were the ones that shone. The Rails figure sits inside a chart image on that post, so this page quotes no number for it.

The detail in that post that matters more than the ranking is the author's own note that Rails and Laravel had to be rerun because the agent "got completely stuck with various missing system packages". That is not a verbosity problem and no amount of convention fixes it. That is a starting point problem, and it is the tax on the first hour of every agent session in a repository nobody prepared for one. Conventions are the context is the long form of the argument, including where it fails, which is any part of your app that is genuinely yours. Token-efficient Rails is the part with numbers, measured in a repository rather than in a blog app, because a benchmark of somebody else's toy is not a benchmark of your codebase.

The files that tell an agent where it is

AGENTS.md is where the tooling converged. Stewarded by the Agentic AI Foundation under the Linux Foundation, described on agents.md as "a dedicated, predictable place to provide the context and instructions to help AI coding agents work on your project", claimed there to be in use across 60,000 open source projects and read by more than 20 tools including Codex, Jules, Cursor and VS Code. The file carries what a README deliberately leaves out: build steps, test commands, conventions.

Rails gets a specific advantage here and a specific trap. The advantage is that most of what such a file would have to spell out for another stack is already true by convention, so the file stays short. The boilerplate this site sells ships 66 lines of it, and the lines doing the work are not the ones restating Rails. They are the ones naming decisions Rails does not make: every user facing string going through config/locales/en.yml instead of a view, optional modules guarded by Feature.enabled?(:ai), multi step logic belonging to a form object or a service rather than a controller. An agent gets all three wrong, consistently, unless it is told.

The trap is that the file goes stale and nothing fails when it does. AGENTS.md for a Rails app covers what earns a line in one and what to delete. Claude Code with Rails and Cursor rules for Rails cover the two tool specific layers on top of it, CLAUDE.md and .cursor/rules, and where a tool specific file is worth maintaining beside the shared one instead of duplicating it.

What would change this position

The position here is narrow. An agent writing the implementation raises the value of a codebase that answers questions before they are asked, and a Rails app with conventions, a suite that fails for a reason and a known starting point is that codebase. Two things would weaken it, and both are being tested in public right now.

The first is context getting cheap enough that conventions stop paying for themselves. The whole argument assumes that inferring a bespoke codebase costs the agent something real, in tokens, in time and in accuracy. A model that reads 200,000 lines of idiosyncratic code as reliably and as cheaply as it reads a conventional Rails app takes the floor out from under this cocoon, and the direction of travel for two years has been exactly that.

The second is HEY 2.0 shipping and then staying cheap to change. If an agent written Rust backend is as easy to modify in its second year as a Rails one, then "pick the stack humans review well" loses to "pick the stack that runs on a Raspberry Pi", and this page needs rewriting rather than defending. That is checkable, it is public, and it takes about eighteen months to know.

José Valim published on the evolution of programming languages in the AI era the same week. Nothing here summarises it, because nobody here has read it yet.

What these pages do not cover

Not prompt engineering, and not which model to use. Both move faster than any page can track and neither is a Rails question.

Not building LLM features into your application either. Putting a chat behind an ActiveRecord model is a separate subject with its own pages on this site, and folding the two together is how two sets of pages end up competing for one query.

Not writing agents in Ruby. Working with an agent and building one are different problems, and this cocoon has nothing to say about the second.

Not the keynote, as a talk. Reading posts about a session is not watching it, the summaries already disagree with each other two days later, and a page claiming to have been in a room it only read about is the one mistake that makes everything else on it worthless.