Post
DHH Went Agent-First — And That Should Make You Pay Attention
The creator of Ruby on Rails went from typing every line by hand to letting AI agents write his code. Here's why that matters more than you think.
Six months ago, David Heinemeier Hansson — DHH, the creator of Ruby on Rails — said he didn't use AI tools to write code. Typed everything by hand. All of it.
This week, he told Gergely Orosz on The Pragmatic Engineer that he's gone agent-first and barely writes any code himself anymore.
That's not just a workflow change. That's a tectonic shift from one of tech's most opinionated people. Let me explain why you should care even if you've never written a line of code in your life.
Who is this guy?
Quick context for the non-devs in the room. DHH created Ruby on Rails — the framework that powers Shopify, GitHub, Basecamp, and hundreds of thousands of other apps. He's been building software for over two decades. He's also famous for having extremely strong opinions about how software should be made and calling out trends he thinks are nonsense.
When someone like that changes their mind in six months, it's not because of marketing. Something real happened.
What actually changed
The shift wasn't gradual. DHH pinpoints it to when AI tools moved from autocomplete (suggesting the next few words) to agents (doing actual work autonomously).
Think of it like this: autocomplete is a GPS giving you turn-by-turn directions. An agent is a driver — you tell it where to go, it figures out the route, and it drives.
The models that changed his mind? Claude Opus 4.5 and Gemini. Not because they got a bit smarter, but because they started acting. Controlling terminals. Running tests. Searching documentation. Fixing their own mistakes. That's what pushed him over the edge.
His actual setup
Here's what DHH's screen looks like now:
| Left pane | Center | Right pane |
|---|---|---|
| Fast model (Gemini 2.5) | Neovim (editor) | Slow model (Claude Opus) |
| Quick tasks, exploration | Code review & edits | Complex, multi-step work |
Two AI models running in split terminals, with his editor in the middle. He reviews what they produce, gives guidance when asked, and merges the good stuff. His own description: he "promoted" the agents from assistants to contributors.
That's a powerful reframe. Not "AI helps me code faster." It's "AI is now a member of the team."
The honest parts
What I respect about DHH's take is what he doesn't claim.
He's not saying AI writes 90% of his code — he calls those numbers out as inflated. He's not saying it eliminates the need for expertise. And he specifically flags the uncomfortable truth: this amplifies senior engineers while creating real challenges for juniors.
If you're a veteran who knows what good code looks like, agents make you incredibly productive. You can review their output, catch mistakes, and guide them effectively. But if you're just starting out? You don't have the judgment yet to know when the agent is confidently wrong.
It's like giving someone a sous chef before they've learned to cook. Helpful in theory. Dangerous in practice.
Why "beautiful code" still matters
Here's a line from the interview that stuck with me: "When something is beautiful, it's likely to be correct."
That's not poetic fluff — it's a design philosophy. DHH argues that even when agents write the code, the human's role is to judge quality, taste, and correctness. Code that reads clearly and is structured well tends to have fewer bugs. That judgment can't be automated.
So the job doesn't disappear. It transforms. Less typing, more thinking. Less writing code, more reading and evaluating code.
The bigger signal
Here's my actual take: the specific tools or models don't matter that much. What matters is who is saying this.
DHH has spent his career pushing back on trends. He was skeptical of microservices when everyone was adopting them. He questioned TypeScript when it was becoming the default. He's not someone who jumps on bandwagons.
When the skeptics convert, it means the technology crossed a threshold. Not the hype threshold — the usefulness threshold. The moment where fighting the current takes more energy than swimming with it.
We saw this pattern before:
| Technology | Skeptic-to-convert moment | What it meant |
|---|---|---|
| Cloud computing | "It's just someone else's computer" → mass adoption | Infrastructure became a commodity |
| Mobile-first | "Real work happens on desktops" → responsive everything | Design priorities shifted permanently |
| Agent-first AI | "I type all my code by hand" → two agents on screen | We're here now |
What to do with this
If you're in tech — start pairing with agents. Not to replace your thinking, but to extend it. Find a tool that fits your workflow (Claude Code, Cursor, OpenCode — there are options). Give it a real task, not a toy example.
If you're not in tech — pay attention to the second-order effects. When senior engineers become 3-5x more productive, teams get smaller. When teams get smaller, companies move faster. When companies move faster... well, that affects everyone.
DHH called this moment comparable to "connecting computers to the internet in the '90s." I think that's dramatic — but I also think he might be right.
See you in the next one.