David Heinemeier Hansson built his reputation making programming more pleasant. The creator of Ruby on Rails now describes a working day in which much of the programming happens without him typing it—or inspecting every line.
Discussing Omarchy Quattro in his August 2026 interview with Lex Fridman, DHH said he had written none of its shipped code by hand. He reviewed its overall shape and critical model code, but said, “I’ve not looked at a bunch of the UI code.” (Interview, 00:15:14–00:16:44)
Much of software development’s progress has come from giving people larger units to think with. Coding agents let you delegate whole changes and judge what comes back. You still need to be able to investigate the code underneath.
Software tools give us larger units to think with
A programmer using a high-level language rarely specifies the machine instructions that execute a calculation. A developer using a web framework rarely implements every detail of routing, database access, and request handling. Libraries let a team use a capability without recreating its internals.
The programmer can describe a computation without arranging every machine instruction, or describe an application’s behavior through a framework’s conventions instead of assembling every part from scratch.
The layers coexist. Someone still writes the compiler, maintains the framework, and investigates the slow database query. Moving up makes it possible to work on a larger problem without holding every lower-level detail in active attention.
The ladder below describes where your attention goes. Its levels overlap; they do not rank programmers or form a strict technical hierarchy.
| Working level | Your main unit of thought | What you direct |
|---|---|---|
| Machine instructions | An operation | How the machine executes it |
| Programming languages | A function or algorithm | How the computation works |
| Libraries and frameworks | An application capability | How existing parts fit the behavior |
| Coding agents | A bounded change | The objective, constraints, and evidence of completion |
| Coordinated agent work | A set of related changes | Boundaries, dependencies, evaluation, and integration |
An agent can work across several of these levels. It may help investigate a business problem, propose a design, implement it, and run tests. Your working level depends on how much of that process you delegate and which decisions you keep.
A compiler translates a formal program according to defined rules. An agent interprets an incomplete request and makes choices that can be helpful, mistaken, or incompatible with the rest of the system. Check its understanding of the request as well as the code it produces.
The first move is from instructions to outcomes
Using AI to finish a line or generate a function leaves you planning the implementation and assembling the pieces. It can save effort without changing your working level very much. To move up, delegate a change with an observable result.
Consider a hypothetical customer export feature. At the function level, you ask for code that turns records into CSV. At the feature level, you ask for an export that preserves the user’s selected filters, handles a large result set, and remains within the application’s existing access rules.
You have to decide which columns belong in the file and whether it should reflect the data when the request starts or when processing finishes. You also need to specify what happens if the download fails.
These questions existed before agents. Delegating the implementation makes them harder to postpone behind the comforting activity of writing code.
The agent can help discover the questions and propose answers. You still need someone who understands the product to settle choices that affect its users.
DHH’s January 2026 account distinguished autonomous agents from autocomplete: he described reviewing completed work and providing guidance, while treating unsupervised professional coding as an aspiration. His later account describes a substantial change in his practice during the year; it does not establish the same result for every team. (Promoting AI agents)
Managing agents is a design problem
Once an agent can complete a bounded change, it is tempting to launch several and call yourself their manager. But a collection of busy agents does not necessarily produce a coherent application.
Return to the export. You could assign one agent the interface, another the background job, and a third the tests. If they invent different meanings for “export complete,” you have bought yourself an integration problem.
Before separating the work, settle the shared contract: what starts the job, how its status is represented, what the interface receives, and how failures appear. Give each agent a clear boundary and identify the changes that must happen in order. Keep one person responsible for the combined result.
Some work should stay with a single agent because the decisions are tightly connected. Other work, such as investigating an unfamiliar dependency or independently challenging a proposed design, can benefit from a separate perspective.
Anthropic’s June 2025 engineering report makes this distinction explicit. Its research system benefited from independent parallel exploration, while the authors cautioned that coding often has more shared context and dependencies. They reported roughly 15 times the token use of ordinary chats for their multi-agent systems. That is a research-workflow comparison, not a multiplier for software projects; it measures resource use without isolating coordination overhead. (Engineering report)
Your job is to divide work that can be separated, supply context, choose appropriate tool access, and ask for evidence that the pieces work together. Agent count follows from those decisions; it tells you little about their quality.
Looking at less code demands a better view of the system
How do you recognize a bad implementation if you stop reading it?
In the same interview, DHH recalled an earlier episode in which individually plausible AI-assisted changes collectively damaged an application’s architecture and required manual cleanup. He also said the models had since changed. The problem lay in how the changes fit together, even when each looked acceptable on its own. (Interview, 00:16:44)
An experienced engineer may recognize a suspicious dependency, a misplaced responsibility, or a data model that will make the next feature painful. Skipping some implementation details can be a choice informed by that knowledge. A newcomer copying the visible behavior does not automatically acquire the judgment behind it.
Reading every line does not guarantee a sound design either; humans miss defects and build incoherent systems. Choose the checks that give you evidence about this particular change.
For the export, that might include observed behavior with representative data, tests of access boundaries, a comparison with the previous interface, and inspection of how the job handles failures. An agent’s declaration that it finished is insufficient. Tests written around its own mistaken interpretation can all pass.
A correct download can still come from a second, divergent implementation of the application’s filtering rules. Ask where those rules now live, and inspect whether the export reuses them or duplicates them. That design choice affects whether a future filter change reaches both the screen and the download.
Jorge Manrubia, a programmer at 37signals, described a large agent-assisted refactoring in which much of his effort went into manually checking screens and returning visual defects for correction. Code review then needed little input. His account still warned against blind merging, and final QA was pending. (Oh my craft!)
How far to reduce direct code inspection depends on the consequence of failure, the maturity of the system, and the strength of the available checks. A small visual adjustment and a change to authorization logic justify different scrutiny.
Learn to climb, and learn to come back down
Joel Spolsky’s account of leaky abstractions explains why tools that hide complexity still require knowledge of what they hide. When the abstraction fails, the underlying behavior becomes relevant again. Agents add another place where that can happen. (The Law of Leaky Abstractions)
A sensible progression starts with a small change in a system you understand. Let the agent implement it, then compare its interpretation with your intended result. Notice which instructions mattered and which checks exposed mistakes.
Next, delegate a complete feature. Describe its behavior, identify existing conventions, and agree on the decisions that need your input. Ask for a demonstration and evidence that important existing behavior survived. Read more deeply where the evidence is weak or the consequences are substantial.
Only then experiment with dividing the work. Start with tasks whose boundaries you can explain. Compare completion time, correction effort, and integration problems with the single-agent approach. Keep the simpler arrangement when additional agents make the result harder to judge.
For someone new to programming, agents can make this learning unusually immediate: build a small thing, observe a failure, and trace it back through the system. Learn how data moves, how state changes, and how a test can be wrong. Have a capable engineer review consequential changes while that understanding develops.
Bret Victor’s Up and Down the Ladder of Abstraction describes the value of moving between broad patterns and concrete instances. Applied here, that means keeping a route from a feature request to observed behavior, from an unexpected result to a trace, and from that trace to the responsible code. (Victor’s essay)
DHH’s example challenges the idea that a programmer’s contribution must be proportional to the code they personally write or read. As delegation expands, more of that contribution can lie in choosing the problem, shaping the system, and establishing that it works.
On the next bounded feature, give the agent a result to achieve and decide how you will recognize success. Keep the means to investigate a failure. You may spend far less time writing code; keep the approach if it reduces effort without weakening your ability to change and maintain the result.
References
- David Heinemeier Hansson, Promoting AI agents, January 7, 2026.
- Lex Fridman Podcast #501, DHH interview transcript, August 26, 2026; especially 00:15:14–00:17:33.
- Jorge Manrubia, Oh my craft!, August 22, 2026.
- Anthropic, How we built our multi-agent research system, June 13, 2025.
- Joel Spolsky, The Law of Leaky Abstractions, November 11, 2002.
- Bret Victor, Up and Down the Ladder of Abstraction.