DHH Argued Developers Should Keep AI Out of Their Editor. Here's Where He's Right and Where He Isn't.
In this article
Bottom line: David Heinemeier Hansson, the creator of Ruby on Rails, argued publicly in 2025 that developers who hand their editor to an AI agent and stop typing code lose the skill needed to judge that code.
His alternative was to use AI as a tutor in a separate window while your own hands stay on the keys.
The evidence is mixed but real: METR's 2025 study found experienced developers were 19% slower with AI tools while believing they were 20% faster.
The practical fix is to decide in advance which work you delegate and which you keep.
I paid for the confidence of an agent that could refactor my whole codebase in one prompt, and I paid for it with the one thing I couldn't get back.
Three weeks ago I opened a service I "wrote" in the spring and couldn't explain how its retry logic worked. Nobody else had touched it. I had reviewed every diff, and I still couldn't explain it.
That's the context in which I revisited the DHH clip that keeps getting passed around, which dates to his mid-2025 interviews. I'll be upfront about what I'm doing here.
I'm not going to fabricate a transcript or invent quotes. I'm going to describe the position DHH laid out in 2025, which I'm confident about, and argue with it using my own production scars.
What DHH Is Actually Saying
His stance, as he laid it out in interviews and on his blog, isn't "AI is useless." He's a heavy user.
What he objected to in mid-2025, including in his July 2025 Lex Fridman interview, was the agent-driven, hands-off workflow, where the model writes into your files while you supervise.
He described keeping AI in a separate window, asking it questions, and typing the code himself.
Treat this as his 2025 stance; his views on these tools may have shifted since, so check his recent posts before quoting him as current.
His reasoning is about craft. Programming, to him, is a skill you maintain by doing it. If you stop typing, you stop noticing, and eventually you're a reviewer of code you couldn't have written.
That's the part that made people angry. The replies split into two camps: "old man yells at cloud" and "finally, someone said it." I think both camps are partly wrong, and the interesting part is why.
Why the Furious Half Has a Point
The angriest responses come from developers who ship faster with agents, and that experience is real. I use Claude in Cursor most days.
It generates migrations, test scaffolding and boring glue code faster than I can open the docs.
If DHH's rule were "never let AI write code," it would be nonsense for a lot of work. Nobody's craft is improved by hand-typing the fortieth CRUD endpoint.
His own framework is famous for eliminating exactly that kind of ceremony.
There's also a survivorship problem in the "type it yourself" argument. DHH has decades of muscle memory, so he can afford to slow down.
A developer two years in doesn't have the same stockpile, and telling them to reject the tools reads as gatekeeping from someone who already won.
Why the Skeptics Have a Point Too
Here's the uncomfortable data. In mid-2025, METR ran a randomized trial with experienced open-source developers working on their own repositories.
They were 19% slower with AI tools, yet they believed they'd been about 20% faster. That perception gap is the whole story.
That study was narrow. It covered experienced developers on mature codebases with the tools of that moment, and models have improved since.
But the mechanism it points at hasn't gone away: AI makes work feel fast because the typing disappears, while the cost moves into reviewing, correcting and re-prompting.
My own version of this showed up in that retry logic. The agent wrote something plausible. I read it, nodded, and merged.
Reading code isn't the same as building a model of it, and I'd skipped the building.
If you want the workflow-level version of this trap, I wrote about it in Vibe Coder Productivity Goals. Speed metrics that count output rather than understanding will reward exactly the wrong behavior.
The Framework: Delegate, Keep, Interrogate
Neither camp offers a rule you can apply on Monday. Here's the one I now use. It's three buckets, and I decide the bucket before I open the chat window.
Delegate
Work where being wrong is cheap and obvious. Boilerplate, config files, test fixtures, format conversions and one-off scripts belong here.
If it breaks, it breaks loudly, and I lose nothing by not knowing the details.
Keep
Work where understanding is the product. Core domain logic, concurrency, auth flows, anything involving money or data deletion, and the first version of any architecture I'll live with for years.
I type these myself, even when the model could do it faster. This is the piece of DHH's argument I've adopted wholesale.
Interrogate
Everything in between. Here I use AI the way DHH describes, as a tutor and reviewer, not an author. I write the code, then ask Claude to attack it: "What input breaks this?
What did I assume about ordering?" I also ask ChatGPT to explain unfamiliar library behavior rather than paste a solution.
The rule underneath all three: if I couldn't rewrite it from memory in a week, it doesn't ship without a written explanation of how it works. That one sentence caught more bad merges than any linter.
The Reality Check
DHH's position has real weak spots, and pretending otherwise would be dishonest. "Type it yourself" doesn't scale to a team under deadline pressure.
It also depends on the assumption that the skill you're preserving is still the scarce one.
If models keep improving, the valuable skill may shift toward specification, verification and taste, and away from syntax fluency. That's plausible.
I just don't think you get good at verification without first having built things by hand, which is the point his critics keep sliding past.
The other weak spot is that anecdote is doing a lot of work on both sides. His experience and mine are single data points. The METR result is one study on one population.
Anyone giving you a confident universal rule, in either direction, is selling something.
What I'd Do This Week
You don't need to pick a side in this fight. You need a cheap test that tells you whether your own workflow is eroding something.
1. Pick one module you "wrote" with an agent last month. Close the editor and explain it aloud, or on paper. Where you stall is where your understanding stopped.
2. Set a keep list for your team. Write down the three areas of your codebase where humans author the first draft. Review the list quarterly.
3. Move one AI habit into a side window. For a week, ask questions instead of accepting edits, and notice whether you feel slower or just more aware.
4. Track your own perception gap. Estimate how long a task will take with AI, then time it. The METR result says most of us are miscalibrated, and you should find out by how much.
I still use agents daily. I just no longer confuse "the diff looks right" with "I know how this works." That distinction cost me an embarrassing afternoon, and I'd rather it cost you nothing.
Where This Leaves Us
DHH isn't really telling you to stop using AI. He's telling you to stop outsourcing the part of programming that makes you able to tell when the AI is wrong.
Whether you find that inspiring or insufferable probably depends on how long you've been doing this.
So here's what I'd like to know. Is there a piece of your own code you've merged from an agent that you honestly couldn't explain today, and did you go back and fix that, or leave it alone?
