David Heinemeier Hansson opened Rails World 2026 with a keynote that had very little to do with Rails. His line: “I have retired from being a professional programmer.” Jared Norman, who builds applications with Rails, went through the talk claim by claim — and found that most of the AI evidence in it does not survive being read closely.

What the keynote asserted:

  • English is now the best programming language, and you do not necessarily need to read the code the LLMs produce. “Writing code by hand is no longer an economically productive enterprise for the vast majority of programmers working at the vast majority of companies.”
  • Hansson says he wrote 150,000 lines of code in August, against a pre-LLM average of about 30,000 lines per year. Ruby is 3% of what he wrote this year. Reading code should be the exception, “like seeing a bug in Sentry.”
  • 37signals is rebuilding Hey as six native apps with a Rust backend — reported at 99% less CPU and 95% less memory, with peak traffic that “could probably be served on a single Raspberry Pi.”
  • By the end of the year, he predicted, this applies to “virtually all domains, virtually all programmers, virtually all companies”; every service should also expose a CLI so agents can drive it instead of a UI.

Norman’s counters:

  • The numbers do not compare. Hansson says himself that lines of code is a poor measure and that he tolerates Rust from an LLM he “would never tolerate” in his own Ruby — then compares unread LLM Rust against hand-written Ruby anyway. “Write” is also doing heavy lifting when nobody read the output.
  • The performance gains are confounded. Dropping the server-rendered web app would make a pure-Ruby JSON backend vastly cheaper too, so nothing here isolates Rust or agents.
  • The 10x programmer is folklore. The study behind it measured developer tooling, not productivity, has been heavily criticised, and never contained the “average of 10x” figure. “Somewhere between the paper and the stage we went from 28:1 to 1000:1, and the only place that’s settled is a keynote where only one person has a mic.”
  • Basecamp 5 came out “like Swiss cheese,” and the models were blamed. Norman’s point is that unreviewed, uncoordinated contributions degrade architecture whether they arrive from agents or people — the failure mode Shopify’s Tobi Lütke calls “slop grenades.”
  • The history is wrong. The ATM story Hansson uses to reassure the room has the wrong decade, the wrong economist and teller numbers off by an order of magnitude. Norman’s verdict: “Perhaps a human should have double-checked this talk.”
  • The talk contradicts itself. “Never look at the code” and a warning that “security, something’s coming, get ready” are fifteen minutes apart, with no bridge between them.

The Rails part is quieter and, Norman argues, worse. Rails was sold for twenty years as the way small teams build ambitious products; it is now presented as a workaround for a world before LLMs, with convention over configuration reframed as “token efficiency.” A flagship Rails app is leaving the stack. His complaint is not the rewrite — it is that the one moment the keynote addressed people still using Rails, it offered “you’re the best of the best” and nothing about Rails itself.

The 189-comment thread on Hacker News

What the thread adds

  • kjksf — the correction that reframes the governance question: the rails/rails commit history shows no commits from Hansson. “It seems he already handed reigns over to other people.” Norman’s closing worry about who drives Rails now has a partial answer the essay did not have.
  • jeffreyrogers — the strongest counter-datapoint to the whole essay: a revenue-generating Rails side project that is about 90% LLM-written (roughly 25,000 lines of production code plus tests) with no problems in reliability, security or performance, and no plans to leave Rails. Their framing: most managers already do not read their reports’ code; they trust process instead.
  • booty — support for that from the other direction: the industry’s “false dichotomy of ‘awesome, wonderful, hand-crafted code’ vs ‘shitty AI slop’” ignores how much hand-crafted code is bad, and “talented engineer plus AI” is the combination that wins.
  • zem — the caveat that keeps the optimism honest: LLMs “can write better code than me, but they can also write far worse code, and often don’t seem to be able to tell the difference.” Steering them requires reading the output: “I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.”
  • jnmandal — splits the skill question by domain: agents are excellent at deployment and CI (“I used to have to ask DevOps for that and wait days”), and bad at architecture in Rails specifically — “Ten queries for what could be one. No separation of concerns. Huge files, lots of duplicated code.”
  • fhub and chvid — the dissent against the Rails-is-dying frame: one reports 99% Apdex and most endpoints answering in under 80ms, so performance would not be the motivation to port; the other argues Rails keeps surviving and only the fat-client/JSON split actually changes the server maths.

The question the thread kept asking

If you never read the code, what is your actual trust threshold? bionsystem, an SRE, asked it directly: managing more than one agent seems to require not reading the output, which implies “you have to have 100% trust, 99.9% is not going to be enough in any serious industry,” and eventually also trusting agents to deploy. pjm331 supplied the honest framing of where that stands: “We are many of us now engaged in a big experiment to see just how little you can read the code, and for how long.” Nobody in the thread claimed the experiment has a result yet.

On reading comments as evidence: HN handles are pseudonymous, the site publishes no per-comment scores, and the ordering here is HN’s own ranking — a slice of the thread, not a consensus.