DHH's Rails World 2026 Keynote: Pencils Down, Now What

TL;DR: DHH opened Rails World 2026 by retiring himself from hand-written code, announcing HEY’s rebuild as native apps on a Rust backend, and putting 37signals “pencils down.” He’s right that native and low-level rewrites got cheap, and right that Rails’ conventions are an advantage when agents write the code. He draws the wrong lesson from his own Basecamp 5 story. A better model doesn’t fix an ownership problem. It produces the same problem faster.

What DHH actually said

DHH opened Rails World 2026 in Austin by naming his mood: not psychosis, he said, but “AI delirium,” or “AI euphoria” (66s). He built the talk on a photography analogy. His great-great-grandfather, the Danish painter Laurits Tuxen, spent three years on a single royal portrait. The 1900 Kodak Brownie made photography cheap, and portrait painters had to find a new reason to exist. By his count, some two trillion photos are taken every year now (652s).

His Brownie moment: “On November 24th, 2025, we got the Kodak Brownie of our era. We got Opus 4.5” (680s). The date matches Anthropic’s release announcement. From there he walked a model timeline through 2026: a “trough of disillusionment” from February to May, Fable 5 and Mythos in June, GPT-6 Astra in September, and DeepSeek-4-1 Flash a week later (783s). That’s his framing of the year, and I’m not checking it model by model.

He traced the “10x programmer” to a 1968 study by Sackman, Erikson, and Grant in Communications of the ACM, which found large gaps between the best and worst programmers it tested. Then he raised the multiple to 100x, and then 1,000x, between the worst programmer without these tools and the best programmer with them (962s).

His own numbers: he says he wrote about 30,000 lines of production Ruby a year for two decades, then 150,000 lines of code in August alone, roughly 60x his old pace (2239s). He replayed a clip from a 2005 Rails talk, “Look at all the things I’m not doing” (1167s), and said this year is the same kind of moment, only bigger.

Then the claims that matter most. 37signals has gone “pencils down.” Writing code by hand there “is now an exceptional state. It is like seeing a bug in Sentry” (1250s). When it happens, the fix is to fix the agent setup, not to keep typing. He asked the room who still writes material amounts of code by hand each week, and about five hands went up (1324s).

HEY is being rebuilt. It stops being a web app and becomes six native apps, kicked off about a week before the talk (1467s). The backend is being rewritten in Rust, a language he says he never reads, with “99% less CPU, 95% less memory,” and ten hosts kept only for redundancy (1726s). He also cited Shopify’s Shop app as rewritten native by a small team to replace React Native (1671s). That’s his account, and I haven’t verified it.

Where he’s right

The cost argument holds up. Native apps and low-level languages got cheaper to build this year, because a model can now hold a Rust or Swift codebase well enough to be useful. Ruby shipped durable software for two decades by being boring, and DHH’s case for Rails in the agent era rests on the same instinct: “Convention over configuration leads directly to things like token efficiency” (2038s). A framework with one obvious way to do things is cheaper for an agent to generate correctly and cheaper for a reviewer to check. It’s the same property behind why Elixir scores so well on LLM code-completion benchmarks, and one step from the shift I wrote about in languages written for agents, not humans.

His description of async delegation matches how I think about it. You hand an agent a task the way you’d hand one to a coworker, and you review when it’s ready. That’s managing agents instead of prompting them.

I also have a personal stake in the framework argument. I started as a Rails developer coming off ColdFusion and went to RailsConf in 2015. Years later I led a migration of Ruby services onto Elixir, for operational reasons (memory, Sidekiq scaling, pager load) rather than agent ones. The part that carries over is DHH’s point: conventions and structure matter more, not less, once something other than a careful human is writing the code.

Who owns the code nobody reads?

The most important 90 seconds of the keynote is a story about Basecamp 5, and DHH draws the wrong conclusion from it (1354s). This spring, 37signals designers vibe-coded the final features for the release. Each pull request looked reasonable on its own. Twenty or thirty of them together left the architecture, in his words, “a little like a Swiss cheese.” The team went back to manual review. DHH now calls that “the wrong conclusion.” His position is that if they’d waited for a better model, Fable, the original plan would probably have worked.

I don’t think that’s what the story teaches. A stronger model writing each pull request doesn’t touch the actual failure, which is that nobody owned the aggregate. Twenty reasonable decisions can add up to an unreasonable system whether they came from twenty engineers, twenty agents, or one very good model asked twenty separate times. Model quality changes how often a single change is locally wrong. It does nothing about who is responsible for noticing that the whole got worse. That is a review and ownership problem, and it gets harder as volume goes up. When one person can produce 150,000 lines in a month, Swiss cheese stops being a one-time spring incident. It becomes the default state, and someone has to push back against it every week.

DHH’s business-owner analogy carries more weight than he puts on it. He evaluates the Rust rewrite from the outside, the way “any business owner in history who’s ever commissioned a group of programmers” would, and says: “I don’t know any Rust at all. I consider that a feature” (2137s). But that business owner had more than distance from the code. They had a contract, acceptance criteria, and a vendor who answered for defects.

What is the equivalent when the vendor is a model checkpoint? DHH has part of the answer. Evil Martians are running agent evals for the Rails Foundation, and the first version saturated around 95% fast enough that they had to make it harder (2063s). That’s the right instinct: acceptance tests you can rerun, instead of a feeling that it seemed fine. It needs to reach past benchmarks into the dull parts. That means supply-chain review on the C image libraries behind the Rails CVE he raised later in the talk. It means a named person who answers for a defect the way a vendor used to. And it means an evidence pack a security reviewer can actually check.

This is the part of the AI transition that lands on a fractional CTO’s desk. Unmaintainable code doesn’t look unmaintainable at pull-request size. It shows up at architecture size, usually after you’ve inherited a codebase built faster than anyone reviewed it. Multiple agents will agree their way into a plausible wrong answer with more confidence than one tired human. And typing was never the hard part. The hard part was building and keeping the shared mental model of the system, which thins out as more of the typing leaves any one person’s hands. If your team is working out where that ownership line sits as agent output scales, that’s a conversation worth having before the Swiss cheese ships. It’s a different conversation from “which model do we use,” which is the one the keynote mostly answers.

Should your app ship a CLI for agents?

Yes. DHH’s reasoning is right, even though the security side got the least airtime. He doesn’t want an in-app chatbot. He wants to bring his own agent, and any serious app needs a command-line surface for that agent to drive (2723s). His demo was a good one: the HEY CLI plus an agent found a five-year-old email by concept, something about sneakers and a podcast, that HEY’s Elasticsearch keyword search couldn’t find (2806s).

Every CLI you add for agents is also a new authenticated API surface, and it deserves the same threat model as any other:

• Scope tokens to the narrowest permission the task needs, instead of handing an agent your whole account.
• Default new capabilities to read-only, and make write access an explicit, logged step.
• Log every command an agent runs the way you’d log calls from an external partner, because that is what it is.
• Decide where the credential lives. Secrets management for agents is its own discipline now.

Omarchy, DHH’s own distro, is the reason to take that list seriously. Its launcher starts most coding agents with a skip-approval flag by default. A CLI built for agents will be driven by agents running in exactly that mode, so its permissions have to hold when nobody is approving each call.

The Omarchy segment

DHH ran the Omarchy part as a progress report (2893s). Install time went from 3 minutes 33 seconds at last year’s Rails World, to 35 seconds on an AMD Strix Halo laptop the week before, to 9 seconds “in the lab.” He said the project has raised about $20 million. He showed one-shot apps: an Omarchy-themed calculator in C++ and Qt, neither of which he says he knows, working about seven minutes after the prompt; an iA Writer-style writing app; a video trimmer that now ships in Omarchy; and Hype, a Markdown presentation app he built while writing this keynote, with a binary he puts at half a megabyte (3090s). When people ask why a three-minute install wasn’t fast enough, he answers with a line from Mitchell Hashimoto: excellence doesn’t need a justification.

I run Omarchy daily on two machines: an M1 MacBook Pro dual-booting macOS through Asahi Linux, and an x86_64 desktop dual-booted with Windows 11. My first install on the M1 was nowhere near nine seconds. It broke on a package version and needed a manual downgrade. That makes the install-time obsession easier to appreciate, not harder.

One note for M1 owners, since DHH didn’t cover it on stage: Omarchy M, announced September 11, makes Apple Silicon an official Omarchy team rather than a side project. I haven’t run its new installer yet. If you’re deciding whether that belongs on a machine you answer for, I wrote up the SOC 2 verdict for a company laptop. Omarchy’s own AGENTS.md is also worth reading, as a case study in how a project that expects agents to contribute writes down its rules.

10x, 1,000x, and what cheap repetition doesn’t buy

I’d push back on the multiplier math too. Going from a 1968 study of individual differences to a 1,000x gap in 2026 is DHH’s extrapolation, not something the study measures. His own numbers make the point without it: 150,000 lines in one month, against a prior pace of about 2,500.

The abstraction argument has a real point in it (2598s). DHH’s claim is that much of software architecture existed to avoid repetition, and that now that writing and rewriting similar code costs almost nothing, some of that abstraction stopped paying for itself. That’s plausible. But repetition was never mainly expensive to write. It was expensive to keep in sync and expensive to review, and DHH says syncing got cheap too. Maybe for the agent doing the syncing. The reviewer still has to notice that the tenth copy of a function drifted from the other nine, and without the shared function that takes longer.

Plenty of codebases that look insane today were rational responses to constraints that later changed. The risk in “the price of repetition has gone to near zero” is building the next set of those constraints without writing down why, because nobody had to sit with the tradeoff long enough to document it.

On numbers I can show: I’ve published my own commit history with agents and what running them actually costs. I’m not going to line either up against DHH’s 60x, because our workloads aren’t comparable.

One correction. DHH’s ATM aside, which he tied to Jevons, cited “30,000 bank tellers” in 1950 and “40,000” by 2010 as proof that automation predictions fail (3616s). The story is real and well documented. Economist James Bessen’s research found that ATMs cut the tellers an average urban branch needed from about 21 to about 13. Branches got cheaper to run, banks opened more of them, and demand for tellers went up. The story holds. The numbers as he spoke them don’t match the published record, so take the shape of the argument and leave the two figures.

The one concern he named without hedging was security: “Something is coming. We gotta be ready for that” (3339s). He brought up a recent Rails CVE that traced back to a C image library and pointed to a quarantine effort a later talk would cover (3580s). That talk is Mike Dalessio’s Hot Cell session, which moves Active Storage’s attachment processing into a sidecar container. The reason: AI-assisted researchers are turning up image-library CVEs faster than Active Storage was built to absorb. That’s the supply-chain surface running security at an AI-native company has to treat as a first-class risk.

The verdict

DHH is right about the direction. Native got cheap. Rust became usable by proxy. Rails’ conventions are an asset when agents do the writing, and handing work to an agent and reviewing it later is a legitimate way to work now. The optimism is fine too. P(bloom) over P(doom) is a bet, and it’s one I mostly share.

Where I part ways is the lesson he takes from his own best story. Basecamp 5 didn’t go Swiss cheese because the model wasn’t good enough yet. It went Swiss cheese because nobody was responsible for the sum of twenty individually fine decisions. A better model doesn’t hand that responsibility to anyone. It lets the same failure happen at higher volume. Writing code by hand may well become an exceptional state. Someone still has to own the code nobody reads, and the thing that created that job won’t be the thing that does it. If that ownership question is live on your team, start with why agents write unmaintainable code and its rule: keep the architecture human-owned, explicitly.