Editor: Jiang Pian
DHH: "I have not written... any of the code."
DHH: The code shipped to Quattro—not a single line was written by my own hands.
The person who said this is David Heinemeier Hansson, the father of Ruby on Rails, known to developers as DHH.
Note: David Heinemeier Hansson, commonly known as DHH, is the founder of Ruby on Rails, co-founder and CTO of 37signals. Rails was initially born during the development of Basecamp and has since been adopted by many internet products like GitHub, Shopify, and Airbnb.
A year ago, DHH didn't like AI code completion and didn't want to embed a chat box into his editor. But in a recently released Lex Fridman interview, he gave a completely different answer: All new code for Omarchy Quattro over the past two months has been entirely handled by agents.
He then recounted an experience: A group of designers used AI to submit a large number of pull requests. Individually, each change made sense; but together, they broke the system architecture.
As code generation becomes cheaper, developers' problems haven't decreased. They've simply shifted from "how to write it" to "who decides, who reviews, and who is responsible for the whole."
The following content is translated and organized from Lex Fridman's interview with DHH.
DHH talks about agents handling all coding
13 Months: From Rejecting AI to 'Or 100'
Lex noted that the percentage of AI-written code has climbed from 5% to 20% and now to 80%. DHH quickly added:
DHH: "Or 100."
DHH: Or 100 percent.
This is not an offhand exaggeration.
DHH recalls that his AI programming experience 13 months ago didn't interest him. Autocomplete interrupted his thinking, and the chat box required constantly carrying context. The model could help, but it still felt like an assistant that needed constant supervision.
Agents changed this interaction.
Now, he hands over the problem and a rough direction. The agent reads the repository, finds relevant files, proposes solutions, modifies code, runs tests, and brings back results. When DHH describes this change in the interview, the emphasis isn't on how many syntaxes the model can write, but that it started taking over complete tasks.
In the past, he had to first think through "how to implement" before having the tool fill in a few lines. Now, the agent tells him where he's heading.
DHH says agents can go to 100%
Two Months Without Writing Code by Hand—What Is He Still Reviewing Line by Line?
Omarchy Quattro is the project DHH has invested the most in recently. He says none of the code shipped in the past two months was hand-typed by him.
This doesn't mean programmers don't need to write code.
DHH hasn't stepped away from development. He reviews the overall shape of all changes, and for parts involving the model layer and critical business logic, he still checks line by line. Routine code can be left to agents, but architectural direction, data constraints, and key boundaries are not delegated.
His workspace has changed accordingly. Neovim is no longer primarily for hand-writing code but for browsing the project, reviewing diffs, and verifying what agents did.
DHH's approach can be summarized in one sentence: Implementation can be delegated, but judgment cannot.
For ordinary teams, this boundary is more practical than "how much code AI can write." If database models, permissions, billing, concurrency, or data migrations go wrong, passing tests doesn't guarantee the change can ship. Agents can provide implementations, but humans still need to know where it's worth reviewing line by line.
Every PR Makes Sense, Yet the System Was Broken
The most cautionary case in the interview comes from Basecamp 5.
After the design team started using Vibe Coding, the pace of PR submissions increased significantly. Each PR individually could explain why it was reasonable; the problem is that these changes lack a shared architectural constraint.
DHH: Together, these changes destroyed the system architecture.
DHH talks about Vibe Coding breaking architecture
AI coding easily creates this illusion: local tasks complete quickly, but overall technical debt accumulates in the background.
One agent modifies login, another modifies caching, and yet another abstracts common components. The three tasks passing tests doesn't mean they follow the same boundaries. Duplicate logic, hidden dependencies, and style fragmentation often only surface in later iterations.
DHH doesn't dismiss Vibe Coding because of this. His solution is very engineering-driven: let more people gain implementation ability while moving architecture review earlier.
In the past, architecture issues were often found in code review. With concurrent agent work, waiting until all PRs are generated is too late. When splitting tasks, you need to specify which modules cannot be touched, which abstractions must be reused, how data flows, and who coordinates between changes.
Running 16 Agent Threads Simultaneously—Developer as Chief Dispatcher
DHH: I initially used tmux to manage parallel agents, but then got tired of switching windows and waiting for notifications, so I built Herdr. It connects tmux sessions and notifications: when an agent needs confirmation, completes a task, or hits an error, it notifies me.
His daily scale has reached 4 to 5 machines running about 16 agent threads simultaneously.
DHH talks about running 16 agent threads at the same time
This workflow looks great, but new bottlenecks quickly appear.
When 16 agents produce results simultaneously, a human can't supervise each in real time. Developers must first judge which tasks can run in parallel, which changes touch the same code, and which results must wait for a previous task to finish.
Concurrent agents are best for tasks with independent boundaries: dependency upgrades, adding tests, generating migration scripts, cleaning duplicate code, investigating different bugs. For work involving the same state or architecture, the more threads you open, the harder conflicts are to manage.
Managing agents can't just rely on 'complete' notifications. Each task must bring back at least four things: change summary, test results, risk points, and rollback plan. If any is missing, a human has to dive back into the repository for context.
Stop Comparing Who Writes More—Lines of Code No Longer Matter
Agents can generate tens of thousands of lines of code a day. Continuing to evaluate engineers by code volume only encourages more ineffective changes.
DHH: "Lines of code is a stupid metric."
DHH: Lines of code is a stupid metric.
DHH talks about lines of code losing meaning
DHH then brought the evaluation criteria back to the product: Don't ask how many lines were written; ask what was accomplished.
For development teams, this means performance reviews and project dashboards need new criteria.
An agent generating 5,000 lines of code that doesn't improve user experience or reduce failure rates only increases maintenance costs. Another engineer deleting 300 lines of old logic and doubling release speed is more valuable.
Better metrics include: whether the problem is solved, whether changes are maintainable, whether production metrics improve, whether incident rates drop, and whether delivery cycles shorten. Code is the material for achieving these results, not the result itself.
Mechanical Coding Is Threatened—Product Builders Still Have a Chance
DHH didn't dodge the employment question. If he had to find a new job tomorrow, he thinks it would be hard to earn the kind of compensation he did from "hand-writing code." He's done that work for 25 years, and now models can handle more and more of its mechanical parts.
DHH: "The mechanical process is under threat."
DHH: The mechanical process of coding is under threat.
DHH talks about mechanical coding being threatened
But he splits "liking programming" into two things.
If someone enjoys hand-typing syntax, memorizing APIs, and personally completing every implementation detail, the coming changes will be hard to adapt to. If you truly love building things, solving problems, and seeing products come to life, agents actually make that happen faster.
DHH himself is an example. He loved coding early on because code made programs appear. Later, large projects, long cycles, and maintenance work diluted that immediate feedback. AI gave him back the feeling of building things quickly.
Developers' value won't disappear, but it will move upstream in tasks and downstream in outcomes: upfront to define problems, choose solutions, and set constraints; later to review results, handle failures, and maintain systems.
Final Thoughts
DHH's transformation is very representative.
A year ago, he disliked AI autocomplete; now, he can let agents handle all new coding while managing over a dozen parallel threads. But he hasn't left software to model autonomy—he's put more effort into architecture, review, and outcomes.
Hand-writing code isn't at zero yet. You still need to understand code and review critical logic. But as implementation speed suddenly increases, the developer's challenge has shifted: how to clearly define problems, how to get multiple agents to work within the same architecture, and how to catch changes that are 'each reasonable but dangerous together' before shipping.
Agents can finish writing the code. But someone still needs to be responsible for what the system ultimately becomes.
Reference link: