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. Around that, the episode covers what is still scarce — taste, judgement, knowing what to build — why large organisations aren't picking up this speed, what a model costs per job, and why Linux of all things becomes the operating system of this era. 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. Below are the chapters that touch our trade, with timecodes: what DHH says, and what I make of it. The non-technical parts — 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) — I leave alone. Not because they're uninteresting, but because this is a software company's soapbox.

In this article

• 1 · Programming with AI agents
• 2 · Why you see none of this in the software you use every day
• 3 · Open source: a thousand pull requests, and agents reviewing them
• 4 · Vibe coding, agentic engineering, and why over-specifying hurts
• 5 · Advice for programmers: nothing is accumulating that you could miss
• 6 · The setup: sixteen threads, four machines, one human bottleneck
• 7 · Obsessing over speed: an operating system that installs in 45 seconds
• 8 · Which model, and what does it cost?
• 9 · Two models, four eyes
• 10 · Linux wins the desktop, and English becomes the programming language
• What this means for how we build

Thirteen months earlier he sat at the same table as a sceptic. Autocomplete was a poor mode to work in, the chatbot a decent tutor, and neither changed how he looked at an editor. He dates his turning point to the day: 24 November 2025, Opus 4.5 (watch from 2:56). Not because the model was suddenly much smarter, he says, but because it could finally apply its intelligence — use tools, check its own work, finish a task. What follows comes in three phases: one agent you steer, then sub-agents that split the task, and since this summer a phase where he no longer says where to go. He describes the problem; the model picks the route. His image for it is satellite navigation: you used to watch whether it was driving you into the harbour, and now the car drives itself.

What gives the argument weight isn't the enthusiasm but the source. This is the man who spent two decades explaining why you write code by hand, and he is precise about where it doesn't hold: on a web application with a database behind it you approach a hundred per cent generated code, while Basecamp — large, old, many users — turned out to be far harder to accelerate. That distinction is more useful than most vendor material, because it is exactly the line our clients run into.

Lex asks the right question: if this is true, why aren't Photoshop and Premiere suddenly getting better? DHH's answer is uncomfortable for anyone with an org chart (from 18:14). As soon as people work together, implementation is rarely the bottleneck; human bandwidth and coordination are. A product manager, two designers, a VP and a CTO who all want a say in the shape — that is where productivity goes to die. To get the ten- to hundredfold, you have to talk to the agents yourself, with no human in between. On top of that, most organisations aren't blocked on building but on knowing what they want: ideas, vision, taste. You can now make a great many mediocre ideas come true, very fast.

He has a scar to go with it. On Basecamp 5, designers were given room to vibe-code. Each pull request was individually defensible; together they wrecked the architecture, and the cleanup had to be done by hand. That is exactly the conversation we have most often in tech consultancy: not whether agents can write code, but who guards coherence when five people generate at once. In full-stack development it is one of the few things we don't delegate, and in modernising existing software it is half the job.

In three months DHH merged over a thousand pull requests into Omarchy, with a few hundred still open (from 27:30). Many came from people who are not Linux developers and who would never have submitted anything without an agent. He has no patience for maintainers complaining about the flood of AI contributions: this is what open source always promised. He no longer reads them all himself — an agent reviews, validates bug fixes in a VM, and hands him a summary where only the human decision is left: merge or don't. And, he notes drily, rejecting an agent's PR hurts nobody's feelings. The real bottleneck being review capacity rather than writing is precisely what we found in research across 25,000 pull requests.

DHH hates both terms and still lands a usable definition (from 47:05): vibe coding is telling an agent to build software without looking at the implementation. His second claim is the more interesting one: programmers are not automatically better at this. Building software is largely product management — what should it do, for whom, what is and isn't in version one — and that skill is not evenly distributed across developers. His own experience worked against him for a while, because he kept prescribing to agents how he would have done it himself. He points at the Opus 5 system prompt, which shrank by eighty per cent because too much instruction actively damages the model, and draws the parallel with the agile lesson of twenty-five years ago: nobody knows what they want until they have used it, so specify as little as possible up front and go touch something.

On one point he comes back down to earth, from 1:00:06. Beautiful, coherent code still pays — no longer because a human has to understand it, but because tokens are scarce. A system an agent can hold without relearning the whole context is cheaper to change. Let the architecture decay into a ball of mud and you pay for it on every PR. That is the same arithmetic we ran in Code is getting cheap. Engineering isn't., and it explains why generated code is not automatically good code.

The most reassuring stretch of the conversation (from 1:10:24). Don't try to predict anything, DHH says, because even the sharpest people in the field don't know what two model generations out looks like. And the good news: nothing is stacking up. Spend a year backpacking and you catch up with the frontier in two weeks — everything that works is being tried and ruthlessly sorted by thousands of people simultaneously, and you get to show up for the results. Anyone who only loved the mechanical part of the job is in for a rough time; anyone who loved making things is not. He is fine with people grieving the old craft for a while. We have written about the downsides he skips past here: what happens to the path from junior to senior and why constant AI assistance wears you down.

The most concrete chapter for anyone wanting to try this (from 1:31:46). No IDE, but the terminal: first tmux with panes, now Herdr, which adds notifications the moment an agent needs a decision. Neovim survives mainly as a project browser, for reading diffs together with the code around them. 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. Programming has moved from single-threaded to parallel, and flow no longer lives in the depth of one problem but in the chain of decisions. It drains you the way an hour of racing drains you, he says: satisfying, and not sustainable.

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.

A new Mac needed 42 minutes before it was usable; a new Windows PC took an hour and a half (from 1:44:11). Omarchy installs in under a minute; the record stands at 45 seconds, and with hardware-specific images he is aiming for twelve. It was won with dull, solid tricks: preloading packages while the user answers five questions, and cutting hundreds of megabytes out of the image — the JetBrains font shipped as a full family at 200 MB where 16 MB was needed. He compares it to McLaren engineers shaving 370 grams off a 1,400-kilo car, and quotes Mitchell Hashimoto: the pursuit of excellence deserves no explanation. We'd put it more prosaically: every second removed from a cycle stays removed, every day after that — which is the same argument as for the wait in your 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 — though his subscription ran dry two-thirds in and Opus 5 completed it from that same plan, which says something in itself about how portable a good plan is. 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; 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. For anyone who would have to learn Rust to do this themselves, he estimates nine months. This is the core of why software projects that never cleared the business case suddenly clear it — the web application that never happened, 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.

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. Even Copilot, which used to produce mostly noise, is in his view now good enough to switch back on. None of this should surprise us: give a good engineer's work to a second good engineer and you get better code. 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 — and 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.

The irony the conversation ends on is a good one (from 3:38:35). Everything Linux was dismissed for over thirty years — everything is a config file or a CLI tool, and the error messages are unreadable to humans — is exactly what an agent needs. An agent knows the source code of your entire machine and can place that cryptic message; Omarchy ships a crash watcher that offers to go and find out. A locked-down operating system where hotkeys can only be changed by mouse is, in this era, an obstacle. Even Linus Torvalds, he notes, welcomes AI contributions to the kernel.

And from 3:59:24 comes the line the whole conversation builds toward: if one programming language is more beautiful than Ruby, it is English. There is a technical point underneath that I see underrated. Programmers would like a model to be deterministic: the same question, always exactly the same answer. It isn't, and that is deliberate. A language model picks its next word from a spread of candidates, and the setting that governs how much leeway it has there is called temperature. Turn it to zero and you get the same answer every time — and never anything better than what you had already thought of. That leeway is precisely what DHH calls the most beautiful part of the whole setup: no randomness, no creativity, in models or in people. And Lex adds what characterises every good prompt: strategic ambiguity. Over-specify and the model follows you literally, and you get your solution rather than the better one. Write too vaguely and you get randomness. Learning to hold that register is the skill of the moment, and it looks more like editing than typing.

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 existing landscape, an ERP nobody dares touch, 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, which architecture survives, how do you spot generated code that is plausible but wrong, and how does it stay operable for whoever is on call.

In practice that means custom software whose build time has collapsed while its architectural decisions have not, modernising existing systems rather than blindly regenerating them, tech consultancy for teams adopting agents without drowning in review, and measuring whether it is genuinely faster. 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 — and these five hours are the best available account of that shift from someone with nothing to sell you.

Curious what this means for your development costs, your existing software or your technology choices? Get in touch. Bring a real problem rather than a demo request; it makes for a better conversation.