DHH’s Rails World 2026 Keynote: Building Software When Agents Write the Code

David Heinemeier Hansson used his Rails World 2026 opening keynote to describe a substantial change in his working life: directing agents has largely replaced writing code himself. He also described plans for HEY, questioned established architectural habits, and urged developers to embrace the transition. Watch the keynote .

Some of his claims deserve scrutiny. A demonstration cannot establish the maintenance cost of a production application, and one company’s experience cannot settle the future of an entire profession. Still, the talk gives developers and business owners plenty to consider, especially when choosing what to build and how much effort to spend building it.

The photography comparison

DHH begins with photography. As producing images became cheaper and more accessible, more people participated, and professional work changed. He expects software development to follow a similar path.

The comparison is useful when thinking about work that never gets funded. Most businesses have awkward processes that everyone tolerates: a spreadsheet assembled manually each week, an administrator copying data between applications, or a report that takes several people to prepare.

These problems can be too small to justify a conventional development project. Reduce the implementation cost enough, and some become worth solving.

The cost of ownership still matters. Someone must maintain the application, protect its data, and deal with failures. A tool that takes an afternoon to build can create years of obligations. Any honest estimate should include both.

How DHH arrived at this position

His earlier writing helps explain the change in his attitude.

In January’s Promoting AI agents, DHH describes agents using terminals, running tests, consulting documentation, and contributing to existing projects. He prefers assigning work and reviewing the result to having an editor continually suggest how to finish his code.

That essay is more cautious than his keynote. He describes supervised collaboration as useful, while saying that largely unsupervised generation had yet to meet his standards for professional work. Quality and consistency remained concerns. Promoting AI agents .

The distinction between those working styles matters. An autocomplete tool helps with the next few lines. An agent can receive a task that includes investigation, implementation, and verification.

For example, an engineer might ask an agent to reproduce a checkout failure, find its cause, fix it, and check the surrounding behavior. That assignment requires more context than a request to generate a function. The engineer must explain what correct behavior looks like and decide whether the result meets that standard.

Handwritten code becomes the exception

At Rails World, DHH says manually written code has become exceptional at 37signals. He also describes an earlier experiment in which individually plausible, AI-generated features produced architectural problems when combined.

That earlier failure deserves attention. A change can work in isolation and still make the application harder to maintain.

Suppose several agents independently add payment handling, account permissions, and notifications. Each feature might pass its own tests while introducing different assumptions about retries, errors, or user identity. The integration work remains, regardless of how quickly the individual features were produced.

A team needs someone responsible for those shared decisions. It also needs verification that reaches beyond the files changed in a particular task. Generating more code will not resolve disagreements about how the product should behave.

HEY and the economics of native applications

DHH describes a new direction for HEY involving native clients and a Rust backend. He presents agent-assisted development as the reason those choices have become practical.

This is worth considering because technology choices often reflect staffing and budget constraints. A team may choose a shared codebase because it cannot afford to maintain separate applications for every platform.

If implementation becomes cheaper, the calculation changes. Platform-specific features or interactions that previously cost too much may become affordable.

But separate applications also mean separate releases, device testing, accessibility checks, and platform updates. A working prototype does not tell you how much effort those activities will require over several years.

The same applies to replacing a backend. Faster execution may be valuable, but a migration must preserve behavior and data while giving the team something it can operate reliably.

Before committing to either change, build enough to test the business case. Measure the interaction that needs improvement or the workload consuming resources. Include migration and maintenance in the estimate. There is no need to settle the future of web development to decide whether a particular application would benefit from a native client.

Rails still has a place

DHH argues that installation-free web applications remain useful and that Rails conventions can support efficient agent development.

Product distribution deserves its own consideration. Someone following a link to approve an invoice is unlikely to welcome an installation step. A person using an application all day may value deeper integration with their device.

Frequency of use, accessibility, discovery, and platform requirements should inform that decision.

Inside the project, consistency is something teams can test. Give an agent a change that resembles existing work and examine whether it finds and follows the established pattern. Check how much explanation it needs, whether it can run the application, and whether it can verify the result.

Those observations are more useful than choosing a framework based on general claims about its suitability for AI.

Let customers use their own agents

DHH’s thinking also extends to the interfaces software exposes.

In Basecamp becomes agent accessible, he describes an updated API, a command-line interface, and instructions for agents. His examples include creating tasks, summarizing project information, arranging schedules, and combining information from other services. Basecamp becomes agent accessible .

HEY documents similar capabilities. Agents can use its command-line interface to review email, draft replies, and organize messages. A terminal interface is available for people as well. HEY’s agent tools .

For a software company, this creates work beyond adding an AI feature to the interface. Important operations need to be accessible and predictable. Permissions must apply consistently, and errors must give the caller enough information to recover.

Consider an agent arranging a customer meeting. Reading availability, creating an invitation, and cancelling an existing appointment have different consequences. The product should expose those differences rather than treating every action as interchangeable.

Customers also need a record of what the agent did and a way to correct mistakes. Those details will determine whether they trust it with repeated use.

Omarchy and personal software

The keynote includes examples of DHH’s personal software projects around Omarchy, including a calculator, a writing application, and presentation software.

His essay The malleable computer explains the appeal. Open source gives users permission to modify software, but exercising that permission has usually required considerable expertise. Even experienced developers can struggle with an unfamiliar language or a large codebase. He argues that agents make modifications more accessible, including changes to the desktop environment itself. The malleable computer .

A small application can be worthwhile even if only a handful of people need it. Internal tools, in particular, can earn their keep by removing a repetitive task.

They still need an owner. Before adopting one, a business should know where its data lives, who can change it, and what happens when it stops working. Otherwise, an afternoon’s useful experiment can become another undocumented dependency.

Architecture is open to investigation

DHH also questions whether familiar architectural trade-offs remain appropriate when many agents can modify an application.

There is room to investigate this without abandoning established practices wholesale.

Shared code can keep business rules consistent, but modifying it may require coordination across several features. Duplicated code allows independent changes, but behavior can drift. Cheaper implementation does not make either consequence disappear.

Teams could compare how agents handle similar changes in differently structured modules. The useful measurements would include defects, review effort, unexpected edits, and difficulty making a subsequent change.

The first implementation is only part of the result. A structure that works well today must also accommodate the next requirement.

What to do with the optimism

DHH closes by urging developers to approach the transition optimistically.

His essay Endless execution describes the pleasure he takes in pursuing more ideas with agents. Endless execution . In his writing about open source, he also argues for welcoming people who can now modify software with AI assistance, while acknowledging the problem of poor-quality contributions. Let the agents democratize open source .

You do not need to accept every prediction in the keynote to try the working methods.

Choose a real task with an agreed acceptance criterion. Give an agent the context and tools it needs. Count the time spent explaining, reviewing, correcting, and deploying the result. Then follow the change into production.

Repeat that exercise across different types of work. Interface changes, data migrations, and production debugging make different demands. Success in one does not establish reliability in another.

The evidence that matters is close to the work: whether customers get a better product, whether the team spends less time delivering it, and whether the software remains dependable afterward. That is how an enthusiastic experiment earns a permanent place in the development process.