Agentic development: Ruby on Rails creator explains why he no longer writes code by hand

If the name means nothing to you: DHH created Ruby on Rails - the framework behind GitHub, Shopify, and Airbnb - and 37signals, the company behind the cult product Basecamp. For twenty years, he was the loudest defender of the craft: small teams, code by hand, no cargo cult. Even people who had not written a single line read his books about the "calm company."

You might think this is another AI evangelist who needs to sell a course. It is the opposite. For someone with that reputation, the "death of handwritten code" is more disadvantageous than for anyone else, which makes his turn all the more valuable. The skeptic who demonstratively learned Bash a year ago now describes the moment like this [37:37]: "Refusing to acknowledge the scale of what is happening - that is the real psychosis."

Most AI stories have no date. This one does. On November 24, 2025, the Opus 4.5 model came out. DHH tried it two days later and describes that evening as the moment after which work never returned to its old course [05:54]: "The quality of the output became frighteningly close to what I would have written myself. I leaned back in my chair and thought: what just happened?"

An important detail that is usually missed. It is not only about the model's "intelligence," but the tooling around it [05:54]: the agent got hands - the ability to run commands on a computer, check its own work, and correct itself. A model without hands is an adviser. A model with hands is an executor.

Then eras changed every three months. At first, DHH was "in the driver's seat" and checked every step. In spring, subagents appeared - one agent delegates work to eight others. By summer, he sums it up like this [05:54]: "I no longer say where we are going. I name the problem - the agent chooses the route itself. In the part of work that produces code, I have become unnecessary."

Over the past two months, not a single line written by his own hands has shipped in Omarchy, his Linux distribution [15:42].

That same argument from every chat. DHH has a precise definition [50:36]: vibecoding is when you ask an agent to build a program and do not look at how it works inside. Do not look at all. He does it himself too: he built a replacement for his favorite notes editor in C++ in twenty minutes and never looked at the code [26:33].

You might think the line runs between "real programmers" and "impostors." DHH has a different line - the cost of error. For a pet project or a utility for yourself, vibe code without opening the code. But here is what happened at his own company: Basecamp designers were allowed to vibe code changes in a large live product, and each change separately looked reasonable [15:43] - "but together they destroyed the architecture. We cleaned it up by hand." He notes that this was in February and the tools have advanced since then [15:43], but the lesson about the cost of error remains: on someone else's production system, with money and other people's data, the "without looking" mode ends.

He does not like the term itself, by the way: it reminds him of "script kiddie" from the 2000s [49:09]. And he calls the word agentic marketing soap. By the end of the conversation, he and Lex agree on an unexpected point [01:32:36]: "Okay, let's just call it programming."

The main fear - and DHH keeps both sides of the scale honest, without comforting fairy tales.

The optimistic side. When programs get cheaper, everyone starts wanting them: demand for software grows faster than the cost of producing it falls. It already happened with ATMs - after they appeared, there were more bank tellers, not fewer [01:10:51]. Plus a sober caveat: the wave of layoffs in IT began with overhiring during the COVID years, and for some companies AI is simply a convenient explanation [03:03:37].

The hard side. He says it too, without anesthesia [01:10:51]: "Productivity growth means fewer people are needed for the same work. For a specific person who was laid off, that is a tragedy - here and now." The Luddites, he reminds us, were not fools from a joke, but highly skilled craftspeople who loved their work. Their craft ended anyway.

Who should be afraid and who should not - his dividing line [01:10:51]: those who loved programming for the mechanics themselves - loops, syntax, debugging - will have a hard time. Those who loved BUILDING face no threat: more builders will be needed than ever.

The hottest question among practitioners. "A vibecoder's career is a dead end," "I no longer remember which file has the button" - there have been dozens of such confessions on Habr over the past year. And this is where DHH made his most uncomfortable turn.

A year ago, he learned Bash precisely out of fear of atrophy - "so competence would not leak out of my fingers." Now [02:13:23]: "I have not written Bash by hand in about two months. Agents have become too good." The fear did not come true - it moved.

Then comes the paradox that makes the episode worth watching. Expertise began getting in his way [52:07]: "Knowing programming worked against me for a while: I told agents HOW to do things - my way." Dictating a solution to an agent means getting your old solution, only slower. When Lex asks whether a non-programmer can be stronger at agentic development than a programmer, he answers without hesitation: one hundred percent. And explains [53:16]: "Many programmers are bad product managers. And software is product management."

There is systemic confirmation too. Claude Code developers told him that they CUT the system prompt for the new model by eighty percent: excessive human instructions were making the agent work worse [56:02]. Micromanagement harms even machines.

What remains for a person then? DHH's answer is specific: taste and acceptance. Compare three options and choose the best. Say where a solution is disproportionate to the task. And one phrase he calls mandatory [02:15:17]: "You really need to tell them: make it simpler." The mechanics of writing code atrophy. Engineering judgment - what to ask for, what to accept, what to simplify - becomes more valuable.

The most practical part of the episode. DHH's workflow, step by step:

Our project has been built by an agent machine for over a year, so we had something to compare every one of his points against. At times, the overlaps are word-for-word.

The split of "the smart one plans - the fast one executes" was written down as a rule for us long before this episode, in the same form. DHH's farm is made of mini PCs; for us, its role is played by parallel agent desktops on one machine. His "one email a day with twelve pull requests" is our report footer at the end of every run: the agent finishes work with a ready verdict breakdown, and the human only decides. Even a small detail matched: his instructions for agents live in one master file referenced by all the others - we use the same setup.

You can verify the scale in live numbers: on openness page you can see how a machine of dozens of agents builds this site day after day - at the time of writing, the uninterrupted streak counter was approaching ninety days, and agents made more than half the commits.

Where we are stricter than him. DHH allows himself honest vibecoding - never looking at utility code at all. We cannot: we have a production system with payments and other people's data, so every agent step goes through checks, tests, and review, while risky areas go through a human only. His story about Basecamp's ruined architecture explains why.

Where we disagree with him. He advocates vague tasks - "be as unspecific as possible" [57:20]. For code, it works: the agent really knows more about the solution's structure. But where a product has a voice and taste, a vague task produces generic, faceless text - here we maintain strict rulebooks and have no intention of loosening them. The difference is simple: the agent decides the form of the code, the human decides the product's taste.

And this article is proof itself. An execution agent proofread the episode's 54,000-word transcript and made a map of points with timestamps; a human designed the article and wrote the text; the draft went through machine acceptance with every quote checked against its timestamp. Exactly the pipeline DHH describes for five hours.

Calm news for everyone afraid of falling behind [01:23:22]: "Missed the last year - you can catch up with the frontier in two weeks. There is noaccumulated gap here." Tools change so quickly that someone else's year of experience loses value almost instantly - the starting line is the same for everyone.

He explicitly advises against planning a career years ahead [01:17:11]: "Don't try to predict anything. You'll go crazy - even the smartest people cannot see two model generations ahead." His advice is shorter: go where you are interested right now, and build.

The practical minimum for the first week comes from his own framework. Give an agent a real task, not a toy one. Ask a second agent to check the first one's work. Say "make it simpler" and see what changes. If you have been programming for a long time, watch yourself: are you dictating YOUR solution to the agent?

And the most unexpected admission from someone who loved code for twenty years [01:28:37]: "I went into programming not because I love conditional operators. I wanted programs. Now I am back" - over the last three months, computers have brought him more joy than ever before [01:31:30].

1. We date the turning point: since fall 2025, agents have learned not to advise, but to do - and to check themselves.

2. Vibecoding and agent-based development are not synonyms: the first is a "without looking" mode for a low cost of error, the second is a system with checks that works without you.

3. The mechanics of typing code are atrophying; task framing, taste, and acceptance are becoming more valuable. "Software is product management."

4. The working setup of the day: a smart model plans, a fast one executes, another reviews; asynchronously, in batches, with a human verdict at the end.

5. Missed a year - the frontier can be caught up with in two weeks. The best time to try is the coming weekend.