This week, the creator of Ruby on Rails stood on stage and announced that he had retired from programming.
Not retired from software. Not retired from building things. David Heinemeier Hansson seems to be building more software than perhaps any other point in his career.
He retired from writing the code himself.
“I have retired from being a professional programmer,” DHH told the audience in Austin. He estimated that the transition happened sometime around March. A few minutes earlier, he announced that 37signals had gone “pencils down” and said, “We’re done writing code by hand.”
There is an amusing symmetry to DHH’s argument.
Rails became popular in the first place because it let developers write less code.
He told the Rails World audience that he had written essentially no code by hand for roughly five months. Yet by his count, agents produced around 150,000 lines of code for him in August alone.
He even has a new favorite programming language.
“English is a better programming language than Ruby.”
So what are we doing now?
His preferred division of labor is increasingly straightforward: he decides what the software should do, agents implement it, and he evaluates the resulting system.
We routinely choose technologies based partly on human implementation cost. How many engineers know this language? How hard will hiring be? Can our existing team maintain six separate clients? Can we justify rewriting this service in something faster?
If agents dramatically reduce implementation cost, ALL of those calculations change.
That is why DHH’s keynote felt much bigger than another talk about AI coding tools.
He is questioning where programming fits into software engineering at all.
Linus Torvalds cut out the middle man
DHH is unusually enthusiastic about lot of his strong opinions, so it would be easy to dismiss the keynote as DHH being DHH.
Linus Torvalds is a more interesting counterexample.
In January, Torvalds published a small hobby project called AudioNoise. One of its components is a Python audio visualizer. Torvalds readily admits Python isn’t his area of expertise, so instead of doing what he normally would have done, Googling examples and piecing them together, he used Google’s Antigravity coding environment.
In the README, he described the visualizer as basically vibe-coded and joked that he had “cut out the middle-man, me.”
That is funny because the middle man in question is Linus Torvalds.
Creator of Linux.
Creator of Git.
One of the most accomplished systems programmers alive.
Torvalds isn’t making DHH’s stronger claim that hand-written programming is basically finished. His public position has been considerably more restrained. That actually makes his adoption more interesting.
By July, during a Linux kernel mailing-list discussion about AI-assisted contributions and AI code review, Torvalds was willing to draw a much firmer line:
“AI is a tool, just like other tools we use. And it’s clearly a useful one.”
He said Linux was not going to become an anti-AI project and argued that its use should be judged on technical merit.
The important skill Torvalds brought to that audio project was knowing enough about computers, audio, data and software to decide what he wanted, recognize whether the result worked, and intervene when necessary.
This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.
Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.
Mitchell Hashimoto started as a skeptic
There is another reason I don’t think this can be waved away as hype.
Mitchell Hashimoto, the creator of Vagrant and co-founder of HashiCorp, documented a much slower path to basically the same destination.
He initially found coding agents frustrating. So instead of immediately declaring them useless or magical, he ran an interesting experiment: he would implement something manually and then force an agent to reproduce the same result without seeing his solution.
Over time, he learned which tasks agents were good at, how to structure work for them, how to separate planning from execution, and how important automated verification was.
Eventually he started delegating tasks to agents while doing other work himself. Then he began deliberately improving his repositories so agents could operate more reliably.
Are you seeing the industry shift?
Programming was never software engineering
I think the identity crisis happening among developers right now comes partly from conflating two things that have always been different.
Programming is the act of expressing instructions to a computer.
Software engineering is the process of figuring out which instructions should exist.
A great software engineer has never merely converted Jira tickets into syntax.
You talk to people. You figure out what they actually need. You understand the existing system. You decide where a feature belongs. You think about the data model. You evaluate tradeoffs. You decide what deserves an abstraction and what doesn’t. You predict what will break. You consider security, performance, observability, reliability and operational cost. You reduce a messy real-world problem into something a computer can execute.
And yes, traditionally, you then spent an enormous amount of time manually translating those decisions into code.
That last step was so expensive that it came to dominate the profession.
We built interviews around it.
We built careers around it.
Many of us (myself included) built our identities around being unusually good at it.
So what now?
The job is moving up a level
For experienced software engineers, I think that suggests a pretty clear direction.
The highest-leverage skills increasingly look like:
Problem formulation. Turning vague product needs into precise problems that humans and agents can reason about.
Architecture. Knowing where responsibilities belong, defining boundaries, choosing data models and keeping the system conceptually coherent.
Verification. Great tests, evals, static analysis, observability, reproducible environments and fast feedback loops become dramatically more valuable when machines can generate changes continuously.
Harness and context engineering. Giving agents the documentation, tools, commands, constraints and feedback necessary to work effectively inside a real codebase.
Technical judgment. Knowing when an implementation is elegant, dangerous, unnecessarily complicated, operationally expensive or solving the wrong problem altogether.
None of those skills are new.
AI is changing their relative value.
An engineer who can manually implement a red-black tree from memory is impressive. An engineer who realizes the product doesn’t require a red-black tree at all might save the company three months.
That distinction existed before AI.
Now we can afford to care about it more.
DHH's own framing locates where the work moved: decide, implement, evaluate. He's cut the middle step, not the last one. I'd read Torvalds' more cautious "AI is a tool" line less as caution than as a sharper sense of what evaluation requires once agents generate at volume.
Duolingo's setup is a concrete version of that evaluate step: a risk-scoring bot approves only the lowest-risk 10% of changes without a human reviewer, cutting median time to merge from 18 hours to 12 across about 300 engineers, while changes to cloud infrastructure and repositories under SOX or ISO audit stay with a human. DHH's "I evaluate" and Duolingo's 10% boundary describe the same shift: oversight is being re-scoped to what can be checked at the volume agents now produce.