Rails 何去何从？DHH 全面转向 LLM 与 Rust

无论出于好意还是坏意，David Heinemeier Hansson 依然掌控着 Ruby on Rails。我本想对他漠不关心，但我用 Rails 构建应用，所以他的动向会直接影响我和我的客户。昨天，他在 Rails World 2026 上作了开幕主题演讲，阐述了 Rails 未来的愿景。

至少他的演讲本该如此。但他的主题演讲跟 Rails 几乎没什么关系。以下是他实际谈论的内容，以及这对 Rails 意味着什么。

核心要点

我已从职业程序员这一角色中退休。

是的，他确实这么说了。不，这并不代表他将脱离软件开发。他现在自称为“创造者”（maker）。他现在宣称英语是最佳的编程语言（因为有 LLM 支持），甚至认为我们未必需要阅读 LLM 生成的代码。

对于大多数公司里的大多数程序员来说，手工编写代码已不再具有经济生产力。

他全面押注 LLM 代码生成，因此改变了对原生应用和 Rust 编程语言的立场。在他眼中，Hey 这类产品原本就不该是 Web 应用。

多年来，他一直主张 Rails 技术栈能让小团队开发雄心勃勃的产品。如今，37signals 正在开发 Hey 的下一个版本，却选择了不同的技术栈。按他的说法，瓶颈已消除，因此他们用 LLM 为支持的每个平台构建原生应用。

在服务端，他们选择了 Rust。DHH 坚持认为这种语言丑陋，人类不应受其折磨，但承认它非常适合 LLM。既然他反正不读代码，如今也能欣赏该语言的性能和稳定性了。

他声称今年 8 月写了 15 万行代码，而在 LLM 出现前，他一年平均只写约 3 万行。他承认其中很多是“啰嗦”的 Rust 代码。过去二十年 Ruby 占他工作的约一半，但今年写的代码中，Ruby 占比仅为 3%。

新策略植根于这样一种理念：人类阅读代码应是例外，而非常态，就像在 Sentry 里看到 bug 一样。

那是今天的状况。到今年年底，几乎所有一切领域、几乎全部程序员、几乎每一家公司都会如此。我们最好习惯它。

他还希望每一项服务都提供 CLI，这样他（准确说，是他的 agents）就能不使用 UI 而与之交互。

如今我们可以想要一切，也可以得到一切。

演讲的后半部分聚焦于他对 LLM 让每个人都能随心创造愿景的描述。他谈到了自己在 Omarchy 上的工作，并在结尾处呼吁观众摒弃对 AI 的怀疑与末日论倾向：

黑药丸是给那些混蛋失败者的。别当失败者。

Rails 形的空洞

DHH 在世界顶级的 Rails 大会的开场主题演讲中，宣布一款旗舰 Rails 应用正在离开 Rails。关于 Rails 的内容仅剩：它依然非常适合 Web 应用（比如 Basecamp），并且也很适合用 AI 来构建。

二十年来，Rails 一直被包装成“小团队、宏大产品”的框架。我参与过很多团队，正是依靠 Rails，用很少的代码实现了很大的功能。你可能也有同感。

Hey 过去是、现在也仍然是 Web 应用，因为为小团队构建 Web 应用才是生产力所在。当然，我说的是旧时代，也就是 5 分钟之前……

他对 Rails 的愿景已经收窄。Rails 从来不是首选，而是一种权宜之计。如今它成了“出于必要才写 Web 应用”的默认平台。约定优于配置已被重新诠释为“token 效率”。Evil Martians 的 agent 评估无非是给大家吃定心丸：AI 擅长 Rails，所以你不需要离开。

或许存在一种更善意的解读。Rails 确实是一个成熟、稳定的框架，稳定性对 agent 开发也确实有益。但他告诉我们，今年他的工作只有 3% 是 Ruby。这场演讲中没有任何内容试图将一个成熟平台与那个创造者已不再关注的平台区分开来。

这些 CLI 相关的说法让人费解。37signals 一向靠独到的 UI/UX 而非新奇功能来打造产品差异化。他们认为网页版体验不够好，甚至把 Hey 重写成六个原生应用。既然 UI 重要到值得彻底重写，怎么又变成大家都只用 CLI 了？如果每个产品都是被代理通过 CLI 驱动使用，那 Basecamp 或 Fizzy 凭什么和最便宜的竞品拉开差距？我觉得这套策略需要好好 Rework 一下。

我不禁想问：Rails 现在的愿景到底是什么？还有谁会来推动它？虽然 Mosscap 是因为理念分歧而分叉的，但他们的核心论点之一就是 Rails 已经功德圆满——足够稳定，只需维护即可。Hanami 则有一份路线图和对用 Ruby 构建 Web 应用的未来愿景。Rails 的日常工作大多由 Shopify 等公司贡献，但愿景历来由 DHH 把握。如今，他是在把自己的生意说没了吗？还是早已心不在此，只是没告诉大家？

Rails 的作者正把自己的一款旗舰产品从技术栈里拿掉。他的 Ruby 代码产出降到了 3%。他相信到 12 月，几乎所有人都不会再手写代码了。面对这一切，他给出的却是恭维。

也许这有点吓人，也许竞争就要来了。可谁怕竞争呢？你不是更强吗？你懂得不是更多吗？当然。你可是个货真价实的 Rails 程序员，是精英中的精英。这简直是《壮志凌云》的现场。拥抱它，满怀热情地拥抱。

这是安抚，不是规划。我猜现场确实被安抚到了——自信总能奏效。但这番话完全空洞。你把这番话逐字讲给 Django、Laravel 甚至 Spring Boot 的开发者听，也毫无违和。他唯一一次直接对 Rails 开发者喊话，却对 Rails 本身只字未提。

房间里那头幻觉中的大象

再说 AI 那些说法。先交代背景：DHH 经营的公司做的是简单、易用的产品，简单到在 LLM 出现之前，他们就会定期把应用完全重写出新版本。

The user wants a translation of a tech article snippet. Key constraints: - Natural, concise Chinese. - Preserve HTML tags. - Preserve LaTeX (none present here). - Keep technical terms in English where appropriate (Rails, Kanban, LLM, Rust, Ruby, CPU, memory, Raspberry Pi). - No Markdown. - Output only the translated text. Segment 1:

37signals succeeds on product and marketing, not on solving hard technical problems. I’m not hating; lots of people love their apps. I’m just saying that their new Kanban app’s success will be driven by product decisions and marketing. Kanban board is not one of the hard problems of computer science.

Translation:

37signals 的成功源于产品和营销，而非解决高难度的技术问题。我无意批评，很多人确实喜欢他们的应用。我只是想强调，他们新发布的 Kanban 应用能否成功，取决于产品决策和营销手段。看板并不是计算机科学中的难题。

Segment 2:

So does his approach (never looking at the output, evaluating the result from the outside) work? These tools have come a long way. They still make all kinds of mistakes, but as long as there’s a human in the loop to verify the results and reprompt, it works fine, at least for small apps and easy problems.

Translation:

那么他的方法（从不查看输出，只从外部评估结果）有效吗？这些工具已经进步很大。它们依然会犯各种错误，但只要有人类介入来验证结果并重新提示，就能正常工作，至少对于小型应用和简单问题是这样的。

Segment 3:

It’s hard to take the numbers in this talk seriously, because David keeps undermining them. Throughout he presents topics as settled, despite failing to support them coherently.

Translation:

很难认真对待这场演讲中的数据，因为 David 不断削弱它们的说服力。他全程将这些话题呈现为既定事实，却无法提供连贯的支撑。

Segment 4:

He admits that lines of code is a poor measure and grants that we can’t compare across languages fairly, then compares 150,000 lines of LLM output in August to his 30k/year average, then immediately concedes that he tolerates Rust code from LLMs that he “would never tolerate from [his] Ruby code”. Lines of hand-written, concise Ruby and LLM-generated Rust slop are not comparable. He seems to know this, but compares them anyway.

Translation:

他承认代码行数是一个糟糕的指标，也认可不同语言之间无法公平比较，但随后却拿 8 月份 15 万行 LLM 生成的代码与他每年 3 万行的平均水平做对比，紧接着又承认他容忍 LLM 生成的 Rust 代码，而这些代码是“他绝不会容忍出现在自己的 Ruby 代码中的”。手工编写的精简 Ruby 代码与 LLM 生成的粗糙 Rust 代码根本没有可比性。他似乎知道这一点，却依然拿来比较。

Segment 5:

In the past 20 months, I have written half as much code as I did in the previous 21 years.

Translation:

在过去 20 个月里，我写的代码量只有前 21 年的一半。

Segment 6:

Apples to oranges again, and he’s struggling with the definition of “to write”. He didn’t even read the Rust his LLM generated.

Translation:

这又是典型的苹果比橘子（不当类比），并且他对“编写”的定义也很含糊。他甚至没有阅读LLM 生成的 Rust 代码。

(Refining "struggling with the definition of to write" -> 他连“编写”的定义都没搞清楚 / 他对“编写”的理解很混乱) Let's use:

这又是典型的苹果比橘子（不当类比），而且他连“编写”的定义都没搞清楚。他甚至没有阅读LLM 生成的 Rust 代码。

Segment 7:

The Hey Next numbers are similarly problematic. There’s no questioning that Rust is a more performant language than Ruby, but it’s another unfair comparison.

Translation:

Hey Next 的数据同样存在问题。毫无疑问，Rust 的性能优于 Ruby，但这又是一次不公平的比较。

Segment 8:

…we end up with a backend that requires 99% less CPU, 95% less memory, and the only reason it needs 10 hosts is for redundancy. In fact, our back-of-the-envelope calculation has led us to believe that Hey’s peak traffic could probably be served on a single Raspberry Pi.

Translation:

……最终我们的后端 CPU 需求减少了 99%，内存减少了 95%，之所以需要 10 台主机，只是为了冗余。事实上，我们的粗略估算让我们相信，Hey 的峰值流量可能由一台 Raspberry Pi 就能承载。

Segment 9:

A pure-Ruby backend with no web frontend would also be vastly cheaper to run than the existing Rails version. Which gains come from Rust and which are from dropping the web app is unknowable. And none of it is an argument for his agent thesis. A team that likes writing Rust could build the same system. But he doesn’t think humans should write Rust.

Translation:

一个没有 Web 前端的纯 Ruby 后端，运行成本也会比现有的 Rails 版本低得多。哪些收益来自 Rust，哪些来自去掉 Web 应用，无从得知。而且这些都不能作为他“智能体”论点的论据。一支喜欢写 Rust 的团队也能构建出同样的系统。但他并不认为人类应该写 Rust。

Check for markdown formatting. No markdown used. Check HTML structure. Preserved. Check terminology. Kanban, LLM, Rust, Ruby, CPU, memory, Raspberry Pi, Rails, Hey Next preserved. Check flow and naturalness. Looks good. Final check on segment 6: "struggling with the definition of 'to write'" - "他连‘编写’的定义都没搞清楚" is natural. Segment 4: "LLM-generated Rust slop" - "LLM 生成的粗糙 Rust 代码" (slop = 粗糙/垃圾代码, "粗糙" is a bit polite, "烂尾" or "糟糕" might be better contextually, "粗糙" is acceptable in neutral tech criticism, maybe "劣质" (low-quality). Let's use "LLM 生成的劣质 Rust 代码"). "He seems to know this, but compares them anyway." -> "他似乎心知肚明，却依然拿来比较。" "David keeps undermining them" -> "David 不断削弱其可信度" or "David 不断自相矛盾，削弱了数据的说服力". "Undermining the numbers" means the argument is flawed or the numbers don't support the conclusion. "削弱数据的可信度" works. Refined Segment 4:

他承认代码行数是一个糟糕的指标，也认可不同语言之间无法公平比较，但随后却拿 8 月份 15 万行 LLM 生成的代码与他每年 3 万行的平均水平做对比，紧接着又承认他容忍 LLM 生成的 Rust 代码，而这些代码是“他绝不会容忍出现在自己的 Ruby 代码中的”。手工编写的精简 Ruby 代码与 LLM 生成的劣质 Rust 代码根本没有可比性。他似乎心知肚明，却依然拿来比较。

Refined Segment 6:

这又是典型的苹果比橘子（不当类比），而且他连“编写”的定义都没搞清楚。他甚至没有阅读LLM 生成的 Rust 代码。

(Maybe remove "（不当类比）" as it's an idiom explanation, "苹果比橘子" is widely understood in Chinese internet slang as "comparing apples to oranges".)

这又是典型的苹果比橘子，而且他连“编写”的定义都没搞清楚。他甚至没有阅读LLM 生成的 Rust 代码。

Refined Segment 1: Kanban board -> Kanban 看板 or just Kanban. "Kanban 应用" is in the text. "看板并不是..." Let's assemble. HTML:

37signals 的成功源于产品和营销，而非解决高难度的技术问题。我无意批评，很多人确实喜欢他们的应用。我只是想强调，他们新发布的 Kanban 应用能否成功，取决于产品决策和营销手段。看板并不是计算机科学中的难题。

那么他的方法（从不查看输出，只从外部评估结果）有效吗？这些工具已经进步很大。它们依然会犯各种错误，但只要有人类介入来验证结果并重新提示，就能正常工作，至少对于小型应用和简单问题是这样的。

很难认真对待这场演讲中的数据，因为 David 不断削弱其可信度。他全程将这些话题呈现为既定事实，却无法提供连贯的支撑。

他承认代码行数是一个糟糕的指标，也认可不同语言之间无法公平比较，但随后却拿 8 月份 15 万行 LLM 生成的代码与他每年 3 万行的平均水平做对比，紧接着又承认他容忍 LLM 生成的 Rust 代码，而这些代码是“他绝不会容忍出现在自己的 Ruby 代码中的”。手工编写的精简 Ruby 代码与 LLM 生成的劣质 Rust 代码根本没有可比性。他似乎心知肚明，却依然拿来比较。

在过去 20 个月里，我写的代码量只有前 21 年的一半。

这又是典型的苹果比橘子，而且他连“编写”的定义都没搞清楚。他甚至没有阅读LLM 生成的 Rust 代码。

Hey Next 的数据同样存在问题。毫无疑问，Rust 的性能优于 Ruby，但这又是一次不公平的比较。

……最终我们的后端 CPU 需求减少了 99%，内存减少了 95%，之所以需要 10 台主机，只是为了冗余。事实上，我们的粗略估算让我们相信，Hey 的峰值流量可能由一台 Raspberry Pi 就能承载。

一个没有 Web 前端的纯 Ruby 后端，运行成本也会比现有的 Rails 版本低得多。哪些收益来自 Rust，哪些来自去掉 Web 应用，无从得知。而且这些都不能作为他“智能体”论点的论据。一支喜欢写 Rust 的团队也能构建出同样的系统。但他并不认为人类应该写 Rust。

All constraints met. Ready to output.

他关于十倍（乃至百倍、千倍）程序员效应的断言同样值得怀疑。相关研究衡量的是开发者工具方面的差异，而非开发者的生产力本身，且该研究已受到各角度的严厉批评。“十倍平均值”这一说法纯属民间传说，原始论文中根本未提及。

开发者之间确实存在显著的生产力差异，我也亲眼目睹过。但不知何时起，从论文的 28:1 到舞台上的 1000:1，数字发生了巨变，而这一切仅通过一个麦克风、由一人独白的方式被定论了。

还有 Basecamp 5 的问题。David 报告称，该产品导致架构变得“像瑞士奶酪一样千疮百孔”，他责怪 AI 模型。无论是来自智能体还是人类，未经审查、缺乏协调的贡献都会导致架构退化。他在演讲后半部分声称，“重复的成本已趋近于零”，但 Basecamp 5 恰恰证明了非零成本的现实。我们早已在 DHH 的圈子里见过这种失败模式。Shopify 创始人 Tobi Lütke 最近叹息说，在进行大规模智能体开发时，“低质内容炸弹”（slop grenades）已成为严重隐患。

David 要求我们从历史中汲取 ATM 的教训：人们曾担忧 ATM 会终结银行柜员时代，结果却恰恰相反。不过，他的故事有个问题：所有细节都错了。十年的时间跨度不对。他引用了错误的经济学家。柜员数量的偏差高达一个数量级。结局也已经过时。也许这本该由人工来复核这场演讲。

“永远不要看代码”和“安全方面，有大事要来了，做好准备”这两句话在演讲中仅相隔十五分钟。这是道鸿沟，且缺乏任何过渡。我被告称，某家公司正在探索重建一个相对简单的电子邮件产品，这种初步努力可以外推至“几乎所有程序员、几乎所有公司，且就在十二月前”。

最后，本该拿出策略的地方，却只剩下一句乐观的呼吁。

我也觉得这些担忧可能有点被夸大了。也许吧，但估计没有。我的意思是，其中一些可能还更严重些。

乐观不是策略，也改变不了事实。这场演讲里的事实并不足以支撑这种乐观。我是带着好奇来看 Rails 的未来的，结果到现在还是一头雾水——我估计 DHH 自己也没答案。他甚至没有表现出对这件事有在认真思考。

这才是最让我失望的地方。我对他的 AI 论调持怀疑态度，但这并不是问题所在。我也不在意 Hey 的重写，他有权用自己的工具开发应用，反正我也不用 Hey。

问题在于，他站在 Rails World 的讲台上告诉所有人，他要把自己的产品迁出 Rails，而对仍在使用 Rails 的开发者，他能想到的最好安慰竟是：我们是“精英中的精英”。行吧，谢谢啊。

也许 Rails 真的如 Mosscap 项目所言走到了尽头，也许是时候把重心放在稳定性和维护上了。如果计划真是这样，那就应该有人说出来；如果不是，那就谈谈我们的方向到底在哪。

DHH 两者都没做。他只是告诉我们未来会很美好，还告诫大家不要陷入 AI 末日论。哪怕给我一两页关于 Rails 本身的幻灯片，我也就满足了。