Fix the Factory First

David Heinemeier Hansson stood up at Rails World last week and told a room full of programmers that he’s retired. Not from 37signals, the company he still runs. From programming itself. “I spent a quarter of a damn century chiseling code by hand and loving every moment of it,” he said, “and this is something to look back upon with joy and accept that it is over.” As Gergely Orosz reported in The Pragmatic Engineer, the internet did what the internet does with a line like that: it took the seven words that fit in a headline and ran with them, past the part of the same keynote that actually matters for anyone leading a team through this.

David Heinemeier Hansson’s Rails World Keynote

David Heinemeier Hansson told the audience that 37signals has “gone pencils down” on writing code by hand as a normal course of business, that he no longer thinks of himself as a professional programmer, and that November 24th 2025, the release of Opus 4.5, will be the date the history books mark as the inflection point for the age of agents. He compared it to what the camera did to painting. That’s a genuinely striking claim from the person who built the framework much of the web still runs on, at a company that’s spent 27 years being profitable and famous for caring about code quality.

But the line doing the real work in that keynote isn’t “pencils down.” It’s the sentence right after it. Writing code by hand at 37signals, he said, is now an exceptional state: “It is like seeing a bug in Sentry: something here went wrong; why was the agent not able to produce what we wanted? Okay, maybe for a little while, we’ll still get the old pencil out and dot it down for them, but then we fix the machine, we fix the factory, we get things going again.”

I’d say that’s not a lack of discipline so much as discipline moved up a level, aimed at the system that produces the code rather than the code itself. If you take that sentence away from the keynote, then what’s left is just a permission slip. With it, what’s left is a claim about where the accountability now sits.

Marc Brooker’s Code Review Call

The same week, Marc Brooker, a Distinguished Engineer at AWS, posted that he believes humans will, long-term, have no role in routinely reviewing code. Read next to David Heinemeier Hansson’s keynote, it looks like confirmation: two credible, senior engineers independently telling you the review step is going away.

I don’t think that’s quite what either of them is describing, though. A world with no routine human code review isn’t necessarily a world with no verification: it’s one where the checking has moved somewhere else, into specs, into automated tests, into the “fix the machine” loop David Heinemeier Hansson was describing. Removing the human from the review step only works if you’ve built something else that’s actually doing the reviewing, and I think most organisations reading these two posts this week haven’t built that something else. They’ve just stopped reviewing.

The DORA ROI Report

That gap between “we changed how verification happens” and “we stopped verifying” is exactly what DORA’s 2026 ROI of AI-assisted Software Development report went looking for, and it found real numbers attached to it. The report’s central argument is that AI acts as an amplifier of whatever organisational capability already exists: strong foundations get stronger, weak ones get worse, faster. It models a 500-person engineering organisation investing $8.4 million in AI adoption and finds a 39% first-year return, an 8-month payback, when that investment sits on top of things like solid version control discipline and a quality internal platform.

It also models what happens without those foundations. A one-point rise in change failure rate, from 5% to 6%, produces a $344,000 negative impact in the same model, once you count the cost of the instability AI-generated code introduces without the automated testing and CI/CD to catch it. DORA calls the reviewing and verification work that has to happen somewhere in the new process the “verification tax.” You can move who pays it. You can’t opt out of paying it.

What Voxium Described

You can see what it looks like when a company tries to opt out anyway. Last weekend, an anonymous engineer posting as voxium described their first two weeks at a new job at a large tech company: specs, code, tests, tickets and reports all produced by Claude Code, twelve and thirteen-hour days spent mostly pressing enter, and, in their words, “nobody is resolving bugs. In reality, nobody is thinking anymore.” Management’s line, apparently repeated more than once, was that pushing code was not the bottleneck, so why was the team slow.

David Heinemeier Hansson’s version of this includes fixing the factory every time the agent gets something wrong. voxium’s account describes a factory nobody is fixing, because nobody has been given the time, or the mandate, to notice it’s broken.

I’ve seen this myself at Bloom & Wild where we’ve put a lot of effort into our own agentic code review tooling and processes. It’s important that this step builds trust in what ends up in production and it does that in a way that is cognisant of your own context. Agentic code review is, in my opinion, now essntial to ensuring fast flow within an agentic SDLC and building a process that fits your teams arechitecture and ways of working doesn’t just mean taking something off the shelf.

The quote spreading through Slack channels and LinkedIn reposts this week is “we’re done writing code by hand.” The one worth carrying into your own planning is three sentences later: we fix the machine, we fix the factory. If you can’t say, concretely, what your organisation’s version of that looks like, the machine that catches an agent’s mistakes and corrects course before it reaches production, then adopting the headline without it is closer to what voxium described than to what 37signals actually did.