From Handwritten Code to the Malleable Computer: DHH's Vision for the Agentic Era

DHH stopped writing most of his own code

DHH created Ruby on Rails and is the CTO of 37signals. For two decades, hand-written code was close to his signature. In his second long conversation with Lex Fridman, he says agents wrote most of the Linux system he recently built.

Coming from him, that lands strangely. He did not arrive there by buying the marketing, though. Code completion tools and chatbots left him cold. What changed his mind was a system that could read code, run commands, edit files, run tests, and then go back and check its own work. At that point the computer stopped waiting for the next instruction and started behaving like a small team that could roll up its sleeves.

From carving tool to director

DHH describes the change with an image. He used to stand at a workbench with a carving tool, one problem at a time. Now he hands a dozen tasks to different actors, watches the rehearsals, changes the direction, and picks the version that works.

That is the difference between an agent and a chatbot. An agent takes a longer path. It looks things up, changes code, runs tests, and backtracks when it realizes it went down the wrong road. You can split work across several of them at once.

He thinks the turning point was not a model gaining points on a leaderboard. It was the moment models and tools clicked together, so AI could use the computer and check its own output.

Omarchy is where this shows up in his own work. It is a Linux system with a strong point of view, and DHH says most features in its latest version were built by agents. His job was the shape of the thing. Should this feature exist? What feels too complicated? Is the critical part reliable? He still reads code. He has stopped spreading his attention evenly across every line of it.

Where the bottleneck actually sits

The line I keep coming back to:

AI may not make programmers disappear, but it is making code-writing less central to programming. What becomes scarce instead is the ability to find problems worth solving, define what a good result looks like, judge different approaches, and take responsibility for the system that ships.

Getting the code written used to be one of the hard parts. That part is getting cheap, cheap enough that one person can build what used to need a team.

So why hasn't AI made large companies ship ten times faster? DHH's answer is that implementation was rarely the constraint. Communication was. A product manager writes the requirements. A designer explains them again. An engineer turns them into a technical plan. Then managers and committees wait to bless it. Every handoff adds translation and delay, and a project with a few days of actual coding in it can absorb months.

AI compresses the building part. It cannot decide what a company should build, and it cannot give a team taste.

What stays scarce is more human: spotting a problem worth solving, explaining what good means, choosing among options that are all technically possible, and owning the result. If those don't grow alongside our capacity to implement, we will produce useless software faster than before.

Open source gets more open and more noisy

DHH is upbeat about agents entering open source. The scenario he imagines is small. You build a tool for yourself, get it into a shape you like, then ask an agent to write the README, cut releases, handle issues, and put it on GitHub. Ideas that used to stay in someone's head get a path to other people.

Lower barriers also mean more noise. Maintainers may start receiving floods of AI-assisted pull requests, some thoughtful, some repetitive, some that should never be merged.

His view is that maintainers matter more under those conditions. Someone still has to hold the quality bar, decide where the architecture goes, and judge whether a change fits the character of the project. Agents can test and filter duplicates. The merge decision belongs to whoever will live with it.

He goes further and says agents have produced designs and implementations that surprised him, some better than what he had in mind. If that holds, agents do more than let more people contribute code. Ideas that would never have surfaced get a chance to be seen. A new idea is not automatically a good one, and an agent's inventiveness does not mean it understands the project. Turning a messy field of possibilities into something usable for years is still someone's job.

Why Linux

DHH thinks Linux may become the natural desktop for the agent era, and might finally have a real shot at winning the desktop.

That reads backwards at first. Config files, the command line, cryptic error messages, endless tinkering: these are the things that have frustrated Linux users for years. But a barrier for a person can be an entry point for an agent.

Most of Linux is out in the open. Configuration is readable, commands are callable, error messages tend to be specific. When an agent hits trouble it can follow logs, inspect config, read source, and try a fix, instead of spending an afternoon guessing which hidden setting a normal user was supposed to find. The parts of Linux that felt unfriendly may be exactly what makes it useful here, while the polish and restriction that made macOS and Windows comfortable start to look like walls once you want to change your computer.

He is not predicting Linux everywhere tomorrow. Adobe software, games, hardware drivers, enterprise support, and security constraints do not disappear because AI showed up, and Lex admitting he still depends on his video editing software is a practical reminder of that. The careful version of the claim: Linux may be the most competitive desktop foundation of this era for people who want to own their computer and keep changing it.

That is where "malleable computer" gets interesting. The computer stops being a finished object you buy and learn to tolerate, and becomes material you keep working on. If you dislike the calendar, the window manager, the keyboard shortcuts, or a basic system feature, you ask an agent for another version. Omarchy demonstrates that way of living with a machine. I don't want to wait for a large company to consider my particular need in its next release.

What the job becomes

Lex and DHH talk about "vibe coding," roughly meaning you tell AI what you want and don't care much how it works underneath. DHH separates that from someone who understands the system and keeps checking the result.

That doesn't mean you owe the craft ten years before you're allowed to make software. You may never hand-write another loop or data structure. You will still have to ask what problem you are solving, whether the result is what you wanted, whether the system is getting tangled, and who notices when it breaks.

DHH makes a point I find slightly uncomfortable. Some programmers are so used to the old way that they tell AI too early how it should do the work. Someone who understands the user's pain and holds no attachment to a coding style may give an agent more room to find a better answer.

Experience still matters, but its job changes. It doesn't always have to compress into precise instructions. It can stay a feeling that this approach is off, this is too complicated, this feature doesn't belong with the rest of the product. The role starts to resemble an editor or a demanding producer. The machine can make the thing. Knowing which versions to keep is still yours.

The cost of running ten agents at once

DHH is obsessed with speed. He keeps asking agents to shave seconds off Omarchy's install time, because "fast enough" is not a satisfying answer when many limits we treat as facts are just habits nobody questioned.

I find that charming and a little dangerous.

You used to be able to sink into one problem. Now ten agents run at once and you switch between them: continue this, redo that, approve the other. Output rises while attention gets chopped into smaller pieces.

DHH admits the state is exhilarating and doubts it can last. He expects agents to review each other, run tests automatically, and report asynchronously, so a person makes a batch of decisions once a day instead of sitting beside them all day.

It is also why lines of code measure nothing. An agent producing hundreds of lines in an hour tells you nothing about whether the product improved, whether anyone benefited, or whether the system got more reliable.

What this means for A2Agent

The question worth asking is what an agent platform is supposed to be. Today it is a window where a user asks and a model replies. What we want is a place where people and agents work together:

• The user gives a goal and its background instead of a checklist of manual steps.
• The system remembers project knowledge, user preferences, and earlier decisions.
• A task can be split across several agents that check each other's work.
• The human gets called back for real judgment calls instead of confirming something every few seconds.
• The user can ask an agent to build new tools, panels, and workflows for them.

The edge won't come from having the smartest model. It will come from how well the platform connects models, tools, context, and human judgment into a way of working that holds together. If computers are becoming malleable, agent platforms should be too, and they should let each person build up a workflow that feels like theirs instead of forcing everyone through one fixed path.

What I take from it

DHH's optimism gets close to fanaticism at times. He changed how he works, though, and that convinces me more than any of his predictions about which model wins. He didn't pretend the world would hold still because he loved handwritten code, and he didn't decide humans stopped mattering because AI can do more.

I won't claim Linux becomes everyone's default desktop, or that today's agents are anything close to their final form. The part that is hard to miss is the change in what we ask. We used to ask whether you could write code. We are starting to ask whether you know what should be built, whether you can tell if the result is any good, and whether you will own it when it breaks.

References

• Lex Fridman Podcast #501: Transcript of the DHH interview
• Main episode page

This article draws primarily on the transcript above. The original page notes the transcript was human-generated and may contain errors. Claims about Omarchy, model capabilities, and the future of Linux on the desktop are DHH's own experiences and judgments, not independently verified industry data.