The DHH Setup Is Not a Tool Stack. It Is an Org Chart.

TV
Thiago Victorino
7 min read
The DHH Setup Is Not a Tool Stack. It Is an Org Chart.
Listen to this article

Six months ago, David Heinemeier Hansson publicly rejected AI coding tools. Today, he barely writes code by hand. His philosophy did not change. The tools crossed a threshold he had set in advance, and his workflow reorganized around them almost overnight.

Gergely Orosz documented the new setup in The Pragmatic Engineer. It is the most precise look we have at what a senior operator actually does when agents start working. Leaders should watch the episode before drawing conclusions: Gergely Orosz interviews DHH on The Pragmatic Engineer. Then they should resist the obvious lesson.

The obvious lesson is “DHH uses agents, so agents work, so we should use them too.” This reading misses what the article actually shows. DHH’s productivity is not produced by Gemini 2.5, Claude Opus, or a tmux layout. It is produced by an organization that happens to make those tools usable. The setup is the visible tip of a structural choice that 37signals made years before the current agent wave.

Productive AI use is an organizational shape, not a tool choice. Before a leadership team copies the workflow, it has to copy the preconditions.

The Five Preconditions Hiding in the Setup

Read the Orosz piece carefully and a pattern emerges. Every operational detail that looks like a tool decision turns out to be a staffing, architecture, or process decision that predates the agent era.

Senior reviewers gate every agent output. DHH is explicit about where his leverage comes from: he can judge production-readiness on sight. His panes are running Gemini for speed and Claude Opus for depth, but the center of his screen is NeoVim and Lazygit, reviewing diffs. The agent generates. The senior human validates. Amazon reached the same conclusion from the opposite direction, restricting junior engineers from shipping agent-generated code without senior review after a string of incidents. The lesson is not subtle. An agent-heavy workflow is a senior-heavy workflow. If your staffing pyramid skews toward juniors, you are not short on tools. You are short on the people who make the tools safe. As we argued in Cheap Code, Expensive Quality, generation got cheap and validation did not. DHH’s setup is what it looks like when an organization already has the validators.

CLIs as a product surface, not an afterthought. 37signals builds command-line interfaces for every product they ship. Not because developers prefer terminals, but because agents can chain CLIs without a human gluing steps together. Check errors, write fixes, open pull requests, post updates to Basecamp. All of it runs as text. Most companies do not have this. They have dashboards, click-through consoles, and half-documented internal APIs. An agent cannot operate a web app designed for human hands. The infrastructure choice to expose everything as text is what makes multi-agent orchestration possible at 37signals and impossible at most of their peers. This is the same point we made in Agentic Engineering: the workflow everyone admires assumes a substrate most teams do not have.

A 1:2 designer-to-engineer ratio. 37signals runs with 20 engineers and 10 designers. At most product companies the ratio is closer to 1:6 or 1:10. This predates AI by a decade. It is a worldview. Designers carry product management responsibility, shape the work, and build it. When generation gets cheap, the bottleneck moves to deciding what to build and what “done” looks like. 37signals already had that capacity in place. Most organizations are about to discover that their design function is half the size it needs to be. We wrote about this dynamic in The Amplifier Effect: Why Your Org Chart Matters More Than Your AI Stack. The designer ratio is not a cultural quirk. It is the governor that keeps generative speed from producing generative garbage.

Framework fit is not universal. DHH notes that Rails is unusually well-suited to agents: token-efficient (cheaper inference), test-first by convention (a built-in validation signal), and readable by default (low review cost). Rails happens to match agent capabilities. Not every stack does. A legacy C++ monolith, a sprawling microservices graph held together by tribal knowledge, a TypeScript codebase with 40 lint rules and no tests: these will not produce the same leverage, no matter how many tmux panes you open. The productivity story at 37signals is partly the story of a framework whose opinions happen to align with what agents are good at. Leaders importing the workflow need to honestly ask whether their codebase is on the right side of that alignment.

Deliberate burnout protection. This is the easiest detail to skim past and the most revealing one. DHH explicitly protects eight hours of sleep during what he calls the “AI gold rush.” He describes multi-agent orchestration as hyper-accelerated work, the kind that feels exhilarating and then hollows you out. His response is structural, not willpower. Scheduled sleep, bounded hours, a refusal to let the mech suit run the pilot. Most organizations have the opposite instinct. If the tools make people faster, extract the speed. The companies that do this will get a quarter of acceleration followed by a year of exhaustion. DHH is pricing that in up front. The risk is real enough that we devoted an entire piece to it in Cognitive Debt: The Invisible Cost of AI-Generated Code.

The Counter-Evidence Matters

It would be dishonest to present DHH’s setup as pure upside. The same period that produced his workflow also produced a string of agent-related production incidents at larger companies. The Evidence Is In: AI Coding Agents Are Breaking Things documents the pattern. Agents that ship without senior review cause outages. Teams that skip the validation layer pay for it in incident hours. The 37signals workflow looks effortless because the preconditions absorb the risk. Remove the preconditions and the risk surfaces immediately, usually in production, usually at 3 AM.

This is why “adopt the workflow” is the wrong frame. The workflow is downstream of the shape.

The Quantified Win and What It Really Says

The most cited number from the Orosz piece is a 37signals engineer improving P1 latency on the fastest 1% of requests from 4ms to under 0.5ms. The framing is that agents made economically unviable work viable. That is true. But notice what had to exist for that win to happen. Someone had to know the 1% tail was worth optimizing. Someone had to have the instrumentation to measure 4ms versus 0.5ms in production. Someone had to have the senior judgment to validate the fix did not break anything else. Someone had to own the codebase well enough to deploy with confidence.

The agent did the tedious part. The organization did everything else. If you only buy the agent, you only get the tedious part. You still need the rest.

What Leaders Should Actually Do

37signals will need to rewrite Shape Up. DHH says so himself. The 2019 methodology assumed cycle times that agents have now compressed. A methodology book published seven years ago is already out of date because the unit economics of software shifted underneath it. That is the real signal from the article. Not that tools have arrived, but that the ground has moved, and the companies that were already standing on solid ground are the ones who will benefit.

The action for leadership teams is not to buy better tools. It is to audit the preconditions. Do you have enough senior reviewers to gate agent output, or is your pyramid upside-down? Do your products have CLI surfaces agents can chain, or are they click-through dashboards? Is your designer-to-engineer ratio built for a world where deciding what to build is the bottleneck? Does your framework and codebase reward agent-generated contributions, or punish them? And critically: are you pricing in the human cost of hyper-accelerated work, or are you planning to extract the speed and deal with the wreckage later?

Answer those questions first. The workflow follows.


This analysis synthesizes DHH’s new way of writing code by Gergely Orosz (The Pragmatic Engineer, April 2026) and related reporting on agent-era engineering practices.

Victorino Group helps leadership teams build the organizational shape that makes AI tools productive, not just present. Let’s talk.

All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →

If this resonates, let's talk

We help companies implement AI without losing control.

Schedule a Conversation