DHH at Rails World 2026: Pencils Down, Agents, and Rails

David Heinemeier Hansson opened Rails World 2026 in Austin with a deliberately provocative claim: at 37signals, writing code by hand has become the exception. His hour-long talk is not a Rails release announcement. It is an account of how coding agents changed his own work, what 37signals is trying with Basecamp and HEY, and why he thinks software teams should redesign their tools for agents as well as people.

Watch the Opening Keynote

Credit: David Heinemeier Hansson and the Rails Foundation created and published the keynote. Shopify sponsored the video editing and post-production; its engineering writing is at Shopify Engineering. The linked chapters lead to DHH's own words and demonstrations.

A Personal Inflection Point, Not a Universal Clock

DHH opens with a photography analogy: when pictures became cheap to make, portrait painters did not disappear, but the economic role of their craft changed. He identifies November 24, 2025 and Claude Opus 4.5 as his tipping point for agent-assisted software. That historical comparison is a way to describe his change in practice, not evidence that every development team reached the same point on the same day.

At 20:45, he says 37signals has gone "pencils down" on handwritten code as the normal course of business. At 39:21, he describes himself as retired from professional hand-coding and excited to make things by directing agents. Treat both as a declaration about how he and his company intend to work. They are not a test result about what every engineer should do.

What Basecamp and HEY Actually Show

Basecamp 5 exposed an integration problem. DHH says designers made roughly 20 to 30 individually reasonable agent-assisted pull requests, but together they left the architecture in poor shape. The shipped release combined agent work with substantial handwritten code. The lesson is not merely that a single PR can pass review; it is that a series of changes must still form a coherent system. Hear the account at 22:12.

HEY is an experiment in changing the product shape. DHH shows early work on six native clients and says the team is exploring a Rust backend for the mail service. He argues that agents reduce the staffing cost of maintaining platform-specific apps. This is an early demonstration, not evidence that the next HEY has shipped across six platforms. His figures of 99% less CPU and 95% less memory are his account of the rewrite effort, with a Raspberry Pi capacity estimate he explicitly calls back-of-the-envelope. They should not be read as an independent production benchmark or a general Rust-versus-Rails comparison.

DHH does not say the web is finished. He argues that products needing immediate, no-install access, such as parts of Basecamp's collaboration workflow, remain well suited to web apps. Whether native clients or a web interface serve a customer better depends on distribution, accessibility, maintenance, and the job to be done, not just how quickly an agent can generate a first version.

Why He Still Sees a Rails Future

In the Rails section, DHH connects the framework's Convention over Configuration doctrine to agent work: a predictable place for models, routes, jobs, and tests can reduce repetitive decisions and give an agent a more legible path through a codebase. That is a plausible design advantage, not proof that Rails is always the most token-efficient or reliable choice for every product.

The Rails Foundation commissioned Evil Martians to test that premise in Agents on Rails. DHH mentions the benchmark's evolution from small tasks toward feature work at 34:23. The published reports are a useful check on both the promise and the limits: model performance changes with task complexity, effort, cost, and the definition of success.

His 150,000 lines in August is striking but easy to misuse. DHH compares it with roughly 30,000 production Ruby lines per year in his earlier work and immediately notes that much of the new output is more verbose Rust. That makes the number a vivid personal observation, not a 60-fold gain in delivered value, maintainability, or safety.

The Most Actionable Ask: Bring Your Own Agent

At 45:23, DHH pushes back on every product inserting its own chatbot. He wants applications to offer a CLI that lets a user's chosen agent perform well-defined tasks. He describes using a HEY CLI to work around gaps in the app's own search experience. The wider idea is an interface that an agent can call and a person can inspect, script, test, and authorize.

A responsible version of that idea needs more than a command parser: documented commands, scoped credentials, clear read versus write permissions, predictable errors, idempotent actions where possible, logs, and human confirmation for expensive or irreversible operations. Those are our implementation implications, not a checklist DHH presented on stage. They matter because an agent that can operate your app also inherits the risks of operating it incorrectly.

His Omarchy and one-shot app demos illustrate how broadly he now experiments, from a calculator to a lightweight presentation tool. Omarchy is a real project; the individual demos, including a roughly half-megabyte binary he cites, are examples from the keynote rather than a measured comparison with other desktop software.

Optimism With a Production Checklist

The keynote ends with DHH arguing for "total optimism" while acknowledging security concerns. The strongest practical countercheck arrived in the Rails Foundation's Stage 3 report, published October 13. Across its specific multi-session Rails tasks, agents sometimes broke earlier requirements while keeping their own tests green. In a helpdesk-app task, 17 runs finished all eight tickets, but none configured a persistent production job queue; only four kept credentials out of logs. These are benchmark observations, not a prediction that every agent-built app has those exact failures.

For a team adopting DHH's approach, the useful question is not "How much code did the agent write?" It is: Did the accepted change meet the business requirement, preserve earlier contracts, survive realistic tests, protect data, and remain operable after the demo? Start with one bounded workflow, review the diff and behavior, and measure accepted outcomes against the old way of working. That makes room for DHH's enthusiasm without asking customers to absorb the experiment's hidden costs.

Jump to the Keynote

Business Idea: Make One Workflow Agent-Ready

A small company may want agents to help with a real back-office or software task but lack a safe interface and repeatable review process. The prompt below uses the keynote's ideas to scope a service around one approved workflow, without promising autonomous production changes.

Sources and Caveats

Primary source: DHH's Rails World 2026 opening keynote, with the supplied transcript checked against its chapter sequence. Event and framework context: the Rails Foundation recap and DHH's Rails Doctrine. Independent countercheck: the Foundation and Evil Martians' Stage 3 evaluation. The keynote's 37signals, HEY, throughput, and performance statements are attributed to DHH; we did not independently reproduce them. Its predictions about the end of handwritten code remain predictions.