Rails World 2026 Opening Keynote - DHH

David Heinemeier Hansson argues that coding agents change not only who writes code, but which products and architectures small teams can afford to build. He describes 37signals making handwritten code exceptional, early work on native HEY apps, and a preference for applications that users can operate through their own agents.

This summary uses the saved English captions, labeled caption by the capture tool. It is not an independent audio or benchmark review. Project results are DHH's reports; his predictions about programming careers and AI's wider benefits remain forecasts.

Agent-first development at 37signals

• “Pencils down” makes manual coding the exception, not an impossibility. DHH says 37signals recently stopped treating handwritten code as its normal development process. When an agent cannot produce the desired result, a person may still intervene, but the goal is then to improve the agent-driven process rather than make manual implementation the default again. 20:45–21:41(opens in a new tab)
• The earlier Basecamp experiment exposed an aggregate architecture problem. Designers generated changes that looked reasonable individually, but 20–30 together damaged the system's shape. Basecamp 5 ultimately combined agent assistance with substantial handwritten work. DHH now believes newer models would probably have made the experiment work; that is his retrospective judgment, not a demonstrated rerun of the failed experiment. 22:12–24:04(opens in a new tab)
• Delegate asynchronously and return to evaluate an outcome. He favors assigning work as to a coworker, leaving the agent to proceed, and reviewing when something is ready instead of watching tokens arrive in chat. He also warns against prescribing implementation details too tightly: for his Rust work, he describes judging the resulting program's behavior without reading its implementation. This is his working approach, not a validation method established by the talk. 31:46–33:04(opens in a new tab), 35:16–36:12(opens in a new tab)

Cheaper implementation changes the architecture trade-offs

• Native apps become more attractive when separate implementations cost less. DHH says web and cross-platform tools previously let a small team serve many platforms without maintaining every native framework separately. He shows early work on six native HEY apps begun roughly a week before the keynote, seeking better platform fidelity and latency. These are early demonstrations, not evidence of completed migrations or long-term maintenance costs; he explicitly describes the first Windows result as not shippable before redirection. 24:04–27:31(opens in a new tab)
• The HEY backend proposal changes both language and responsibilities. With native clients, he describes replacing the HTML-serving web application with a Rust backend focused on the mail service. He reports 99% lower CPU and 95% lower memory requirements, and labels serving peak traffic on one Raspberry Pi a back-of-the-envelope calculation. The keynote does not establish that switching languages alone yields those savings. 28:14–31:46(opens in a new tab)
• The web still fits products that should not require installation. DHH keeps Basecamp-style, short-lived collaboration and access for occasional visitors as strong web use cases. He argues that Rails' conventions help token efficiency and that its one-developer focus fits agent-assisted work. He also reports that Rails Foundation evaluations run by Evil Martians needed harder feature-implementation tasks after agents approached 95% completion on the earlier set. That score describes the earlier evaluation, not arbitrary Rails work. 33:04–35:16(opens in a new tab), 36:12–36:39(opens in a new tab)
• Shared abstractions may become coordination bottlenecks. His proposal is to reconsider designs built mainly to avoid repetition: many agents changing one application could contend over shared abstractions, while agents might make duplicated code cheaper to keep synchronized. He explicitly says there is no blueprint yet. The argument is a proposed change in trade-offs, not evidence that duplication is generally safer or that abstractions are obsolete. 42:49–45:06(opens in a new tab)

Bring your own agent, and keep forecasts separate from results

• Expose a CLI so a user's agent can work across applications. Rather than requiring a separate chatbot inside every product, DHH wants command-line interfaces that let his existing agent connect services such as Basecamp and HEY. His example is finding an old email from a vague memory about sneakers and a podcast. He does not explain the retrieval mechanism, so the anecdote does not establish how it works or a general advantage over other search systems. 45:10–48:01(opens in a new tab)
• Small custom tools illustrate work that previously felt too expensive. He reports generating an Omarchy-themed calculator from a screenshot despite lacking the C++ and Qt knowledge to build it that quickly himself. He then describes a writing app, video-trimming tool, and Markdown-based presentation software. His broader claim is that cheaper implementation makes customization and performance optimization worth attempting; the examples are practitioner reports, not controlled productivity comparisons. 51:21–55:00(opens in a new tab)
• His strongest economic claims go beyond the project evidence. DHH suggests a 100–1,000× gap between the weakest unaided programmer and the strongest agent-assisted programmer. He also reports producing 150,000 lines in August versus a historical 30,000 lines of Ruby per year, while acknowledging that Rust's verbosity inflates that comparison. Neither establishes equivalent gains in delivered value or quality. His prediction that handwritten programming will become uneconomic across virtually all domains by year-end is a forecast. 16:02–18:59(opens in a new tab), 36:39–38:01(opens in a new tab), 40:31–41:50(opens in a new tab)
• Optimism is his recommended stance, not a quantified risk assessment. The keynote opens with photography as an analogy for cheaper creation and changing craft, then closes by arguing that uncertain predictions should not stop experimentation. He acknowledges security concerns and points to isolation work around a vulnerable image library as a response people can build. His confidence in abundance over catastrophe remains an opinion, not a probability demonstrated in the talk. 05:33–11:55(opens in a new tab), 55:02–1:01:09(opens in a new tab)

Full video: https://www.youtube.com/watch?v=vDjW_dRyKXY(opens in a new tab)