AI Removes the Constraint
AI-accelerated development makes most software worse by default, not because agents build badly but because they dissolve the scarcity of build-hours that used to ration scope automatically.
The two-step argument
At 37signals, the software stayed simple because building anything was expensive: the first version of Basecamp shipped in 380 hours, and out of the hundred things customers were asking for, the team could build three, so it had to select carefully. The selection happened because it was forced, not because anyone involved was especially disciplined. The claim built on that fact is easy to mistake for ordinary AI skepticism, and it is not that, because it depends on this first step about where quality came from in the first place.
The second step is that this rationing was a side effect of implementation cost, and implementation cost is exactly what AI removes. David Heinemeier Hansson's compressed version of the consequence: give a team 380 hours and ten AI agents and the team can build a monstrosity, something that tries to do a million things for a million people, because the bloat that used to require payment now arrives for free.1 The job does not disappear, it moves: if scarcity used to do the editing, the builder's remaining work becomes almost entirely editorial. In Hansson's words, "our task as software builders becomes so much more about distilling, so much more about killing our darlings, killing features that we think are good but are just too much."1
The reported case
The one concrete instance behind the claim is Basecamp 5, 37signals' first AI-accelerated build. What changed was that designers could suddenly take features all the way to completion, something that had not been possible before, and the resulting failure mode was not bad work, it was finished, defensible work arriving at the shipping gate with no remaining check other than whether the product could absorb it, an image Hansson returns to as a balloon that pops once it keeps expanding past the point where it loses the one property that kept customers around. The loudest piece of customer feedback on the release was not about any new feature. It was that a button had moved.
Why this is not simple skepticism
The claim carries weight because Hansson converted on capability before he formed this view, and says so. He originally dismissed early AI coding tools as an interruption machine, what he called "the open office on steroids," and locked onto that framing as the whole story. Tobi Lutke pulled him out of it, not by arguing but by asking him where his eyes were pointed, the same question a driving instructor asks a mediocre racer who is staring at the wall instead of the apex: a driver steers toward whatever they are looking at.1 Hansson says he is frustrated with himself for not reaching the same conviction earlier, and the epistemic lesson he draws is that abstract argument moved him less than actually touching the tools himself, in the same way nobody learns to drive a race car by reading a book about it.
So the resulting position has an unusual shape: converted on capability, unconverted on consequence. Hansson believes agents work, and believes that working is the problem, and he explicitly includes himself and his co-founder Jason Fried in the population he expects to misuse the new capacity.
Why it matters
If generation is now free, the scarce input becomes judgment about what not to ship, which is a hiring and taste question rather than a tooling question. The claim also predicts something checkable: AI-built products should show feature counts rising faster than perceived simplicity, with the divergence invisible from inside the company, since every individual feature was justified on its own, and visible only in customer surveys after the fact.
Practiced by
Connections
Loading connections…
References
- 01
DHH: How to Build a Profitable Company Without Losing Control
David Heinemeier Hansson · podcast · 2026
Related