Rails World 2026 Keynote: DHH, HEY, Rust, and AI Coding Agents

By Rustify Team, updated September 2026

TL;DR: At Rails World 2026, DHH said 37signals now treats AI agents as the primary producers of code and hand-written code as an exceptional state. HEY is being rebuilt as six native applications with a Rust backend. DHH reported roughly 99% less CPU and 95% less memory, but described those figures as a back-of-the-envelope estimate. The announcement is not the end of Rails, Rust, or software engineering. It is a claim that the main engineering bottleneck is moving from typing code to directing and evaluating software-producing agents.

• 37signals: hand-written code is no longer the normal production workflow
• HEY: six native applications with a Rust mail-server backend
• Performance claim: 99% less CPU and 95% less memory, according to DHH
• Rust implication: agents make performance-oriented code cheaper to produce, but humans still own architecture, correctness, security, and review

What Did DHH Announce at the Rails World 2026 Keynote?

DHH did not announce that Rails is dead. He said 37signals now treats AI agents as the default producers of implementation code, while HEY is being rebuilt as six native applications with a Rust backend.

At the opening keynote of Rails World 2026 in Austin, David Heinemeier Hansson, creator of Ruby on Rails and co-owner of 37signals, made one of his strongest claims about AI-assisted development yet.

He said 37signals had gone "pencils down" on writing code by hand as its normal way of building products. In DHH's description, an engineer should usually give an agent an outcome, let it produce the implementation, and return later to review what is ready. Manually writing code becomes an exception that signals the agent workflow needs repair.

The full talk is available through the official Rails World keynote page and the recorded keynote video. The statement is about 37signals' operating model. It is not a declaration that every software company has stopped writing code, or that developers no longer need to understand programming.

That distinction matters. The headline is dramatic. The actual change is more specific:

Old default:
human writes implementation -> human reviews implementation
 
New 37signals default:
human defines outcome -> agent writes implementation -> human evaluates result

The human work does not disappear. It moves upward toward product judgment, system design, testing, architecture, and agent direction.

What Is Confirmed and What Is Still a Claim?

The keynote confirms what DHH said and what 37signals is attempting. It does not independently verify the performance numbers, prove that every team should choose Rust, or show that the HEY rewrite is complete.

Why Is HEY Moving Its Backend to Rust?

The concrete example behind DHH's argument is HEY, 37signals' email service.

DHH said the next version of HEY will stop being primarily a web application. The project is being rebuilt as six native applications, with the mail-server core rewritten in Rust. He presented the project as something that would have required a large team before agentic development made native applications cheap enough for a small company to attempt.

The architecture described in the keynote looks like this:

Six native HEY apps
        |
        v
Rust mail-server backend
        |
        v
Lower CPU and memory use

The Rust choice is practical, not ideological. HEY's core job is handling mail. A compiled, efficient backend can reduce infrastructure cost and improve latency, especially when the system handles a large amount of concurrent work.

DHH reported that the new backend uses approximately 99% less CPU and 95% less memory than the previous setup. He also said that ten hosts are kept mainly for redundancy and that a back-of-the-envelope calculation suggests HEY's peak traffic could potentially run on a single Raspberry Pi.

These are useful signals, not independently verified benchmarks. The rewrite was still in progress when he presented it. The figures came from 37signals' own comparison and estimate, not from a published reproducible benchmark. A serious analysis should therefore say DHH claims, not present the numbers as universal proof that Rust will deliver the same result for every backend.

Why Does DHH Like Rust If He Does Not Write Rust?

DHH was unusually direct about his relationship with Rust. He described Rust as unpleasant for humans to read and write, but excellent when agents produce it and the application delivers better performance.

His model is a division of labor:

• The human describes the desired behavior and constraints.
• The agent generates Rust code.
• The compiler and tests reject many invalid implementations.
• The human evaluates the system from the outside and reviews important internals.

This is attractive for a founder or product engineer who cares about outcomes more than language identity. It is also where the argument becomes controversial. Treating Rust as a black box can work for a narrow, well-tested service. It becomes dangerous when nobody on the team can diagnose ownership errors, unsafe code, concurrency behavior, dependency risk, or production incidents.

Agents can make Rust cheaper to produce. They do not make Rust unnecessary to understand.

Does This Mean Rails Is Dead?

No. DHH's own keynote makes a narrower argument.

HEY is a special case because email is a product people may use intensively across dedicated devices. Native applications can provide better platform integration, responsiveness, and offline behavior. A public web app has a different advantage: users do not need to install anything.

DHH explicitly said the web remains valuable for products used by temporary or occasional users. He also argued that Rails' conventions may work well in the agent era because agents benefit from predictable structures, familiar patterns, and fewer arbitrary decisions.

The official Rails AI initiative makes the same strategic point: Rails is being positioned as a conventional, agent-friendly framework for building web applications. The HEY rewrite is therefore not evidence that every Rails application should become a Rust service. It is evidence that the cost calculation for some native and performance-sensitive products has changed.

The more accurate map is:

What Does This Mean for Rust Developers?

The most important consequence is not that humans will stop typing. It is that typing speed becomes a weaker professional advantage.

If agents can generate thousands of lines quickly, the scarce skills become different:

1. Defining precise outcomes. Agents need clear behavior, constraints, interfaces, and acceptance criteria.
2. Understanding system boundaries. Someone must decide what belongs in the native client, the Rust backend, the database, or an external service.
3. Reviewing behavior instead of just syntax. Code can compile and still lose mail, leak data, mishandle retries, or create an authorization bug.
4. Testing and evaluating agents. A good workflow needs tests, fixtures, benchmarks, logs, and regression checks that make failure visible.
5. Debugging generated Rust. The engineer responsible for production cannot treat ownership, lifetimes, unsafe, async cancellation, and concurrency as magic.

This strengthens the case for learning Rust seriously. Not because every developer must hand-write every line, but because someone must be able to judge whether generated Rust is correct, maintainable, safe, and fast enough.

The future Rust developer may write less boilerplate and spend more time on:

• API and data-model design
• concurrency and failure behavior
• performance profiling
• security boundaries
• test strategy
• infrastructure and deployment
• reviewing agent-generated pull requests

That is a more demanding role, not a less technical one.

Is Agent-Generated Rust Ready for Production?

Sometimes. The answer depends less on whether an agent can produce compiling Rust and more on whether the surrounding engineering system can detect wrong behavior.

An agent can usually generate a standard Axum handler, a typed request model, or a database query quickly. The risk rises when the code controls money, authentication, permissions, migrations, cryptography, deletion, retries, or distributed state.

A production workflow should give agents a constrained environment:

Specification
    -> agent implementation
    -> cargo fmt and cargo clippy
    -> unit and integration tests
    -> security and dependency checks
    -> benchmark or load test
    -> human review
    -> deployment with observability

The agent should not be the only source of confidence. Rust's compiler is powerful, but it does not know whether a business rule is correct. A passing test suite is useful, but it only proves what the tests cover. Human review remains essential where the cost of a wrong decision is high.

What DHH Gets Right

The strongest part of DHH's argument is that software production has changed from a scarce activity to a much cheaper one. Native apps, repetitive integrations, migrations, and infrastructure experiments can now be attempted by smaller teams.

He is also right that asynchronous agent workflows are more promising than sitting in a chat window and waiting for tokens. Assigning an agent a meaningful outcome, letting it work, then reviewing a completed change resembles delegation to a junior engineer or contractor. That model creates a natural place for tests, review, and iteration.

The Rust example is compelling because it connects agent productivity to a concrete system outcome: lower resource consumption and smaller deployment artifacts. It is more persuasive than a generic claim that AI makes developers faster.

Where the Argument Needs Caution

The keynote still contains several claims that should not be treated as settled facts.

Lines of code are a weak productivity metric. DHH said he produced 150,000 lines of code in August, compared with a long-term average of about 30,000 lines of production Ruby per year. More code can mean more capability, but it can also mean more surface area, duplication, bugs, and maintenance cost.

The HEY numbers are not a universal Rust benchmark. They describe one rewrite, one workload, and one architecture. The result may include changes beyond the programming language, including native clients, backend boundaries, data flow, and deployment choices.

Agents do not remove ownership. They move ownership to the person who specifies the work, approves the change, and operates the system. If nobody understands the output, the team has increased its dependency on a machine it cannot effectively audit.

Manual coding remains valuable for learning. A developer who never writes or studies Rust may be able to direct a narrow agent workflow, but will struggle when the generated system fails in a way the prompt did not anticipate. Learning by hand builds the mental model needed to evaluate the agent.

Should You Learn Rust in the Age of AI Agents?

Yes, if you want to work on performance-sensitive backends, infrastructure, developer tools, networking, embedded systems, or AI infrastructure.

The reason is changing. Rust is not valuable only because humans type it. It is valuable because it combines strong compile-time guarantees with predictable runtime performance, and because engineers who understand those properties can direct and verify systems that agents generate.

The highest-value profile is not “Rust developer who refuses to use AI.” It is:

Rust fundamentals
    + systems understanding
    + agent workflow design
    + testing and evaluation
    + production judgment

That combination makes a developer harder to replace and more capable of supervising a larger volume of software work.

Frequently Asked Questions

The Bottom Line

DHH's announcement is not really the end of writing code. It is the end of treating manual implementation as the main bottleneck.

37signals is betting that a small team can direct agents to build native applications and a high-performance Rust backend. HEY is the first major example in the keynote. The performance numbers are promising but still self-reported. The broader lesson is more durable: when code becomes cheap, judgment becomes expensive.

For Rust developers, that is good news. Rust remains valuable because someone must understand the systems being produced, set the right constraints, and know when an agent-generated implementation is wrong.

Related Rustify Articles

• Building AI Agents from Scratch in Rust in 2026
• Rust for AI Infrastructure Engineers in 2026
• Learning Rust Faster with AI Tools
• Should You Rewrite It in Rust?

Sources

• Rails World 2026 opening keynote
• Rails World 2026 official event page
• Rails World 2026 keynote video
• Community transcript of the keynote
• Rails and AI