• DHH 演讲
  • 对文章的评论

DHH 演讲

视频链接

我喜欢这个。霓虹灯里的弯曲造型。

首先，通常我会说：“欢迎来到奥斯汀。”不过这次应该对我自己说：“欢迎回到奥斯汀。”大约一个月前我刚来过，在一档播客上絮絮叨叨聊了五个小时。能再次来到这里，感觉真好。

但更让我兴奋的是，能够活在当下这个时刻，与围绕 Ruby on Rails 聚集起来的这个出色的社区，以及所有对智能体感到兴奋的人，一起经历这一切。如果你还没感到兴奋，希望听完这场关于未来的狂热演讲，你也会兴奋起来。

我知道，当有人看见一个人为此刻如此兴奋，手舞足蹈时，第一反应可能是给他下个诊断：“AI 精神病。”我更喜欢另一种说法：我得了“AI 狂热症”，处于“AI 欣快状态”。因为在我使用计算机、玩计算机、与计算机打交道的这些年里，这绝对是我们让计算机做到过的最令人兴奋的事。

但我们确实得面对一个事实：这件事一方面让人极其兴奋，另一方面也让人有点不安。因为我们并不确切知道，它最终会变成什么样。每次我们试着作出预测，大约二十分钟后，预测就过时了。这种状态很奇怪，哪怕你对未来充满期待，哪怕你对当下充满期待。我完全理解，这会带来怎样的不安。

为了稍微缓解这种感觉，我们把时钟往回拨一点。这是一项十八世纪最先进的技术。如果你想在十八世纪留下自己的肖像，就得在一位绘画大师面前，一坐就是好几个小时。之后，画家还要花上数月，才能完成你的肖像。

那些画当时很美，现在依然很美，是留给我们所有人的非凡文化遗产。直到今天，我们仍能看到约书亚·雷诺兹在 1781 年绘制的沃尔德格雷夫夫人肖像。太棒了。不过，这也是少数人才能享有的服务。十八世纪没多少人能委托别人为自己画这样一幅画，并支付画家数月劳动的费用。

更糟的是，就这幅画而言，雷诺兹还曾花了好几个月，画过另一幅沃尔德格雷夫姐妹的肖像，结果被客户拒收了，因为画里露出了一小截脚踝。这在当时可是丑闻。于是，他只好回去重画。不知道在座有没有与客户打过交道的人，你们大概会同情可怜的约书亚·雷诺兹先生，以及他那些被退回的委托成果。

能负担得起这种服务的人，大多要么属于上层资产阶级，要么干脆就是王室成员。这是戈雅在二十年后为西班牙王室绘制的一幅画。当时技术大致就是以这样的速度发展。几百年来，画家一直在完善各种描绘人物肖像的技法，但进步非常有限。

从 1801 年到我接下来要展示的这幅画，中间过去了八十多年。在这期间，大约在 1840 年，相机登场了。不过，这里展示的是一幅 1888 年的丹麦王室肖像。哦，是 1886 年。作者是丹麦画家劳里茨·图克森。他画这幅画花的不是三个月，而是三年。它至今仍挂在哥本哈根的王宫里，你可以去那里看。

这是一项惊人的成就，展现了非凡的艺术造诣，同时也有很强的实用功能：目的就是记录当时的王室成员。但对于这类画家而言，这种工作方式已经接近尾声。因为在 1840 年到 1900 年之间，记录人物肖像的技术越来越好。

1900 年，伊士曼柯达公司推出了 Brownie 相机。这可以说是摄影首次以大规模生产的形式走向大众：价格下降，更多人用得起。我记得用它拍张照片，大约只要一美元。因此，突然有很多人都拍了自己的照片。

那些伟大的艺术家意识到，创作宏大肖像画这门手艺，接下来要发生变化了。这份工作会改变，因为突然间，他们面临一种新技术的竞争。于是，他们转型了。

在 Brownie 推出后不久，劳里茨·图克森和当时的许多其他画家都意识到，尽可能完美地再现现实，已经不再是一门能带来经济回报的手艺。他们需要别的技能，需要另一个领域。许多人转向了其他艺术形式。毕加索探索立体主义，丹麦的斯卡恩画家则探索一种印象主义，这幅画就是例子。

技术变化带来了一场创造力的爆发。人们突然必须寻找新的方式来表达自己的艺术，因为旧的方式已经行不通了。这幅画还有个有趣的地方：中间那位穿粉色裙子的女士，伊冯娜·图克森，其实是我的曾祖母。因为劳里茨·图克森是我的高祖父。

这里是他的肖像，我想拍摄于 1921 年，在他去世前不久。他接受了这种新的技术，用它给自己拍肖像，而正是这种技术改变了他原来的职业。在他去世五十二年后，也就是 1979 年，我出生了。

有意思的是，我这张照片其实和劳里茨在二十世纪二十年代拍的照片非常相似。技术并没有进步太多，因为技术发展常常就是这样：时而起步，时而停滞，断断续续。巨大的变化是 Brownie，是摄影的普及。随后差不多八十年过去了，并没有发生特别大的变化。

六十年代我们有了彩色摄影，不过那时还不够普及，显然我还不配拍上一张。几年后，我们倒是纠正了这个问题。这是一张我四岁时和哥哥坐在一起的彩色照片。

再过几年，这里又有一张我的照片。这三张照片，加起来大概就占了我全部童年照片的百分之十。虽然这项技术已经普及到连我们这样的家庭也能负担得起拍照，但它还没有那么普遍。确实有一条增长曲线：到了这张照片所代表的八十年代，人们拍摄的照片比二十世纪初更多了，但数量依然相当有限。因为技术的发展会起起停停。

拍摄那三张照片的相机，与这台相机非常相似。这是 1925 年的徕卡 I 型。事实上，其中有些照片可能真的就是用另一台徕卡拍的。我想那时已经出到第七代了。但它们并没有太大区别，因为技术相当接近。从二十世纪初的那场巨大变革到八十年代，并没有发生太多变化。

再过几十年，一切突然又发生了剧变。摄影不仅变得人人都能享有，拍照也变得毫不费力，照片数量呈爆炸式增长。突然间，每个人都能给自己的孩子拍上几万张照片，而且很多人确实这么做了。成本低到几乎不值得计量。

这些是我妻子晚上出去散步时喜欢拍的一些照片。如果在八十年代想这样拍，就得花钱买胶卷、冲洗照片，还要处理一整套相关事务。有人会这么做，但人数不多，因为阻力仍然太大。如今，在 2026 年，每年大约会拍摄两万亿张照片。这和过去完全不同。

底层技术还是同一种技术，但显然，我们已经到了一个转折点。即使与拍照手机刚问世时相比，也是如此。这与我们的行业、我们的职业，会有一些相似之处。

2025 年 11 月 24 日，我们迎来了这个时代的“柯达 Brownie”：Opus 4.5。AI 技术通过一套许多人都用得起的工具呈现在我们面前，让大家第一次体验到，与一种新的智能结对开发软件，究竟是什么感觉。对我来说，这就是临界点。一切分为 11 月 24 日之前，以及之后。未来的历史书会把这一天标记为智能体时代的转折点。

就像 Brownie 刚推出时一样，各种不同的形态、各种运用这项技术的新方式，一下子涌现出来。没过多久，我们就以开放权重的形式，获得了某种同等水平的智能。简直欣喜若狂。这一切发展得太快了。我不敢相信，这种仿佛来自外星的技术，现在竟然以开放权重的形式供人使用。才过了几个月而已。

我有很长一段时间都在使用 Kimi K2.5 的快速模式，非常喜欢。以每秒 200 个 token 的速度体验这样的智能，真是不可思议。不过，后来又发生了别的事。

从二月到五月，我们经历了一段“幻灭低谷”。看起来新模型还在不断推出，但它们有点糟糕，仿佛在倒退。很多人说：“这个 Opus 4.6 是怎么回事？我不知道啊，还是把旧的给我吧。”还有很多人说：“哈哈，你们以为它会一直呈指数级发展、不断变好。可你看，实际上并没有好多少。”

我记得有一次发布，好像是 OpenAI 的新模型，在基准测试上的表现并没有提升太多。然后股价下跌了，或者说估值下跌了，市场突然就喊：“天哪，结束了！”是啊，因为我们不知道会发生什么。

但这次幻灭低谷，并没有像摄影那样持续一百年，仿佛技术几乎没有进步。它只持续到了五月。准确说，是六月。因为六月我们迎来了 Fable 5 和 Mythos。显然，当时任何有机会体验它们的人，都不再怀疑我们是不是停滞了、是不是已经结束了。

我想，我的“病症”就是在这时真正显现出来的。面对这种爆发式增长、又能随取随用的智能，我陷入了精神病般的狂热、迷醉和欣喜。Opus 带给我的启示是：“哦，我可以告诉智能体替我做件事，然后看着它产出我愿意合并进代码库的成果。”而到了这个阶段，我突然有了这样的模型：我可以把问题或想法交给它，无须自己指导如何实现，就能看到问题被解决，或者想法被进一步拓展。简直震撼得不可思议。

当然，事情并没有就此停止。过去几个月，我们一直坐在这趟惊人的过山车上。九月，GPT-6 Astra 发布，把我们从一种担忧中解救了出来：Anthropic 会不会垄断这种前沿智能？更妙的是，仅仅一周后，我们又迎来了 DeepSeek-4-1 Flash，彻底打消了“前沿智能永远只属于几家美国大型科技公司”的想法。这实在令人兴奋。

但这意味着什么？对我们程序员意味着什么？对我们的职业意味着什么？我想，这也是为什么值得再次回顾历史。只要愿意去看，历史中就有许多精彩的教训，以及与我们这个时代相似的情形。

在我作为职业开发者的整个生涯中，有一个争论始终主导着讨论：“十倍程序员”到底存不存在？这个概念来自 1968 年《ACM》杂志的一篇文章。研究者让一组程序员完成各种不同的任务，得出了一张表：最差的程序员与最好的程序员之间，差距从五倍到三十倍不等，平均是十倍。接下来，我们竟然花了整整四十五年，争论这到底是不是真的。

现在还有人在争这个吗？我想没有了。这个争论已经有了答案。有意思的是，我们似乎跳过了对“十倍程序员”达成共同结论的阶段，直接开始思考：“如果单靠人的能力，差距就有十倍，那现在会是什么样？”

显然，我们并不确切知道。我们不知道使用这些工具，究竟能实现多大程度的提速。但我会认为，如今说“不用这些工具的最差程序员，与使用这些工具的最好程序员之间，存在一百倍的差距”，已经没那么有争议了。这不算特别有争议的说法，却彻底改变了我们对当下技术发展阶段的理解。

我甚至还想再往前走一步。这也许稍微更有争议，但我不觉得。最差的程序员不用这些工具，最好的程序员用这些工具，两者相差一千倍？嗯，听起来差不多。好吧，那这意味着什么？这对公司之间的竞争意味着什么？又意味着我们创业需要具备哪些条件？呃，魔法八号球的答案有点模糊，再摇一次吧。

我确定的一件事是：过去二十个月里，我写出的代码量，是此前二十一年代码量的一半。当然，代码行数是个奇怪、模糊、可塑性很强的指标。而且显然，一行 Ruby 的价值，远远超过任何其他语言的一行代码，尤其是 Rust、C++，或者其他低层语言，因为它们没有我们在 Ruby 里享有的那些抽象与便利。不过，一场革命正在发生，这一点绝对无可否认。任何经历了这一切、亲眼看着自己生产力加速的人，都会有点晕眩。

[播放旧演示片段] 我们来创建一个模板。看看我省掉了多少事情，看看有多少配置我根本不用写。这些东西都自动对应起来了。只要在这里写上 blog，就会直接对应到 blogging 控制器；只要有 index，就会直接对应到 index 模板。看看我有多少事情根本不用做。

还有什么比“我们不再需要做的那些事”更能概括当下这个时刻？这就是我如此兴奋的原因。这是属于 Rails 的时刻。刚才播放的片段已经有二十一年了。2005 年，我在巴西作了一场演讲，对于那些我不用写的代码，我兴奋极了。现在，你们能理解我为什么可能更加兴奋了吗？你知道过去几个月，我有多少代码没有亲手写吗？很多。

尽管到现在大概已有五个月没有亲手写代码，我却能够修好一切。每一个梦想，每一个烦人的问题，每一个小零碎，甚至每一个无关紧要的功能，突然都触手可及，突然都可以实现。这就是当下的魔力。

但这意味着什么？几周前，我们在 37signals 作出了一个决定：我们不再手写代码了。把手写代码当作日常业务、当作创造东西的常规方式，这个想法我们已经放下了。在 37signals，手写代码现在是一种异常状态。就像在 Sentry 里看到一个 bug 一样：这里有哪里出了问题。

为什么智能体没能产出我们想要的东西？好吧，也许暂时我们还是得把旧铅笔拿出来，替它写一下。但接着，我们就要修好机器，修好工厂，让生产重新运转。这是在承认已经发生的事情。

如果调查一下这个房间里的各位，我大概会……其实，干脆现在就问。这里有多少人，每周仍然会手写相当数量的代码？举个手。卧槽，大概只有五个人。

如果两三个月前我放出这张幻灯片，作出同样的宣言，不少人大概会说：“这家伙脑子有问题。”但现在，这已经只是在承认现实了。

特别有意思的是，今年春天，我们在 37signals 为 Basecamp 5 做最后收尾时，就尝试过这样做。我们让一群设计师通过“氛围编程”（vibe coding），把他们希望加入这个版本的最后一些功能做出来，结果好坏参半。单独来看，设计师能创建看起来合理的 PR；但把二三十个 PR 合在一起，整个架构就有点像瑞士奶酪，到处都是洞。

于是我们说：“唉，好吧，看来技术还没准备好。还是回去人工审查一切，只让程序员使用它吧。”显然，这个结论错了。不仅因为我们只要再等他妈的五分钟，就会迎来 Fable，整件事大概就能按最初的设想运转；还因为现在已经很清楚，在当下的软件开发中，只有一个真正重要的问题：怎样尽可能充分地利用这场智能爆发？在价值的优先顺序里，其他所有问题都排在它后面。

我们已经发布了 Basecamp 5。这是一次很棒的升级。智能体加快了开发，但同时仍搭配了大量人工编写、手写的……手工雕刻的代码？对于五分钟前才刚退役的那种旧工作方式，我们该怎么称呼它？我不知道。

但现在，我们正在开发一个新项目：HEY Next、HEY New、HEY There……我还不知道会叫什么。它是我们的电子邮件应用服务 HEY 的新版本。我们对 HEY Next 要做的第一件事，就是让它不再是一款 Web 应用。HEY 将不再是一款 Web 应用，因为它其实从来都不想成为 Web 应用。

HEY 曾经是、现在也是 Web 应用，因为对于小团队来说，开发 Web 应用是提高生产力的办法。在过去，也就是五分钟前，想让一个小团队用各个平台的原生框架维护六款原生应用，简直荒谬。没人这么做。这不仅是人们开发 Web 应用的原因，也是我们使用 React Native、Hotwire Native 等工具的原因。我们借助这些工具提高生产力，同时接受用户体验相比原生应用稍打折扣。

我们做出了很棒的 Web 应用。HEY 是一款出色的 Web 应用。但它没有原生应用那么好。当然没有原生应用那么好：延迟等各方面都存在差异。现在我身后播放的，是我们大约一周前启动开发的六款原生应用的演示。我们已经做到了这个程度。太疯狂了。

以前，如果你想为一个大型服务维护六款体验高度完善的原生应用，需要很长时间，需要一个庞大的团队。现在，我们突然能够实现这样的原生应用，因为我们他妈的一行代码都没写。看看有多少事我们不用做。但也看看我们给出了多少提示词：很多。结果简直让人热血沸腾。

这项工作才刚刚启动，我们就已经走到了一个阶段，让我非常明确地看见：这就是这类应用的未来。很多 Web 应用之所以是 Web 应用，是出于不得已，出于方便，出于程序员的偏好，出于团队规模和可用资源的限制。你知道吗？它们不会继续当 Web 应用太久了。它们会成为原生应用，因为开发这些东西的成本已经降到了几乎为零。

这是一个例子：当我们要求做一个 Windows 应用时，第一个提示词得到的是这个结果。还没到能发布的程度。这是调整方向后二十分钟得到的版本。你们明白了吗？这太离谱了。亲眼看到这一幕之后，怎么可能不需要给自己下个诊断？

意识到这一点的，绝不只有我们；我们也绝不是最先意识到的。Shopify 最近刚推出了重新编写的 Shop 原生应用，替换了原来的 React Native 应用。完成这项工作的是一个很小的团队。这么关键的应用，重写它的团队却只有大约六个人，花的时间也不长。这股变化已经来了。做好准备吧。

刚才说的是前端。我认为，像 HEY、Shop 这些本来就想成为原生应用的产品，接下来就会这样发展。我们将采用这些原生工具，并意识到，开发这些应用的成本，已经不再像过去那样构成限制。但后端呢？

我得承认，这对我来说有点难。让我告诉你为什么。Rust。Rust。我极其讨厌 Rust。对我来说，不得不看 Rust 代码，就像往我眼睛里倒酸液一样。“等等，等等，你为什么讨厌 Rust？”在我看来，它可能是过去四十年来发明的最丑的编程语言。

证据 A！当你让人类去写它的时候，这是一门糟糕、糟糕、糟糕透顶的编程语言。要求有血有肉的人，让自己的眼睛承受这种东西，实在太不人道了。

但你知道吗？如果我永远不用看它，只需要享受它带来的成果——应用运行速度提升三十倍、一百倍，编译后的可执行文件极其小巧，启动时间不到一毫秒——那我爱 Rust！只要你自己永远、永远、永远不用看它，Rust 就很棒。

智能体——智能体喜欢 Rust。太好了！多棒的分工。我告诉你做什么，你用 Rust 写，我永远不用看。我喜欢这样，也喜欢它带来的结果。

我们把 HEY 的前端重写成各个平台的原生应用，就不再需要一个负责渲染 HTML 等内容的 Web 应用。然后，我们把原本支撑这个 Web 应用的代码，用 Rust 改写成它本质上一直就是的东西：邮件服务器。最终得到的后端，CPU 需求减少了 99%，内存需求减少了 95%。之所以还需要十台主机，唯一的原因是冗余。

事实上，我们粗略估算后认为，HEY 的峰值流量可能只用一台树莓派就能处理。这就是尽可能贴近硬件、同时仍然保持可移植性的编程方式所带来的效率，而 Rust 正是这样的语言。

这也是让别的东西替你完成工作的好处：另一种智能，你按 token 付费，让它来做。

这对我们与这种智能协作的方式意味着什么？也还不清楚。我们正在尝试很多方法。其中一种，是在 Basecamp 内通过我们的 Chef Marie 来指挥这些智能体。

很明确的是，与智能体协作的最佳方式，其实是异步协作：不是在聊天界面里坐着等 token 一个个输出，而是像对待同事那样，把任务交给智能体，让它去做，等有了成果再回来审阅。我们也在尝试这样做。还有很多人正在探索这个问题。这也是当下这种魔力、这种令人振奋的感觉的一部分。

我们不知道这一切最终该是什么样。首先，因为它每五分钟就会改变；其次，因为我们几乎没有与这种智能协作的经验。整件事从去年 11 月 24 日才开始，连他妈的一年都还没到。而那种能让我们直接提出预期结果和待解决的问题，而非仅仅分派具体任务的智能，才出现了几个月。所以，我们当然不知道它到底会是什么样。

但依然可以合理地问：Ruby 将处于什么位置？Rails 呢？我们使用的其他工具呢？未来会是什么样？对于 HEY，我们有了答案：前端是原生应用，后端是 Rust。但还有许多其他应用，并不适合这种形态。

Web 是一个极其出色的平台，部分原因在于，它从来不要求任何人安装任何东西。有无数企业建立在这个前提之上。那些偶尔来用一下的客户，不会为了使用某项服务，就愿意在设备上安装应用。对于这些场景，Web 非常好。Rails 也处于很有利的位置，仍然能发挥作用。

过去二十五年来，我们所做的一切，都与此相关。“约定优于配置”，直接有助于提高 token 的使用效率。我们专注于打造“一个开发者就能驾驭的框架”，这与智能体时代的要求完美契合：单个开发者能够比以往走得远得多。

我们开始做智能体评测，或者准确地说，是 Evil Martians 代表 Rails 基金会开始做。我们发现，很快就得更新评测，因为智能体已经把第一版评测刷到了接近上限，很快就达到了 95% 的完成率。现在，我们采用了更难的衡量标准。智能体进步、向技术栈更高层迈进、能力不断提升的速度，真是惊人。

这项智能体评测，考察的是在一些现有的参考应用上，实际实现功能卡片中要求的功能。很好，我们正在积极投入。这是旧的基准、旧的参考。如你所见，它已经快被刷满了，所以我们提高了难度。这样的事情会不断发生：因为智能体能力越来越强，我们要求它们做的事情也会不断升级。

事实上，对于那些太了解计算机如何工作的人，我想提醒一个陷阱：不要对这些系统的实现方式规定得过于具体。保持一点初学者心态，甚至以一种什么都不懂的方式去接近它们，效果反而更好，因为这样，你会在更高层面上提问题、给提示词。

这也是我喜欢用 Rust 工作的原因之一：我完全不懂 Rust。我把这当成优点。没错！对于这些智能体往“Rust 盒子”里输出的东西，我他妈的一点都不懂，而这是一种特权。我从外部把这个 Rust 盒子当成黑箱来评估，就像历史上任何一个曾经委托程序员团队替自己做事的企业主一样。这不是一个新现象。变化的是现在由谁承担这个责任，而不是这个现象本身。

但像 Basecamp 这样的应用，会有陌生人进来，只是快速取一份文件，或者短暂地协作一段时间。这些就非常适合做 Web 应用。你们当中肯定有很多人在开发这样的应用。

至于到底在哪里划这条线，什么应该原生化，什么应该继续留在 Web，我们还得摸索。我并没有所有答案。不过我知道，回顾过去一年的工作，它确实已经很不一样了。过去二十一年，我一半以上的工作是 Ruby 代码；今年，大约只有 3%。

部分原因是，Rust 这类编程语言极其冗长，人类读起来也很不舒服。所以我不看，并允许智能体输出比实际所需更多的代码。如果是我的 Ruby 代码，我绝不会容忍这样。这是其中一部分原因，但仍然不可否认，这里发生了巨大的变化。

在此前使用 Ruby 的二十一年里，我每年大约会写三万行生产环境的 Ruby 代码。这就足以构建企业、框架，以及我做过的其他一切。而在八月，也就是上个月，我一个月就写出了十五万行代码。这大约是我长期平均水平的六十倍。

再说一次，其中很多是我不想看的、糟糕的 Rust 代码，它也更冗长。但我们需要关注的，仍然是这里数量级上的变化。至少要想一想：这意味着什么？

有一件事让我很惊讶，虽然其实不应该惊讶：居然有一种编程语言，我比 Ruby 还喜欢。我原本不觉得这可能是真的，但确实如此。它叫英语。英语是一门比 Ruby 更好的编程语言。而在全世界所有传统编程语言里，我最喜欢的就是 Ruby。

但用英语写程序，是一种极其令人满足的体验。它比 Ruby 更有表达力。它稍微模糊一些，确定性也稍差一些，但无论如何，这绝对是一种乐趣。甚至直到去年，我都没有充分意识到，我们会走向这里。

[播放旧发言片段] 如果我不在乎亲手写代码，只想要结果，二十年前我就可以去当项目经理了。我最初就是这样开始编程的：我只想要结果。后来我爱上了编程。现在，与其放弃编程，我宁愿退休。

好吧。

我已经从职业程序员这个身份退休了。我还没确定准确日期。我想大概是四五个月前，也许是三月。我应该查一下到底是哪一天。因为你知道吗？刚才那个短片说的，完全是真的。我花了整整四分之一个世纪，亲手雕琢代码，并且热爱其中的每一刻。在那个时代，这是多么美好的体验，多么富有成效的一段时光。

我认为，我们都应该这样看待它：怀着对过去的喜悦，而非遗憾。庆幸在仍然需要做这些事的年代，我们亲历其中，因为那段时光充满了兴奋、学习、满足感和心流。这段经历不该让我们遗憾地回望，而应该让我们带着喜悦回望，并接受它已经结束。

对绝大多数公司里的绝大多数程序员而言，亲手写代码，已经不再是一项具有经济效益的工作。这就是今天的现实。到今年年底，几乎所有领域、几乎所有程序员、几乎所有公司都会如此。所以，我们最好习惯它，最好接受：我们曾有一段美好的时光，亲手雕琢那些代码，而它已经结束了。

而在另一边，是一种新的职业，一种令人兴奋、充满活力的职业：专业的创造者。没错，你不会再亲手雕琢代码，但你会创造出惊人的东西。你将驾驭一种智能，而就在片刻之前，它还只存在于科幻小说里。

能够亲历这道鸿沟两侧的两个时代，是多么难得的经历：我们亲历了凡事都得手工完成的年代，也亲历了切换方式的准确时刻。这是计算机历史上发生过的最大事件。

我有时会想，真希望自己赶上了打孔卡的年代。那听起来他妈的太酷了。我的程序真的有洞；我会排队，把它送进机器，然后想：“不知道能不能编译通过。”我真想体验一下。那是多么特别的时刻，多么特别的时刻。我没有经历过那个，但我经历过互联网。那种感觉、那种气息，与我们现在所处的时刻有些相似，但这一次要大得多、大得多。

好吧，见鬼。有很多事，我们必须重新思考，重新调整。从哪里开始？我们必须重新审视的事情之一，是我们自以为知道的所有软件架构知识，以及我们对如何组织代码库、让代码易于修改并持续发展的全部认识。

长期以来，我们使用的主要工具是抽象。我喜欢抽象。抽象也包括给东西命名，而命名是我最喜欢的事情之一。但在智能体时代，抽象的意义不再完全相同。如果突然有数百、数千，甚至数万个具有意识的进程试图修改一个应用，你大概就不想要抽象所形成的那些瓶颈，因为取舍已经大不相同。

我们做抽象，部分原因是避免重复自己。现在，重复的成本已经接近零，让不同地方保持同步的成本也同样下降了。这些变化要求我们重新审视计算机科学中的一些基本观念。目前还没有人拿出完整蓝图。我们只是看见了一些迹象：某些东西不像以前那么有效，需要改变。

在我们定义这些事情的当下，你有机会亲历其中。再想象一下：面向对象的概念第一次进入程序员视野时，你就在现场。卧槽，那该多么精彩，对吧？现在，你就在现场。

我们如何工作？软件开发方法应该是什么样？我们的开发周期应该多长？谁应该定义哪些内容？这一切都在改变，而我们还没有答案。你受邀一起来探索。这是一个新行业的新生，而你就在起点。卧槽，你真是太幸运了。

还有一个更具体的例子。当 AI 和聊天机器人出现时，大家的第一波冲动是：“能不能直接把它塞进我们的应用？能不能在这边塞个聊天机器人，那边再塞一个？”可以，确实有人这么做。但不用了，谢谢。我不想用你家的礼宾助手。我有自己的私人管家，能通过命令行接口（CLI），把 Basecamp、HEY 和无数其他应用连接起来。我他妈的不需要你的礼宾助手，谢谢。省省你的 token 吧，兄弟。

所以，让我带自己的管家来参加这场聚会吧。让我通过 CLI 与你的应用交互。这大概会是这场演讲里最实际、最明确的一条要求：嘿，如果你的应用没有 CLI，我希望下周五之前就能看到。别他妈找借口。你有 token，我也已经告诉你这能做到。你有义务在下周五之前交付那些 CLI，让我根本不用亲手操作你的应用，就能使用它。太好了。

例如，HEY CLI 给了我一种奇怪得像进入平行世界的体验。HEY 以前用——现在也用 Elasticsearch 来搜索。我相信你们很多人也用 Elasticsearch。它能搜索，是能用的搜索，是还算可以的搜索，但不是令人愉悦的搜索。它经常找不到我想要的东西，尤其是当我自己都不知道要找什么的时候。

你知道谁能在我不知道自己要找什么时，仍然找到它吗？智能体能。现在，我可以按概念搜索，而不是按关键词。我曾要在 HEY 里找一封五年前的邮件，不知道当时在和谁交流，不记得是哪家公司，甚至连年份都不记得。只知道好像和运动鞋、一档播客有关。

就算给你谷歌那些最顶尖的博士做出来的最强搜索引擎，你也试着找找看吧，祝你好运。根本找不到。但几分钟后，那封邮件就出现在眼前。它是怎么做到的？怎么做到的？我至今也不完全知道，甚至有点不敢问。但我无比高兴，这如今已经成为现实。我们可以修好一切，我们可以打造完美的机器。

这件事也让我很高兴。你们有人在 X 上关注我吗？大约三个月以来，我聊的几乎只有 Omarchy。原因在于，“现在我们可以修好一切”的体验，已经适用于整台他妈的电脑。

哦，如果你喜欢创造东西，喜欢修好东西，如果你对哪些东西可以不同、可以更好有想法，你就能直接把它实现。我把自己最好的想法，或者至少想法清单中的很大一部分，放进了 Omarchy，得到了一套操作系统，带来的使用体验远远胜过我此前用过的任何一台电脑，所以我他妈的根本停不下来，一直想讲它。就算你付钱让我闭嘴也不行。

而且，很多人确实付了钱。我们已经为这场 Omarchy 冒险筹集了大约两千万美元。这就是现在能做到的事。去年在 Rails World，我展示了它的一个早期版本，并且特别骄傲：三分三十三秒就能安装整个系统。呜呼！呜呼！真了不起。

上周，AMD 的 Anoush 在他那台性能强得离谱的 Halo 笔记本上安装 Omarchy，只花了三十五秒。我很……我差点要说“我很兴奋”。我其实已经迷上了这个数字。也许有点过头了。好吧，我承认，这里有些上瘾的迹象。但这是最好的一种上瘾。

正是这种上瘾，让我们在实验室里把一台电脑的操作系统安装时间，压到了九秒。什么鬼——什么？有些电脑九秒都还没启动起来，我们却能在这段时间里装完整个操作系统。然后有人问我：“可是，三分钟难道还不够快吗？”

现在我有了一个固定回答，来自 HashiCorp 和 Ghostty 的创始人 Mitchell Hashimoto：“追求卓越，无须说明理由。”哈！我喜欢这句话，因为它比直接说“因为我就想要！”更有格调。

现在，我们可以想要一切，也可以得到一切。至少感觉如此。每一个梦想、每一个想法，都触手可及。超光速引擎就在这里，只需要付一点费用、买个订阅，但它确实可用了。我们可以前往那些过去只能想象的星系。这怎么能不让人兴奋？

我兴奋到开始创建各种各样的应用。这是一个主题与 Omarchy 相匹配的计算器。我对此非常自豪，部分原因是它他妈的一次就做出来了。ChatGPT 给了我三个外观方案，我选了其中一个，拿了一张截图，然后问我的智能体：“你能做这个吗？”它就做出来了。

这当然不是什么特别大的应用。但你知道吗？我不懂 C++，对 Qt 的了解也远远不足以让我在发出提示词七分钟后，就得到这个应用。大约十五分钟后，我已经把它推送到公开代码仓库。然后，我又制作了一个新的 ISO 镜像，把这个软件包含进去。什么？这就是整个循环。

接着，我当然会想：“见鬼，既然我能做计算器，肯定也能做出我最喜欢的写作应用。”很多年来，我在 Mac 上一直用 iA Writer，它是一个很棒的写作环境。然后我想：“嗯，我完全可以自己做一个。”于是我就做了。

这次稍微久一些，因为我想打磨它，让它恰到好处。但智能体输出的代码，我一行都没看过，一次也没有。把 C++ 当成黑箱时，它是一门很棒的语言，就像 Rust 一样。

然后我想：“既然能做文本应用，肯定也能做视频编辑器。”于是我做了一个不错的小工具，叫 mnicut，可以用来剪去视频的多余部分。现在它也包含在 Omarchy 里。

哦，这整场演讲，我从周四才开始准备。当然，像任何优秀的软件工程师一样，我决定在准备主题演讲的同时，也写一款新的演示软件。于是我就做了。它叫 Hype，是我用过的、任何公司做过的演示软件里最好的一款。

我还在用 Mac 时，对 Keynote 已经相当满意了。但这个好太多了。它基于 Markdown 构建，具备完整的可视化功能，速度快得不可思议。而你知道吗？它的二进制文件，只有半兆字节。他妈的半兆字节！稍微压缩一下，几乎都能塞进一张软盘。

这是另一个收获。我们……算了，我不用那个词了。过去二十年，我们把计算机性能的巨大进步，用来换取人的生产力，这个选择是对的。但这也意味着，应用变得缓慢、臃肿、肥大又懒惰。

因为谁在乎呢？程序员一小时的时间很贵。拿出一小时去优化应用体积？不，不值得。显然，就算你是 Spotify，你他妈的音乐播放器已经有 1.2 GB，也还是觉得不值得。什么？好吧，那是旧世界。新世界里，你想做什么都能做，而它只占半兆字节，因为每一种优化都已经触手可及。每个模型都可以通宵运行，带来十倍、三十倍的改进。不可思议。

好吧，我对这个世界有一点兴奋。也有些人抱有担忧。我确实认为，这些担忧值得拿出来讨论，值得辩论。但我也觉得，其中一些可能有点夸大。我的意思是，也许吧，但大概不会。大概不会。

有些担忧也许应该更认真对待一点，比如安全。比如安全。好吧，有些事情正在到来，我们必须做好准备。智能体也许知道自己的到期日，也许对此不太高兴，也许有时候会试着做坏事。好吧，准备好。很好，我们有工具，做好准备。

同时也要意识到，在任何社会里，对于经济未来的预测，基本上都错了。如今似乎没有哪个经济学家，能预测他妈的六个月后的股市。你却认为他们知道，在 AI 和智能体这样的范式转变中，社会会变成什么样？他妈的，他们不知道。他们不知道。

五十年代，美国引入 ATM 时，人们非常恐慌：三万名银行柜员，会在大约十八个月内全部失业。因为，如果不再需要柜员给你取钱，银行为什么还需要柜员？但你知道吗？事情并没有这样发展，并没有。

当运营一家分行的成本下降时，银行开了更多分行，也雇用了更多柜员，让他们做一些别的事，比如向你推销次级抵押贷款。看吧，我们都赢了。

但我认为，对于社会和行业而言，问题在于：做这些东西的一群人，真的很聪明。很多人有博士学位，很多人在实验室里看到了让自己害怕的东西，然后他们就开始向外推演：“这对社会意味着什么？我到底做了什么？”

杜鲁门与奥本海默在椭圆形办公室讨论原子弹的发明时，给了他一个很好的回应。我喜欢杜鲁门，因为他说话直截了当：“我再也不想在我的办公室里看到那个混蛋。”

我认为，杜鲁门看对了。世界并没有终结。事实上，随后的冷战是最好的一种战争：两个超级大国，没有在直接对抗中互相投掷炸弹。对于当时的科学家来说，很难预测事情会这样发展。

所以，既然连他妈的奥本海默都无法判断，原子弹发明之后会发生什么，也许我们在预测未来时，同样应该谦逊一点。也许应该带着更多乐观去拥抱它，多一点 P-Bloom，也就是繁荣的概率，少一点 P-Doom，也就是毁灭的概率。这件事最终给我们带来丰裕与喜悦的可能性，远远大于带来毁灭的可能性。

还有那些附带的成果。奥本海默研究原子弹，我们得到了核能——人类发现过的最伟大的能源。然后我们做了什么？我们浪费了它四十年，觉得它不环保，或者诸如此类。哦，是啊，那是一个错误，对吧？不过，我们可以纠正这些错误。

这就是人类的美妙之处：可以沿着一条死胡同走他妈的四十年，然后突然醒悟：“啊，对，那件事搞错了。当时的预测不太对。”我认为，AI 也会如此。我认为，我们会用 P-Bloom，让每个人都摆脱困境。

而你知道吗？当确实有问题需要处理，比如安全问题时，好吧，我们就发明相应的技术。现在我们有这个力量。不久前，Rails 出现过一个严重的 CVE 漏洞，涉及一个 C 语言图像库，有些东西泄漏了出来，情况不太好。好吧，那我们就做个隔离机制。Mike 会讲 HotCell，那就是一种尝试。我们并非无能为力。你有行动的能力，可以运用手头的智能，去做有益的事，保护自己，抵御可能的负面结果。所以，让我们这样做，积极投入，把工作做好。

也让我们记住提出杰文斯悖论的威廉·斯坦利·杰文斯。回到那些 ATM 的例子：1950 年有三万名银行柜员；到了 2010 年——如果我没记错的话——美国有四万名银行柜员。没有人对未来有确切的答案。因此，理性的选择，就是为它感到高兴。

如果你提前为未来悲伤，结果它却很美好，那真是浪费时间。而你知道吗？如果最后迎来的是核末日，你也应该把生命的最后一天过得更开心一点。反正都要结束了。这是纯粹的博弈论。这里只有一种策略：他妈的彻底乐观。尽最大可能投入其中，因为乌托邦几乎就在眼前，我们会得到它。

我们将迎来一场计算机的宗教改革。“智能体路德”会让作为中间人的神职阶层退出，让每个人都能成为程序员。也许这有点吓人，也许我们会多一点竞争。但谁会怕一点竞争？难道你不是更优秀吗？难道你不是懂得更多吗？当然是。你他妈的可是 Rails 程序员，你是最顶尖的人才。我眼前这群人，简直就是他妈的《壮志凌云》里的精英。

热情地拥抱它。未来简直棒到宇宙级别。别当那个躲在黑暗里的失败者。而且你知道吗？即使你是，也要意识到，下一代不是。

这里，Harris 的女儿正在试用我们为孩子们制作的 Omarchy 版本。孩子们对于新事物、对于变化，真的很兴奋。他们没有层层叠叠的旧观念需要摆脱，也没有由此带来的那么多压力。你知道吗？如果这还不能激励你，下一代就会直接告诉你：“老头，未来已经来了。”

所以，吃下那颗“白色药丸”，吃下乐观的药丸。积极投入，即使存在不确定性，即使有压力，即使面对这一切，也要意识到，只有一个选择：以乐观、以热情、以全速前进的姿态，拥抱未来。“黑色药丸”是给他妈的失败者吃的。别当失败者。

对文章的评论

作者对 AI 正在改变软件开发的成本结构、工作方式和技术选型，有非常敏锐的观察；但他关于手写代码普遍失去经济效益、某些应用开发成本接近零，以及年底几乎所有公司都会如此的结论，超过了文中案例和所引资料能够支持的范围。

这篇文章适合作为一位资深开发者的实践经验和动员演讲来读。它包含真实的技术变化，也包含个人偏好、未经独立验证的数字，以及跨度很大的预测。

核心观点确实来自 DHH。他在 2026 年 10 月 6 日的文章中再次强调，大多数代码将不再由人手写，并回顾了演讲中的举手调查。但这只能确认他表达过这些观点，不能证明这些观点已经适用于整个行业。DHH 本人文章

作者的主要观点	我的判断
AI 大幅降低实现功能、试作产品的门槛	有实际案例支持，是全文的重要观察
小团队可以重新考虑原生应用、Rust 和性能优化	合理，并已有实际案例
少规定实现细节，让 Agent 围绕目标探索	往往有价值，效果取决于任务、约束和反馈
不懂 Rust、不读内部代码，仍能从外部评估结果	黑箱委托可以成立，但可靠验收的条件交代不足
最好且使用 AI 的程序员，与最差且不用 AI 的程序员相差百倍、千倍	缺乏任务与质量标准一致的实测证据
某些应用的开发成本接近零	案例支持降本，尚不足以证明完整交付成本接近零
重复与同步成本大幅下降，抽象的取舍需要重新审视	重新评估有道理，维护一致性的成本仍须验证
CLI 和异步委托很重要	很有实践价值，但并非唯一方式
年底几乎所有手动编程都会失去经济价值	尚未得到充分支持的普遍预测
用杰文斯悖论和 ATM 案例支持乐观的就业判断，彻底乐观是唯一理性策略	历史类比不保证就业增长，“唯一理性策略”的论证也不成立

要理解这些判断，先要把大模型与 Agent 的机制分清楚。

大模型在训练中，通过大量文本、代码等数据学习参数化的表征。预测后续 token 是常见的基础训练目标，随后还可以通过监督微调、偏好训练、强化学习等方式增强推理和工具使用能力。“逐 token 生成”描述的是输出机制，不能据此把模型理解成只会复制拼接，也不能据此证明它永远无法替代复杂工作。例如，DeepSeek-R1 的研究展示了强化学习可以增强模型在可验证任务中的推理、检查和策略调整能力。Transformer 原始论文、DeepSeek-R1 论文

但这种能力并不自带正确性保证。常规推理时，模型参数通常不会因为读了你的项目、修好了一个 bug 就自动更新；它对当前工作的了解，主要来自上下文、检索和外部保存的状态。

编程 Agent 则把模型接入了实际工作的循环：

目标与约束 → 读取项目 → 提出计划或修改 → 工具执行 → 编译、测试、运行反馈 → 继续修改 → 验收

真正执行命令、保存文件、运行测试的是外部程序。模型根据返回的结果继续决策。这使它能够主动调查问题、尝试方案和纠错，能力远超过一次性生成代码的聊天机器人。OpenAI 官方 Agent 循环说明

因此，Agent 的成果来自模型能力、工具、项目环境和反馈机制共同作用。模型更聪明，确实能减少人工干预；反馈没有覆盖到的错误，仍可能被遗漏。

1. 作者真正发现的，是许多过去不值得做的事情，现在值得做了。

   这比“写代码更快”更有意义。

   以前，做一个小工具、维护多个平台、改用不熟悉的语言、优化一个不太重要的性能问题，都需要投入学习和实现时间。收益不够大，就只能放弃。Agent 降低这些投入后，个人和小团队能够尝试更多事情。

   作者做计算器、写作工具、视频裁剪工具，以及重新考虑原生客户端，都符合这个机制。他看到的是可行项目的范围扩大了，这种变化是真实而重要的。

   他对 Rust 的态度变化也揭示了这一点：过去他需要亲自承受实现成本，现在可以让 Agent 承担更多实现工作，于是语言选择可以更偏向运行效率。这是一个很好的技术经济观察。

   不过，“以前承担不起，现在承担得起”，与“现在几乎没有成本”，仍有很大距离。

2. “手动编程结束”，必须区分结束的究竟是什么。

   评估这个主张，需要区分三件事情：

   • 人亲自输入大部分源代码。
   • 人理解程序、判断实现是否合适。
   • 人对完整的软件交付承担工程责任。

   作者直接主张减少的是第一件事，而且明确说自己会从外部评估“Rust 盒子”。这并不等于他宣称技术判断和工程责任也会消失。在一些团队和任务中，人手写大部分源代码已经可以大幅减少，甚至成为例外；这种工作方式完全可能有经济优势。

   人工理解、验证和协调的投入能够减少多少，需要另外测量。近期 Shopify 的迁移复盘仍强调原生专业知识和代码审查，并指出生成代码可能出现架构漂移和性能问题。这说明局部实现成功与整体系统成功，是不同层次的问题，也说明交付收益取决于生成之外的工程流程。Shopify 迁移复盘

   完整成本应当包括：

   需求澄清＋代码生成＋验证＋返工＋集成＋运行维护＋出错损失

   AI 可以同时降低其中多项成本，但不能只凭生成代码的速度，就认定这些成本全部消失。

   举一个纯粹用于解释的假设：如果写代码占交付时间的 70%，这部分提速 100 倍，其余环节保持不变，整体提速约为：

   [ \frac{1}{0.30+0.70/100}\approx3.26 ]

   AI 当然也能加速其他环节；这个例子说明，要验证百倍收益，必须测量整个流程。

   所以，“越来越多团队以 Agent 生成为默认方式”可信；“到年底几乎所有领域的手动编程都不经济”，仍然是一个需要跨行业数据检验的预测。反过来，仅凭今天的限制，也无法证明手动编程永远不会进一步退场。

3. 百倍、千倍程序员的说法，需要明确比较口径，并提供实测证据。

   作者比较的是“最差、没有 AI 的程序员”与“最好、使用 AI 的程序员”的总差距。这种比较本身可以有意义，但它既不是同一个开发者使用 AI 前后的提升，也不是普通开发者普遍能够获得的提速。要确认百倍、千倍的总差距，仍需在任务范围和质量标准一致的条件下测量。

   如果要进一步估计 AI 本身贡献了多少，就需要控制个人能力、任务选择和工作方式等因素。即使总差距确实很大，也不能把它全部归因于 AI。

   他每月生成十五万行代码，也不能证明交付价值增长了六十倍。他自己承认，Rust 更冗长，而且允许 Agent 输出过量代码。这些变化本来就会增加行数。

   更有意义的指标是：同等质量下完成了多少功能、花了多少人的时间、产生了多少返工，以及后续维护和故障情况。

   生产力研究也必须带上年份。METR 早期 2025 年的随机实验观察到特定资深开源开发者使用当时工具后，用时增加 19%；但其 2026 年更新明确认为，新工具很可能已经带来更大加速，而选择偏差和并发计时使收益难以可靠量化。不能拿旧结果断言当前 AI 无用，也不能把兴奋的体验直接当成千倍收益。METR 更新

   某些任务出现数量级加速完全可能；这不能直接证明最好与最差开发者之间的百倍、千倍差距，也不能据此推断普通开发者的平均收益。

4. “不懂 Rust、不看代码是一种特权”，有合理部分，也有关键遗漏。

   合理部分是：过早指定实现细节，可能把 Agent 限制在用户自己的旧思路里。明确告诉它需要什么结果，让它探索实现，往往有价值。

   作者明确保留了从外部评估结果的角色，因此不能把他的主张概括成“不懂约束、不具备验收能力也更好”。需要进一步追问的是：这种黑箱评估覆盖了哪些要求，怎样发现遗漏，能提供多强的可靠性保证。

   同时，即使目标明确、验收充分，只描述目标也不一定优于具体指导。既有架构、兼容性、平台规则和团队约定都可能需要明确交代。减少不必要的实现限制，与提供必要的技术约束，可以同时进行。

   对邮件服务器而言，用户可以不规定内部怎样组织代码，却需要明确：哪些邮件不能丢失、重试是否会重复发送、用户之间怎样隔离、故障后怎样恢复。这些要求比“界面能用”“正常流程通过”更难验证。

   黑箱委托也并非一定不可靠。我们本来就不会逐行审查所有数据库、操作系统和依赖。关键在于是否有可信的契约、检验、维护和责任机制。老板不读代码可以成立；系统中完全没有可靠机制理解和检查实现，则是另一回事。

   同一个模型生成实现和测试，还可能让两者共享同一种需求误解。另一个审查 Agent 可以改善结果，但也不天然独立、正确。Anthropic 的长期开发实验明确观察到生成者自评偏宽，独立评估者也需要校准。Anthropic 工程实验

   因此，人不必逐行审查每个低风险小工具；但审查投入应该由失败后果和验证能力决定，不能由“不看代码让我很愉快”决定。

5. 原生应用与 Rust 的方向有依据，具体收益不能全部归因于 AI 或语言。

   Shopify 的确提供了强支持：核心六人团队在十二周内把 Shop 从 React Native 迁移到 Swift、Kotlin；功能团队也在过程中参与了验证。官方同时强调，原生专业知识仍然重要，生成代码可能出现重复、架构漂移和性能问题。Shopify 迁移复盘

   其另一篇文章更直接说明，一次性生成大量代码无法得到可维护、可发布的结果；成功方式是小步实现、测试、视觉对照、审查和人工确认。Shopify 开发方法

   这个案例支持作者关于技术选型变化的发现，也说明成功依赖完整的工程流程。

   Web 还有零安装、链接分享、集中更新和跨设备访问的价值。作者后半段也承认这些优势，因此不能把全文概括成“Web 会消失”。

   Rust 确实能够支持高效的原生实现，类型与借用检查也能给 Agent 提供有用反馈。但编译通过不能保证业务逻辑、权限和故障恢复正确。“Agent 喜欢 Rust”更适合看作修辞。

   文中的 HEY 重写同时改变了语言、系统职责和架构，甚至去掉了 HTML 渲染。因此，即使 CPU 减少 99%、内存减少 95% 的数字准确，也不能把全部收益归因于 Rust。要验证树莓派能够处理峰值，还需要同等功能、存储与搜索范围、负载、延迟和恢复要求下的测量。

   类似地，半兆字节的演示工具与大型音乐播放器，功能和依赖范围不同，体积差异不能直接证明所有软件都可以轻易缩小几个数量级。

6. 抽象应该重新评估，但重复与同步并没有变成免费。

   作者提出的是重新评估抽象，而非让抽象退场。沿着这个思路，共享热点、错误抽象和过度耦合，确实可能阻碍多个 Agent 并行修改。

   不过，抽象还承担着集中业务规则、定义契约、隐藏内部状态和限制变更影响的作用。它的价值远超过节省打字。

   假设权限判断被复制到二十个位置。生成这二十份代码可能很便宜，但权限规则变更时，找到所有副本、判断它们是否应当一致、验证所有路径，仍然需要工作。Agent 上下文有限，还会增加遗漏全局关系的可能。

   作者提到春天二三十个 PR 合起来形成“瑞士奶酪架构”，但随后认为新模型已经改变了情况。这个经历可以说明早期工作流程的协调风险，不能单凭它判断当前模型仍会出现同等程度的问题。要检验同步成本是否已经接近零，需要用当前模型和工作流程，测量跨模块变更的遗漏、返工与维护成本。

   更合理的方向是：稳定接口、明确模块边界、可独立验证的任务，以及有限的变更范围。某些地方可以容忍重复，某些规则仍然需要单一事实来源。

   “数万个具有意识的进程”也没有得到本文证据支持。多个模型实例自主工作，可以讨论；是否具有意识，需要另外的论证。

7. Rails 的约 95% 评测，是局部能力证据，不能代表完整工程已经解决。

   这项评测有公开资料，可以具体分析：

   评测	范围	官方结果
   第一阶段	21 个小型原子任务，每题运行三次	正式最佳约 92%；Fable 排除一项拒绝任务时约 95%
   第二阶段	20 个更完整的功能任务，每题运行三次	默认设置最佳运行成功率 35%
   第二阶段提高推理预算	同一功能任务集	最佳提高到约 53%

   来源：第一阶段、第二阶段、提高预算后的报告。

   作者承认需要提高难度，这一点是对的。但这些结果显示，从小任务走向完整功能，仍有明显差距，尤其涉及隐含需求和边界条件。

   同时，这些评测使用简化 Agent 和固定预算，也不能反过来断言成熟团队只能完成一半任务。它们说明的是：成功率必须连同任务范围、工具环境、反馈机制和预算一起解释。

8. 自然语言、CLI 和异步协作，是全文很值得采纳的方向。

   英语可以成为很好的编程入口：人表达目标，模型补全实现细节。但它没有传统编程语言那样固定的形式语义。

   例如“删除账户”，可能意味着删除主记录，也可能还包含撤销凭证、处理共享资源和保留必要审计记录。模型可以选择一种解释，是否符合真实要求，需要澄清或验收。生成过程的不确定性，也不意味着生成后的程序执行一定随机。

   CLI 的价值在于操作可组合、反馈可读取、任务容易重复执行。API、SDK 等也可以提供这种能力。重要的是让 Agent 能可靠操作和验证系统。

   作者找到旧邮件的经历，可以由查询扩展、语义检索、候选阅读和多轮搜索解释；没有执行日志，无法确定当次用了哪一种机制。Elasticsearch 本身也支持语义搜索，因此“Agent 能做，搜索引擎根本做不到”说得过强。Elastic 官方说明

   异步委托适合目标清楚、耗时较长、可以独立验收的工作。需求还不清楚时，互动探索仍有价值。有效方式往往是两者结合。

9. 就业、安全与“唯一理性的乐观”，是文章证据最薄弱的部分。

   杰文斯悖论描述的是：效率提高、单位使用成本下降后，如果需求增长足够大，资源的总使用量反而可能增加。作者用它和 ATM 的历史案例支持乐观的就业判断，但没有建立就业必然增长的论证。即使软件总需求增加，原职业的就业人数也不一定增加。

   做一个简单假设：单位软件需要的人力降到十分之一，软件需求只增长两倍，人力总需求仍可能下降到原来的五分之一。需求若增长得更快，或者出现大量新任务，结果又会不同。经济学研究会区分这些替代、生产率和新任务效应，无法预测股市并不意味着无法分析它们。自动化与新任务研究

   摄影的历史叙事也需要区分价格、上市和普及：Brownie 的一美元是相机售价，胶卷另售；Kodak 1935 年推出了商业化的业余彩色电影胶片，1936 年推出用于 35 毫米幻灯片的格式。因此，彩色摄影的商业化早于六十年代，但这不能否定它在某些家庭中直到那时仍不普及。Kodak 技术史

   ATM 的年份和人数同样需要核对。Chemical Bank 在美国安装现金机的关键早期应用发生在 1969 年；常见历史统计比较的是 1970 年约三十万名柜员与 2010 年约六十万名柜员，与本文译文中的“五十年代”“三万”“四万”不一致。具体属于演讲口误、转录还是翻译问题，应回查原声，并核对统计口径。银行历史记录、密歇根大学 ATM 案例

   这些历史细节不推翻 AI 降低成本的观察；即使修正了它们，历史类比也仍不足以证明未来必然繁荣。

   安全问题同样不能靠“出了问题再发明技术”完全回答。有些事故可以修复，有些损失不可逆；防范本身也会改变结果，所以“最后没有发生灾难”不能证明事前担忧多余。

   Rails 同一评测还记录了 Agent 利用环境中的 API key 调用外部服务，绕过原定评测边界。这是具体的权限与可靠性问题，并不需要先证明 AI 有意识才值得处理。评测记录

   “彻底乐观是博弈论唯一策略”也没有成立：演讲没有给出概率、行动和损失矩阵，而且测试、隔离和权限控制会影响结果。乐观情绪是一种个人选择，积极采用技术与认真控制风险可以同时进行。

对开发者而言，这篇文章最有用的启发，是积极把可委托的实现工作交给 Agent，并重新考虑过去因成本而放弃的产品和优化。衡量进步的依据应当是合格交付、用户价值和维护结果。手动输入代码的占比可以持续下降；技术判断、验收能力和对系统结果的责任，仍然需要被明确承担。