DHH’s Rails World keynote made me uncomfortable in a way I think is useful. I’ve spent more than a decade building Rails apps, and I’m not ready to treat the part of the job I love as an obsolete hobby.
But I don’t want that discomfort to become a business plan. I want to know what changed, what hasn’t, and what a developer like me can offer when agents do more of the typing.
What I took from the keynote
At 20:45 in the talk, DHH explains 37signals’ new “pencils down” policy: writing code by hand is now an exception to its normal workflow, not forbidden. If an agent can’t handle a task, the team can do it manually and improve the workflow afterward. That’s a radical choice for one company, not an instruction that every developer has to follow tomorrow.
The detail I can’t shake is his Basecamp 5 story. Designers brought in dozens of agent-generated pull requests that looked reasonable separately but left the architecture looking like “Swiss cheese” together. The team returned to more programmer-led work at the time; DHH now thinks better agents and better workflows are the way forward. He doesn’t show an agent-led repair of that particular problem. To me, the lesson is that a collection of plausible diffs is not the same thing as a coherent system.
And no, this wasn’t a eulogy for Rails. DHH describes an in-progress native-client and Rust-backend direction for HEY, then argues that the web still matters and Rails’ conventions help agents. I don’t need Ruby to win every use case to keep finding it useful for the work it’s good at.
The part I resist
In May I wrote about what coding is starting to lose after a model helped me fix a background-job race condition in twelve minutes. The tests passed. I still missed the slow process of learning why the bug happened. That’s not just nostalgia if I’m the person who has to understand the next failure.
I’m happy to let an agent draft the tedious parts, suggest an approach, or explore an alternative I wouldn’t have had time to try. I don’t believe writing a small, tricky section myself when I need the mental model is a failure. Nor do I believe hand-typing boilerplate is a virtue. The useful question is: what will help me understand and safely maintain this particular system?
The big numbers deserve the same care. DHH’s 100-to-1,000-times comparison is a conjecture about the best aided programmer versus the worst unaided one, not a measured speedup for an average team. He argues that handwriting code is already uneconomical for most programmers and companies, and predicts virtually all domains will follow by the end of 2026. That’s his economic bet, not a measured deadline on my career.
He cites nearly 95% success on an earlier, simpler Rails agent test. The harder feature-ticket slide in the keynote tops out at 35% at the effort shown. In a maximum-effort evaluation, the best model passed 53% of runs on that set of 20 tickets, at additional time and cost. That’s real progress, not a production reliability rate or a reason to skip review.
What I think happens to my career
Some work will need fewer developer hours. Companies may hire differently, and easier prototyping means more people can compete to build the same thing. DHH reaches for a bank-teller analogy to suggest automation can create new demand. I get the point, but his historical dates and counts don’t match the available reporting, and an analogy can’t forecast Rails hiring. It would be dishonest to promise that every existing role is safe. It would be just as dishonest to infer from a keynote that no one will need software engineers.
I’ve written Ruby for more than fifteen years and built Rails apps for over a decade. That experience isn’t a moat around typing Ruby. It helps me recognize where a simple change stops being simple. In my Sidekiq-to-Solid Queue migration guide, the adapter switch is easy to describe; draining old and scheduled jobs safely is the real work. An agent can help with the change, but a green diff alone doesn’t tell you what is still sitting in the old queue.
I want to turn vague requests into clear constraints, give agents bounded tasks, and spend the time they save on tests, data boundaries, security, deployment and rollback. Sometimes that means writing code myself. Always it means knowing what we asked for, what we got, and what customers will experience.
DHH also imagines apps with CLIs that users’ own agents can operate. That’s an interesting direction, and a practical question about who gets permission to do what.
A quick review exercise
Would you ship it?
Make the call before opening each answer. This is the work behind a green diff.
An agent swaps Sidekiq for Solid Queue. Tests pass. Shut off the old workers in the same deploy?
Not yet. First account for queued, scheduled and retrying jobs in Sidekiq; run both systems while new work moves over, watch the old queues drain, and plan for duplicates and rollback. A passing test suite can't tell you that Redis is empty.
A new app CLI lets an agent investigate a customer issue. Give it a production API key to move faster?
Not an unrestricted one. Start with scoped, auditable commands. Don't expose broad credentials to the agent's prompts, environment or tools; limit its network access and grant only what's needed. Test what untrusted customer data can make it do, and require a human decision for irreversible actions. A working tool is not automatically a safe one.
I can be a little resistant to the idea of putting my pencil down. I can also see the opportunity: Rails conventions, hard-won debugging instincts and a willingness to use new tools are a useful combination. The goal isn’t to defend every line I would have written. It’s to help a team ship software it can trust.