DHH says agents wrote Omarchy Quattro, while Basecamp exposed their limits

Why it matters

Hansson's reversal gives the AI coding debate a concrete test: he says agents handled Quattro's implementation, while a mature 37signals codebase still required human architectural control.

David Heinemeier Hansson (@dhh), creator of the Omarchy Arch Linux-based desktop distribution, told Lex Fridman that AI agents wrote all the code shipped in Omarchy 4. It is a sharp reversal for the programmer who spent two decades preaching the value of carefully handcrafted software.

In the five-hour conversation posted August 26, Hansson described Omarchy Quattro, released around August 21 according to the interview, as the point when AI agents stopped serving as assistants and took over most implementation. Hansson said he still directed the product, inspected its overall structure and reviewed critical sections, though he wrote none of Quattro's shipped code by hand.

That claim carries unusual weight coming from the creator of Ruby on Rails. Hansson developed Rails while working on Basecamp and released the framework as open source in 2004. 37signals' official REWORK podcast page identifies Hansson as its CTO and co-founder.

Hansson started Omarchy in the summer of 2025 between sessions at the 24 Hours of Le Mans, after watching what he described as one too many videos about customizing Linux desktops. Omarchy followed Omakub, his earlier attempt to turn Ubuntu into a ready-made developer workstation. Hansson moved deeper into the stack with an Arch Linux distribution built around Hyprland.

A convert with a test case

Hansson dates his change of mind to November 24th, 2025, when he says a new generation of coding models and agent harnesses began producing work close to what he would have written himself. The importance of that date is personal rather than scientific: it marks when a programmer previously unimpressed by autocomplete began trusting agents with complete tasks.

Official Quattro materials describe a unified Quickshell-based shell, dual-boot support, faster installation and expanded customization. Hansson's interview presents the release as heavily built through agents. The release materials also describe visual theme tools and other changes intended to make Omarchy more customizable.

Hansson told Fridman that agents handled effectively all implementation during Quattro's final two months. His role moved toward specifying problems, choosing among proposed solutions and judging whether the result felt coherent. That is a meaningful distinction from the common pitch that AI merely helps developers type faster. Hansson is testing whether one experienced product builder can direct far more software production while moving away from the code itself.

Hansson told Fridman that Quattro had been downloaded by tens of thousands of people shortly after launch. That is his count rather than an independently measured active-user figure, but it shows the experiment has reached beyond Hansson's own workstation.

Basecamp found the limit

Hansson's experience inside 37signals offers the necessary counterweight. During the final development sprint for Basecamp 5, 37signals allowed designers to use agents to implement features directly. Hansson said the resulting pull requests could appear reasonable in isolation while collectively damaging the product's architecture. Human programmers had to clean up the code.

That failure separates greenfield agent work from changes to a mature system. An agent can produce functioning code without understanding the years of accumulated decisions that make a large application maintainable. Hansson said experienced programmers were still required when 37signals wanted to preserve the architecture of its existing products.

Hansson's current position is therefore narrower than his rhetoric about the end of manual programming can sound. His account of Quattro shows extensive agent use under an experienced product builder. Their performance inside established commercial systems remains uneven, even at 37signals.

Programming becomes a management problem

Hansson distinguishes his process from "vibe coding," which he defines as asking an agent to build software without examining the implementation. His preferred workflow still depends on technical judgment. He directs the work, reviews critical code and decides which proposed design belongs in the product.

That makes prior programming experience valuable in a different place. Knowledge of architecture, security and system behavior becomes a way to frame assignments and spot failures rather than a requirement to type every function. Hansson argues that programmers attached mainly to the mechanical act of constructing code face the most pressure. People motivated by building products gain cheaper access to implementation.

The labor-market conclusion remains a forecast. Omarchy demonstrates what one highly experienced programmer says he can produce with agents; it does not establish how typical teams, junior developers or safety-critical systems will perform under the same arrangement.

Omarchy is building the environment around the agents

Hansson's larger bet is that an operating system should be designed for software that can modify the computer on its user's behalf. Quattro includes agent instructions for creating plugins and diagnosing crashes, moving AI access closer to the operating system itself.

That convenience creates a wider security boundary. Omarchy's security documentation offers a passwordless sudo mode for long-running agent tasks and warns that anything running under the user's account can obtain root privileges while the setting is enabled.

In the Fridman interview, Hansson argued that the economic payoff from manually perfecting code is diminishing as agents perform more modifications, while coherent architecture remains valuable. Basecamp shows why his answer remains incomplete.