DHH Prefers Programming in English. The Bottleneck Is Reviewing the Result.

In July 2025, David Heinemeier Hansson compared writing code to playing a guitar. You could listen to a recording, he told Lex Fridman, but playing the instrument yourself was the point.

Fourteen months later, the creator of Ruby on Rails stood onstage at Rails World 2026 and announced that he preferred programming in English.

He also said he'd retired from writing production code by hand.

DHH was describing a new way of building software—one that 37signals, the company behind Basecamp and HEY, had started treating as its default.

His talk included useful warnings about what happens when a team can produce implementation faster than it can understand the resulting system.

What changed DHH's mind?

In the July 2025 Lex Fridman interview, DHH worried that delegating the work would turn him into a manager of AI agents. He wanted to keep writing code because he enjoyed the craft.

At Rails World on September 23, 2026, he traced his change of mind to the release of Claude Opus 4.5 on November 24, 2025. He compared that release to the Kodak Brownie: a technology that made a previously specialized activity much more accessible.

That date is his personal dividing line, not an established industry-wide turning point. Developers disagree about when coding agents became reliable enough for serious work, and their experiences vary by task, repository, and model.

By the time of the keynote, however, DHH had made a concrete decision. He said he was no longer a professional hand-coding programmer. He was still deeply involved in building products.

The impressive—and misleading—150,000-line number

DHH offered a dramatic comparison. Across his long Ruby career, he estimated writing about 30,000 lines of production code per year. With agents, he said he produced 150,000 lines in August 2026 alone.

Compared with his historical monthly average, that's roughly 60 times as much code.

The figure describes output volume, though, not a measured 60-fold increase in useful productivity. DHH acknowledged that some of the new output was verbose Rust code he would never have written in Ruby.

Code volume becomes an especially awkward metric once agents can generate large implementations cheaply. A 500-line change that removes a recurring operational problem might be worth more than a 10,000-line rewrite.

I'd want to know how much of the generated code was accepted, how much required rework, and how the changes behaved after release. The keynote didn't provide enough evidence to answer those questions.

37signals has changed its default workflow

DHH said 37signals had effectively gone pencils down: writing code by hand had become an exceptional case. If an agent couldn't produce an implementation, the company wanted to understand what was wrong with the workflow and improve it.

In an October 6 follow-up, he repeated the argument. He expects agents to handle the vast majority of typing.

That is a stronger position than using AI for autocomplete or boilerplate. It changes where the engineer spends attention: on requirements, boundaries, review, and the behavior of the finished software.

AI-generated conceptual illustration of developer review; not a screenshot of 37signals' workflow.

The obvious difficulty is review capacity. A developer may be able to read a focused change carefully. A team that generates many substantial changes in parallel has to understand their interactions as well.

DHH gave a concrete example of that problem.

The Basecamp 5 lesson: reasonable PRs, damaged architecture

During the keynote, DHH described an experiment in which designers used AI to implement features for Basecamp 5.

The individual pull requests looked reasonable. Taken together, roughly 20 to 30 PRs left the application's architecture looking, in his words, like Swiss cheese.

Individual changes can satisfy their immediate requirements while creating duplicate logic, weakening boundaries, and increasing coupling elsewhere in the application.

Illustration of the general failure mode, not a diagram of Basecamp's actual architecture. The PR numbers and changes are invented examples.

Passing tests wouldn't necessarily catch this. Tests usually check behavior the team thought to assert. They can miss architectural drift, especially when every agent optimizes for a different ticket.

DHH said the tools had improved since the experiment, and he questioned the team's initial decision to return to conventional review. That's his interpretation. The underlying engineering risk remains worth measuring, even when the implementation model gets better.

A review process needs someone—or something—responsible for the structure of the whole application, not merely for each individual diff.

HEY is where the argument becomes concrete

DHH also described an ambitious rebuild of HEY, 37signals' email product. The plan involves six native applications instead of relying on a web-centered approach, along with a Rust backend for the mail service.

He said the team had started the native applications roughly a week before his demonstration. Those were early results, not evidence that the complete rewrite had already shipped.

For the backend, DHH reported 99% less CPU usage and 95% less memory usage.

Those numbers are company-reported figures from the presentation, not an independently reproduced benchmark. Also, the architecture is changing. When work moves out of the server and into native clients, server resource usage cannot be attributed to the choice of Rust alone.

Even with those caveats, the economics are interesting. Maintaining six native clients would once have been an extraordinary commitment for a small team. Agent-driven implementation may make that option more plausible.

It also creates a much larger testing and release surface. Native app behavior, synchronization, background execution, accessibility, deployment, and compatibility still need attention. The code may be cheaper to produce; the product still has to work on real devices.

English needs a definition of done

DHH is right about the appeal of English as an interface to software creation. A good agent can turn a short request into code, tests, and a proposed pull request.

The request can still hide important decisions.

Take this instruction:

Add retries for failed payments.

Should the system retry a permanently declined card? What happens after a provider timeout, when the charge may already have succeeded? How do concurrent workers avoid charging the same order twice?

The implementation can't be evaluated properly until someone defines the desired behavior.

For a task like that, I'd give the agent a compact engineering contract:

Goal: Retry transient provider failures without duplicate charges.
Boundaries: Reuse existing payment states and background jobs; don't change public APIs without approval.
Evidence: Add tests for timeouts, permanent declines, repeated jobs, and concurrent processing.
Review: Explain which modules changed, what assumptions were made, and what could break elsewhere.
Release: Prepare the change for review; keep production deployment separately approved.

An illustrative engineering checklist, not a validated guarantee of correctness or a description of 37signals' internal process.

This adds work before the agent starts coding. It can also save the much more expensive work of debugging the wrong behavior after deployment.

One useful habit is asking the agent to return a list of unresolved assumptions alongside the PR. The reviewer can then inspect the decisions the implementation depended on, rather than only the code it generated.

What should teams measure now?

If lines of code become nearly free to generate, I'd watch a smaller set of delivery metrics:

Time to a verified change: From an agreed requirement to an accepted, tested result.
Rework: How often does a generated PR need substantial revision or architectural redesign?
Escaped defects: What reaches customers despite passing automated checks?
Operational cost: What does the change do to latency, compute, incidents, and maintenance?
Review load: Is the team actually shipping faster, or moving the bottleneck into a growing review queue?

None of these numbers works alone. They are more informative together than counting generated files or commits.

This is also why DHH's position shouldn't be read as advice to stop learning programming. His ability to direct agents rests on more than twenty years of experience with software architecture, products, and operational trade-offs.

A beginner can generate a working-looking service. Knowing which guarantees it fails to provide is harder.

And Ruby on Rails?

DHH didn't announce the end of Rails. He described Rust as a fit for this particular HEY backend, while defending web applications for products where native clients aren't justified.

Rails also has a property that suits agent-driven development: convention over configuration. Predictable structure gives both humans and agents fewer arbitrary choices to make. It can reduce the number of conflicting patterns that end up in a codebase.

AI coding agents make implementation cheaper. That lets teams try ideas and architectures that used to be out of reach. But architectural coherence, acceptance criteria, and evidence of correctness have to keep pace with the code being produced.

Before handing an agent your next feature request, write down the behavior you expect, the boundaries it must respect, and the evidence you'll accept that it works. Then review the resulting change as part of a system, not just a completed ticket.

How has your own coding workflow changed: less typing, more reviewing, or more time spent on specifications?