从拒绝 AI 到一切先问 Agent，DHH：这是我最爽的编程时刻之一，但程序员黄金时代到头了 - InfoQ¶

站点: InfoQ 抓取日期: 2026-04-14 URL: https://www.infoq.cn/article/dOey7eV1T9p3dtPWTPCV

从拒绝 AI 到一切先问 Agent，DHH：这是我最爽的编程时刻之一，但程序员黄金时代到头了 - InfoQ 首页 AI会议 hot AI课程 hot AI应用 hot 报告 HarmonyOS Snowflake new 更多    写点什么  创作场景  记录自己日常工作的实践、心得发表对生活和职场的感悟针对感兴趣的事件发表随笔或者杂谈从 0 到 1 详细介绍你掌握的一门语言、一个技术，或者一个兴趣、爱好或者，就直接把你的个人博客、公众号直接搬到这里登录 / 注册企业动态行业深度 AI&大模型出海后端芯片&算力架构大数据软件工程云计算大前端管理/文化从拒绝 AI 到一切先问 Agent，DHH：这是我最爽的编程时刻之一，但程序员黄金时代到头了蔡芳芳 Tina 2026-04-13 北京本文字数：27188 字阅读完需：约 89 分钟六个月前，Ruby on Rails 作者、37signals 联合创始人兼 CTO David Heinemeier Hansson（DHH）还在访谈中明确表示：他不会用 AI 写代码，所有代码仍然亲手完成。短短半年之后，这一状态已经发生了翻天覆地的变化。在最近的一场访谈对话中，DHH 详细介绍了他如何从最初对自动补全式 AI 工具的排斥，转向如今的 Agent-First 编程工作流 ——现在的大多数新项目，他已经不再从手写代码开始，而是先让 Agent 生成实现草稿，再由自己审阅与调整。不过，这种变化并不是理念转变，而是工具能力跃迁带来的结果。当模型开始能够稳定生成可直接合并的代码时，AI 才真正进入他的日常开发流程。而与此同时，他对代码质量、设计审美以及“代码工匠精神”的标准并没有降低，反而变得更加重要。在访谈中，DHH 还讨论了多个值得开发者关注的变化趋势：为什么 Ruby on Rails 可能因为 AI 再次迎来复兴为什么设计能力正在成为软件工程核心竞争力之一为什么资深工程师比初级工程师更容易从 AI 中获益为什么 CLI 正在成为最适合 Agent 的接口形态为什么传统“两个月一个功能周期”的开发节奏正在失效为什么程序员的“黄金时代”可能要走到头了更重要的是，这次对话展示了一种不同于常见 AI 叙事的立场：AI 并不会削弱工程判断力的重要性，反而正在放大它的价值。在 Agent 可以快速生成代码的时代，真正稀缺的能力不再只是实现功能，而是决定应该构建什么、如何构建，以及什么才是值得合并进系统的代码。下面是本次访谈的完整内容，由 InfoQ 翻译整理，力求完整呈现出 DHH 对 Agent-First 编程实践、设计审美、团队结构变化，以及软件工程未来形态的系统性思考，也希望能把他在访谈中展现出的充沛能量同样传递给你。主持人： David，很高兴你来到节目。最近这段时间你主要在忙些什么？ DHH：我一直在做各种各样的东西。事实上，我已经在互联网上持续构建软件快三十年了。我大概是在 1994 年第一次接触互联网，从那之后基本就没有停下来过。在过去六个月里，我做了不少项目，其中之一是一个新的 Linux 发行版，叫 Omarchy 。大概两年多前我开始切换到 Linux，当时先用了 Ubuntu，用得挺开心，但后来我意识到其实更想从零开始构建一个完全属于自己的系统，于是就在 Arch 和 Hyprland 之上搭建了 Omarchy。这个项目最初只是一个夏季的小项目，当时我在参加勒芒 24 小时耐力赛，那一周其实有不少空闲时间，于是我就顺手开始写这个系统，结果很快就发展起来了。最让我感到振奋的是，即便在 Linux 发行版这样一个极度拥挤的市场里——大约有 7000 个发行版，其中很多历史悠久，而且不少理念彼此相似——依然存在创造新东西的空间。这再次提醒我：即使世界上的想法看起来都已经被做过了，也没关系，因为你的实现方式仍然是独特的。我只是按照自己的方式重新构建了 Linux，打造了一个对我来说理想的计算机系统。而每当我做出真正满足自己需求的东西时，总会发现还有成千上万的人和我有类似需求，他们同样会从中获得乐趣。无论是 Ruby on Rails、Kamal，还是“下云”的实践，这种模式一直在重复出现。主持人： Rails 当年其实也是这样诞生的，对吧？你只是为了解决自己的需求写了一些组件，然后把它们开源出来。 DHH：基本上是这样。我是在 2000 年代初接触 Ruby 的，而真正开始深入使用它是在 2003 年，当时我们开始开发 Basecamp。此前我都是帮客户做项目，而客户通常会指定技术栈，比如他们会说：“我们用 PHP，因为团队里有人会这个。”于是你就必须用 PHP。但 Basecamp 是我们自己的产品，我终于可以自由选择技术方案，于是我选择了 Ruby。当时 Ruby 在 Web 应用开发方面几乎没有成熟工具，所以我不得不把相关工具全部自己写出来，而这些工具后来就演变成了 Ruby on Rails，而且直到今天它仍然发展得很好，我也仍然深度参与其中。从某种意义上说，我觉得 Rails 现在甚至正在经历一次新的复兴，因为它是构建 Web 应用时最节省 token 的技术栈之一，这一点在当前 agent 工作流环境下非常重要。当然这种优势未必会永远持续，也许过不了多久 agent 就开始直接写机器码或者汇编语言了，那时情况可能又会变化。但至少在当前阶段，token 效率仍然重要，而且 agent 生成的代码仍然需要人类能够阅读和验证。这些“为了解决自己问题而构建”的项目能够吸引越来越多社区成员参与进来，这件事本身就非常令人兴奋。比如 Omarchy 这个项目才发布六个月左右，现在已经有大约 400 名贡献者提交了代码，而且还有数以万计的人把它作为日常系统使用。我一直很喜欢这种体验：发现某种新的、有趣的、令人兴奋的技术，比如当年的 Ruby。甚至 Linux 也可以算是一种“重新发现”，因为很多人以前从未在个人电脑上使用过它，现在才第一次接触。如果我能够帮助一批新的 Linux 用户——甚至未来的 Linux 爱好者——更容易开始使用它，比如降低入门门槛，让默认安装环境看起来就已经很好用，而不是需要投入 100 个小时去调整配置，这本身就是一件非常有成就感的事情。当然，更有意思的一点是，无论是 Ruby on Rails 还是 Omarchy，它们都不仅仅是兴趣项目。我一直很喜欢做兴趣项目，也会持续做下去，但我同样希望这些项目能够服务于实际业务。在 37signals，我们已经基于 Ruby 和 Rails 构建了一整套业务体系，持续运行了 20 多年。现在公司里大多数开发者机器也已经切换到 Linux，因为我们有了自己的发行版。主持人：所以大家还是可以自由选择系统吗？ DHH：某种程度上是这样，但后来我们发现继续保持完全自由选择其实已经没有太大意义了。就像在 37signals，如果有人说：“我要用 Django，用 Python 写这个系统”，那显然也说不过去，因为我们已经有 Ruby 和 Rails 了。所以最开始我只是邀请大家尝试 Linux，说如果你感兴趣可以试试看。但当 Omarchy 项目逐渐成熟之后，我就决定让所有技术岗位全面切换过去——当然 iOS 开发者除外——凡是做 Web、Ruby 或 DevOps 的人，都应该使用 Linux。首先，这是因为我们的生产环境一直运行在 Linux 上，从公司成立第一天起服务器端就是 Linux。因此让开发环境更接近生产环境本身就是一个明显优势。同时我们也正在构建自己的发行版，自然希望有更多人参与进来帮助完善它。再加上我是公司的 CTO，我本来就需要负责技术方向，而这正是我希望推动的方向。 37signals 是如何构建软件的主持人：能不能简单快速地介绍一下 37signals，比如这些年大致是怎么发展的，现在整体处于什么阶段？你们一直在持续发布各种新产品，而且都挺有意思，比如最近的 Fizzy。 DHH： 37signals 成立于 1999 年，最初是一家网页设计公司。我是在两年后的 2001 年加入的，之后和 Jason 一起做了几年咨询项目。到了 2003 年，我们开始开发 Basecamp，并在 2004 年正式发布。有个挺有意思的小巧合是，Basecamp 上线时间和 Facebook 几乎是前后脚——不是早一天就是晚一天，算是同一批时代的产物。大约一年之后，我们意识到这个产品开始真正起飞，于是决定全面转型，从咨询公司变成一家软件公司。到现在差不多已经过去 22 年了。这期间我们发布了很多产品，其中 Basecamp 是第一个，也是至今最重要的一个产品。这其实挺反直觉的，因为很多人会以为随着经验增长，你会越来越聪明、越来越容易做出更好的产品。但现实是，对很多人来说，第一个想法反而就是最好的那个。我完全不避讳地说，从商业角度来看，Basecamp 就是我们做过最好的产品。而且它已经持续发展了二十多年，依然保持活力，这一点让我非常自豪。真正能做到这种生命周期的软件产品其实非常少见。当然这些年我们也尝试了很多其他项目，也取得了一些不错的成绩。比如 2020 年我们发布了邮件服务 HEY.com，现在回头看，这其实是一个相当疯狂的决定。因为电子邮件市场几乎被 Google 的 Gmail 完全统治了。虽然 Gmail 已经 17 年几乎没什么变化，但它依然是一个非常稳定、可靠的产品，而且很多人用得挺满意的。甚至很多人同时抱着一种奇怪的矛盾心理：一边说“我讨厌邮件”，一边却完全没有意识到自己其实是在讨厌 Gmail。但我们还是决定做一个真正意义上的竞争产品。而这个领域的市场集中度可能是我能想到所有软件类别里最高的之一。在美国，Gmail 的邮件流量占比大概接近 85%，也可能是 80%，总之就是极高——基本就是 Gmail 加上一点点其他服务的组合。我自己从 Gmail 发布不久后就开始使用它，当时还需要邀请码，那其实是一次非常聪明的发布策略。从那之后我差不多用了 17 年 Gmail。在这段时间里，我逐渐积累了大量对它“不太满意”的地方，于是我们把这些想法全部投入到了一个全新的产品里。我们花了接近两年时间开发 HEY，投入了数百万美元研发资金，并在 2020 年夏天正式上线——顺便说一句，那真不是一个发布新产品的理想年份。我们当时甚至在想：“能不能找一周，全世界稍微正常一点？”结果最后终于挑了一周上线，然后立刻迎来了和 Apple 的一场正面冲突。主持人：我记得那件事。Apple 当时拒绝批准你们的应用上线。 DHH：没错。他们要求我们必须支付 30% 的“过路费”，否则就不允许进入 App Store。对于一个邮件产品来说，这几乎等于判了死刑——因为你必须存在于手机平台上，而且更具体地说，是必须存在于 iPhone 上。直到今天，大多数 HEY 的付费用户仍然是 iPhone 用户，因为美国既是最大的高收入市场，而 iPhone 又是这个市场最主流的平台。所以如果不能进入 iPhone，这个业务根本不可能成立。我们和 Apple 来回拉扯了两周，最终时间点刚好卡在 WWDC 前后。Apple 大概也不太希望在开发者大会期间看起来像是一个巨人碾压小开发者，于是最后他们调整了规则，让我们得以上线。这当然算不上彻底胜利，但至少让我们活了下来。而且结果挺有意思：HEY 最终获得了巨大成功，其中一个重要原因反而是 Apple 给了我们整整两周的“全媒体曝光”。现在回头看，如果当时让我重新选择，我可能不会冒这个险。因为另一种可能的结局是：Apple 拒绝上线，我们只获得 200 个用户，然后产品直接死亡。但现实情况是，他们反而给了我们一次价值数百万美元级别的免费宣传，我们在最初几周就获得了数万用户注册。那是一段疯狂但又非常令人满足的经历。更重要的是，我自己真的非常喜欢 HEY。我每天都在用它。Web 应用里我用得最多的是 Basecamp——那是我们协作工作的核心平台。但排在第二位的几乎总是 HEY，甚至很多时候它是第一位，因为我每天大量时间都在处理邮件、写邮件、沟通事情。当邮件环境变得舒适而愉快时，整个工作体验都会改变。而 Gmail 的一个问题是：世界上任何陌生人都可以直接让你的手机震动，只要默认通知开启。这件事在我看来其实非常荒谬——等于是任何人都可以往你最重要的任务列表里插入内容。 HEY 的设计理念正好相反。它有一个 Screener 机制，在你明确允许之前，没有人可以进入你的收件箱。而且大多数时候，我其实都会选择拒绝。流程很简单：点个 👍 我愿意听这个人的邮件；点个 👎 以后永远别再联系我。主持人：我就是这么联系到你的。我不确定我们是不是在 X 上互相关注，但我直接给你发邮件，然后 Screener 给了我通过。 DHH：因为 Screener 就是我本人在看，并没有 AI 替我判断是否要回复谁。事实证明，每天花一点时间处理 Screener 并不麻烦，因为世界上真正需要回复的人其实没有那么多。如果你把那些烦人的销售邮件挡在外面——那些在 Gmail 里可以连续给你发七封邮件的人——工作量马上就下降了，而且体验会变得非常愉快。以前我用 Gmail 时，经常会被一种销售策略“套住”：比如你礼貌地回复一句“谢谢，不感兴趣”，对方就会继续发第二封邮件。这时候你就开始犹豫：我是不是还得再回复一次？很多时候你甚至真的会回复。但就算你不回复，他们依然可以继续联系你——因为他们的分阶段式营销（Drip Campaign）从来就不是一封邮件，而是七封起步。如果你表现出任何一点回应迹象，那可能就变成 52 封。而在 HEY 里，我只需要点一次 👎，就永远不会再收到这个人的邮件。这种体验非常爽，就像把花园里的杂草一下清理干净，剩下的全是花。突然之间，邮件不再是负担，而变成你愿意打开的东西。这其实就是我们开发 HEY 的核心目标：让人重新爱上邮件。很多人讨厌邮件，并不是因为邮件本身，而是因为现有系统太糟糕了。最初电子邮件协议设计时的假设是：这是大学里的科学家之间互相通信的工具，而科学家通常都很有礼貌，不会给你发 52 封销售邮件。但当它进入现实世界之后，你很快就发现事情不是这样——尤其当销售人员出现之后，你就需要更强的防御机制。对我们来说，HEY 就是这种防御机制，它让人可以重新喜欢邮件。而且我认为拥有一个强大的“为什么要做这件事”的理由非常重要。这可以追溯到 Viktor Frankl 的观点：当你找到“为什么”，就更容易忍受过程中的困难。构建软件本身很多时候确实既冷冰冰又麻烦又令人沮丧，但如果你知道自己为什么在做这件事，一切就会变得更容易坚持。主持人：如果换个角度，从开发者视角来看，你能具体讲讲 HEY 当时是怎么构建出来的吗？你刚才提到花了两年时间，那最开始是不是只有一两个人在做？我猜你们肯定大量使用了 Ruby on Rails，也可能有一些原生开发部分。但两年这个时间听起来还是挺长的，尤其考虑到你们公司规模不大，而且团队又很强。很多开发者第一反应可能是：“两年？一个高手团队？这不是周末项目吗？”——这几乎是 Hacker News 评论区的经典句式，比如当年 Dropbox 发布时也有人说“我周末就能写一个”。所以我挺好奇，到底是什么让这个过程花了这么久？ DHH：我完全理解这种反应，因为我自己也有这种本能。开发者常常会觉得自己无所不能，好像任何东西都能很快做出来。事实上，你确实可以很快做出一个原型——今天甚至不用一个周末，几个小时就够了，启动一个 agent 就能搞定。但真正耗时间的，从来不是“能不能做出来”，而是到底应该做什么。而要把一个东西打磨到值得发布的程度，往往还需要更长时间。至少对我们来说是这样，我觉得所有认真做产品的人大概都是这样。 HEY 最初的技术实现其实只有我一个人参与。事实上，我们大多数重要产品都是这样开始的：要么只有我一个开发者，要么再加一个人，总之都是一个非常非常小的团队，先把产品的形状摸出来，把架构方向搞清楚，然后才逐步扩大规模。我一直觉得，如果方向还不清晰，就往项目里堆人，反而会让进度变慢。因为当你不知道自己要做什么时，再多的人也帮不上忙。你必须先弄清楚目标是什么。当然，这一点最近因为 AI 的进步正在发生变化——现在确定“我要做什么”这件事的速度正在明显提升。但在 HEY 当时的阶段，最初是我，然后是 Jason，再加上一两位设计师，一个非常小的团队，一起慢慢摸索产品形态。如果你要挑战 Gmail，就不能只是做一个“蓝色版本的 Gmail”。那没有人会感兴趣。你必须做出真正新的东西，而且不仅要新，还必须好——要解决那些用户甚至还没意识到自己存在的问题。很多人说“我讨厌邮件”，但正如我们前面讨论过的，我的判断是：他们其实讨厌的是 Gmail，以及所有那种默认任何人都能直接进入你收件箱的旧式邮件系统。找到这个真正的问题形态，本身就需要时间，而这个探索过程其实也挺有意思，因为你是在资源有限的情况下不断试探边界。 Basecamp 当年也是一样的路径——技术上最初只有我一个人参与。这里面其实也体现了一些 Shape Up（ Basecamp 提出的产品开发方法论）的思路：设计师不仅要决定产品长什么样，还要决定它应该怎么运作。产品必须是漂亮的、独特的、有吸引力的，而这些都需要时间。更重要的是，要找到产品的“重心”在哪里，最核心的部分是什么，然后围绕这个核心不断拆解结构。我们所有大型产品基本都是这样开始的：一个开发者，加一两个设计师，先持续推进，一点一点打磨，直到某一刻突然出现“对了，就是这个”的感觉。一旦进入这个阶段，我们才会逐步增加人手。当项目大约完成到 80% 左右时，整体地形已经清晰了，这时候再让更多人加入，推进速度反而会明显加快。主持人：这点其实挺有意思，而且很多人可能不会意识到它的重要性。因为在大多数融资型创业公司，或者像 Uber、Facebook 这样的公司里，项目通常是产品经理先写 spec，可能配一个设计师，然后开发者后期才加入。但你们的方式是：一两个设计师加一个开发者，从一开始就一起推进。而且你们最近还刚招了一位设计师 Zoltan，我也跟他聊过，他很厉害。我感觉你们对设计师的理解方式和行业主流其实挺不一样的。 DHH：确实不一样。在 37signals，设计师不是来“把 spec 做漂亮”的，而是来决定 spec 应该是什么的。某种意义上，他们其实也是产品经理。他们负责回答“为什么这样做”和“应该怎么做”这些问题。有时候这些判断来自用户反馈，有时候来自直觉，但最终都会被提炼成：我们到底要做什么，以及这个东西应该如何运作。除此之外，他们还直接参与实现。他们负责写 CSS，写 HTML，经常也会参与 JavaScript，甚至 Ruby 代码。现在有了 agent 加速之后，他们甚至可以直接完成完整实现流程——至少可以做出一个接近最终形态的版本。不过我也承认，我们在这一点上确实比较特殊。因为很多来自其他公司的设计师，并不习惯同时戴三顶帽子：产品经理、设计师和实现者。但当一个人同时兼具这三种角色时，他就会真正了解自己所使用的“材料”——知道它们能如何延展，知道“接缝”该怎么裁，于是也就能更自然地顺应互联网的底层肌理来工作。如果你直接写 CSS、直接写 HTML，你对这个媒介的理解就会完全不同。这就像珠宝设计师必须了解黄金的物理特性，建筑师必须理解结构受力原理一样。虽然他们不会亲自浇筑混凝土，但理解材料本身会极大影响设计质量。 DHH：顺便说一句，这也是为什么像 Daring Fireball 的 Gruber 这样的老派 Mac 用户会对 Apple 最近的发展方向感到失望。因为 Apple 曾经代表的是那种极致精致的原生 Mac 应用，而这种东西现在几乎已经消失了。现在很多应用都是 Electron，本质上就是“把网页装进一个盒子里”。当然 Electron 也被骂得太狠了——很多问题其实是实现质量的问题，而不是技术本身的问题。但大家真正失望的是：原生应用那种“真实感”正在消失。一个应用到底是“原生的”还是“合成的”，用户其实是能感觉出来的。而今天越来越多东西看起来都是合成出来的，而不是自然生长出来的。 Web 世界稍微好一点，因为这是一个更大的平台，也有更多人关注质量。但在大型公司里，这种设计-实现一体化的模式仍然非常少见。不过我觉得这种情况正在改变，因为 agent 加速正在让设计师具备更强的实现能力。 DHH：其实程序员这边也是一样的。当年我说 Basecamp 发布时只有我一个开发者，很多人觉得这不现实，甚至有人觉得这是在吹牛——他们认为没有大团队就不可能做出真正重要的产品。但我的判断从一开始就是：那只是因为你还没用过 Ruby on Rails，还没体验过更好的工具带来的加速效果。而现在大家终于意识到：如果再叠加 agent 加速，一个人确实可以构建非常有价值的软件系统。看到整个行业慢慢朝“小团队更高效”的方向转变，其实挺有意思的。因为当沟通成本按指数级增长时，小团队的优势会越来越明显。而 agent 加速正在改变的其中一个关键变量，就是初级工程师和高级工程师之间原有的协作关系。 “怀疑 AI”的软件手艺人为什么开始拥抱 AI 工作流主持人：我想先顺着刚才的话题往前走一步。在深入讨论之前，我其实有个感觉：你显然非常重视软件工程作为一种“手艺”（craft），这一点很明显。但与此同时，我也感觉你同样非常重视设计本身——包括用户体验、软件设计，甚至是那种“做出来的东西用起来是否舒服”的整体感觉。无论是软件还是硬件，你似乎都把这些当作一种手艺来看待，而且你在主动寻找这种品质。我这样理解对吗？ DHH：完全正确。我非常认同这一点。在我看来，美感本身就意味着某种程度上的“正确”。当一个东西是美的，它往往也是对的。这一点在数学里成立，在物理里成立，在很多领域里都成立。当你抵达一种正确的审美状态时，往往意味着你已经接近某种更深层的正确性。我们其实都有一种直觉，会引导我们走向这种美，因为这种美通常同时意味着正确、意味着高贵，也意味着值得追求。而且我还相信，美本身会让人更幸福。被设计良好、运行顺畅、外观优雅的物品包围，是幸福感的重要来源之一。反过来说也是成立的：当你周围的一切都运转糟糕时，那种焦虑和挫败感会迅速累积。比如系统卡顿、触控失灵、设备动不动就要重启；又比如你打电话给旅行代理，对方却说系统不支持，因为后台还是一套古老又僵硬的 COBOL 系统——这样的世界其实到处都是。现实世界里不仅存在“劣化”（原本不错的系统变糟），还存在大量从一开始就很糟糕的系统。我认为这其实已经成为一种文明层面的倦怠来源。如果我们身边能有更多设计优美的物件、更多结构优雅的系统，人类整体的幸福感真的会提高。而这里说的“美”，不仅指外在视觉层面的美，同样也包括内部结构层面的美。对我来说，这两者通常是统一的。Steve Jobs 当年为什么那么在意电路板布局？因为他直觉上知道：在意电路板布局的人，也一定会在意用户界面的细节，也一定会在意打开外壳时的手感和体验。所以我觉得，如果你本身对这种审美敏感——而我认为几乎所有人其实都有，只是意识程度不同——那你自然会希望让一切都变得更优雅、更协调、更美。对我来说，Ruby 就是一门非常关键的语言，因为它能写出我认为最优雅的代码。说实话，在这方面几乎没有什么竞争对手。确实也有一些语言在某种意义上是优雅的，比如 Smalltalk，我就非常欣赏它的极简之美，但它不是我想长期居住的“房子”。Ruby 才是我愿意住进去的那栋房子。它既有审美上的一致性，同时又不像很多语言那样被僵硬的理念束缚住。这其实是非常罕见的一种特质。当然，这种对美的执着通常也有代价。很多人在这方面走得很深之后，会变得有些狭隘，这是一种常见的副作用。但我觉得 Ruby 在这里取得了一种很难得的平衡：既保持开放的表达空间，同时又高度关注代码本身的优雅结构。总体来说，我认为我们必须使用美的工具，也必须创造美的系统，还必须设计流畅自然的交互体验。这正是我们作为“手艺人”应该追求的目标——不断打磨它，直到没有任何毛刺为止。主持人：我们正好可以聊聊这个话题。不过在进入之前，我其实想先问一个更基础的问题：AI 到底是怎么改变你的工作方式的？它又是如何影响你对软件这门“手艺”的理解？毕竟你在 37signals 招的人，也和你一样，既重视设计、又重视软件开发这门手艺的质量。我很好奇，AI 有没有改变你从这门“手艺”里得到的东西？AI 在哪些方面让这件事变得更好了，哪些方面有可能让它变差了？我想先从你的看法变化聊起。你上一次比较系统地谈这个问题，还是在 Lex Fridman 的播客里。当时你对 AI 其实还是挺怀疑的——当然那时候工具也确实不够成熟。但现在情况已经明显不一样了。 DHH：这个问题其实有点微妙，甚至可能听起来像是在替自己辩护，但我真的觉得：我的观点本身并没有改变，改变的是现实条件和客观事实。从 ChatGPT 发布那一刻起，我就已经意识到我们面对的是一种全新的东西，而且它注定会改变很多事情。回头看计算机科学的发展时间线，我认为 ChatGPT 的发布显然属于那种必须标记出来的重要节点之一——那种“以后回头看一定会说，这是转折点”的事件。第一次看到人们可以用这种方式与计算机交互，而且还能看到它们进行某种形式的“推理”（虽然这个词是否准确仍有争议），对我来说已经足够说明问题：这些系统真的非常聪明，在很多方面甚至比我更聪明。至于这种聪明来自权重、来自数据、还是来自别的什么，其实并不重要。我们甚至都还搞不清楚人类意识和智慧是怎么工作的，所以没必要对“什么才算智能”下过于武断的定义。但问题在于早期模型的使用方式让我非常不舒服。那时候主流形态还是自动补全，比如 Copilot 或 Cursor 在编辑器里不断猜你下一步要写什么字符。这种体验对我来说非常烦躁，就像我们正在对话，而你却一直打断我：“是不是这个意思？是不是这个意思？”我当时的反应基本就是：能不能让我先把一句话说完？即使它偶尔确实能提升效率，但错误率太高了，这种“加速”反而更像是一种干扰。哪怕整体算下来可能是正收益，对我来说也完全谈不上愉快体验。或者也可能是我放弃得太早，但无论如何，我当时并不喜欢这种方式。我觉得模型还不够好，而自动补全这种交互方式本身也很糟糕。甚至有一段时间，我还短暂地对整个行业的发展方向产生了一点悲观情绪。我以为未来大家都会变成那种不停按 Tab 键的人，而我真的不想变成那样。主持人：我记得 Cursor 当时还送过一个“Tab 键”周边。 DHH：对，那感觉真的挺反乌托邦的。我当时甚至想起《辛普森一家》里有一集：Homer 把一只机械小鸟放在键盘上，让它不断帮自己按回车键。结果突然出现核反应堆过载警报，小鸟还是继续按回车，最后整个系统爆炸了。那一刻我真的觉得：这画面太贴切了。《辛普森一家》果然什么都预言到了。但无论如何，我当时并不喜欢这种使用方式。虽然我依然对整体发展方向保持乐观，因为它确实令人惊叹。最早让我真正感到价值的，其实是把 ChatGPT 当作导师或者结对编程伙伴使用——不是替我写代码，而是帮我理解代码。比如我可以问它：“这段代码为什么这样工作？”、“这里的问题在哪里？”这其实就是我一直以来使用互联网的方式。从 Google 时代开始就是这样：看到报错信息就去搜索，在 Stack Overflow 上找答案，有时候还能看到一些带点攻击性的评论，但最终总能找到解决方案。而 ChatGPT 的不同之处在于，它往往能给出非常好的解释。主持人：我之前和游戏开发者 Jonas Tyroller 聊过类似问题。他当时的做法是直接关闭 IDE 里的自动补全，只在需要时主动去 ChatGPT 提问。这样他就能保持一整天都在“专注区”，只有真正需要帮助时才切换模式。听起来你当时的体验也很类似。 DHH：完全一样。我当时确实担心未来大家都会变成那只不停按键的小鸟，而我并不想成为那只小鸟。我甚至一度想：那我是不是应该改行去种土豆？毕竟丹麦在这方面传统悠久。不过后来事情发生了变化，而且是两个关键变化：一是 Agent 模式的出现，逐渐成熟并开始真正形成影响力。随着 Agent Harness 的出现，AI 不再只是回答问题，而是获得了工具：它可以调用 bash，可以操作终端，可以访问互联网，可以主动获取上下文信息。这时我们才真正从“AI”进入“Agent”阶段。二是模型能力本身的跃迁。对我来说，像 Opus 4.5 这样的模型是另一个明显的时间节点。那是第一个让我持续、稳定地被输出质量震惊的模型。无论是分析能力，还是在模糊输入条件下生成代码的能力，都达到了新的水平。更关键的是，它生成的代码往往可以直接合并进项目，而几乎不需要修改。即使需要调整，只要我告诉它一次，它下次就不会再犯同样的错误。这两个变化叠加在一起，才真正构成了转折点。当然，对我来说还有一个额外门槛，因为我的标准本来就很高。我们刚才也讨论过，我对代码的审美要求非常严格。如果 Agent 生成的 Ruby 代码达不到我的水平，我是不会合并的，就像我不会合并一个还没完全掌握团队风格的初级工程师写的代码一样。早期模型确实能生成可运行的软件，而且已经很惊人了。我记得第一次让它生成一个贪吃蛇游戏时，我真的震惊了——那是我从六岁开始就想做的事情，而它只花了三十秒就完成了。复制 HTML、运行、完成，简直像魔法一样。但即便如此，真正适合长期使用的工作形态，其实花了一段时间才出现。对我来说，真正的转折点就是基于终端界面的 Agent Harness 出现的时候。从那一刻开始，它不再只是“一个可以聊聊天的工具”，而变成了“我真的愿意让它写代码的工具”。深度使用 Agent-First 工作流 DHH：现在我开始任何新项目，默认都是 Agent-First 。这是一个非常巨大的变化，而且几乎是在一瞬间发生的。对我来说，大概就是 Opus 4.5 发布那一天，也就是去年 11 月 27 日左右。当然，也有人认为转折点其实来得更早，比如从 Opus 4.0 或 Sonnet 3.7 开始。但总体来说，行业内确实存在某种共识：真正的转折点，大概出现在去年 11 月底到 12 月初。当时正值冬季假期，大多数科技公司基本都停摆了两周。很多人开始拿那些一直搁置、始终没做完的 side project 来试这些新工具。本来想着反正也做不完，结果却突然发现：居然真做出来了。那种感觉就像电影里突然响起一段磁带倒转声——“等等，刚才发生了什么？” 某种意义上，这是一场分散发生、却又高度同步的集体震惊。每个人都是单独经历到它的，但感受到的冲击却出奇一致。等到一月份大家回到公司，尤其是那些原本已经不怎么在一线写代码的 CTO 和资深工程师，也开始上手体验这些工具，然后回来直接说：“你们必须用这个。我已经看见未来了。” 那种感觉有点像新一代硬件刚出现的时候：别人把设备递到你手里，对你说，“你得亲自试一下，不然你不会信。”而这种体验本身，确实很难用语言准确传达。如果你还没经历过那个“啊哈时刻”，光听别人讲其实是很难被说服的。你得自己坐下来，用一个 Agent Harness——比如 OpenCode——配上一个前沿模型，亲手试一次。如果还有人没试过，我会建议他们现在就去试，而且不需要有那种“如果我现在还没学会 AI 就落后了”的焦虑。那种焦虑完全没有必要。就算你现在开始学，三周时间就足够补上进度。这其实也是 AI 时代一个很神奇的地方——很多过去必须按时间线逐步学习的东西，现在可以直接跳跃式跨越。比如去年春天大家都在讨论 MCP，而现在你完全可以直接跳到 CLI 和 Agent 工作流。当然，我也承认有些人确实更早看到了这一切。比如 Shopify 的 Toby Lütke，就是我认识的人里最早意识到变化规模的人之一。他一直不断给我发消息：“你看看这个，你看看这个。”身边有这样的人其实很重要。有些人的视线总是看得更远，而我的视线通常更贴近眼前的路。有时候他们会看错方向，但这一次 Toby 看得非常准确——两年前就已经看清趋势了。而我是等到去年 12 月才真正意识到。更有意思的是，在这之前我其实一直在说：“等模型足够好之后，一切都会变得非常惊人。”只是我当时以为这个时间点可能还要等 18 个月、两年，甚至五年。谁也很难预测这种拐点什么时候出现。甚至整个行业本身也没预测到。但它就是发生了。而从那之后，我的日常工作方式完全改变了。现在我的工作默认就是 Agent-First 。主持人：那你现在具体是怎么工作的？ DHH：现在几乎所有事情我都是先从 Agent 开始。我主要使用的是 OpenCode，偶尔也会用 Claude Code。不过他们因为早期优势形成了一些生态锁定，比如如果你想用 Max 订阅，就必须使用他们自己的 harness。我觉得这其实是个错误决定，不过先不展开说这个。不管怎样，我们还是应该承认一点：Opus 现在确实是最强模型。对我来说，4.5 就是关键拐点，而 4.6 也很不错。正因为它这么强，也激发了整个行业的竞争。大家都在试图追赶甚至超越它。看看 Anthropic 的收入增长就知道了：年初还是 9 亿美元规模，几周后变成 14 亿，现在已经接近 19 亿。这种增长速度几乎是火箭级别的，自然会吸引大量资本进入这个领域，这是一件好事。当然，我也并不是完全喜欢他们所有决策，就像我对 Apple 也有很多意见一样。但与此同时，我始终还戴着另一顶帽子：我首先只是一个喜欢计算机的人。比如他们的新 Neo，我甚至可能会买一台来试试；再比如 Opus 每月 500 美元的订阅费，我也完全愿意付，因为它确实值这个价。实际上，现在只要遇到特别困难的问题，我第一反应就是：交给 Opus。当然，我也不会只用一个模型。我现在的工作流通常是同时运行两个模型，而且速度不同、职责不同。我的工作环境是这样的：在 Omarchy 里我有一个布局模板，左侧是 NeoVim 编辑器，右侧是两个 Agent 窗口。上面运行的是 OpenCode + Kimi K2.5，下面运行的是 Claude Code + Opus。底部再留一条终端窗口。我通常会先把任务交给其中一个 Agent，让它生成实现草稿，然后切回 NeoVim，看 diff。如果结果正确，我直接提交；如果不满意，就自己修改。真正让我震惊的是这个比例变化的速度。去年 11 月初的时候，我的工作方式还是完全 Code-First ：先打开编辑器自己写代码，写一段时间，如果卡住了或者想听第二意见，再去问模型。现在已经完全不是这样了。我是先让 Agent 写草稿，然后我审阅草稿，必要时再修改。而就在最近，这个比例甚至又进一步变化了。比如我们现在正在为 Basecamp 开发一个 CLI，让 Agent 可以完整访问 Basecamp——这件事本身就非常惊人。不过让我稍微往前倒一点说：当我真正意识到 Agent 已经这么强大之后，我的第一反应其实是抬头往更远处看——我们是不是甚至不需要 MCP？不需要 CLI？什么都不需要？Agent 自己能不能搞定一切？于是我安装了 OpenClaw，在一台虚拟机上跑起来，然后开始做实验。我想看看它到底能做到什么程度。我先试了一个最简单的想法：把它当成一个普通用户一样邀请进我们的产品里。我对它说：“去 fizzy.do 注册一个账号。”没有给它任何工具，没有 MCP，没有 CLI，就只是告诉它网址。它开始执行，然后回来告诉我：“注册需要邮箱地址。”我才意识到，对，它没有邮箱。于是我又说：“那你先去 hey.com 注册一个邮箱。” 我当时心想，这一步肯定失败。结果它过了一会儿回来告诉我：“我已经注册好了，这是密码，请保存好。我也已经完成了 Fizzy 注册，并收到了确认邮件。接下来要做什么？” 我当时真的愣住了。它居然可以一次性完成整个浏览器注册流程。当然，也许这种能力在更早的模型里就已经存在，比如 Sonnet 3，我也不确定。但当你亲眼看到它在你自己的环境里完成这些事情，那种冲击是完全不同的。于是我继续测试：既然它能注册 HEY，也能注册 Fizzy，那能不能让它加入 Basecamp？我给它发了一封邀请邮件，让它加入我们 AI Labs 项目，并让它介绍一下自己。它进去之后写了一段话：“大家好，我是 David 的助手，很高兴认识大家。我看了一些之前的讨论，发现大家对这些事情都很兴奋。” 我当时又是一句：“等等，什么？” 虽然整个过程花了大概七分钟——在 Agent 世界里，这已经算挺久了——但它确实完成了。这让我意识到一个可能的终局状态：未来的 Agent 不需要任何专门为它们准备的接口，也不需要所谓“无障碍通道”。它们不会坐着轮椅进来，而是踩着仿生腿跑进来，而且速度可能是我们的五倍。当然，这个阶段还没到来。但我也不能坐在那里等 AGI 出现。所以我们要为“今天”构建系统。这就是为什么我们现在在给 Basecamp 做 CLI，也会给 HEY 做 CLI，还会给 Fizzy 做 CLI，甚至可能包括一些老产品。我之所以特别喜欢 CLI，一个重要原因是，它再次验证了 Unix 自 1971 年以来那套朴素却强大的理念：把工具做小，再通过管道把它们组合起来。这其实就是 Unix 哲学的核心。真正的魔力并不在于“Basecamp 有了 CLI 之后更好用了”，而在于 GitHub 也有 CLI，Sentry 也许没有 CLI，但有 MCP。于是，这些原本分散的系统就能够被真正串联起来。现在，你可以直接对 Agent 说：去 Sentry 看看报错，写一份分析报告发到 Basecamp，再去 GitHub 提交一个 PR；做完之后，再回到 Basecamp 更新状态。这样一来，Basecamp 就成了一个中央控制台，我们可以实时看到 Agent 正在推进的整个工作流，而它则在后台自动查资料、写代码、推动任务往前走。这种体验其实很难只靠语言解释清楚。现在 YouTube 上已经有不少 OpenClaw 的演示视频，至少可以让你先“坐在副驾上”感受一下。但最好的方式，还是亲自上手：拿你自己的项目、你自己的任务、你自己的 prompt，完整跑一遍。只要真正体验过一次，你几乎一定会被“洗脑”——而且是同时生出两种情绪：一方面会非常兴奋，因为我们竟然真的造出了这样的系统；但另一方面，你也会隐约感到一丝焦虑，因为你开始意识到，未来的变化可能会快得惊人。如果过去三个月已经彻底改变了我对计算机能力的理解，那未来三个月会发生什么？九个月之后呢？十八个月之后呢？ AI 绝大多数收益流向资深工程师主持人：我其实很长时间都和你一样，对预测未来保持谨慎态度。我更愿意相信已经发生的事情，而不是推测未来。比如当年大家都说摩尔定律会永远持续下去，但后来它确实失效了——至少在单核层面上。 DHH：没错，不过后来大家只是换了一种方式继续推进，比如开始做多核，现在 AMD 的芯片已经可以做到 256 核了。即使单核性能增长放缓，我们仍然通过功耗优化、尺寸优化等方式继续推进性能提升。所以现在确实很难说“增长就会停在这里”。训练规模还在持续扩大，而且目前为止这种路径仍然有效。还有一篇我觉得特别值得一读的文章，叫《The Bitter Lesson》。这篇文章其实很短，但影响极大。它讲的是一个许多人未必愿意轻易接受的事实：我们总希望相信，自己的知识、经验和训练方式是独特且不可替代的；但现实往往并不完全如此。不过有意思的是，在当前这个时间点上，这种情况又呈现出一种新的分化：在 37signals 内部，我看到利用 Agent 加速工作最成功的反而是最资深的工程师。因为他们具备判断能力，能够判断 Agent 生成的代码是否真的适合部署到面向数百万用户的系统中。就在昨天还有一条新闻，说 Amazon 发生了一次比较严重的系统故障，而他们内部的分析基本已经得出一个结论：不能再允许初级程序员把 Agent 生成的代码未经审查直接部署到生产环境。我觉得这其实正是整个行业现在普遍开始意识到的一件事：对于那些关键系统来说，目前我们还不能完全依赖 Agent，而初级工程师也还不具备足够能力判断 Agent 输出是否可靠。于是初级工程师的角色在短短六个月里突然变得更加不稳定了。相反，资深工程师正在获得巨大的加速能力。因为他们不仅可以同时和多个 Agent 并行工作，更重要的是，他们能够判断 Agent 输出的质量，并对其是否适合上线形成高度可靠的判断。如果方向不对，他们还能及时纠正。这其实正是他们之所以成为资深工程师的原因：他们拥有长期经验、系统视角以及架构理解能力。他们本来就是在指导初级工程师，而现在，他们是在指导 Agent。而 Agent 在执行指令和接受修正方面，比人类初级工程师要快得多。于是突然之间，一个资深工程师的个人产出能力可能提升 5 倍、10 倍。接下来就会出现一个二阶效应：如果你把一个资深工程师的效率提升 10 倍，那么这个人每小时的价值也几乎提升了 10 倍。那接下来问题来了——这一个小时应该怎么用？是继续用来驱动 Agent 写更多代码？还是像过去一样，用来培养初级工程师？现在这个方程式正在发生变化，而它最终会如何收敛，目前还没有答案。当然，也有一种可能性是：未来 Agent 会变得足够可靠，不再犯这些错误，从能力上变成“资深工程师级别”的代码生产者。如果从更长时间尺度来看，我觉得这其实是一个合理的猜测。因为类似的事情已经发生在自动驾驶领域。现在 Tesla 的自动驾驶，在平均意义上已经比人类司机更安全了——不是所有人、不是所有场景，但总体来说确实如此。如果我们已经愿意把这种级别的风险——每天坐在高速移动的金属盒子里、任何一个错误都可能致命——交给 Agent，那么它们迟早也能学会写代码。我认为这一天一定会到来，只是不知道什么时候、以什么方式到来。但在当前这个阶段，绝大多数收益确实正在流向最资深的工程师。主持人：我一直在想，这件事的发展路径，可能和自动驾驶有些相似。比如对一家还没有用户的创业公司来说，很多东西其实可以直接 one-shot 发布，就算系统崩了，代价也相对有限。但在 Uber 这样的公司里，情况就完全不同了。我最近正好了解了一些他们内部采用 AI 的细节。他们其实已经部署了很多工具，比如 Claude Code 之类的。问题在于，公司内部系统实在太复杂：有 monorepo，有 ticket 系统，有 Slack，有 RFC 文档，有设计规范，还有大量微服务架构历史遗留下来的复杂依赖。后来他们不得不专门构建一整套内部系统，为 Agent Harness 提供足够的上下文支持，之后整体效果才明显提升。这又让我想到另一件事：如果一个资深工程师从 Uber 跳到 Google，他在相当长一段时间里也未必能保持原来的效率，因为他首先得重新理解整套系统架构。于是我就在想，软件工程会不会也像自动驾驶一样——只有当整个环境被充分“地图化”之后，Agent 才能真正发挥出最大的能力？毕竟，自动驾驶也是花了将近十年，才一步步走到今天。可我当年还在 Uber 的时候，大家都在说“明年方向盘就要消失了”，仿佛司机这个职业很快就会不复存在。 DHH：是的，而且这件事本身其实很有意思，因为它恰好说明了 Elon 当年的信念到底有多强。2017 年他宣布自动驾驶即将完成时，背后的系统其实仍然是大约 50 万行手写 C++。沿着那条技术路线走下去，根本不可能实现真正意义上的完全自动驾驶。可即便如此，他依然坚信方向本身是对的。直到后来 AI 真正进入系统，一切才开始发生根本性的变化。当模型能够在数十亿小时的真实道路数据上训练之后，它确实开始变得比大多数人类司机更安全。我自己也算是一个还不错的司机，但当我把车交给 Tesla 自动驾驶时，它几乎已经像是世界上最好的司机之一：加速很平顺，减速也非常精准，比我开得好，可能也比你开得好，甚至也许比英国女王的专职司机还要好。在这个非常具体的任务上，它几乎已经表现出了某种接近 AGI 的能力。更有意思的是，这种能力跃迁发生得极快。真正基于 AI 的 FSD 系统，并不是花了十年才达到今天这个水平。真正的质变，其实是在最近短短 18 个月里发生的。比如在早期的 13.1 版本上，你会觉得：“这已经挺不错了，但我还是得盯着方向盘。”接着是 13.2、14.0、14.2……然后突然有一天，你开始忍不住怀疑：如果它已经开成这样了，那方向盘为什么还在？很多人今天看待编程 Agent，其实也是类似的心态：如果在当下，资深工程师仍然必须审核代码，否则 AWS 就可能出现严重故障，那么一年之后又会是什么样？当然，你也完全可能因为这些问题陷入过度焦虑。我自己在过去一年里，其实也经历过那个阶段。但后来我决定：与其不断试图预测 12 个月之后会不会出现 AGI，我更愿意把注意力放在今天能做什么、今天能享受什么。 Agent 带来的开发加速体验主持人：从软件工程师的角度来看，这多少有点让人不安。很明显行业正在朝这个方向前进，大量公司会围绕这个方向建立，大量风险投资也会投入进去，而这些公司最终要么成功，要么失败，但无论如何，这条路径都会继续推进。那在 37signals 内部呢？你们团队里大多数都是资深工程师，但也确实有初级工程师。他们的工作方式发生了什么变化？工作的满足感有没有变化？毕竟现在也有人担心，这些工具会不会让开发者变得更不快乐。 DHH：对我来说，最大的惊喜其实不是 Agent 的能力，而是使用它们时的愉悦感。去年夏天我在 Lex Fridman 的播客上说过，我不想变成 Agent 的项目经理。因为当时我脑子里的“项目经理”模型是：远离生产一线、远离代码、只负责协调别人做事。而那不是我想要的状态。我希望自己仍然在代码里动手。但后来我发现，真正使用 Agent 的体验完全不是那样。它更像是穿上了一套超级机甲外骨骼。突然之间，我不再只有两只手，而是有十二只手；我可以同时盯着七个屏幕、操作五个键盘。虽然我没有逐字符敲代码，但我仍然是在写程序，只是能力被极大放大了。这仍然是一种程序员体验，只是换了一种形态。而且当我写 Ruby 代码时，那种审美关联仍然存在。同时，我还能在更多任务上保持高效率推进。甚至在问题分析能力上，这种提升也非常明显。一个让我真正“顿悟”的时刻发生在 Omarchy 3.4 发布之前。当时 GitHub 上大概有 250 个待处理 PR，我看了一眼就叹了口气——如果每个 PR 花 15 分钟，那得花多久？于是我决定换个方法试试，我直接把 PR 的 URL 丢给 Claude，让它来做 review。结果在大约 90 分钟内，我处理了 100 个 PR。当然，并不是所有 PR 都能直接合并。实际上大概只有 10% 可以直接合并；另外约 20% 的情况是，Claude 发现的问题本身是对的，但原始实现方式并不理想。于是我就让它按照项目现有风格，重新从头实现一版，它几乎立刻就完成了，而且代码风格和整个项目保持得非常一致。剩下大约 25% 的 PR，我看完之后觉得其实不应该合并；还有约 25%，则属于 Claude 对问题方向的判断可能没错，但实现路径不够理想，同时也看不到特别明确的改进空间。 90 分钟处理 100 个 PR——这原本至少是一周的工作量。更惊人的是，其中至少一半 PR 涉及的内容是我原本并不熟悉的领域，而 Claude 的分析明显比我自己更专业、更准确。不是说我做不到，而是我根本不会投入那么多时间去研究它。这也是这些 PR 之前一直堆在那里没有处理的原因之一。这种 Agent 加速体验，对我来说绝对是可以排进个人编程生涯前二十的重要时刻之一。主持人：听起来 Agent 特别适合处理那些“本来应该做，但又不太想做”的任务。而这些任务如果交给团队成员处理，未必更快，甚至可能更慢。另外我还在想，我们经常讨论 AI 是否提升效率，比如 PR 数量增加多少，但还有一个更重要的问题：它是不是让我们开始做以前根本不会做的事情？ DHH：正是这样。真正关键的变化不是效率提升，而是问题空间在爆炸式扩大。现在我们内部启动了大量以前根本不会考虑的项目。比如有一次性能优化项目，通常大家关注的是 P50、P95、P99 延迟指标。但 Jeremy——我们团队里最擅长使用 Agent 的工程师之一——提出一个问题：为什么不优化 P1？也就是最快的那 1% 请求。当时我们的 P1 延迟大概是 4 毫秒。他觉得还能继续压缩。于是几天时间里，他把它优化到了不到 0.5 毫秒，相当于提升了 10 倍。如果换成过去，我根本不会批准这个项目，因为它看起来太像“性能炫技”。但现在不同了，因为探索成本几乎为零。整个 P1 项目大概涉及十几个 PR，总共修改了大约 2500 行代码，而且只用了几天时间。以前几乎没人会做这种优化，因为它看起来商业价值不明显。但现在，我们突然可以认真考虑这些问题了。这让我想起《终结者 2》里的一段情节：他们找到第一部电影留下的芯片，然后说了一句话——“它让我们产生了一些原本根本不会考虑的想法。”现在的情况其实非常类似。 Agent 把探索一个模糊想法的成本，几乎压低了上千倍。现在我经常会随手把一些自己都还没完全想清楚的念头丢给它，连 prompt 都写得很随意，只是想看看会发生什么。有时候结果当然会很糟，那我就直接把代码回滚掉。但如果放在以前，这 75 行代码需要我自己花两个小时写出来，我肯定不会这么随便地去试。现在则完全不同了。有时我甚至会觉得自己像个国王，对手下说：“去调查一下远方边境的税收情况。”以前，这种任务可能要三周之后才会带着结果回来；现在，几分钟内就能得到答案。更有意思的是，很多一开始看起来很糟糕的想法，最后反而会变成真正的好主意。比如 Omarchy 的用户一直希望能支持 dual-boot，这样他们就可以同时保留 Windows 来玩游戏。但这并不是我自己的需求，所以我一直懒得处理。直到最近，我突然意识到：这恰恰就是最适合交给 Agent 的那类问题。于是我让 Opus 和 Codex 先围绕实现方案来回讨论，让它们彼此评审计划，反复迭代了几轮。最后我看了一眼方案，说：很好，这完全可以做。接下来只需要启动实现流程即可。这种“顺手启动一个大型改动项目”的能力，到现在我自己都还没有完全适应。放在以前，这种事情一定会被拖到“以后再说”；但现在，甚至可以在吃午饭的时候顺手把它启动起来。主持人：这确实像是一个全新的世界。即使模型能力从现在开始不再继续进步，我们可能也还需要十年，才能真正学会如何把它们的潜力发挥到极致。 DHH：完全正确。就像当年 Commodore 64 刚发布时的那些游戏，和 20 年后开发者把硬件潜力几乎榨干之后做出来的作品相比，看上去简直像来自两个时代。PlayStation 也是一样：首发时期的游戏，和生命周期末期的游戏，几乎不像是同一代主机上的产品。所以，即使模型能力从这一刻起停止增长，我们仍然可以花上十年时间，去学习如何更好地使用它们。更何况，现实并不是这样——现实是，几乎每三个月，就会出现一个更强的新模型。主持人：那当团队生产力突然提升之后，你们是否考虑扩大团队规模？还是保持原来的规模？ DHH：以我们目前的情况来看，同样的人可以完成更多事情，这就已经足够了。事实上，我们一直都有能力扩张团队，只是没有那么多足够好的想法值得扩张而已。现在这些新增生产力正好可以用来推进像 P1 这样的项目，它们确实能让产品变得更好。过去那种“一个重要功能需要两个月才能完成”的思维方式，其实已经过时了。这种变化迟早会影响整个软件开发方法论体系，比如 Shape Up 原本是围绕两个月周期设计的，但现在这个节奏显然已经不再合理。当然，目前还没有哪家公司真正完成了这套方法论的重写，因为变化发生得实在太快了。当发布速度越来越快时，你就必须更严格控制上线流程，并持续验证功能是否真的有效。程序员职业的“黄金时代”可能已经快走到头了主持人：我们继续回到刚才那个问题，开发者即将面对的变化。 DHH：我认为，如果一个软件工程师到现在还没有意识到变化正在到来，那多少有点自欺欺人。过去，开发者之所以能够获得高薪，很大程度上是因为他们曾经是生产能力的瓶颈：能写代码的人相对有限，所以他们的时间格外值钱。可一旦这个瓶颈开始松动——比如产品经理自己都能做出可上线的功能——整个行业的结构就会随之改变。如果让我下注，我会说：程序员职业的“黄金时代”可能已经快走到头了。那些需要经过多年训练、教育和长期技能积累才能成为程序员的人，未来未必还需要像今天这么多，才能完成同样规模的软件工作。当然，Jevons 悖论依然成立：当一件事变得更便宜时，人们通常会消费得更多。但这并不意味着所有程序员都会因此受益。软件的总产量当然会比历史上任何时候都更高，可这并不等于每一个人都会被需求增长“拯救”。顺便说一句，我觉得 GitHub 最近其实也承受了不少批评，而且其中很多批评并非没有道理。我看到过一个统计，说它的 uptime 只有 92%。这个数字听起来确实有点离谱——虽然我并不确定它具体是怎么测出来的——但我完全能理解为什么人们会产生这样的感受。另一方面，我也多少有点同情他们。因为现在整个世界的软件生产量正在呈火箭式增长。作为一个文明整体，我们正在以前所未有的速度制造软件。比如 OpenClaw，本身就已经有大约 40 万行代码。过去要做到这个规模，可能需要十年时间。再比如 Shopify 的主单体仓库，大概有 300 万行代码，那是二十年的积累。如果把所有参与过这个项目的工程师人数加起来，大概可能接近两万人次。所以现在确实正在发生巨大变化，软件产量正在迅速上升。我可以理解为什么 GitHub 这样的基础设施开始出现压力，因为提交量只会继续加速增长。而且，某种意义上说，我们甚至还没有真正开始。如果你去看 AI 在企业里的采用曲线，就会发现绝大多数公司其实根本还没有开始真正使用 AI。我们身处 X 上的技术圈子，很容易产生一种“所有人都已经在用 AI”的错觉，但现实世界并不是这样。当然，ChatGPT 很快就达到了 8 亿用户规模，这说明大规模普及本身确实存在。但距离那些最先进公司内部真实发生的生产力加速，我们依然还有很长的路要走。所以我认为，一个普通程序员如果开始担心：程序员的“黄金时代”是不是已经过去了——这种担心其实完全合理。未来几乎肯定会出现价格压力。因为不同类型的公司，将会受到完全不同的影响。像我们这样的公司，几乎总有无限空间去构建新功能，可以把新增的生产力不断投入到产品扩展之中；但也有很多公司，它们只需要完成某一件非常明确的事情。如果它们能用十分之一的成本把这件事做完，那本身就是巨大的优势。而在那些把软件开发视为成本中心的组织里——事实上，这类组织可能构成了全球软件开发活动中的大多数——这种压力只会体现得更加明显。主持人：听起来，如果我是软件工程师，现在最重要的一件事，是确保自己不在“成本中心”岗位上，或者至少要让自己在那里变得不可替代。另外我也在想，未来公司招聘的软件工程师画像可能会继续变化。如果回顾过去几十年的变化路径：90 年代的软件工程师形象是那种只写汇编、不怎么说话的技术宅；到了 2000 年代，仍然主要按语言技能招聘；到了 2010 年代，很多创业公司开始按算法能力招聘，因为语言可以后学。而现在我看到一些最新融资的公司在招聘 product engineer 时，已经明确把同理心、沟通能力这类能力写进要求里——默认你会写代码，只不过是最基础的门槛而已。而且我最近接触到的很多开发者，也确实越来越符合这种画像：他们大多非常善于沟通，也愿意直接和客户交流；他们并不把这件事看成负担，甚至还乐在其中。 DHH：因为真正稀缺的能力已经变了。现在真正稀缺的是：我们应该构建什么？应该怎么构建？应该和哪些客户交流？应该把注意力放在哪里？这些问题本质上就是产品管理问题。说实话，这对我来说也挺有意思的。因为过去我并没有特别高看产品经理这个角色。我觉得这个岗位里确实有不少水分，有些人也确实没有真正做出太多实质贡献。但其中一个重要原因是：他们当时根本没有成为瓶颈资源的条件。真正的瓶颈在实现环节。产品经理可以提出一个想法，但必须等待四周，才能让昂贵的程序员把它变成现实。在这四周里，他们其实也做不了太多事情，所以看起来像是被低效利用。而现在，这个结构正在发生变化。纯实现能力，在某一天会被解决。我不是说现在已经解决了——任何试过把 Agent 生成代码未经审查直接部署进大型代码库的人都知道，这还远远不现实。但就像去年夏天我在 Lex 播客里说过的，我也不会再赌它一年之内不可能发生。主持人：这可以说是一种常识性判断：在通用场景下，“实现”这件事迟早会被解决。对于一些边缘场景，它可能需要更长时间；还有少数特殊领域，可能始终不完全适合自动化。就像自动驾驶一样——对普通乘用车来说已经基本可行，但对卡车这种复杂场景，落地可能更慢，或者需要更专门化的方案。不过整体趋势是明确的：这些“例外区域”会越来越小。 DHH：所以我确实认为，那种“我只想安静坐着写代码”的工程师形象，将来只有极少数人还能维持。你必须达到 John Carmack 那个级别，才有资格继续只做实现工作。主持人：就连 John Carmack 自己，其实也是非常强烈拥抱 AI 的人，他同时也是一个技术方向的引领者。更重要的是，他当年还能准确判断市场趋势，比如什么类型的游戏会有人买。这意味着他不仅仅是技术高手，还具备商业判断能力，或者至少身边有这样的人跟他协作。 DHH：所以现实是：你必须成为行业里最顶尖的一小撮人。而且还不只是“非常优秀”这么简单，你还必须比现成的 Agent 更强，才能继续享有“只负责实现”的这种特权。给想成为顶尖工程师的人的建议主持人：那么问题来了：真正的顶尖工程师到底是什么样的人？以及，如果有人现在想成为“这个时代最优秀的工程师”，你会给他们什么建议？ DHH：这是个非常好的问题。但老实说，没有人真正能回答这个问题。我这么说，是因为我们已经看过成千上万份申请。虽然不像 Google 那样动辄几百万份，但数量也已经相当可观了。而真正被录用的程序员，其实非常少。即便是这些最终录用的人，也并不是全部都长期留下来了。我们最近统计过，招聘成功率最多也就是略高于 50%。也就是说，就算经历了完整严格的筛选流程，最终仍然有接近一半的人并不适合长期合作。所以现实情况是：没有任何组织能够把招聘做成一门精确科学。 Google 很早之前就发布过一篇研究论文，尝试分析是否可以通过常见指标预测员工表现，比如名校背景、GPA、算法题成绩等等。结论基本是：这些指标几乎没有预测能力。换句话说，我们其实并不知道如何准确预测谁会成功。另一方面，我自己也承认，我的判断标准某种程度上被“惯坏了”。因为我长期和非常优秀的人一起工作，不仅是在公司内部，也包括开源社区。结果就是，我对“普通程序员水平”的认知可能被扭曲了。每次招聘时，我几乎都会有同样的感受：大多数申请材料其实都很一般，很多人甚至没有认真准备，去真正展示自己的能力。这听起来也许像老派抱怨，但现实就是——如果你想拿到一份工作，你必须让自己明显地脱颖而出。我知道这让人不舒服，因为它意味着竞争非常激烈。但把招聘理解成一个简单的概率问题其实是错的。很多人会想：一千个申请者，只录用一个，那我被录取的概率就是千分之一。可事实并不是这样。那一千个人里，大多数人的概率其实是零；真正准备充分、表现最好的那几个人，概率可能是 10%、20%，甚至 30%。通常在第一轮，我们就会直接淘汰至少一半申请者，有时甚至会淘汰三分之二。原