Pencils down: what DHH actually said at Rails World 2026

A keynote that gets quoted for a week usually gets quoted wrong. DHH opened Rails World 2026 in Austin on 23 September and the phrase "pencils down" was on every timeline by evening, attached to roughly four different claims, at least two of which he did not make.

This page separates three things that are being reported as one: what was said, what the news is being read to mean, and what actually lands on somebody who has a Rails application in production right now. The third is the smallest of the three by a wide margin, and it is the only one with anything to do for you this quarter.

What was said, and where every quote here was read

The sentence doing the work is DHH's own, from his post about the talk:

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 summarised the talk as a keynote "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."

Now the sourcing, because it changes how much weight those two paragraphs carry. Nobody here was in Austin. The keynote video is at youtu.be/vDjW_dRyKXY and it has not been watched for this page, so every quotation above is a quotation of a post, not of the room. There is a second gap worth naming: the official session page for the opening keynote on rubyonrails.org lists DHH at 9:45 on 23 September with the abstract "Opening Keynote highlighting what's new in Rails, what's coming next, and where Rails is headed in the future", and mentions neither agents nor pencils. The framing everybody is arguing about comes from the @rails post, which is the account of the project rather than an attendee, and that is as close to official as the written record currently gets. Fetching the posts directly is not possible either: x.com answers HTTP 402 to an unauthenticated request, so the text above was read as relayed and as quoted in search results.

The HEY 2.0 plan is the part nobody should skip

HEY 2.0, as described in the coverage of the keynote, is native apps on every platform with a Rust backend, all of it written by agents directed by programmers and designers. DHH's claim for that backend is that it would be efficient enough to serve HEY's peak traffic on a Raspberry Pi.

Say the plain version of that before saying anything else. The creator of Rails is rebuilding his company's flagship product with a server that is not Rails and clients that are not the web. A site that sells a Rails boilerplate and reports this news as unambiguously good for Rails is a site that expects you not to have read it.

The move is also less sudden than it reads. On 10 August 2026 DHH posted that Fable one-shotted a Rust rewrite of the TerminalTextEffects Python library in 11 million tokens, taking startup from 87ms to 2ms with rendering 9.6 times faster, leaving a 3MB single executable with no dependencies. Six weeks later the same idea is pointed at a production email service. The interesting part is not that he likes Rust now; it is that the cost of a rewrite in a language he does not want to read has dropped far enough to change what is worth rewriting.

One caveat on that post, since this page is about separating claims from measurements: no benchmark methodology, hardware or transcript was published with those numbers. They are a report from the person who ran it.

The Raspberry Pi number is about an architecture

A commenter on the Hacker News thread for the keynote video made the objection that matters, and it is not a language argument at all: 37signals' CPU reduction comes substantially from moving rendering to the clients, which is what "native apps on every platform" means, rather than from Ruby being slow.

Compare the two systems honestly. A Rails HEY renders HTML for every screen every user opens, on the server, on demand. A native HEY hands that work to a phone and a laptop, and the server's job shrinks to answering data requests and pushing changes. The second one needs a dramatically smaller machine whatever it is written in, and the Rust rewrite is bundled into the same announcement, so the two causes cannot be told apart from the outside.

The claim is still interesting. It is just a claim about what happens when you move a decade-old server-rendered product to native clients and rewrite the remainder, and reading it as "Rust is n times faster than Ruby" is reading a number that nobody published. When Rails is still the answer takes the other half of this, which is what you give up when you make that trade for an application that is not HEY.

The Rust line, and why it is older than the keynote

The joke that travelled furthest is the one people found funniest:

I love Rust! Rust is amazing ...if you never, ever, EVER have to look at it yourself.

It reads as a reversal. It is not one. In April 2024 DHH posted almost the same position in flatter words: he likes Rust "for the use case of having other people program fast libraries in it", and "that level of abstraction is not for me." The opinion has not moved. What moved is who the other people are. Once an agent writes the Rust, the part he objected to, which was reading and maintaining it, is the part he expects never to do, and a language he was never going to write by hand becomes available to him.

That is the actual mechanism in the whole story, and it generalises past Rust. Any technology whose cost was mostly the cost of human fluency gets cheaper. Any technology whose cost is mostly operational complexity does not get cheaper at all.

What the internet decided it meant

Reaction hardened faster than reporting. The Hacker News submission of the keynote video sat at 40 points and 15 comments the following day, which is worth knowing before anyone describes the community as being in uproar. The comments there split three ways: that Rails itself has no answer to agentic development, that the performance claims are architectural rather than linguistic, and that agent-written code is failing review in ways that matter. One commenter reported patching an AI-generated API endpoint that "shipped without any auth whatsoever". Another wrote the line that will outlive the thread: "Rails has always been a framework of extraction. Now they are not even coding anymore there is nothing to extract."

Longer takes went further. Olly, writing on 24 September as a twenty-year Rails developer, predicted that Rails releases effectively end after 8.2 and that this may have been the last traditional Rails World. That is a forecast by a reader of the same posts you have read, not something announced from the stage, and it is the clearest example of the gap this page exists to mark. The keynote said 37signals has stopped writing implementation code by hand. It did not say Rails development stops, and the @rails summary argues the opposite case, that convention over configuration is what makes the framework suited to the moment.

The debate is not confined to Ruby either. José Valim published on evolving programming languages in the AI era the same week, which is mentioned here only to establish that the question is being asked in other ecosystems by people with the same standing, and nothing about that article's argument is characterised here because it has not been read.

What changes for your production app this quarter

Nothing in your Gemfile. No deprecation was announced, no release was pulled, and no version of Rails behaves differently today than it did on 22 September.

Check the ground truth rather than the timeline. The latest released rails gem on rubygems.org is 8.1.3.1, published 29 July 2026. The 8.2 release notes exist on edgeguides.rubyonrails.org, which is the documentation built from the unreleased branch, and they describe real work in progress: Sec-Fetch-Site header CSRF protection, Argon2 for has_secure_password, has_json and has_delegated_json. A framework being wound down does not land that list. Meanwhile basecamp/once-campfire, a Ruby repository, was pushed to on 22 September, the day before the keynote, and is not archived.

A keynote is not a changelog. The distance between "37signals changed how it writes code" and "your Rails 8.1 application needs work this quarter" is not a short one, and nobody on stage tried to close it.

The one thing that should genuinely be on your list is unglamorous: if agents are already writing code in your repository, and for most teams they are, then the review process is now the load bearing part of your engineering, and it was probably designed for a colleague who could explain their reasoning. Reviewing Rails an agent wrote is about that specific shift, including why the missing authorization check is the defect that survives review.

What genuinely changes, and what would change this position

The durable claim in the keynote is the one that got the least attention, and it arrived from the @rails account rather than from DHH: "Ruby on Rails scales from PROMPT to IPO. Token-efficient code that's easy for agents to write and beautiful for humans to review."

Take the first half of that seriously and the consequence is uncomfortable for anybody with a bespoke codebase. If an agent writes the implementation, the scarce resource becomes a codebase the agent does not have to guess in: conventional layout, predictable names, a test suite that fails loudly, a starting point that already made the boring decisions. Rails has always sold that to humans. The new buyer is a machine with a context window and no memory of last Tuesday.

This is already visible in the framework's own repository. rails/rails carries an AGENTS.md whose first line is "Ruby on Rails Codebase Guide for AI Coding Agents", and it spends its length on exactly the things an agent cannot infer: that the monorepo holds ten-plus loosely coupled components, that tests run as cd actionview && bin/test test/template/form_helper_test.rb:123, that the project uses Minitest and not RSpec. Writing an AGENTS.md for a Rails app covers what belongs in yours, and conventions are the context covers why a conventional app needs less of that file than a clever one. Token-efficient Rails takes the second half of the @rails line, which is the one claim in it that can be measured.

The position here, stated so it can be argued with: the keynote is bad news for people who sell typing, neutral for a Rails app in production this quarter, and good for anything that makes a codebase legible without a conversation. Three things would change it. Rails 8.2 shipping with no agent-facing tooling in the framework itself, which would make the "nothing here pushes things forward" complaint correct rather than early. A stalled release cadence over the next two cycles. Or HEY 2.0's Rust backend turning out to need less review than the code it replaced, which would mean the durable skill is not review after all.

What this page does not cover

Not the talk. The video has not been watched for this page and no transcript was available while it was written, so anything said on stage that was not quoted in a post or a session listing is absent here, including whatever was shown in slides.

Not the rest of the programme. The conversation between Matz, DHH and Jeremy Daer on AI and the future of Ruby and Rails was listed for 10:00 on 24 September, and it is a separate session with separate claims that this page makes none of.

Not whether agents are good enough. That is a question about your codebase and your review process, and it is answered by running them on a real branch rather than by anybody's keynote. Testing what an agent wrote is where that question gets an answer with a pass or a fail attached.