The creator of Ruby on Rails doesn't write code any more

Lex Fridman spent over five hours with David Heinemeier Hansson: DHH, creator of Ruby on Rails, CTO of 37signals and, for the past year, builder of the Omarchy Linux distribution. The conversation fits in a single paragraph: a programmer who spent twenty years chiselling Ruby by hand, and treated that as a craft, has let go of nearly everything he thought he knew about it in nine months. He no longer writes a line of code himself. He drives roughly sixteen agents at once across four machines instead, and used them to ship a complete operating system in three months. His own summary of the moment is borrowed from Lenin: there are decades where nothing happens, and weeks where decades happen.

Five hours is a lot, even for a good conversation. I have pulled out the three things you can use on Monday: what a job costs on which model, what his setup looks like now that he runs sixteen things at once, and the trick of having two models check each other's work. Those I work out. The rest sits further down in brief, with timecodes. The non-technical parts I leave alone: AI and filmmaking (2:50:57), fatherhood (3:10:28), politics and immigration (4:22:17), his dislike of the longevity cult (4:53:54). This is a software company's soapbox, after all.

In this article

• What it costs: the same program, a twenty-fourfold price gap
• The setup: sixteen threads, four machines, and a human who can't keep up
• Two models, four eyes
• The rest of the conversation, briefly
• What this means for how we build

This is the one number in the episode that concerns a buyer directly (from 2:21:05). DHH had a Python library translated into Rust: one prompt, no knowledge of Rust, not a line of code reviewed. Fable produced an eight-step plan and finished in forty-five minutes; his subscription ran dry two-thirds in and Opus 5 took over from that same plan. Priced per token, that run would have cost around $550. He then handed the same plan to other models: GPT Sol did it in an hour and a half for $46, Grok 4.6 for about $55, DeepSeek V4 Pro in two hours forty-five for $23. Two cheap models failed outright, and one of them tried to cheat by wrapping an existing implementation. In every successful case the result was the same working program, ten times faster than the original and forty-six times after two automated optimisation rounds.

Do the arithmetic. Same outcome, a twenty-fourfold price gap, and the most expensive run is the fastest. Whether the gap is twenty-fourfold on your work too, I don't know: this is one library, measured once, by someone who enjoys this sort of thing. The direction does match what we see. Projects that never cleared the business case are clearing it now: the customer portal that died in three budget rounds, the integration between two systems that looked too expensive for what it delivered. Exactly where that sum flips is different per organisation, and that is the conversation we have in AI consultancy.

The most concrete part of the conversation for anyone wanting to try this (from 1:31:46). He works in the terminal: first tmux with panes, now Herdr, which adds notifications the moment an agent needs a decision. An IDE no longer comes into it. When one machine stopped being enough he pulled four mini PCs out of a closet, hung them off KVM adapters and a WireGuard network, and now runs about sixteen threads at once. The hardware could take more; he can't. (Aside: four mini PCs wired together out of a closet is not a data centre, it is an attic. I think it is the best detail in five hours of conversation.) Programming has become parallel, and flow now lives in the chain of decisions. It drains you the way an hour of racing drains you, he says. Satisfying, and after a day you have had enough.

His own conclusion is the interesting part: the human in the loop is now the limit. So he is building a bot that works through PRs and issues autonomously overnight and sends him one email a day with what is left to decide, and 37signals is experimenting with agents as colleagues inside Basecamp, assigned to-dos rather than chat, because chat tempts you to sit and wait. Anyone setting this up seriously wants to know whether it is genuinely faster rather than merely busier; that is what Agile Analytics is for, and why we wrote about reading DORA metrics when AI writes half your commits.

His standard way of working is simple and worth copying (from 2:37:55): have one model do the work, then have a different one check it. He builds with Claude, has Codex review on its highest setting, and recently added Grok. And they find things. He cites a study Shopify's CTO ran against real production incidents: pull requests reviewed by agents caused fewer outages than those reviewed by humans. Meanwhile the same models are so good at finding vulnerabilities that 37signals' security team ended up with an avalanche of patches. His sharpest line is about the teams seeing no avalanche: that doesn't mean your system is safe, it means you are blind and your adversaries are not. Of everything in this piece, this is the easiest to copy: it costs a subscription and a checkbox.

• How he got here (2:56). Thirteen months earlier he sat at the same table as a sceptic. He dates his turning point to the day: 24 November 2025, Opus 4.5. The model did not get much smarter, he says; it could finally apply its intelligence, using tools and finishing its own work.
• Why you see none of this in Photoshop (18:14). As soon as people work together, implementation is rarely the bottleneck; coordination is. On Basecamp 5 designers were given room to vibe-code: each pull request was defensible, together they wrecked the architecture. That is the conversation we have most often in tech consultancy and in modernising existing software.
• A thousand pull requests in three months (27:30). Many of them from people who are not Linux developers. He no longer reads them himself: an agent reviews, tests in a VM and summarises, and he merges or doesn't. Rejecting an agent's PR hurts nobody's feelings, he notes drily. That review is the real bottleneck is what we also found in research across 25,000 pull requests.
• Why over-specifying hurts (47:05). Programmers are not automatically better at this: building software is largely product management. From 1:00:06 he comes back down to earth, because coherent code still pays, now that tokens are scarce. The same arithmetic we ran in Code is getting cheap. Engineering isn't.
• Nothing is accumulating (1:10:24). Spend a year backpacking and you catch up with the frontier in two weeks. Anyone who only loved the mechanical part of the job is in for a rough time; anyone who loved making things is not. We have written about the downsides he skips: the path from junior to senior and why constant AI assistance wears you down.
• An operating system that installs in 45 seconds (1:44:11). A new Mac needed 42 minutes; Omarchy does it in under a minute. Won with dull, solid tricks: preloading packages while the user answers five questions, and cutting a 200 MB JetBrains font family down to 16.
• Linux wins the desktop, and English becomes the programming language (3:38:35). Everything Linux was dismissed for over thirty years, from config files to error messages no human reads, is exactly what an agent needs. And from 3:59:24: a language model is deliberately not deterministic, and that leeway is what DHH calls the most beautiful part of the whole setup.

I recognise most of this from our own work, and I disagree with the tone on one point: DHH works largely in his own projects, where he is client, architect and reviewer at once. That is the easy version. At a client with an ERP nobody dares touch, two integrations hanging off it and a team that still has to maintain the thing in three years, the agent is just as fast, but the judgement around it gets more expensive rather than less. That is why we shifted our emphasis to AI-native software engineering and to the questions that remain once implementation is cheap: what do we deliberately not build, and how do you spot generated code that is plausible but wrong.

In practice that means custom software whose build time has collapsed while its architectural decisions have not, and modernising existing systems rather than blindly regenerating them. I wrote in 2023 that the end of programming was silly sales nonsense. I still think so. What I underrated was how far the job itself would move.