Five takeaways from DHH's five-hour conversation about AI

· Torrey Nommesen

Notes

#ai #programming #open source #podcast

Lex Fridman's second conversation with DHH runs a little over five hours. I listened to it, took notes, and then had AI help me fold those notes into the transcript — which is either a sensible use of the technology or a small joke at my own expense, depending on how the next five years go. Follow this link if you want to see my notes and conversation that created that article.

Then, I meant to use VSCode to just reformat for this site so I could post it here, but Cline actually rewrote the whole post for some reason. So I went in and edit it a bit more to make it sound more like something I would write. I'll have to fix this workflow for my next post. I guess. I don't know. Writing a blog in 2026 is such a surreal experience.

Anyway, DHH is the creator of Ruby on Rails and the CTO of 37signals. He also built Omarchy, a free operating system built on Linux and set up for AI programmers who would rather not spend the weekend configuring one. Omarchy comes up repeatedly in the conversation. A year ago he was sceptical about AI writing code. Now he is one of the loudest people saying otherwise, which is the closest thing this episode has to a plot.

What follows are the five parts I kept thinking about afterwards. The jargon is explained where it appears, for anyone who does not spend their days thinking about this.

1. The day it clicked

DHH can name the day his mind changed: November 24, 2025, when a model called Opus 4.5 came out. My conversation was a conversation I had last March with a friend who used to be a Googler and now is a full-time YouTuber.

DHH's story is that he tried it two days after the model came out and the code it wrote looked almost exactly like code he would have written himself. The important part is not that the model got smarter. It got better at using tools and checking its own work, which is the difference between an intern who types quickly and an intern who proofreads. People noticed this over the Christmas break, when there was finally time to sit with it. He now describes a vague problem, lets the AI pick the route, and reviews where it went: driver to passenger, glancing at the map now and then.

A single date is a tidy story, and models tend to improve on a curve rather than on a morning. But the reason he gives is the useful part: tool use and self-checking, not just raw intelligence.

2. The slowest part of the project is us

DHH puts the gains from working directly with a model at 10x to 1000x. The numbers only hold when there is nothing between you and the machine. Every extra person who has to approve something is a queue, and the queue is now slower than the work it is approving. He is sharper on what that exposes: most companies are not held back by how fast they can build. They are held back by not knowing what to build, and he offers Microsoft as Exhibit A; endless programmers, no taste. A faster builder does not fix a company that cannot decide what to build. It just produces more of it.

3. Open source gets a flood, and he likes it

Open source means anyone can read the code and propose changes to it. A pull request is how a proposal arrives: one person asks the project owner to accept a change, and the owner decides. The expensive part has always been reading the pull requests. Some maintainers now describe the AI-assisted ones as a flood, and DHH's response is that this is like complaining that your steak is too juicy. He approved more than 1,000 in three months, many of them from people who are not programmers. The AI does a first pass, so he only reads the ones worth reading. He also says he would rather receive a proposal written by an AI than by a person, because turning down a machine hurts nobody's feelings. With this process, Omarchy picked up 330 community add-ons in three days.

That last point is the one I keep coming back to. Maintainer burnout gets described as a volume problem. It is also a politeness problem — every rejection has a person on the other end — and a machine does not mind being told no.

4. Start vague, then react

Nobody knows what they want until they see something, which is why a detailed plan written before doing any work has never worked well. DHH points at the move to Agile in the late '90s and early 2000s, when software teams admitted the spec sheets were not making anyone happy and replaced them with build a little, try it, then adjust. Working with AI is the same lesson at a faster tempo: start with a loose idea, ask for a first version, react to it.

Two details are worth stealing:

  • Ask for three options rather than one. People are good at picking from three and bad at picking from twenty-two.

  • Give fewer instructions. The company behind Opus 5 apparently cut its built-in instructions by 80%, because enough human rules made the model worse.

His own 40 years of experience worked against him for a while, because experience tends to arrive as instructions. The uncomfortable conclusion is that project management matters more than knowing how to code.

That is not the same as saying code does not matter. It is saying the scarce skill moved from typing it to deciding what it should do.

5. Do not predict the future, join in

His advice to anyone worried about their job is to stop guessing. Nobody knows what the next version looks like, including the people building it, and a prediction is something to argue about rather than something to act on. He also thinks the gap is smaller than it feels: a year away from AI coding can be caught up to in about two weeks.

He is hopeful about work, with the standard example. ATMs were supposed to wipe out bank tellers. Instead they made branches cheaper to open, so banks opened more branches and hired more tellers. Economists call it Jevons paradox — when something gets cheaper, people want more of it. The honest version is narrower than the slogan: the job that survived was not the same job, and not everyone who lost the old one got the new one.

He admits there are no guarantees, that a bit of grief is fine, and that things could go badly wrong, up to and including the end of the world. Since that is out of your hands either way, he would rather choose to be excited. He also suggests doing it alongside other people, because worrying alone in your cave mostly makes the cave worse.

The whole conversation

Five hours is a lot, and this is the short version.

← All writing