In July 2025 David Heinemeier Hansson, the creator of Ruby on Rails and better known as DHH, said that working with AI made him literally feel the skill of programming leaving his fingers. A year later he had almost stopped writing code by hand, had started running several agents at once, and announced from the Rails World stage:
Writing code by hand is no longer an economically viable skill for most programmers at most companies.
Changing your mind is fine, especially when the technology changes. In the case of DHH, though, the reversal itself is not the interesting part. The interesting part is why one developer’s personal experiment changes which tools other engineers begin to treat as acceptable. DHH created Ruby on Rails, Hotwire, and Kamal, builds Basecamp and HEY together with 37signals, and also launched the Linux distribution Omarchy. People follow his decisions far beyond the Rails community.
From “competence draining” to no hand written code
In an interview with Lex Fridman in July 2025 DHH said that he enjoys working with AI but keeps it in a separate window and never lets it drive his code. He put the reason emotionally:
I can literally feel competence draining out of my fingers.
He felt himself losing the skill once AI started writing the code. For DHH programming was never only a way to arrive at a working result. The process mattered on its own. That fit the philosophy of Ruby well: code should be correct, expressive, and pleasant for the person writing it. He did not deny the value of AI. He asked models questions, discussed decisions, and had unfamiliar constructs explained to him. The line ran roughly here: AI helps you program, but the programmer is still a person.
In that interview he compared programming to playing the guitar. You can watch lessons and study someone else’s technique, but the movements only appear after your own practice. In his view the same thing happens with code: part of the skill forms while a person types the constructs, makes mistakes, and fixes the result. Bash shows the position particularly well. DHH noticed that he kept asking AI to generate the same constructs again and again while remembering none of them. So he decided to learn the language and write the commands himself.
In January 2026 DHH wrote Promoting AI agents. He still disliked the way AI worked inside an editor: autocomplete kept intercepting a thought and trying to finish the code for him. An autonomous agent turned out to be a different tool. The developer describes a task, the agent works with the repository, runs the tests, and comes back with a result.
DHH no longer compared that process to an assistant grabbing the keyboard, but to a small team at work. Several agents can carry out tasks independently, and a person returns to them when a choice or a review is needed. For him this was a fundamentally different way of interacting, even though a model generates the code in both cases.
By then DHH was already calling agents capable of changing production code:
They’re fully capable of producing production-grade contributions…
The January position was still careful. DHH wrote separately that he gets no more than 90% of his code from agents and is not ready to give up control over quality and the integrity of the system. Over the following months that line moved noticeably further.
In August came the post Endless execution. The earlier caution had almost disappeared. DHH compared an agent to a little genie inside the computer that lets him test any idea, and called working with it the most exciting experience he has ever had at a computer.
In a new conversation with Lex Fridman he came back to the Bash example. He did learn the language, and then stopped using it, because agents had become good enough to take that work back:
I have not written any Bash myself for probably a couple months…
So over the course of a year:
2025: AI is useful, but I want to write the code myself -> I can feel the skill draining from my fingers -> so I deliberately learn Bash.
2026: agents got so good that I have not written Bash myself in months.
The technology changed enough that DHH revised not only how he works but also the criteria he uses to choose tools.
Rust, now written by an agent
In June 2024 DHH published Why I retired from the tech crusades. He wrote that there is no universally best language: functional programming suits some people, Go or JavaScript suits others, and he found his own language in Ruby.
He noted separately:
I wouldn’t be a happy camper if I had to spend my days programming Rust…
DHH did not deny the merits of Rust and praised the tools built with it. He simply did not want to spend his working days programming in that language. The position matched his long standing philosophy: a language is an interface between a person and a computer, so enjoying the work matters.
At Rails World 2026 DHH was already showing Rust code and describing the new architecture of HEY: the interface moves into native applications, and the server side of the mail service is being rewritten in Rust.
I love Rust! Rust is amazing…
And he immediately added the condition:
…if you never, ever, EVER have to look at it yourself.
He has not warmed to the language itself. Something else changed: an agent is now the one who writes that code.
Agents like Rust. Great! What a division of labor. I’ll tell you what to do. You’ll write it in Rust.
Choosing a language used to involve more than performance. A team also weighed how comfortable it is for people to write, read, and maintain the system. DHH proposes a different model: a person picks the architecture and reviews the critical parts, while syntax he finds unpleasant stays the machine’s problem. In that model some of a language’s traditional downsides start to weigh less. Verbosity, a strict compiler, and large amounts of ceremony do not bother an agent. The advantages of Rust remain: performance, control over memory, and compilation to a native binary.
DHH claims the new server side of HEY will need significantly less CPU and memory. Those numbers cannot be read as a comparison of Ruby and Rust under equal conditions. The architecture of the product changes along with the language: HEY is being rebuilt from a web application into a set of native clients with a separate mail server.
In the same talk DHH also defended Rails. The strict conventions of the framework help an agent understand the shape of a project faster, and the absence of boilerplate keeps the context small. Read that way, convention over configuration becomes an advantage not only for a person but also for a model. With dynamic typing the conclusion is less obvious. For a person, not having mandatory types allows faster movement from an idea to a result. For an agent, types can provide extra information and stop a share of the errors at compile time. So the talk does not imply that AI automatically strengthens every previous advantage of Ruby.
I quoted the line below in an earlier post but barely developed the thought. Here I want to say more about what stands behind it. The shift shows in the work of DHH himself. On stage he gave the numbers:
If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.
For someone who spent decades talking about the joy of programming in Ruby, that is a serious change. One of the main advantages of Ruby has always been developer productivity: expressive syntax, little boilerplate, and a short path from an idea to a working product. If an agent writes more and more of the code, that advantage does not disappear. Compact code and the conventions of Rails help a model find its way around a project. Rust and Go, meanwhile, keep static typing and the strengths that show up most in loaded services: efficient use of several cores and comparatively small overhead. Rust does without a garbage collector and allows more frugal and more predictable work with memory, while Go uses a concurrent GC with short stop the world pauses. MRI still has a GIL, and when CPU parallelism is needed you add instances, and infrastructure costs money.
The experiment raises a question broader than the usual argument about languages:
Does a developer need to love a language if an agent writes most of the code in it?
It is too early to say how far the approach will go. Even when an agent writes most of the code, someone still has to read it, debug it, and maintain it, especially when something breaks in production. But the plain fact that the creator of Rails is willing to choose a language he finds unpleasant to write shows how much AI is already changing the familiar trade-offs behind technology choices.
Why an opinion from DHH becomes an event
If an ordinary developer writes in a work chat that Cursor is making him dumber, and six months later announces that Cursor made him a hundred times faster, the industry barely notices.
With DHH it works differently. His name is attached not only to a framework but to a whole approach: convention over configuration, and a bet on a plain relational database for more than application data, the cache included. Rails spread those ideas along with the code. DHH knows how to turn a technical decision into a story people understand. That does not make the decision right. But it does make people look at it seriously. No developer can personally and deeply evaluate every language, framework, AI tool, and deployment method. You have to decide what is even worth your time.
When some developer has AI write Rust, it looks like a personal experiment. When the creator of Rails demonstrates the same model from the Rails World stage and applies it in his own product, the combination of a Rails developer, AI, and Rust carries a different weight. And at that moment you start to wonder whether there is something to it after all. You do not have to follow DHH, but the idea stops looking marginal, at least for a while, and turns into an option some people may use for their own problems.
Linux and TypeScript: other ways to influence
Something similar happened with Linux. DHH used Apple hardware for many years, then assembled Omakub, a ready made development environment on Ubuntu, and later moved to Arch Linux and Hyprland and created Omarchy.
In August 2025 37signals announced that it would gradually move its developers to Omarchy. In the post All-in on Omarchy at 37signals DHH explained the decision by control over the working system and access to its source code.
Arch Linux and Hyprland existed long before Omarchy. The contribution of DHH was different: he assembled familiar technologies into a finished product and gave it a name, a visual style, and a philosophy people could follow. After that a new audience started talking about the same tools.
The project Omarchy M for Apple Silicon does not mean DHH returned to macOS or fell in love with Apple again. He criticised the closed operating system before while acknowledging the quality and energy efficiency of the hardware. The new idea continues that same position: keep the Apple computer and replace the operating system.
With TypeScript the story is a little different. DHH had said before that he does not like static typing. But in 2023 he removed TypeScript from Turbo, and that started a noticeable argument inside the community about whether dropping static typing in JavaScript projects is justified at all. I disagree with DHH here. When a project develops on TypeScript for several years, habits form around it among the team and the contributors, and types, tools, and expectations appear with them. So the approach is hard for me to follow: first an ecosystem gets used to TypeScript, then the course turns sharply back to JavaScript. You could recall CoffeeScript, which Rails once promoted actively and then gradually moved away from. The situation was different, though: JavaScript itself had changed a great deal in the meantime, gaining classes, modules, and the other features of ES6 that CoffeeScript had often been used for. TypeScript in 2023 was in no comparable position and kept developing actively. So the argument that the JavaScript stack has been changed before does not fully work for me here. The question is rather why you would move a project toward TypeScript for several years if its main author never shared the idea of static typing in the first place.
That DHH was never a fan of TypeScript explains his position, but it does not fully explain why the project was led in that direction for years if the typing was going to be removed in the end.
Where his experience stops applying
Someone else’s experience saves you from testing every existing idea yourself. The trouble starts when two different statements collapse into one:
- DHH tried a technology and it worked well under his conditions;
- DHH uses a technology, so this is now the right way to develop software.
37signals works under specific conditions. The company has small teams, decades of experience with Rails, its own infrastructure culture, and products that the same people have been developing for years. A technical leader there can experiment constantly and make many architectural decisions himself.
Working with AI depends especially on the experience of the person checking the result. In the interview with Lex, DHH gives a good example: one agent carries out a task, another reviews it and finds the solution acceptable. But DHH sees that the code came out too complex, asks for it to be simplified, and gets a version nearly half as long. A similar problem came up in Basecamp 5. Designers used agents to prepare several dozen changes. Individually they looked fine, but together they started breaking the integrity of the system, and the team had to fix it by hand. Reviewing each pull request on its own is not enough: someone still has to watch where the architecture is going as a whole.
The model where AI writes and a person reviews means different processes for an experienced engineer and for a beginner. You can only review what you are able to judge. If a developer does not know what a good solution looks like, a large volume of automatically written code will not fix that. Even DHH did not hand agents the whole responsibility. In Omarchy he looked over the general structure of every change and read the critical code line by line. He genuinely did not study parts of the supporting code and the interface in detail, but that is a deliberate boundary, not the disappearance of review.
This is probably an obvious thing to write, but what works at 37signals does not automatically start working for everyone else. The company has its own products, its own teams, its own infrastructure, and people with different experience. At the same time I increasingly get the feeling that individual practices from 37signals are presented not as their local experience but almost as a universal direction for the whole industry. That is the part I disagree with. Someone else’s successful case is a good reason to look at an approach, not a reason to transfer it automatically into completely different conditions.
Why confident claims sell so well
DHH rarely phrases a thought as a careful set of conditions and exceptions. In his telling agents become magic, Linux gives you control over your own destiny, and writing code by hand (I like to call it crafted code) stops being economically justified. Phrasing like that is memorable and starts arguments better than moderate conclusions do.
The real limits of his position are usually more complicated than the headline. Working with Rust did not make the language more pleasant for DHH personally. Giving up hand written code does not mean he stopped looking at architecture. But an audience more often remembers the short categorical version.
In Why I retired from the tech crusades DHH examines this effect himself. In his younger years he tried to prove the universal superiority of his stack and long believed that the arguments were what made Rails win. Later he arrived at a different conclusion: developers were convinced by a demonstration in which a few minutes showed how quickly Rails lets you assemble an application.
He does the same with agents. The example works better than another post: DHH stopped writing Bash, uses agents for Omarchy, and lets them build parts of HEY in Rust. He does not only talk about a tool, he shows what he makes with it. That is why many people start looking at the idea differently after he speaks. The question of whether AI can be trusted with production code turns into how to organise review of the code agents write. Instead of asking why a Rails developer needs Rust, people ask which parts of a system can be handed to an agent in Rust.
New questions do not prove the answers from DHH are right. They show how far a personal experiment inside one company can travel before it produces a reaction across an industry.
The reversal itself is not necessarily a flaw either. If the tools really have changed, revising a position honestly is more useful than defending an old thesis for the sake of a consistent public image. The trouble starts when another opinion from a well known engineer is taken as the final answer for every team.
A quote without context means little
In this industry we look for bearings from people we trust, and that is normal. The problems start when the opinion of a respected engineer becomes an argument in its own right:
DHH said monoliths are better.
DHH is moving his developers to Linux.
DHH is throwing TypeScript out of Turbo.
DHH stopped writing code by hand.
DHH is starting to use Rust where he did not want to write it himself.
Authority on its own proves none of that. It is more useful to ask, every time:
- what problem the person was solving;
- what constraints they had;
- what alternatives they considered;
- what changed compared with their previous position;
- what risks they can afford;
- how similar their situation is to ours.
The story of DHH and AI shows why those questions are needed. In July 2025 his words could back an article about the need to write code yourself. In September 2026 the words of the same person can prove that programming by hand makes no economic sense. Both positions belong to one person, but they refer to different capabilities of the tools.
Reversals by well known engineers are useful not for the answers they hand over. They show what changed in the initial conditions. For DHH, an agent got a terminal, tests, and access to the repository. Along with that, DHH still has decades of experience, knowledge of his own systems, and the ability to spot a bad architecture in generated code. So asking whether DHH flip-flopped gives you little. It is more useful to ask: what changed in his conditions, and did the same thing happen in ours?