本文来自微信公众号： InfoQ ，编译：蔡芳芳，作者：Tina，蔡芳芳
六个月前，Ruby on Rails作者、37signals联合创始人兼CTODavid Heinemeier Hansson（DHH）还在访谈中明确表示：他不会用AI写代码，所有代码仍然亲手完成。短短半年之后，这一状态已经发生了翻天覆地的变化。
在最近的一场访谈对话中，DHH详细介绍了他如何从最初对自动补全式AI工具的排斥，转向如今的Agent-First编程工作流——现在的大多数新项目，他已经不再从手写代码开始，而是先让Agent生成实现草稿，再由自己审阅与调整。
不过，这种变化并不是理念转变，而是工具能力跃迁带来的结果。当模型开始能够稳定生成可直接合并的代码时，AI才真正进入他的日常开发流程。而与此同时，他对代码质量、设计审美以及“代码工匠精神”的标准并没有降低，反而变得更加重要。
在访谈中，DHH还讨论了多个值得开发者关注的变化趋势：
1.为什么Ruby on Rails可能因为AI再次迎来复兴
2.为什么设计能力正在成为软件工程核心竞争力之一
3.为什么资深工程师比初级工程师更容易从AI中获益
4.为什么CLI正在成为最适合Agent的接口形态
5.为什么传统“两个月一个功能周期”的开发节奏正在失效
6.为什么程序员的“黄金时代”可能快走到头了
更重要的是，这次对话展示了一种不同于常见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，我本来就需要负责技术方向，而这正是我希望推动的方向。
137signals是如何构建软件的
主持人：能不能简单快速地介绍一下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加速正在改变的其中一个关键变量，就是初级工程师和高级工程师之间原有的协作关系。
2“怀疑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出现的时候。从那一刻开始，它不再只是“一个可以聊聊天的工具”，而变成了“我真的愿意让它写代码的工具”。
3深度使用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，完整跑一遍。
只要真正体验过一次，你几乎一定会被“洗脑”——而且是同时生出两种情绪：一方面会非常兴奋，因为我们竟然真的造出了这样的系统；但另一方面，你也会隐约感到一丝焦虑，因为你开始意识到，未来的变化可能会快得惊人。如果过去三个月已经彻底改变了我对计算机能力的理解，那未来三个月会发生什么？九个月之后呢？十八个月之后呢？
4AI绝大多数收益流向资深工程师
主持人：我其实很长时间都和你一样，对预测未来保持谨慎态度。我更愿意相信已经发生的事情，而不是推测未来。比如当年大家都说摩尔定律会永远持续下去，但后来它确实失效了——至少在单核层面上。
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，我更愿意把注意力放在今天能做什么、今天能享受什么。
5Agent带来的开发加速体验
主持人：从软件工程师的角度来看，这多少有点让人不安。很明显行业正在朝这个方向前进，大量公司会围绕这个方向建立，大量风险投资也会投入进去，而这些公司最终要么成功，要么失败，但无论如何，这条路径都会继续推进。
那在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原本是围绕两个月周期设计的，但现在这个节奏显然已经不再合理。当然，目前还没有哪家公司真正完成了这套方法论的重写，因为变化发生得实在太快了。当发布速度越来越快时，你就必须更严格控制上线流程，并持续验证功能是否真的有效。
6程序员职业的“黄金时代”可能已经快走到头了
主持人：我们继续回到刚才那个问题，开发者即将面对的变化。
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更强，才能继续享有“只负责实现”的这种特权。
7给想成为顶尖工程师的人的建议
主持人：那么问题来了：真正的顶尖工程师到底是什么样的人？以及，如果有人现在想成为“这个时代最优秀的工程师”，你会给他们什么建议？
DHH：这是个非常好的问题。但老实说，没有人真正能回答这个问题。
我这么说，是因为我们已经看过成千上万份申请。虽然不像Google那样动辄几百万份，但数量也已经相当可观了。而真正被录用的程序员，其实非常少。即便是这些最终录用的人，也并不是全部都长期留下来了。我们最近统计过，招聘成功率最多也就是略高于50%。也就是说，就算经历了完整严格的筛选流程，最终仍然有接近一半的人并不适合长期合作。所以现实情况是：没有任何组织能够把招聘做成一门精确科学。
Google很早之前就发布过一篇研究论文，尝试分析是否可以通过常见指标预测员工表现，比如名校背景、GPA、算法题成绩等等。结论基本是：这些指标几乎没有预测能力。换句话说，我们其实并不知道如何准确预测谁会成功。
另一方面，我自己也承认，我的判断标准某种程度上被“惯坏了”。因为我长期和非常优秀的人一起工作，不仅是在公司内部，也包括开源社区。结果就是，我对“普通程序员水平”的认知可能被扭曲了。
每次招聘时，我几乎都会有同样的感受：大多数申请材料其实都很一般，很多人甚至没有认真准备，去真正展示自己的能力。这听起来也许像老派抱怨，但现实就是——如果你想拿到一份工作，你必须让自己明显地脱颖而出。
我知道这让人不舒服，因为它意味着竞争非常激烈。但把招聘理解成一个简单的概率问题其实是错的。很多人会想：一千个申请者，只录用一个，那我被录取的概率就是千分之一。可事实并不是这样。那一千个人里，大多数人的概率其实是零；真正准备充分、表现最好的那几个人，概率可能是10%、20%，甚至30%。
通常在第一轮，我们就会直接淘汰至少一半申请者，有时甚至会淘汰三分之二。原因很简单：他们没有针对岗位准备申请材料，没有按照招聘说明提交内容，或者显然不符合岗位要求。剩下的人里，大约只有三分之一能进入下一轮，然后我们再筛到大概二十人，发放笔试作业测试。
很多人不喜欢这种测试，觉得那是在提供免费劳动力。我其实不太理解这种看法——难道你会觉得我们真的会把这些测试代码直接部署到生产环境里吗？这些题目本来就是专门设计出来评估能力的。
当然，我也理解另一种顾虑：如果要花六个小时做测试，最后却没有任何结果，确实会让人不愿意投入。但现实就是，这件事没有捷径。你不可能只投一份简历，再接一个30分钟电话，就顺利被录用。自从我进入这个行业以来，我从没见过这种事。
主持人：除非有特别强的内部推荐。
DHH：对，只有这种情况才可能发生。而且这种情况通常只发生在公司非常早期的阶段，比如创始团队搭建时期。那时候大家是基于长期合作经验建立信任，比如“我和这个人一起工作过两年，我可以完全信任他”。事实上，如果看长期成功率，通过这种“强推荐”进入公司的员工，比公开招聘进入公司的员工更容易长期留下来。
说实话，通过公开招聘找到真正适合我们的工程师，一直都非常困难。当然也有成功案例，所以我仍然愿意相信这条路径是可行的。但如果你把概率算清楚，会发现确实非常低。而强推荐路径成功率明显更高。
但问题是，这对大多数人来说并不是可执行建议。真正可执行的建议只有一个：尽可能提升自己的能力，并且认真对待你正在工作的地方。
很多人会觉得，如果自己所在公司不好，就没必要努力。这其实是在伤害自己。你在一个不理想的公司里工作，然后决定随便应付、刷刷Reddit、看看X，那你未来最有可能获得推荐的人是谁？恰恰是那些和你一起工作过的人。而他们只会推荐那些即使在糟糕环境中，仍然认真工作、持续学习、持续交付的人。
你必须变得足够优秀。而如果你不练习，就不可能变得优秀。如果你觉得当前公司“不值得你认真投入”，那其实是在限制自己。因为优秀公司招聘的是那些能够持续提高标准的人。
就算你不喜欢老板，也没关系。我职业生涯早期合作过的大多数老板，我也谈不上特别喜欢。但我仍然努力工作，因为那是为了我自己的成长，也是为了让我成为那种“机会来临时已经准备好的人”。当所有能力都被打磨到位、所有技能都成熟时，你才真正有资格抓住机会。
主持人：这其实和你进入37signals的经历很像吧？当时那只是一个合同岗位，你对产品也没有所有权，但你依然全力投入。结果Jason后来意识到：“这个家伙必须给点股份，否则留不住。”这其实是一个挺典型的故事。
DHH：没错，不过这种故事本身就是典型的“创始人叙事”，不能轻易外推成一种通用路径。几乎所有创始人故事都有这个特点。但其中真正具有普适性的原则，其实很简单：愿意出现，愿意投入，努力做到最好，并且持续学习。
还有一点是我后来有些后悔的——在某种程度上，我自己也曾助长过一种观念：好像你可以成为一个优秀的程序员，却并不真正喜欢编程；好像你也不需要在工作之外继续关心这件事。
主持人：这是你当时的真实想法吗？
DHH：某种程度上是的，不过这是一个误解。因为我当时是在反对那种“每周工作100小时甚至120小时”的极端文化。但那从来都不是我的工作方式。我们开发Basecamp的这25年里，一直基本保持平均每周工作40小时的节奏。
不过与此同时，就像我一开始说的，我是真的喜欢计算机。我会在业余时间折腾计算机，看新的技术，探索新的系统。这并不是那种“全天候给Basecamp客户交付功能”的工作，而更像是一种兴趣驱动的探索。但它确实一直存在。
而在2010年代，有一段时间行业形成了一种误解：你完全可以不做这些事情，只要按时上班写代码就够了。因为编程太稀缺了、太值钱了，公司几乎愿意录用任何人——哪怕这个人其实并不怎么在乎编程。
如果这种时代真的存在过，那它现在已经结束了。当年代码训练营（bootcamp）的兴起，其实就是一个很明显的信号。这本来就是经济体系应有的反应：当某个职业的薪资高到离谱，就意味着供给不足，于是自然会有更多人涌进来。这本身并没有问题。只是那个阶段，如今已经过去了。
主持人：我们刚才一直在讨论一个问题：程序员的黄金时代是不是已经过去了？也许所谓的“黄金时代”，其实指的是——只要愿意投入几个月甚至几年时间学习，大多数人都可以进入这个行业。那时候你可以去大学，也可以去训练营，只要投入时间，就能找到工作。面试不会严格查推荐人背景，甚至很多公司根本不做推荐人背调。
但现在这种情况可能正在结束。未来公司可能会越来越依赖推荐人调查，而且不只是确认“你是否在那里工作过”，还会深入了解你的能力表现。比如Databricks就很出名，他们不仅做推荐人调查，还会详细追问：你是否愿意再次和这个人合作？他的弱点是什么？你是否还会再次录用他？等等。
DHH：不过这里有个有意思的地方：所谓“程序员黄金时代结束”，听起来像是会影响所有程序员，其实并不是这样。真正优秀的程序员——甚至不用是全球最顶尖的那种，只要是很强的程序员——现在反而比以往任何时候都更有价值。因为他们最擅长利用AI带来的加速能力。
而改变我看法的关键一点是：至少在37signals内部，以及我自己的体验里，我现在做程序员的快乐程度，是自2000年代初第一次接触Ruby以来最高的一次。那种感觉真的很像“刚发现Ruby的时候”。
你可以在多个维度同时高速推进：探索P1指标优化、思考Omarchy的dual-boot支持、快速尝试各种新想法——整个工作过程本身变得前所未有地有趣。而我看到我们团队里那些最积极使用AI的程序员，也有同样的体验。虽然他们也会有一些焦虑，但这种焦虑往往被“创造能力突然增强”的兴奋感压过去了。
所以现在其实出现了一种分化状态：我们一方面知道未来充满不确定性，这确实会带来焦虑，尤其当你的收入关系到孩子七年后的大学学费时，这种焦虑完全可以理解。但问题是，这种焦虑本身并不能转化成任何建设性行动。唯一有效的路径，就是主动投入进去。
如果你只是坐在那里反复思考七年后的世界会变成什么样，那其实是在浪费时间。真正可行的路径只有一个：开始使用这些工具，而且通常这并不需要太大努力。比如把一个你以前一直没完成的业余项目拿出来，用模型试试看。如果你真的喜欢计算机，我很难想象你不会觉得这个过程有趣。
我也看到很多人正在进入这样一个阶段，比如Kent Beck。他写程序已经52年了，但他说自己现在依然非常享受编程。最近他在做一个一直想做的项目——实现一个Smalltalk服务器。过去这类事情可能要花很久才能完成，而现在，它正在逐渐接近成型。与此同时，他还能住在湖边的房子里，写到一半停下来，看两个小时的鸟，然后再回来继续写代码。
顺便说一句，Kent Beck一直都是我的偶像之一。2001年我刚开始编程的时候，曾在丹麦的一次会议上听过他的演讲，当时我完全被他的表达能力和思想深度震住了。在那之前我已经读过《Extreme Programming》之类的书，而他的《Smalltalk Best Practice Patterns》到今天仍然是我最推荐的编程书之一。如果你真的想理解方法设计、类结构设计这些更偏“战术层面”的编程模式，那本书是最好的材料之一。所以看到他现在既在使用Agent，又还能悠闲地去看鸟，我觉得非常棒。
不过也有一个现实变化：我观察到很多真正“all-in AI”的人，现在反而比以前工作得更努力了。我自己也是这样。当你只需要用一小时监督Agent，就能产生这么大的影响力时，那种效率带来的兴奋感是非常容易让人上瘾的。
如果你是那种对“发布成果”会产生多巴胺反馈的人，现在这种反馈几乎是过载状态。但我也不断提醒自己：这不是限时促销活动。AI下个月还在，之后几年也还在，不需要把所有兴奋感都压缩在两周之内消耗完。
我觉得对那些最深入使用这些工具的人来说，现在最大的挑战反而是：不要被它吞没。因为正如那句老话说的——现在已经是它们最弱的时候了。未来只会越来越强。所以你更应该想办法保持节奏，而不是被兴奋感彻底带着跑。
主持人：这种“被卷进去”的状态确实存在。比如Steve Yegge最近看起来就有点疲惫——虽然他自己也很坦诚地说，他确实被这波变化吸进去了。他身边很多朋友也是这样。你现在显然已经是深度使用AI的人之一，那你是怎么保持平衡的？比如我记得你以前提到过睡眠的重要性，而且你甚至不用闹钟？
DHH：是的，我基本不用闹钟。当然现在我妻子会用，因为孩子要按时上学。但对我来说，每晚睡满八小时，是对认知能力最好的投资。只要少睡两小时，比如从八小时变成六小时，你接下来那18小时的状态都会明显下降。这是一笔非常糟糕的交换。
我偶尔确实也会失眠，比如最近围绕AI这些事情，有几次脑子转得太快睡不着。不过这种情况非常少见。但无论如何，我认为最不应该牺牲的就是睡眠，其次是不应该牺牲健康。为了多做Agent工作而少锻炼三小时，是一笔非常差的交易。如果你想保持头脑清晰，整个系统都必须维持良好状态。
我确实看到有些人现在已经有点过度消耗自己了，但问题是：这不是一场短跑，而是一场至少持续十年的变化过程。所以别透支健康，也别透支睡眠，更别透支饮食质量。哪怕只从短期效率来看，减少睡眠也完全没有意义。连续三周每天少睡两三个小时，你最后只会变成一团混乱的状态，而不是更高效的人。
主持人：那我们最后换个角度聊聊。你其实早就可以退休了，完全可以去湖边听鸟叫。但你还是每天继续写代码——过去是打开终端，现在是调度Agent。到底是什么驱动你继续做这些事情？以及接下来你最期待什么？
DHH：驱动我继续工作的，其实就是我对计算机的热爱。对我来说，这是最有趣、最值得投入时间的事情。当然，我也做很多别的事情，比如开赛车、陪孩子。但如果每天有八小时要投入到某件事情上，那最好的选择依然是计算机。
从我五岁开始就是这样。最早是电子游戏，而现在调度这些Agent，其实某种程度上也像在玩策略游戏，比如在玩《星际争霸》一样指挥单位行动。所以不管是不是出于经济原因，我都会继续折腾计算机、理解它们的工作方式，并继续创造新的东西。
很多人对“财富”的理解其实有误区，他们以为财富是一个终点：达到之后就可以彻底躺平。但过去一百年的心理学研究早就说明，这种状态并不会带来幸福。如果你拥有无限时间，却没有目标和使命感，那并不会令人满足。几乎所有卖掉公司套现的创业者都是这样：在海滩躺三周，然后又重新回来创业。
因为他们真正追求的，从来不是终点，而是过程本身。这种创造过程，就是意义本身，也是满足感的来源。所以我会继续做这些事情。不管是自己敲代码，还是调度Agent，还是向它们学习——我都会继续和计算机打交道。
而且过去三个月之后，我现在已经非常坚定地投入到Agent可访问性（agent accessibility）这个方向上了。最近几周我们就在开发新的Basecamp CLI。这个过程也再次提醒我：我们还没有达到AGI。你当然可以让Agent写CLI，但如果你希望它“刚刚好”，仍然需要人工参与优化。
不过我很乐意做这件事。我们很快就会发布Basecamp的CLI，也会为其他产品推出类似工具。我现在非常关注一个问题：我们到底还能把这些能力推进到什么程度？
另外还有一点是，我现在每天早上都会产生一种新的冲动：醒来之后特别想看看世界又发生了什么变化。我甚至需要刻意控制自己不要一醒来就打开X，因为变化实在太快了，我总想第一时间知道最新进展。这种好奇心短期内肯定不会消失。事实上，我现在比五年前更喜欢计算机了，这种感觉真的非常棒。
视频原链接：
https://www.youtube.com/watch?v=JiWgKRgdgpI