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 and viraptor — commit activity leaves the governance question open. kjksf infers a handover from a recent contribution window: “It seems he already handed reigns over to other people.” viraptor objects that “Rails is a whole umbrella of projects” and points to work elsewhere in the organisation. Rails’ official community page still lists Hansson on the Core team that stewards the framework. A narrow commit view cannot establish a leadership handover.
  • 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. Their follow-up makes the human role concrete: “At our company (big Rails/React monolith) all PRs do get a human review.” They report filtering model-generated review findings for relevance and avoiding unnecessary complexity. That is supervised development, with architecture and judgement still part of the job.
  • 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 — separate server costs from the framework’s future. fhub reports most endpoints answering in under 80ms, so end-user response time would not motivate a port. chvid argues that removing server-rendered HTML lowers server load regardless of language, while also declaring Rails dead. The defence of its continued use comes from jmuguy: “Rails itself will continue. I see no reason to stop using it.”

The question the thread kept asking

If you never read the code, what is your actual trust threshold? bionsystem, who identifies as an SRE, a site reliability engineer, asks whether serious systems demand “100% trust” and eventually require trusting agents to deploy. viraptor challenges that threshold: “There are many types of code.” They distinguish easily checked one-off analysis, low-stakes dashboards, tested production features and medical billing rules they keep off-limits to agents. The proposed boundary depends on consequences and independent checks. pjm331 supplies the unresolved long-term question: “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.”

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.