DHH Is Right. Now What?
DHH is right. The days of writing code by hand are over. Watch his Rails World 2026 keynote.
If you’ve made it this far, you might be upset. You may have already started writing a furious response. You may have even labeled me a Nazi. Let me save you the trouble. Womp womp. Cry more. I don’t care.
What I said is true, and nothing you can say will change that fact. If you haven’t accepted it yet, one of two things will happen.
- Once you finish the stages of grief, you will accept it.
- You will never accept it and will inevitably be left behind.
That is the easy part of this post. The hard part is what comes next. While writing code by hand is over, we are still figuring out how to work with agents. We are in a transitory state.
Model and agent capabilities are improving fast. Every week, your flavor of agent harness improves. Every few months, the models get more capable.
So what does the job look like when typing the code is no longer the hard part?
Right now, a lot of us treat agents like a faster pair of hands. Write a prompt. Get a diff. Skim it. Merge it. Repeat. It feels incredible until the agent produces more code than you can understand. Then you have a new problem. You are shipping a system you can no longer explain.
An agent will happily write a thousand lines for a problem that needed fifty. It will implement the requirement you forgot to question. It will write tests for the wrong behavior and give you a beautiful green checkmark. None of this is a reason to go back to typing code by hand. But it is a reason to get better at directing the machine.
And to do that, you need to be able to do two things:
- Define the problem (correctly!).
- Verify the outputs (correctly!).
You have to know what you are trying to build. You have to know why. You have to give the agent a way to see whether it worked. Run the software. Click the button. Read the output. Break the thing. Ask why. Understand why. If you cannot tell the difference between a working product and a convincing demo, more agents will just help you ship the wrong thing faster.
Lauren Tan’s guide to pstack gets at this. She treats verification as infrastructure. Give the agent a way to actually run the software, inspect the result, and try again. Make it prove the change works. Otherwise you are the one closing every loop, no matter how many agents you spin up.
This is not a new pattern in software. Every major abstraction has moved the work somewhere else.
The move from assembly to C, and from C to Python, changed what software engineers spent their time on. Agents move the work again. And the job was never just writing code. It was designing a solution, seeing where it fails, and making it better. That has not changed. You are an engineer now in every sense of the word.
The agent can do the manual part, but you have to be the architect. Decide what matters. Decide what is good enough. Say no when it builds the wrong thing beautifully. Human taste and judgment matter more than ever because you can’t bake soul into model weights.
The workflows we have now are temporary. The models will change. The harnesses will change. The tricks you learned last month will stop working or become unnecessary. We are going to have to keep rebuilding the way we work as the tools improve.
So do not get too attached to a workflow. Get better at the parts that survive it.
Know what you are trying to build. Know how to tell if it’s right. Know how to tell whether it works. Know why it works. Keep your taste. Develop your taste. Keep your judgment. Keep your understanding.
As Kache said: “you can outsource your thinking but you cannot outsource your understanding.”
And while handwriting code is over, engineering is not.