DHH walked onto the Rails World 2026 stage in Austin on September 23 and announced in a pre-keynote tweet that his talk “might ruffle a few feathers.” Then he delivered: 37signals is going pencils down on hand-written code. His full keynote described directing AI agents to produce 150,000 lines of code in August 2026 alone — roughly 60 times his historical average of 30,000 lines per year. He called the productivity gap between developers working with agents and those working without as approaching 1,000x, and described 37signals rebuilding HEY as native apps on a Rust backend written primarily by agents.
The story went viral in part because DHH says things plainly, and in part because the numbers are genuinely striking. What didn’t spread as far: what the transition actually requires.
flowchart TD A[Adopt AI coding agents] --> B1[With architectural oversight] A --> B2[Without architectural oversight] B1 --> C1[Agents write to a known standard] C1 --> D1[Code volume plus coherence] D1 --> E1[Sustainable productivity gain] B2 --> C2[Agents optimize locally] C2 --> D2[Code volume without structure] D2 --> E2[Integration debt at 60x velocity] class E1 good class E2 bad class D1 accent classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6; classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9; classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7; classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
The rundown
DHH’s September 23 keynote at Rails World 2026 in Austin was organized around a single argument: the transition to AI-agent-written code is not incremental — it is a phase change. He described directing agents to produce 150,000 lines of code in a single month, rebuilding 37signals’ HEY product as native apps on a Rust backend. He identified November 24, 2025 as the inflection point — “the Kodak Brownie of our era” — and characterized the productivity gap between developers working with agents and those working without as approaching 1,000x.
The declaration drew immediate coverage, with developers and executives debating whether “pencils down” was hyperbole or a genuine inflection-point call. The debate mostly missed what DHH was describing precisely: a specific organizational configuration at a specific company, with a specific oversight structure, producing specific results.
37signals is a small team with exceptional technical taste and a founder who has been writing and reviewing production code for over two decades. DHH reviewed what the agents produced. He held the architectural standard. The agents wrote to that standard.
For engineers: the output volume is real; the judgment is still the constraint
The productivity gains DHH is describing are real, and engineers who have been using coding agents seriously in 2026 have a version of the same experience — code that used to take hours takes minutes, scaffolding that used to require an afternoon happens in a prompt.
What doesn’t change with agents is the question of what the code should be doing architecturally. Agents produce locally correct code. They do not inherently produce globally coherent architecture. An agent will build you a working authentication module that conflicts with three other authentication approaches already in the codebase, or a data model that solves the immediate problem and forecloses the migration you’ll need in 18 months. The agent doesn’t know that — and at 150,000 lines per month, the cost of that incoherence compounds faster than anyone can catch manually.
What actually made DHH’s approach work is that he knew what he was reviewing. The constraint in any agent-heavy workflow is not compute time; it is the judgment capacity of the person evaluating the output. For a team without that capacity distributed across contributors, the same tooling produces a different result.
The productive near-term investment for engineering teams is not acquiring more tools. It is investing in the architectural scaffolding that gives agents something coherent to write toward: documented data models, API contracts, integration patterns, naming conventions, test requirements. Agents produce more useful code when they have more useful context — and someone who can tell the difference when they don’t.
For business owners: the productivity gains don’t standardize automatically
DHH’s keynote will be interpreted by some business owners as a signal to restructure engineering teams around AI agents, reduce headcount, and expect proportional output increases. That interpretation misses the most important variable in what he described.
37signals has DHH. DHH has more than 20 years of experience writing production software, a clear architectural vision for his products, and the ability to review 150,000 lines of agent output in a month and know which lines are sound and which need to be reconsidered. The organizational infrastructure that makes their approach work is not the agents — it is the judgment that sits above the agents and holds the standard they write to.
The realistic question for business owners is not “can we go pencils down” but “what does our architectural oversight capacity actually look like right now.” If the answer is unclear, adding more agent tooling without adding oversight infrastructure will accelerate the accumulation of technical debt, not reduce it. The output multiplier is real; it multiplies whatever the underlying structural quality is, in both directions.
My take
I spent five years as a senior enterprise architect at LERETA, the second-largest property tax payment processor in the United States, where we were processing roughly $18 billion annually on a legacy mainframe stack. In the middle of that engagement, the organization acquired a company from Texas that built similar processing technology, with the intent of retrofitting that company’s code into the flagship product we were rebuilding.
What followed was predictable in retrospect and expensive in practice. The Texas company’s data structures were similar but not identical. Their processing logic handled certain edge cases differently. Their naming conventions didn’t match ours. None of these differences were large individually. Together, they produced months of rework — developers discovering mid-sprint that components that looked compatible weren’t, and circling back to reconcile systems that should have been aligned from the start.
In retrospect, it would have been faster and cheaper to start the new initiative with a clean requirements-gathering process rather than retrofitting an architecture that wasn’t built for our standards. The mismatch didn’t surface at import time. It surfaced later, at the integration boundaries, when two systems that each worked correctly individually started failing where they touched.
DHH’s agents are writing 150,000 lines a month. DHH is the integration boundary. He holds the standard; the agents write to it. For teams that want the productivity gain without that architectural authority in place — or without investing in building it — the lesson from the Texas retrofit applies at 60x the velocity. The question worth sitting with is not whether the agents can produce the volume. They clearly can. The question is who reviews it, and whether that person has enough architectural context to know what they’re looking at.
