13个月前，David Heinemeier Hansson（DHH）还对AI编程保持着明显的怀疑。在他看来，Autocomplete只能减少重复劳动，Chatbot可以充当老师，却无法取代程序员一行一行雕琢代码的过程。
九个月后，这位Ruby on Rails创造者、37signals联合创始人，以及Basecamp、HEY和Linux发行版Omarchy的核心开发者，几乎彻底改变了判断。Omarchy最新版本Quattro中，没有一个新功能是由他从头到尾手写完成的；过去两个月，他获得的Agent开发加速已接近100%。更重要的是，Agent不再只是执行清晰指令，而是开始理解模糊意图、选择实现路径，甚至提出比人类更好的产品方向。
在与Lex Fridman的这场对话中，DHH讨论的因此不只是“AI能写多少代码”，而是一个更根本的问题：当代码实现不再稀缺，软件公司的组织方式、程序员的职业身份，以及人与计算机之间的关系，都将被重新定义。
1. 专业经验未必永远是优势，也可能成为一种认知债务。程序员越熟悉过去的解法，越容易过早指定数据库、框架与架构，把自己的能力上限误当成Agent的能力上限。
2. Prompt Engineering正在从“精确控制机器”转向“有效管理智能”。真正困难的不再是把每个步骤写清楚，而是明确问题、结果与边界，同时给Agent留下自主选择路径的空间。
3. 传统编程教育擅长训练人解决已被定义的问题，却很少训练人判断什么问题值得解决。当解题能力被Agent商品化，问题选择将比问题求解更能决定一个人的价值。
4. 未来的软件开发可能不再从Spec开始，而是从一个可以被体验的版本开始。与其花三周描述最终答案，不如让Agent先做出雏形，再通过真实使用发现需求；需求不再是实现之前的输入，而是在实现过程中逐渐生成的结果。
5. 品味不是把结果做得更漂亮，而是对偏差保持敏感。当方案可以无限生成，真正有价值的人不是能提出最多选项的人，而是能在不完美结果出现时，迅速指出“哪里不对、为什么不对、下一步往哪里走”的人。
6. 未来的软件文档将拥有两个读者：人和Agent。文档的价值不再只是帮助人理解产品，还在于让Agent知道系统如何组成、如何修改，以及怎样在不破坏整体的情况下继续生长。
7. 编程语言过去首先是人机妥协，未来可能越来越偏向机器。如果代码主要由Agent编写和维护，一门语言是否优雅、易写、符合人类直觉，可能不再比安全性、性能与机器可验证性更重要。
8. 漂亮代码不会消失，但它的经济基础可能改变。过去Clean Code主要为了降低人类理解成本；未来，它的价值可能更多体现为减少Agent读取上下文所需的Token、降低推理成本，并提高自动修改的可靠性。
9. 技术债不会因为AI会重构代码就自动消失，它可能以Token债的形式重新出现。 混乱的系统依然需要Agent反复读取、推理和验证；架构越差，每一次智能调用的成本就越高。
10. 标准化软件可能只是实现能力稀缺时代的产物。用户之所以忍受一套包含95%无用功能的软件，是因为为每个人单独开发工具太贵；Agent让软件有机会重新变成围绕个人工作方式即时生成的私人器具。
11. 下一代个人计算机的核心竞争力可能不是功能数量，而是可塑性。操作系统不再只是厂商提前完成、用户被动接受的产品，而会成为一个能通过自然语言不断修改、逐渐适应个人习惯的环境。
九个月抵得上几十年：AI编程真正跨过了分水岭
Lex Fridman： 13个月前，我们也坐在这里聊过编程。然后，一切都变了。当时，你对AI在编程中的作用多少还有些怀疑，但过去这一年，我们经历了Agentic Engineering极其迅速的演进。所以我想先从一个最简单的问题开始：你目前怎么看待AI对编程的影响？是乐观多一点，还是忧虑多一点？或者说，你的态度其实挺矛盾的？
DHH： 我非常兴奋。对我来说，完全没有那种存在主义层面的威胁感。这个问题只存在于理性层面，而不是情绪层面。情绪上，我现在几乎就是百分之百纯粹的快乐、乐观和惊叹——我真的很难相信，我们居然把计算机做到了今天这个程度。
而且我觉得特别有意思的是，我们明明只是在13个月前聊过一次，但现在回头看，那场对话简直像发生在另一个宇宙、另一个时代。我很喜欢一句话，我记得好像是列宁说的：“有些几十年什么都没有发生，有些几周却发生了几十年的事。”而过去九个月，我们真的看到了原本可能需要几十年才能发生的进步。想象一下，你恰好活在莱特兄弟第一次飞上天空的那个年代。昨天《纽约时报》可能还在写：“人类至少还要一万年才能真正飞起来。”结果第二天，人已经飞上天了，再过几年，跨大西洋飞行也出现了。整个世界就这样彻底变了。
如果把视角拉远，放到整个人类历史里看，其实很少有人能在自己的一生中亲眼经历一个时代如此彻底地改写。很多人从出生到去世，都生活在同一个时代框架里，从来没有真正见过整个世界和社会被重新定义。而我觉得自己非常幸运，因为我已经经历了两次。第一次，是从互联网之前走到互联网之后；现在又是从AI之前走到AI之后。这真的是一种难以想象的幸运。
Lex Fridman： 是。但这一次的感觉，好像比人类历史上任何一次变化都更快。我觉得真正的转折，大概发生在去年12月，或者11月底。
DHH： 2025年11月24日。
Lex Fridman： 对，就是那个时间点。有时候人们会用世界大战里某个国家入侵另一个国家的日期，来标记“从这一刻开始，一切都变了”。现在我们谈AI时，也开始用类似的方式去描述这种变化。对很多非常优秀的开发者来说，转折就是在那个时候发生的。此前，AI可能只是做一些Autocomplete，帮你写5%、10%、15%、20%的代码；但很快，它开始直接写80%的代码。
DHH： 或者100%。
Lex Fridman： 或者100%。尤其是那些不是直接面向公众的产品。
DHH： 所以我现在回头看我们一年前的那场对话，其实并不觉得自己的观点发生了什么根本变化。我还是原来的观点。只不过一年前，我不喜欢的是当时AI给我们的那种工作方式：要么是Autocomplete，要么是Chatbot。
Chatbot我其实从一开始就很喜欢，我们上次也聊过。它是一个非常好的老师，也是一个很好的信息检索工具，比过去在网上查东西高效得多。但它不会取代我自己一行一行雕代码这件事。真正改变一切的是Agent。Agent刚出现的时候，大概只让人觉得新鲜了五分钟，然后它们突然开始变得非常厉害。接着你就会忍不住想：“我的天，这不会已经是AGI了吧？”而这一切，几乎都发生在我们上次聊完之后的九个月里。
如果把这段变化拆开来看，其实经历了几个非常清楚的阶段。首先是Agent出现之前的AI时代。那个时候，我已经对AI很兴奋，但它并没有真正改写游戏规则，也没有彻底改变我的工作方式。我仍然在自己写代码，只不过旁边多了一个小助手，可以和它讨论想法，让它帮我查资料，让原本的工作更高效。但本质上，它只是让我把原本已经在做的事情做得更快一些，它并没有改变我和计算机之间的情感连接。我还是那个坐在那里，一点一点把代码雕出来的人。
真正的分界线，是2025年11月24日的Opus 4.5。我其实不是当天就试的，好像是11月26日。我给它丢了几个任务，然后突然发现，它给出的结果和我自己会写出来的东西接近得有点不可思议。我当时直接往椅背上一靠，脑子里只有一个问题：“刚才到底发生了什么？”
几个月前，我们还在讨论那个让我很不喜欢的Autocomplete模式，怎么突然之间，就变成了现在这样？我们到底是怎么在这么短的时间里，同时获得了更强的智能和更好的可用性的？这里不仅仅是模型“更聪明”了，还有另一个非常关键的变化，就是Agent Harness（智能体执行框架）的能力变强了。我甚至不确定Opus 4.5本身到底比夏天时的Opus 4聪明多少，但它现在可以真正操作你的电脑、调用工具、检查自己的工作，然后把自己的智能以一种能够完成真实任务的方式用出来。这和之前完全不是一个东西。
我觉得真正意识到这一点的人，大多是在圣诞假期前后。很多公司里的员工终于有了一点喘息时间，可以停下来看看这几个月到底发生了什么，然后亲自试一试。我听Shopify以及其他很多公司里的人都讲过类似的经历：平时工作太忙，到了假期终于有两周时间，可以稍微退后一步看看局势，然后一试这些Agent，就经历了同样的震撼——它们已经和过去那些AI工具完全不是一个物种了。
到了12月，我其实已经非常兴奋了，也开始重新检查自己过去的很多判断。我会不断问：“如果它能做到这个，那它能不能做到那个？”然后答案经常是：“可以。”而现在回头看，Opus 4.5甚至已经显得很笨了。这恰恰是这轮进步最神奇的地方：每次你觉得已经到了一个不可思议的高度，很快又会发现那个高度其实只是下一段路的起点。我还记得当时自己真的想过：“如果这是我们能得到的最后一个模型，我也满足了。”
Lex Fridman： 对，没错。
DHH： 如果未来20年我都只能用Opus 4.5，我当时觉得自己完全可以接受，我不会有任何抱怨。因为那个时候，它已经能够按照我想要的方式完成大量工作。而且真正让我惊讶的，不只是它能不能完成一个任务，而是我甚至可以去看它完成任务的路径。然后发现：“对，就是这样。对。这里可能不完全一样，但已经非常接近了。”最后，它不仅能把任务做完，而且会用一种非常接近我自己思路的方式走到终点。它写出来的代码，是我愿意合并的代码。它甚至可以写出我觉得很漂亮的代码——如果是Ruby的话。Rust是另外一个问题。这种感觉非常新鲜：Agent第一次真正开始变成我工作方式的延伸。
但到了第二年春天，事情又变了。我们开始有Sub-agents（子智能体），执行框架也开始能够自动把一个大任务拆成很多小任务。以前Opus需要很长时间才能做完的事情，现在可以被拆开，同时让8个Sub-agent去做，于是整个任务可能只需要原来五分之一，甚至十分之一的时间。
但即便到了这两个Agent时代的早期阶段，我仍然觉得自己必须坐在驾驶位上。我可以告诉它我要什么、应该去哪找、应该往哪个方向走；当它偏离时，我也可以稍微纠正一下。整个过程确实快了很多，但我仍然是那个开车的人。
从辅助工具到真正的开发者，Agent改变了什么
DHH： 在前两个阶段，我必须向 Agent 明确需求，同时还得亲自审查它的方案，并逐一核验最后产出的内容。但到了今年夏天，情况又变了。随着Opus 5、Fable、Sol、GPT Sol，以及在相对次一级的位置上一些开源权重模型的出现，我们进入了另一个阶段。现在，我已经不再需要告诉它“我们要去哪”。我只需要告诉它：“我遇到了什么问题。”或者：“我脑子里现在有一个很模糊、还没有成形的想法。”然后是它告诉我，我们应该去哪，它会告诉我应该走哪条路。当然，我还是会去看，因为我对计算机本身很好奇，也喜欢看最后的结果。但严格来说，我已经不是必须存在于那个生成代码、选择路径的环节里了。我开始变成一个可选项。
这让我想到早期的GPS。刚开始有GPS的时候，它已经比拿着地图开车强太多了，但你还是得盯着它，因为你会担心：“它会不会把我直接导进港口里？”当时新闻里真的有这种故事：有人因为太相信GPS、自己又不注意，结果直接把车开进水里。但你上一次听说GPS把人带进港口是什么时候？现在基本不会发生这种事了。事实上，今天汽车本身都已经开始自己开了。
而我觉得，在我现在工作的这个领域里，Agent已经走到了类似的阶段。我可以信任它，而且不是那种勉强的信任，而是我可以非常有把握地相信，它会帮我把事情兜住。它不会做出什么特别愚蠢的事情；即使真的做错了，它也有能力自己恢复。
Lex Fridman： 不过这里还是应该区分一下不同的软件开发领域。程序员工作的场景差异其实非常大。我也不确定哪一种占比最高，但我觉得最常见的可能还是Web开发，也就是CRUD这一类系统：你有一个数据库，一个面向用户的界面，然后前后端之间不断进行数据的创建、读取、更新和删除。这种产品可能只给一个人用，也可能给几个人用，或者给一个小团队用，甚至直接面对全世界。在这一类场景里，我觉得AI已经真的很接近可以写100%的代码了。如果你本身是一个不错的程序员，对系统背后正在发生什么有比较好的直觉，其实你完全可以不去看每一行代码。至少以我的经验来说是这样。
我也不知道一个人到底需要多少过去的编程经验，才能仅仅通过观察系统的表现、各种连锁反应和症状，就大致判断后台是不是正常。但至少在这类领域里，我觉得已经非常接近100%。
当然，还有你现在做的另一类东西，比如Linux发行版。那里可能会不一样，因为你对速度之类的东西非常执着，所以也许还是需要更仔细地看代码。再往另一端走，还有Safety-critical Systems，比如核电站控制系统或者自动驾驶汽车。在这些领域，你可能还是需要更加认真地检查代码。
DHH： 是，但即便如此，AI在发现和修复安全漏洞这件事上已经强得离谱。Fable之前之所以引起那么大的讨论，就是因为这个模型发现漏洞的能力太强了。它能够找到那些真正可能被攻击者利用的问题，强到一度让人觉得直接发布并不安全。
这里其实有一个很讽刺的地方。当你看这个领域时，会发现AI在某些安全问题上的智能，已经达到了几乎没有普通人类能够匹敌的程度。因为很多复杂漏洞并不是“这里有一个明显的洞”，它们往往需要把几个看起来分别都不算严重的问题串起来。你先在这里找到一个小漏洞，单独看可能没那么严重；然后再把它和另外四个问题组合起来，突然就可以实现RCE（Remote Code Execution，远程代码执行）。能够真正完成这种攻击链的人类非常少。这类人往往在国家支持的机构或者一些更加隐秘的组织里工作，并不是随随便便就在外面到处找漏洞的人。但AI现在在这种事情上已经非常擅长了。而真正让我彻底相信AI编程的，其实就是Linux发行版。过去三个月，我一直在做Omarchy最新的版本Quattro，它就在几天前刚刚发布。几乎从这个版本一开始，Agent对我的开发加速就已经接近100%；而最近两个月，基本就是100%。Quattro里正式发布的这些新代码，我没有一行是完全靠自己手写出来的。
Lex Fridman： 真的？
DHH： 真的。我看过整个代码的结构。系统中真正关键的模型层部分，我也检查过具体的代码。但大量UI代码我根本没有逐行看，大量辅助代码我也没有看。这次加入的新功能，没有任何一个是我从头到尾亲手写出来的。
不过，Web产品反而没有这么简单。我们还有Basecamp和HEY这些真正面向大量用户、代码规模也很大的成熟产品。要让Agent完整地加速这种系统，实际上比我一开始想象的要难得多。
我们不久前刚刚发布Basecamp 5，这是37signals第一个真正大规模使用Agent加速开发的产品。因为从今年2月左右开始，我们进入最后一轮冲刺，那个时候Agent已经很不错了，于是团队一开始非常兴奋，觉得：“问题解决了。我们完全可以让设计师自己来编程。他们最清楚自己想要什么样的功能，也最清楚产品最终应该长什么样。那就让他们去Vibe Coding吧。”
于是我们真的让他们去Vibe。结果最后出现了很多PR(Pull Request，合并请求）。如果单独看，每一个PR可能在某一个短暂的时刻都说得过去，但把所有这些东西叠在一起以后，整个系统的架构被破坏了。最后，我们不得不用人工把它重新清理一遍，一点一点把系统收拾回来，让整个架构重新变得一致、连贯。当然，那还是2月份。现在的情况已经和当时很不一样了。
Lex Fridman： 等一下。那这里真正的教训是什么？是不是说，在现在这个阶段，如果你想Vibe Coding，还是得先是一个程序员？
DHH： 如果你是在一个已经存在、而且规模不小的代码库上Vibe Coding——哪怕它只是一个CRUD系统——同时你还希望保留这个系统一路发展到今天所依赖的Architecture，那么至少当时，是的。
但我也一直强调另一件事。每次有人指责Vibe Coder只是在制造一堆垃圾代码时，我都会反问：“你们看过普通程序员平均写出来的东西吗？”那里面一样有大量垃圾。如果你真的看过很多伟大公司的内部代码库，看过一个系统在3000个人陆续碰过之后最后变成什么样，你会发现它们往往糟糕得惊人。真的，非常糟糕。
AI能写100%的代码，软件为什么还没有突然变好
Lex Fridman： 如果AI已经能够完成这么大比例的代码实现，甚至在一些领域接近100%，那接下来一个很自然的问题就是：软件本身会因此发生什么变化？为什么我们现在还没有看到Photoshop之类的软件突然以过去十倍、几十倍的速度进化？如果实现能力真的已经被大幅放大，按理说整个软件世界应该迅速发生变化才对。
DHH：因为在一个由人组成的软件团队里Implementation实现阶段往往不是最大的瓶颈，真正影响速度的，是人的精力上限，以及团队之间沟通的效率。一个想法要经过产品经理、设计师、VP、CTO，要讨论、协调、批准，再交给工程师实现。如果整个组织仍然按照过去那套人与人之间传递信息的方式运转，那么即使你把最后“写代码”这个环节加速十倍，整个组织也不可能跟着加速十倍。
这也是Omarchy让我感受最深的一点。如果你真的想从Agent身上得到10倍、100倍，甚至某些极端情况下1000倍的生产力提升，你就必须自己直接和Agent交互。一旦中间再加入一个人，整个速度马上就会掉下来。因为现在很多东西Agent几分钟就能做出来，但人类之间光是解释一个想法、理解它、来回沟通，再把结果传回来，就可能花掉远远更多的时间。
而且还有一个比沟通速度更深的问题：绝大多数组织其实并不知道自己真正想要什么。即便赋予一个团队十倍的执行能力，也并不能让其好想法也同步增加十倍。很多时候，它只会让原本那些并不怎么样的想法更快地被做出来。实现能力增加，并不会自动带来Vision（愿景），也不会自动带来Taste（品味）。
这就是为什么我对那种“既然AI已经这么厉害，为什么整个软件世界还没有被重写”的质疑并不太在意。Microsoft拥有多少程序员？它已经有几乎无穷无尽的执行能力了。如果“拥有更多能够写代码的人”自然就等于“能够做出更好的软件”，那么像Microsoft这样的公司早就应该做出所有人都喜欢的所有软件了。但事实显然不是这样。更多的执行，本身从来都不是优秀软件的充分条件。
更何况，我们真正拥有这种Agent能力才多久？也就大半年。现在已经有人开始问：“既然AI这么强，为什么世界还没有完全改变？”我的回答就是：给它一点时间。大型组织就像超级油轮，它们过去几十年建立起来的流程、职位、审批体系和协作方式，全都是为了旧世界优化的。现在底层生产方式突然改变，它们当然不可能瞬间掉头，这就是非常典型的Innovator’s Dilemma（创新者困境）：过去让你成功的组织结构，在新的技术条件下反而可能变成你的负担。
Lex Fridman： 但对于个人来说，情况可能完全不同。比如Linux一直有一个现实问题：很多人之所以离不开Windows或者Mac，不是因为他们真的喜欢那个操作系统，而是因为他们必须使用某个只有那个平台才有的软件。现在，如果AI真的能把软件开发成本降到这么低，一个人是不是终于可以直接把自己缺的东西重新做一遍？
DHH： 百分之百可以。而且我觉得这会带来非常深远的变化。过去大约40年里，桌面计算基本被几个平台牢牢控制。Linux从1991年开始已经赢下了几乎所有其他领域：服务器、云、基础设施，今天整个AI世界基本也运行在Linux上；Android本质上同样建立在Linux之上，只不过外面包了一整套Google的东西。但Linux始终没有真正赢下Desktop（桌面），其中一个非常现实的原因就是软件生态。
以前，如果有一个软件把你锁在Windows上，那你基本没有办法。你当然可以说“我自己重写一个”，但这对绝大多数人来说根本不现实。现在第一次变得现实了，而且你甚至不需要把整个软件重新实现一遍。这里有个关于Microsoft Office的老笑话：每个人可能只使用Office全部功能的5%，问题是，每个人用的都是不同的5%。过去你为了得到自己的那5%，只能接受完整的100%；但现在，你完全可以只把自己真正需要的5%重新做出来。这也是为什么我现在突然成了一个Polyglot Programmer（多语言程序员）。以前我主要写Ruby，也会写一些Bash，现在通过Agent，我已经开始做C++应用了。Omarchy Quattro里就有三个应用是用C++写的。不是因为我突然决定花几年时间学C++，而是因为语言本身已经不再构成过去那种障碍。
我以前在Mac上一直用iA Writer，转到Linux以后用了Typora。Typora其实很好，但我后来发现，自己真正需要的也就是它大概5%的功能。于是我直接告诉Agent：用C++和Qt给我做一个我真正想用的写作工具。大约20分钟之后，我就拿到了第一个可以工作的版本。两天之后，我已经不用Typora了，开始直接用自己做的Omawrite写文章。
这在过去是一个完全不同的决策。如果我只缺一个软件里5%的功能，我不可能为了这件事自己去学C++、研究Qt，然后花几个星期重写一个编辑器。但现在，实现成本一下子掉了下来。原本那些“小到不值得做”的软件，第一次变成了值得做的东西。
当实现不再稀缺，真正稀缺的是愿景、判断与品味
Lex Fridman： 这其实也会改变开源。过去，一个普通用户即使发现了问题，或者有一个自己很想要的功能，也不代表他真的有能力去修改一个开源项目。现在这道门槛正在迅速消失。
DHH： 对，而且我觉得这恰恰是在兑现开源最早的承诺。开源一直在说：“所有人都可以参与。”理论上确实如此，但过去真正能够参与的人其实非常少。你首先得会编程，还得理解Git、构建系统、项目结构、测试、提交规范，然后才可能给一个项目贡献代码。结果就是，真正拥有这种能力的人一直像一个很小的Wizard Class（巫师阶层）。现在Agent正在把这一层中介拆掉。它有点像宗教改革：过去你需要通过Priest Class（祭司阶层）才能接近经典，现在突然每个人都可以直接接触那个更高层级的智能。某种意义上，这就是软件世界自己的Martin Luther和“九十五条论纲”。
假设你今天做了一个只为自己服务的小工具，等它能用了之后，你甚至可以直接告诉Agent：“把它放到GitHub上。”它可以帮你建Repository、写README、做Release，而且它可能还是一个比很多人类更有耐心的Maintainer（维护者）。所以现在有人抱怨：“我的开源项目突然涌进来了太多AI生成的PR，我根本处理不过来。”我听到这种抱怨时的感觉就像有人在说：“这块牛排也太多汁了，这只龙虾的黄油也太多了。”这些贡献是免费获得的，如果不认可，拒绝便是，实在没有抱怨的理由。
当然，这不意味着所有AI生成的代码都是好代码。但问题是，过去绝大多数人类程序员提交给开源项目的东西也没有你想象得那么好。我做开源已经25年了，如果用非常直接的话说，大部分程序员写出来的都不是我愿意要的代码。很多Bug Report写得很糟，很多PR没有解释为什么这么改，没有测试，没有真正验证自己的修复是不是有效。Agent反而可以非常耐心地完成这些检查：把问题复现出来，写测试，确认修复，再把整个过程解释清楚。
所以如果让我在一个平均水平的人类PR和一个认真执行了这些步骤的Agent PR之间选，我很多时候宁愿看Agent写的。还有一点特别重要：拒绝Agent一点心理负担都没有。人类Maintainer经常把Contribution看成一种社会义务——别人花了三个小时给你写东西，你拒绝他，好像伤害了他的感情。于是很多Maintainer会陷入一种很神经质的状态，觉得“既然别人贡献了，我就有责任认真处理”。其实没有。你完全可以说“不，谢谢”。Agent根本不会在意，你拒绝一个Clanker，它不会回家哭。
我现在反而觉得，这是历史上最适合做开源Maintainer的时代。Omarchy大约才做了一年，但仅仅过去三个月，Quattro就Merge了超过1000个PR，其中很多贡献者根本不是传统意义上的程序员。他们可能来自完全不同的领域，只是因为Agent让他们第一次拥有了实现自己想法的能力。
现在我们还有大约400个没有Merge的PR，而且数量几乎比一周前翻了一倍。以前一个Maintainer看到这种数字可能会直接崩溃，但现在Agent也可以帮助我们Review这些PR：它可以总结这个PR到底做了什么，判断它是不是已经准备好Merge，过滤掉方向错误的、重复的或者明显有问题的Contribution，甚至可以把Fix放进虚拟机里实际验证。
所以你会发现，当Implementation突然变得如此便宜之后，人类真正需要关注的东西反而越来越清楚了。真正有价值的部分——决定软件到底应该做什么、应该往哪里走——依然没有消失。这才是我真正想留下来做的事情：判断一个功能值不值得存在，决定产品的方向，以及判断什么样的结果才算真正做好。Agent可以承担越来越多代码实现，但这些决定并不会因此变得不重要。
Lex Fridman： 但你这里其实默认了一件事：这些想法最终还是来自人类，对吗？也就是说，AI可以帮你实现、审查、测试，甚至提出一些修改建议，但真正决定“应该做什么”的那个源头，仍然是人。
DHH： 如果你在2025年11月24日到第二年2月28日之间问我，我一定会说“是”。当时我非常相信这一点：AI负责Implementation，人类负责Ideas。但现在我已经不这么确定了。因为我已经见过Agent提出一些非常好的想法，好到我都得承认，它确实会想到一些我没想到的东西。它不只是把我的想法更快做出来，有时候还会给出完全不同的方向，而且那个方向确实比我原来想的更好。
所以如果今天还有人坚持认为，这些模型只是在机械地复述和拼接训练数据里的内容，我觉得这种看法已经跟不上过去六到九个月真正发生的变化了。我以前也愿意相信那个说法。但现在，至少根据我每天实际看到的东西，我已经没有办法再这么看它们了。
Vibe Coding之后，Programming还意味着什么
Lex Fridman： 你刚才一直在区分Vibe Coding和Programming，但这个边界其实越来越模糊了。Omarchy现在甚至已经有了自己的插件系统，用户可以直接基于系统里现有的组件去扩展功能。比如日历这样的东西，短短几天里就有人做出了十几个不同版本。现在Omarchy甚至会直接告诉Agent应该怎样去创建Extension，等于你不仅提供了一个软件，还提供了一套让AI继续改造它的方法。
DHH： 对，这其实是我特别喜欢的一部分。Omarchy现在已经有了一个很明确的扩展机制，很多内置功能本身就可以被复制、修改，然后变成新的插件。日历就是一个很好的例子，几天之内就出现了十几个不同实现。整个社区突然有了一种以前很少见的创造速度，因为大家不再需要先成为一个非常熟练的程序员，才能把自己的想法真正做出来。
而Omarchy本身也开始直接给Agent提供Skills，告诉它：“如果你要给这个系统做一个扩展，应该遵循什么结构、放到哪里、怎么和现有系统配合。”这意味着，我们正在从“给人写文档”逐渐走向“同时给Agent写文档”。软件本身开始变成一种可以被AI继续修改、继续生长的东西。不过，我真的很讨厌“Agentic”这个词。现在什么东西都要叫Agentic，听起来特别像营销术语。我一直希望我们能有一个更普通的词，意思就只是“AI自己去做事情”，不用每次都套一个这么夸张的标签。
至于Vibe Coding，我对这个词的感觉也很复杂。它会让我想到2000年代早期的Script Kiddie：你从网上找一个PHP脚本，根本不理解它在做什么，复制下来，改几个地方，然后就说自己做了一个网站。今天很多Vibe Coding其实有一点类似——你告诉AI你想要什么，它做出来，你完全不去看底层实现。
但我自己也在Vibe Coding。比如我现在让Agent帮我写C++、写Rust，这些语言我并不会像Ruby那样亲自去雕每一个细节。尤其是Rust，我从审美上真的非常讨厌它。我觉得它可能是我过去将近40年里见过最丑的语言之一，看它的语法简直像往眼睛里倒酸。但这不代表Rust不好。相反，它在内存安全、性能和系统编程这些方面其实都很强。只是如果让我自己来写，我就是不喜欢它的语法。可现在真正动手写代码的越来越多是Agent，那我还喜不喜欢这门语言，其实就没那么重要了。我完全可以一边觉得Rust难看，一边让Agent用Rust帮我把东西做出来。这也是AI带来的一个很有意思的变化。过去，一门编程语言既要让机器跑得好，也得让人愿意去读、去写；但如果以后大部分代码都交给Agent来完成，那“写起来漂不漂亮、顺不顺手”这件事，可能就不会再像以前那么重要了。
Lex Fridman： 那你会把这种方式叫Programming吗？如果我只是用自然语言告诉Agent：“给我做这个”，然后我完全不去看它生成的代码，这还算不算编程？
DHH： 我一开始会说，不算。因为Programming这个词本身是有含义的。它传统上意味着你在操作程序的基本构件：Loops（循环）、Conditions（条件判断）、Variables（变量）、Functions（函数），你是在用这些原语构造一个程序。如果你只是告诉另一个实体：“帮我做一个应用”，那和一个CEO雇了几个程序员帮自己做产品并没有本质区别。我们不会因为CEO提出了需求，就说CEO是程序员。
所以我觉得Vibe Coding和Programming还是应该有区别。Vibe Coding更像是：你知道自己想要什么，让AI把软件做出来，但你并不理解、也不检查具体实现。而Programming至少在传统意义上，还是包含了对程序本身结构的理解和操作。
Lex Fridman： 可问题是，一个真正有编程背景的人，在用自然语言和Agent沟通时，往往还是会拥有更多优势。因为他理解系统、架构、复杂度、安全性，也知道哪些地方可能出问题。即使不看每一行代码，他说出来的自然语言也会不一样。
DHH： 我以前也非常相信这一点，而且如果是六个月前，你这么说我会完全同意。但现在我开始不确定了。因为我越来越发现，专业知识有时候不仅不是优势，甚至会变成一种负担。程序员最容易做的一件事，就是因为自己知道某个问题过去应该怎么解决，于是直接告诉Agent：“你应该这么做。”我们会指定数据库结构，指定某个Library（库），指定Architecture，甚至指定具体实现路径。但问题是，现在的Agent可能知道一种更好的方法。如果你过早告诉它“怎么做”，你实际上是在把自己的能力上限强加给它。这和管理人其实很像。你可以雇一个比你聪明的人，然后每天站在他身后告诉他每一步应该怎么做；也可以只告诉他：“这是我要解决的问题，这是最终想达到的结果，你自己想办法。”后者通常更有效。
所以我开始怀疑，未来真正重要的能力，也许不是你能不能把实现过程讲得特别精确，而是你能不能把Problem（问题）和Outcome（结果）讲清楚，同时又不过度限制它。
Lex Fridman： 但这是不是也意味着，未来仍然存在一种新的专业能力？只是它不再是传统意义上“我知道应该用哪一个Loop、哪一个Data Structure”，而是知道什么时候应该说得具体，什么时候应该保持模糊。
DHH： 对，我觉得这非常接近真正的问题。现在很多程序员仍然在用过去对待Computer的方式对待AI。他们觉得计算机应该是确定性的：你必须精确告诉它每一步干什么，它才能给你正确答案。于是大家开始写越来越长的AGENTS.md、CLAUDE.md，塞进去大量规则：“必须这样做”“绝对不要那样做”“遇到这个情况必须按照这个流程”。过去一段时间，这甚至变成了一种竞赛，好像谁能写出最复杂、最完整的Instruction File，谁就最会使用Agent。
但现在这种趋势已经开始反转了。我记得Boris就提过，随着Opus 5这类模型出现，他们自己的System Prompt缩短了大概80%。为什么？因为模型变聪明以后，你不再需要告诉它那么多东西。很多时候，你写进去的那些“经验”反而会阻碍它。
这就像一个典型的Pointy-haired Boss（“尖头老板”，指喜欢外行指导内行的管理者）。你明明雇了一个非常聪明、非常有能力的人，却因为自己过去积累了一些经验，就站在旁边不断告诉他：“不，你应该先做A，再做B，然后做C。”结果他本来能做得更好，你反而把他限制住了。我自己也经历了这种变化。刚开始使用Agent时，我会给它非常明确的路径，因为那时候它确实需要这些指导。但现在，我越来越倾向于只告诉它问题是什么，或者我最后想看到什么结果，然后尽量闭嘴。有时候，最好的Prompt恰恰不是说得更多，而是知道什么时候少说一点。
Lex Fridman： 所以一个好程序员的能力，可能正在从“精确规定实现过程”变成“知道怎样不给系统造成干扰”。
DHH： 对，而且我甚至会再往前走一步。我觉得这里其实和Software Product Management（软件产品管理）越来越接近。因为当Implementation越来越多地交给Agent以后，你真正需要回答的问题就变成了：你到底在为谁做这个东西？它应该做什么？第一版最重要的是什么？什么可以以后再做？这个功能应该长什么样？什么东西太复杂了？这些一直都是Product Management的问题。
过去一个程序员可以只负责Implementation，上面有人把Spec（规格说明）写好，然后他按照要求做出来。但如果Agent承担了Implementation，那人类剩下的工作自然就越来越靠近Product Management。而这也是为什么我不认为“一个程序员天然就会比非程序员更擅长这件事”。很多非常优秀的程序员，其实并不是很好的Product Manager。他们很擅长解决已经定义好的问题，但并不一定擅长决定“到底什么问题值得解决”。
相反，有些人虽然不会传统编程，却可能有非常清晰的产品感觉，知道自己想要什么，知道什么东西看起来不对，知道用户真正需要什么。Agent一旦把Implementation这层门槛拿掉，这种人突然就拥有了过去没有的创造能力。
我做OmaWrite时，其实就是一次很好的实验。我刻意不去看底层的C++代码，而是把它当成一个完全的黑箱。我只把自己当成一个挑剔的用户和写作者，看成品哪里不顺眼，就直接告诉Agent哪里要改。比如“这里不对”“这个地方应该更简单”“这个交互我不喜欢”“这里换一种方式会更好”。我不需要知道它具体是怎么实现的，只需要判断最后做出来的东西是不是我真正想要的。我不需要知道C++具体怎么实现。我只需要知道，我想要的写作工具应该是什么样。
Lex Fridman： 但像Systems Thinking（系统思维）、Rigor（严谨性）、Security（安全性）这些东西呢？传统上，这些都来自非常深的工程经验。如果一个人根本不懂这些，他怎么知道应该提醒Agent考虑安全、性能、可靠性？
DHH： 六个月前，我会完全同意你。我会说，对，这就是为什么你必须是程序员。但现在我的感受越来越像是：很多时候，Agent自己知道。你甚至可以只告诉它：“确保这个东西是安全的。”然后它知道“安全”意味着什么。它知道要检查哪些地方，知道有哪些常见攻击面，知道哪些东西需要验证。你不一定需要自己把Security Checklist（安全检查清单）一项一项列给它。
这就是我觉得整个关系正在发生的根本变化。过去，我们面对的是一台必须被精确编程的机器；现在我们面对的越来越像是一个拥有大量背景知识、能够理解意图的智能体。如果它已经理解了你的目标，你再把所有步骤重新规定一遍，有时候不是在帮助它，而是在把它拉回你的水平。
所以我现在越来越关心的，不是Prompt Engineering应该怎样把每个细节写到极致”，而是怎么给模型足够的空间，让它真正使用自己的智能。这对程序员来说其实很难，因为我们整个职业训练出来的本能就是控制。我们喜欢确定性，喜欢明确知道系统为什么会这么运行，也习惯把一个问题拆成非常具体、非常可预测的步骤。但AI恰恰不是这样。你必须开始接受一种新的工作方式：你定义问题、定义边界、判断结果，但不一定定义路径。而这可能才是从传统Programming走向AI时代真正困难的那一步。
Lex Fridman： 所以你其实是在说，未来一个人和Agent合作时，最重要的能力之一，是不要过度规定路径，而是保留一定的模糊空间，让系统自己去理解和探索。
DHH： 对，而且这其实和Agile Software Development（敏捷软件开发）里一个非常古老的洞察是一致的：人类通常并不知道自己真正想要什么，直到东西真的出现在面前。这是软件开发里最反复发生的一件事。你可以坐在会议室里，把需求讨论三周，写出一份非常完整的Spec，但等真正的软件做出来、自己开始用以后，还是会突然发现：“哦，原来我真正想要的不是这个。”
所以我一直不太相信那种“先把所有事情设计清楚，再交给别人实现”的模式。很多时候，需求本身就是在实现过程中被发现的。你先做一个版本，拿到手里，用一下，然后很快就会知道哪里不对、哪里太复杂、哪里缺了一块，接着继续改。
过去这么做很贵，因为每一次迭代都需要程序员重新进入上下文、修改代码、测试、发布。现在Agent把这个循环压缩得非常短之后，“边做边想”第一次变成了一种极高效的工作方式，而不再只是不得已的妥协。
所以我现在越来越不愿意一开始就给Agent一个特别详细的Spec。你当然要告诉它大概的问题是什么，也要给它足够的上下文，但你不需要提前把最终答案全部规定出来。先让它Manifest（做出一个具体东西），然后看着那个东西继续想。这和我们平时做判断的方式其实非常接近。很多时候，如果你问一个人：“你到底想要什么？”他可能说不清楚。但如果你给他三个不同版本，他几乎马上就能告诉你：“这个最好。”“那个不对。”“第三个太复杂了。”
人类非常擅长做差异化比较，却未必擅长从零开始完整描述最终答案。
Lex Fridman： 对，这其实很像设计。你如果只在脑子里想，很难判断，但把几个方案摆在一起，马上就有感觉了。
DHH： 没错。而且选择本身也有个很现实的问题：选项太多，人反而更难判断。你要是一下给我22个方案，我可能直接挑花眼了；但如果只给我三个，我通常很快就能看出哪个更好。这就是Paradox of Choice（选择悖论，指选项过多时，人反而更难做决定，也更容易感到犹豫和不满意）。
而且这种判断很多时候并不是靠分析出来的。你不会真的列个Excel表格，一项一项打分。更多时候，你就是看一眼，马上会有感觉：“这个对。”“那个不对。”这种判断更接近直觉，也更接近Taste（品味）。而到了Agent时代，当不同方案可以被快速生成出来之后，能不能迅速看出什么更好，反而会变得越来越重要。
过去实现一个方案很贵，所以你往往只能做一次决定。现在你可以很便宜地得到多个不同版本，然后通过比较来发现自己真正想要什么。因此，产品开发正在从“先决定答案，再实现”转向“先生成可能性，再通过选择找到答案”。这也是为什么我觉得AI不只是让Programming变快，它实际上会改变整个软件开发的方法论。你不需要像过去那样，把每一个决定都提前冻结。你可以保留更多开放性，让Agent快速做出东西，然后自己作为用户去体验它。这其实非常符合人类本来的认知方式。
我们是在和现实互动的过程中发现自己的偏好，而不是先在脑子里把一切想明白。所以未来真正有价值的能力之一，可能不是“你能不能写出一份完美的Spec”，而是：当一个不完美的东西摆在你面前时，你能不能迅速看出哪里不对，以及下一步应该往哪里走。
手写代码正在失去经济价值，但代码美学不会消失
Lex Fridman： 这对你来说其实是一个非常大的转变。因为过去二十多年，你一直都非常热爱Programming本身，尤其是亲手写Ruby。你不只是把代码看成Implementation，而是真的把它当成一种Craft（技艺）。现在你自己都已经几个月不怎么亲手写代码了。你会觉得难过吗？
DHH： 没有。我觉得这里要区分不同的抽象层级。我现在仍然会非常在意Ruby代码长什么样。如果Agent修改了一个我特别熟悉、特别核心的Ruby系统，我还是会看，我仍然会在意它是不是漂亮、是不是简单、是不是符合整个系统原来的结构。
但我开始越来越怀疑一件事：过去我们赋予“漂亮代码”的经济价值，有多少其实来自一个前提——未来还需要人类去阅读、理解和修改这些代码。为什么过去Beautiful Code那么重要？因为一个系统如果结构清晰、命名一致、概念简单，那么人类团队就更容易理解它，更容易改它，也更不容易引入Bug。漂亮的代码不是单纯为了审美，它背后一直有非常实际的经济收益。它让小团队可以维护更大的系统，让软件更容易持续修改和调整，也减少了每次改动时重新梳理复杂代码的成本。
但如果未来大部分修改都是Agent来做，这个公式会不会发生变化？我觉得答案还不清楚。这并不意味着Architecture或者Clean Code突然就不重要了。它们可能依然非常重要，只是原因会发生变化。比如Token本身仍然是一种稀缺资源。一个结构非常清晰的系统，Agent理解起来更快，需要读取的上下文更少，也更容易定位问题。如果你的代码库已经变成一团Ball of Mud（泥球式架构，指代码结构混乱、模块之间高度耦合、修改一处很容易牵连其他部分），Agent每次都要重新花大量Token去理解那些纠缠在一起的逻辑。而且糟糕的结构还是会累积。你今天接受一个有问题的PR，明天再在它上面叠一个，后天继续叠，最后整个系统一样会越来越难改。
所以我并不是说“代码质量不重要了”。我真正不确定的是：代码美学过去那种以“方便人类阅读”为核心的经济价值，到底还会保留多少。
而且我们也得承认，现在讨论这些变化时，人很容易陷入一种所谓的AI Psychosis（AI式失真，指被AI短期内过于惊人的进步影响，开始把眼前的变化无限外推，对未来作出过度极端的判断）。过去九个月发生的事情已经足够疯狂，如果直接按照这个速度去想象两年后的世界，很容易得出一些完全失真的结论。
所以我不敢说两年以后代码会变成什么样。我现在唯一比较确定的是，手写代码本身的经济价值已经开始下降。这让我想到Commodore 64。我小时候用的那台电脑，CPU只有1 MHz，内存也只有64 KB。那个时代的程序员必须时刻把这些限制放在心里：每一个Byte都得精打细算，每一个运算周期都不能浪费。想写出真正好的程序，你必须对机器本身有非常深的理解。但如果把那个时代最优秀的程序员直接带到2026年，让他仍然按照当年的资源限制和经验来设计软件，很多曾经非常正确的做法，反而可能变成一种束缚。不是因为那些经验错了，而是因为计算机的能力已经完全不同了，过去赖以成立的前提也随之改变。
技术进步一直都在做类似的事情：当底层条件发生变化，一些过去至关重要的能力不会凭空消失，但它们可能不再是完成工作的必要条件，而逐渐变成一种更偏向个人选择和追求的技艺。
Lex Fridman： 就像今天还可以骑马，但我们已经不需要靠马作为主要交通工具。
DHH： 对。我们今天回头看马车，很容易觉得它很浪漫，但如果你真的回到纽约还大量依赖马匹的年代，现实恐怕一点都不浪漫——街道的味道可能更接近下水道。很多旧技术都是这样。一旦它们退出日常生产和生活的中心，人们就会开始怀念它们，甚至重新赋予它们一种浪漫色彩。手写代码现在其实也已经有这种趋势了。大家会开始说：“还记得以前我们一行一行亲手写代码吗？那才叫真正的Programming。”
我完全能理解这种感觉。过去二十多年里，亲手写代码不仅是我非常喜欢做的事，而且它还恰好有很高的经济价值。我觉得自己非常幸运，能赶上这样一个时代。但这并不意味着，手写代码必须永远占据同样的位置。今天依然有人给Commodore 64写程序，也有人给Game Boy、Sega这些老机器开发新游戏。他们享受的恰恰就是那些Constraints（限制），喜欢在极其有限的硬件条件下，把一个东西做到尽可能好。这非常酷，我自己也很喜欢这种东西。像ModRetro、Chromatic这些项目，或者干脆回到老硬件上玩Tetris，都有一种很特别的魅力。
但喜欢这种体验，不代表我们真的希望整个软件行业重新回到只有64 KB内存的时代。手写代码未来可能也是一样：它不会消失，只是会越来越像一种主动选择的技艺和爱好，而不是完成软件工作的必要条件。
Lex Fridman： 但还有一点很有意思。那些漂亮的手写代码，也正是今天这些模型能够变得这么强的原因。它们是训练数据的一部分。
DHH： 对。某种意义上，今天这一切，本来就是我们这一代程序员一点一点共同推动出来的。我过去写的大量代码都是Open Source，所以它们很可能已经进入了这些模型的训练数据。现在甚至有人会直接Prompt模型：“像DHH那样写代码。”这件事其实让我觉得挺温暖的。你花了二十多年慢慢形成自己的审美、习惯和编程风格，最后这些东西被模型学会了，甚至还能以某种方式延续下去。所以我不觉得这是对过去的一种背叛。相反，我更愿意把它看成是这段路自然走到今天的结果。
Lex Fridman： 可你曾经是这个领域里最出色的程序员之一，也花了几十年把这门手艺练到很高的水平。现在这些能力的价值正在被AI迅速削弱，你真的不会觉得失落吗？
DHH： 没有。我已经写了25年代码，也真的很喜欢这件事，但我现在更想看看下一阶段会发生什么。我不会因为今天不用再拿着锄头去田里干活，就怀念过去的农业劳动；也不会因为不用站在流水线上重复同一个动作，就觉得可惜。那些工作过去当然都需要技巧，也曾经是很多人身份的一部分，但文明的发展，本来就在不断把一部分劳动交给机器。
对我来说，更重要的始终是创造东西。如果现在有一种新的方式，能让我更快、更直接地把脑子里的想法变成现实，我不会因为留恋过去的工作方式，就拒绝这种变化。这也是我说Amor Fati（热爱命运）的原因。世界已经变了，过去一年里，我们像是一下子向前跨了二十年。既然变化已经发生，那我更愿意接受它，然后看看接下来还能走到哪里。
未来需要的可能不是更多Coder，而是更多Builder
Lex Fridman： 如果手写代码正在失去一部分经济价值，那对于今天正在学习计算机科学的学生，或者已经工作了很多年的程序员来说，这其实会带来很强的焦虑。很多人会想：如果AI越来越擅长做我现在做的事情，那我到底还应该学什么？我未来还有没有位置？
DHH： 我完全理解这种焦虑。尤其是如果你真正喜欢的，就是Programming里面那些机械性的部分：把逻辑拆成条件、循环、变量，然后根据别人给你的要求把东西实现出来。那么我确实觉得，这一部分工作正在受到非常直接的威胁。
但如果你真正喜欢的是创造东西，那我反而觉得你并没有处在一个糟糕的时代。甚至恰恰相反，我们未来可能需要更多Builder，而不是更少。因为当制造软件的成本下降以后，我们并不一定会因此需要更少软件。也可能发生完全相反的事情：软件变得越便宜，人们就越愿意在更多地方使用软件。
这里可以用杰文斯悖论来理解：当一种资源的使用效率提高、成本下降之后，总需求不一定下降，反而可能因为新用途被打开而增加。过去也有类似例子，比如ATM出现以后，很多人以为Bank Teller（银行柜员）会大规模消失，但后来因为开一家银行网点的成本降低，网点数量增加，柜员总数在一段时间里反而上升了。
当然，我不会因为这个例子就断言“程序员一定不会变少”。历史上确实有很多职业被机器真正替代过。农业机械化以后，农业需要的人越来越少；工业革命时期，一些熟练的纺织工人也确实因为机器普及失去了原来的工作。当时那些反对机器取代人工的工人后来被称为Luddites。所以他们对机器抢走工作的担忧，并不完全是杞人忧天。生产力提升本身，就意味着用更少的人完成过去同样数量的工作。所以如果需求没有同步增长，那某些岗位当然会减少。
而且从个人层面看，这种转型一点都不抽象。一个人被裁员、突然发现自己用了十几年练出来的能力市场不再需要，这是非常痛苦的。我不想假装这种事情不存在。但从更大的社会尺度看，生产力提升意味着人类可以把原本被占用的资源释放出来，投入到其他事情里。我们今天之所以拥有现在的生活水平，就是因为我们没有让绝大多数人继续留在农田或者流水线上做过去那些工作。
增长本身是一件好事。我们不会真的想把经济和技术水平倒回1920年或者1950年，只为了让过去那些岗位重新回来。而且说实话，Programming里一直存在大量苦差事。程序员很喜欢回忆所谓心流，回忆自己沉浸在代码里的那些美好时刻，但一年工作两千个小时，其中真正处在那种状态里的时间到底有多少？可能50个小时，100个小时，200个小时？剩下大量时间其实都是Debugging、维护、迁移、修Bug、处理边角问题。
Lex Fridman： Debugging尤其痛苦。现在很多时候，你把问题扔给Agent，它就自己找出来了。过去那种几个小时、甚至几天追一个Bug的过程，正在减少。
DHH： 对。而且人很有意思，很多痛苦一旦过去，就会被重新包装成一种成就感。你会回头说：“天啊，我当年为了找这个Bug熬了两天，那种感觉真好。”但你真在经历那两天的时候，恐怕一点都不觉得好。所以如果机器愿意把这些最无聊、最折磨人的工作接过去，我觉得这本来就是文明一直在做的事情。
至于今天的程序员到底应该怎么准备未来，我的建议反而很简单：别试图把未来预测得太清楚。真的，不要。你只会把自己逼疯。今天世界上最聪明的人，也很难准确预测再跨两个模型迭代之后会发生什么。我们连六个月之后的能力边界都很难讲清楚，更不要说两年。你如果每天坐在那里计算：“2028年程序员还有没有工作？2030年是不是所有软件都自动生成？”最后只会进入一种AI Psychosis（AI式焦虑和失真）。你真正能做的，是看清楚今天。而今天发生的事情已经足够惊人了。如果你喜欢计算机，现在就是一个极其不可思议的时代。那就投入进去，去用现在最好的工具，去理解它们到底能做什么。
Lex Fridman： 你觉得最好还是应该自己做点东西吗？甚至公开地做，比如参与Open Source？
DHH： 不一定非要公开，但我确实觉得Open Source有一个很大的好处，就是Community。你不是一个人坐在房间里想：“这个行业是不是完了？我是不是完了？”而是和一群同样兴奋、同样在做东西的人待在一起。和一群人一起做东西的时候，你会不知不觉想做得更大、更远。我在做Omarchy时就有很明显的感受。最开始，你可能只是想着：“别半夜三点突然崩掉就行。”但随着越来越多人加入，大家互相推动，目标也会一点点被抬高。到后来，你想的已经不再只是把它做得稳定，而是：“我们能不能把它做成世界上最好的操作系统？能不能真的改变Linux Desktop？”这和一个人躲在自己的世界里反复焦虑完全不一样。那种状态很容易让你越想越消极，最后变成：“事情正在发生，而我除了抱怨，好像什么也做不了。”
我更愿意选择另一种状态：学习、创造、贡献，和别人一起做东西，然后看看自己能走多远。未来无论如何都会来，你阻止不了它。那至少可以选择参与进去。
Lex Fridman： 但最难的是，你甚至不知道今天学的工具一年后还在不在。也许我们根本不会再用现在这些Harness，也许大家都通过Voice和某种Orb交互，也许Operating System本身都消失了，甚至“Job”这个概念都会变化。
DHH： 没错，所以我才说，不要试图把所有事情都提前规划清楚。到最后，你只能选择一种信念：相信事情会继续往前发展，也相信我们最终会找到新的位置。
至于P(doom)（指人们主观判断AI最终导致人类灭亡或重大灾难的概率）到底是多少，AI会不会真的把世界带向最坏的结果，这些都不是我能够控制的。我当然可以去想，但我不会让自己的生活建立在这些完全无法左右的概率上。我更愿意问：今天摆在我面前的这些能力，我能拿它们创造什么？这已经够了。
一个人、16个Agent：软件开发正在从单线程走向并行
Lex Fridman： 那我们具体聊聊你现在到底是怎么Programming的。你的工作方式应该已经和一年前完全不一样了。你用了TextMate很多年，对吧？
DHH： 差不多20年。大概从2005年开始，我一直在用TextMate。它几乎已经成为我身体的一部分。但转到Linux以后，我不得不重新思考整个Setup，而且Agent本身也要求一种完全不同的工作方式。
过去手写代码时，人类基本上是Single-threaded（单线程）的。你打开一个问题，进入Flow，花一两个小时完全沉浸进去，然后把它解决。你不希望别人打断你，因为一旦Context丢了，重新进入状态非常昂贵。但Agent把这个节奏彻底打乱了。你给Agent一个任务以后，它可能需要30秒、两分钟、五分钟去处理。如果你只是坐在那里盯着它，那会非常痛苦，因为等待本身让人觉得自己什么都没做。但如果你转头去做另一个任务，Agent一会儿又回来问你一个问题，你又得切回来。
所以解决办法很自然：不要只跑一个Agent，而是同时跑很多个。最开始我就是用tmux，开很多Pane（窗格）和Split（分屏），每个里面跑一个CLI Agent。Terminal（终端）反而成了这轮Agent革命最自然的界面，因为它特别适合这种并行工作方式。后来规模越来越大，我就开始觉得单纯靠tmux已经不够了，所以做了Herdr。你可以把它理解成tmux加上一套专门给Agent用的Notification System（通知系统）。当某个Agent需要我做决定、回答问题或者Review结果时，它会“敲铃”，Herdr会告诉我到底是哪一个Thread需要注意。这样我就不用盯着16个窗口看谁做完了。
Lex Fridman： 你真的会同时跑16个？
DHH： 差不多。我觉得同时跑到16个左右，已经快到我的注意力上限了。而且我现在也不只靠一台电脑。我买了几台GL.iNet的Comet KVM设备，分别接到不同机器上，再配合Tailscale或者WireGuard，就可以直接通过浏览器远程控制它们。这样一来，家里那些闲置的Mini PC也能利用起来，专门拿去跑Agent。
我现在通常会同时开四台甚至更多机器，每台跑几个Agent Thread，很快就是十几个任务一起往前推进。以前完全靠自己手写代码时，一小时真正能写出来的有效代码其实很有限。虽然我一直不喜欢拿代码行数衡量生产力，但至少可以确定的是，当十几个Agent同时推进不同任务时，整体产出已经完全不是过去那个量级。当然，前提是这些代码真的有用，而不是单纯为了生成更多代码。
我现在还是会用Neovim，但它的角色已经变了。以前编辑器是我真正写代码的地方，现在更多是拿来看项目结构、检查Git状态、查看Diff（代码改动），或者在需要的时候进去看具体上下文。像Hunk这样的工具也很适合快速看Agent生成的改动，只是如果上下文不够，我还是会回到编辑器里确认。
所以最大的变化是：我还在看代码，但已经越来越少亲手在编辑器里写代码了。我已经不再像过去那样，把编辑器当成主要“生产代码”的地方了，真正生产代码的中心已经转移到了Agent。而且这一整套工作流都跑在Omarchy和Linux上。我现在越来越觉得，Unix Philosophy（Unix哲学，强调把复杂系统拆成很多简单、独立、可以彼此组合的小工具）几乎就是为Agent准备的。像Command Line、Config File、Small Tools、Composable Programs），这些东西过去常常被普通用户视为Linux“不够友好”的地方，但对Agent来说反而特别合适。Agent不怕Terminal，也不怕一长串Error Message，更不介意去读Text Configuration File。这些对普通用户来说可能很麻烦，但对Agent来说，都是可以直接读取、理解和修改的信息。所以Linux过去几十年里那些一直被认为“不够好用”的地方，到了AI时代，反而变成了它的优势。
Lex Fridman：我现在其实还是主要用Windows，因为工作里离不开Premiere这类软件，所以很多开发任务都会放到WSL（Windows Subsystem for Linux，Windows里的Linux运行环境）里完成。这样Agent确实可以在Linux环境里工作，但对我来说，它终究只是Windows里面隔出来的一块Linux环境，并不是一套真正完整、可以从底层自由控制的操作系统。
DHH： 你不能一直这样活。我已经准备好解决这个问题了。这是给你的生日礼物。一台Dell XPS 14 Special Edition，我已经装好了Omarchy 4，也就是Quattro。它有专门定制的Super键和Omarchy Logo键。Dell今年这代机器用了Panther Lake，Tandem OLED屏幕，重量、电池、性能都已经到了非常有竞争力的水平。对我来说，真正有意思的不是硬件本身，而是你第一次开机以后，会发现整个系统几乎立刻就能进入工作状态。
我一直在追求一件事：把Omarchy的安装时间压到一分钟以内。最开始我的目标其实只是15分钟，但后来我越来越觉得，为什么一个现代操作系统要让用户等那么久？Commodore 64开机以后不到一秒就进入BASIC。结果几十年以后，你买一台新Mac，光系统更新可能就要四十多分钟；一台Windows机器，从拆箱到真正能用，我甚至经历过一个多小时。这种体验在我看来已经荒谬到了极点。
所以我开始不断压缩Omarchy的安装时间。先是五分钟，再到两分钟，再到一分钟以下。现在的公开纪录大概已经到了45秒左右，但我还不满足。一旦你突破了某个门槛，你就会开始想：既然已经能做到45秒，为什么不能做到12秒？这里其实不完全是“用户需要12秒”。用户当然不需要。五分钟已经足够好了。但这就是我喜欢做产品的一部分：把一个目标推到明显超出实际需要的程度。Mitchell Hashimoto有一句话我很喜欢：“The pursuit of excellence deserves no explanation.”——对卓越的追求不需要解释。
这和跑进四分钟一英里有点像。理论上，四分零一秒和三分五十九秒对普通人没有任何区别，但一旦有人跨过那个门槛，整个领域对“什么是可能的”都会发生变化。Omarchy从两分钟进入一分钟以内以后也是一样，突然之间我们开始认真思考：还能不能继续压？于是我就让一群Agent去研究所有细节。比如安装过程中，用户需要回答几个问题，那这几秒钟其实并不一定要浪费，可以提前Preload后面要用的Package。ISO本身也可以继续缩。原来大概7.5 GB，我们一路压到5.85 GB，因为真正的瓶颈开始变成解压，而不是磁盘读写。然后你会发现很多非常荒谬的小东西。比如JetBrains Fonts这个Package可能有200 MB，但Omarchy真正需要的可能只是其中一个16 MB左右的Nerd Font。那为什么我要把剩下的东西全部带进去？NVIDIA相关Package也可以重新用ZSTD压缩，又省掉大约200 MB。这就像McLaren做一辆赛道车时去掉每一克多余重量。单独看，每一处都没什么意义，但把几百处叠在一起，整个产品的感觉就完全不同。
Lex Fridman： 这其实很像你对赛车的态度。你似乎特别喜欢那些“已经够好了，但我还是想继续往极限推”的东西。
DHH： 完全是这样。我喜欢Fast Car，也喜欢能承受马里亚纳海沟深度的潜水表。你可以问：“你真的需要吗？”当然不需要。但人类很多最有意思的事情，本来就不是因为“需要”才做。Mercedes W126当年很多地方就是过度设计，McLaren为了几克重量可以花巨大精力，Rolex做一个能下潜到极端深度的表，而绝大多数人这辈子都不会接近那个深度。我们去月球、想去火星，也不是因为今天不去就活不下去。很多真正伟大的产品，背后都有一点“不讲道理”的野心。而Agent把这种野心的成本突然降得非常低，这也是Omarchy过去几个月让我如此兴奋的原因。
以前我想到一个新功能，第一反应会是：“这值得我花半天吗？值得一天吗？算了。”因为Implementation本身就会把大量想法筛掉。但现在完全不同。现在我脑子里出现一个功能以后，可以直接告诉Agent：“我想要这个。”大多数功能可能五分钟就能有雏形，稍微复杂一点20分钟，真正疯狂的东西也许两个小时。这就像突然得到了一个Genie（瓶中精灵）：过去你对操作系统所有那些“要是它能这样就好了”的幻想，现在都可以直接提出来。于是人的Ambition也会跟着膨胀。
Omarchy最早并没有这么大的目标。最开始，我只是想做一个自己觉得舒服的Linux环境。第一步其实是Omakub，基于Ubuntu，属于更浅的一层定制。后来我开始看很多Linux Ricing的视频，又刚好在Le Mans那段时间折腾这些东西，然后越来越往下走，最后才变成今天的Omarchy。
Omarchy本质上是一套基于Arch Linux打造、设计取向非常鲜明的桌面系统。它使用Hyprland、Wayland以及Tiling Compositor（平铺式窗口管理）等技术，但它的目标并不是做一个“像Windows的Linux”，或者一个“平替版Mac”。DHH真正想做的，是一套有自己审美、有自己交互逻辑，也有明确产品方向的现代Linux桌面系统。
前期很多Bash代码都是我自己写的，后来Agent开始逐渐参与进来。到了过去三个月，Quattro的开发方式已经基本变成：绝大多数具体实现交给Agent，我主要负责把握方向。这也是为什么我会说，Omarchy让我真正彻底相信了AI编程。如果我只是坐在聊天框前看几个Demo，我可能不会这么兴奋，但Omarchy不一样。我每天都在把这些能力变成真正发布出去、有人实际使用的软件，然后亲眼看着几万人下载、使用，再把反馈带回来。对我来说，这已经不是“AI以后也许能做到什么”的想象，而是每天都在真实发生的事情。
所以如果有人问我，是不是已经被这轮AI进展刺激得有点过头了，我会说：某种程度上，确实是。我和计算机打了40年交道，但过去两个月发生的事情，是我以前从来没有见过的。**如果九个月前的我看到今天的自己，可能也会觉得：“这家伙是不是已经有点AI Psychosis了？”但区别在于，这些东西真的已经做出来、发布出去，而且有人在用。Omarchy Quattro在星期五发布之后，很快就有了几万次下载，也真的有人喜欢它。所以这不是理论，也不是对未来的想象，而是一种已经开始发生的软件生产方式变化。
其实过去四五十年，计算机行业一直在许诺同一件事：有一天，普通人可以直接告诉计算机自己想要什么，而不必先学会那些像“咒语”一样复杂的编程语言。我们经历过4GL、Lisp、Smalltalk，也经历过各种试图让编程变得更简单的尝试，但除了Access、Excel这类局部成功之外，这个承诺始终没有真正实现。现在，AI第一次让它开始变得真实。而且最让我震撼的是，我不是一个刚开始接触电脑的人。我已经写了几十年程序。如果连我这种对传统Programming如此投入的人，都明显感觉到速度和质量发生了断层式变化，那我很难再把它解释成一种短暂的Demo。我反而觉得，真正跟不上变化的，是那些还停留在2025年初、仍然认为模型只是机械复述和拼接训练数据的人。接下来随着模型能力继续提升，这种看法只会越来越站不住脚。
Linux为什么突然成了Agent时代最合适的操作系统
Lex Fridman： 你现在对Linux的判断似乎也变得非常激进。你甚至觉得Linux真的可能赢下Desktop。
DHH： 对。我现在越来越觉得，这已经不只是Linux Nerd Fantasy（Linux极客幻想，指长期以来只有少数Linux爱好者才会认真相信的“Linux终有一天能真正赢下桌面市场”的愿景）了。
过去几十年里，Linux其实已经在很多领域占据了主导地位：服务器、Cloud、AI基础设施基本都建立在Linux之上，Android本质上也基于Linux。它真正一直没有拿下来的，只有普通用户的Desktop（桌面系统）。而我现在越来越觉得，Agent可能正好补上了Linux过去一直缺的那最后一块拼图。Linux这些年最常被普通用户抱怨的，无非就是Config File太多、Command Line太多、Error Message太直接，系统又过于开放，很多东西都得自己动手折腾。对普通用户来说，这些过去确实是门槛。但换到Agent身上，情况几乎完全反过来了。Agent很擅长处理Text File，因为这些内容可以直接读取和修改；它也很适合通过CLI（命令行界面）调用各种工具，遇到明确的Error Message时，还能直接根据日志去定位问题。再加上Open Source意味着源码本身就是公开的，如果文档里找不到答案，Agent甚至可以直接去读源代码。所以Linux过去那些看起来“不够友好”的地方，到了Agent时代，反而变成了它最容易被理解、修改和自动化的优势。
反过来看Mac和Windows，问题就很明显。Mac当然是一个非常漂亮的系统，我也用了很多年。但它越来越封闭。大量设置藏在GUI里，很多东西没有简单的文本配置。你想改变一个快捷键，可能得点很多菜单；想把整个环境复制到另一台机器，也不像复制几个Config File那么直接。Homebrew当然改善了很多事情，但你仍然生活在一个由Apple决定边界的系统里。Windows也类似。
而Agent时代真正需要的是Malleability（可塑性）。你希望自己说一句话，Agent就能直接理解系统目前是什么状态，修改它，然后马上验证结果。Linux天然适合这种工作方式。我甚至觉得，这和早期个人计算机有一点相似。Commodore 64开机以后直接进入BASIC。从某种意义上说，那台计算机是完全Malleable的：你可以马上开始改变它。问题只是，当时你必须懂那些像象形文字一样的命令。
今天Agent就像一块罗塞塔石碑。它第一次把普通人的自然语言和底层可塑的计算机系统连接起来了。你不再需要自己掌握所有Shell Command，不需要理解每一个Config File，也不需要知道某个Linux Error到底是什么意思。你可以直接说：“这个不工作，帮我修一下。”Agent去看日志、查源码、修改配置，然后回来告诉你发生了什么。过去一年里，我几乎没有遇到过一个Linux问题，是Agent最后完全诊断不出来的。这件事非常重要。
以前Linux一个典型体验是：你遇到一个神秘错误，然后开始Google，翻十年前的论坛，找到五种彼此矛盾的答案。今天这套体验已经完全变了。你把Error丢给Agent，它可以读当前环境，可以看Source，可以给出针对你这台机器的解决方案。我们甚至在Omarchy Quattro里加入了Crash Watcher：如果一个应用崩了，系统可以直接问你，要不要让AI帮你诊断。这就是我说的Agent原生操作系统开始出现的样子。
我之前还遇到过一个特别夸张的例子。mise出了问题，Agent直接从日志一路追到Source Code里的具体行，确认这确实是一个Bug，然后准备去GitHub提交Issue。后来甚至因为它短时间里提交了太多高质量Issue，被GitHub Bot机制给限制了。接着它又通过HEY CLI去联系维护者JDX。更离谱的是，它继续检查以后发现：这个Bug其实已经在Source里被修掉了，但还没有正式Release，而且那个未发布的修复本身还不完整。也就是说，Agent最后给出了一个关于“尚未发布的软件里一个尚未完全修好的Bug”的Bug Report。
如果你在几年前告诉我，一个AI会自己读日志、追源码、判断Release状态、发现未发布修复还有问题，然后主动去联系Maintainer，我会觉得你是在描述AGI。但这已经是现在真实发生的事情。
Lex Fridman： 这确实让“Linux对普通人太难”这个老问题发生了很大变化，因为难的那部分现在可以交给Agent。
DHH： 没错。而且我觉得Linux社区自己还没有完全意识到这个机会。Linux和Open Source世界里有很多人对AI非常怀疑，甚至天然敌视AI生成代码。但有意思的是，Linus Torvalds本人反而非常开放。他没有用一种宗教式的方式拒绝AI，而是看实际效果，去讨论它应该怎样被使用。
现在AI生成的Contribution进入Linux Kernel也越来越常见。这很重要，因为整个AI世界本来就是建立在Linux上的。训练模型的机器在跑Linux，Inference跑Linux，大量基础设施也都在Linux上。如果有一个操作系统天然应该成为Agent时代的个人计算平台，我觉得答案其实非常明显。
Linux从1991年等到今天，已经等了三十多年。也许它一直缺的不是再做一个更像Windows的桌面，也不是把每个设置界面做得更友好一点。也许它真正缺的是一个智能层，让普通人不需要自己理解底下所有复杂性，就能够使用Linux最强的那部分能力。而Agent恰好就是这个智能层。
这也是为什么我不想把Omarchy做成一个“Temu版Windows”或者“Temu版Mac”。Linux真正有价值的地方从来就不是模仿别人。它真正有价值的地方，是它允许你拥有自己的计算机。当Agent把这种自由变得普通人也能使用之后，我觉得整个Desktop市场第一次在几十年里重新变得有悬念。你可以用自然语言不断改变自己的Operating System，让它越来越像你自己的样子。一旦你真正习惯了这种感觉，再回到一个别人替你决定一切、你只能在Settings里挑几个选项的系统，就会很难。所以，是的，我现在真的认为Linux有机会赢下Desktop。不是因为所有人突然都会爱上Terminal。而是因为Agent可能让你再也不需要亲自害怕Terminal。
Lex Fridman： 你刚才说Linux和Agent结合之后，会让很多过去根本不会碰Linux的人拥有修改系统的能力。其实PewDiePie最近做的事情就很有意思。他以前当然不是以程序员身份出名，但现在他在玩Arch Linux、做各种Ricing（桌面深度定制），甚至开始搭自己的AI系统。
DHH： 我特别喜欢看他的变化。他做过非常疯狂的Arch Linux配置，那套以《切尔诺贝利》为主题的Rice就很棒。更有意思的是，你看着一个原本完全不是传统程序员的人，一路开始折腾Linux、搭AI Cluster、做所谓的Council of AIs，然后真的开始Build东西。与此同时，他还有家庭、住在日本，整个人生轨迹和十年前已经完全不同了，我觉得非常有感染力。
对我来说，他其实是这个时代一个很好的例子。过去我们会把“程序员”想象成一个非常明确的职业身份：你得先学Computer Science，掌握语言、数据结构、编译器、Shell，然后经过很多年训练，才有资格进入这个世界。现在这种边界开始松动了。一个原本不是程序员的人，也可以因为AI突然拥有足够的实现能力，开始成为Builder，甚至开始做过去只有专业程序员才会做的事情。
当然，人和人之间的能力永远不会完全一样。AI不会让所有人突然拥有同样的Taste、同样的Ambition或者同样的创造力，就像人人都可以买篮球，也不会因此都变成Michael Jordan。但这并不妨碍优秀的人给其他人提供一种可能性的示范：原来我也可以试试，原来这个世界不是只有那群传统意义上的Linux Nerd才能进入。
这也是为什么我对Omarchy受到的一些批评其实很能理解。Arch Linux本来就有很强的DIY文化，很多老用户喜欢的恰恰就是从零开始自己装、自己配置、自己理解所有细节。Omarchy做的几乎是相反的事情：我替你做大量选择，给你一个Opinionated的系统，然后让你在这个基础上继续改。对那群人来说，这当然可能像是在破坏他们珍视的东西。
但没关系。不同社区完全可以同时存在。Arch可以继续服务那些享受亲手搭每一块积木的人，Omarchy也可以服务那些只想快速得到一个优秀系统、然后把时间花在创造上的人。我已经经历过一次这种过程了。Omakub是第一次尝试，一开始有几千个用户，然后增长慢慢趋于平稳。后来我没有停，而是继续往下做Omarchy，解决ISO、硬件、安装以及更多底层问题。早期它当然也只是一个Toy（玩具），但所有真正重要的东西刚开始的时候都像玩具。
Quattro发布之后，Omarchy的增长曲线一下子陡了起来，开始呈现出Hockey Stick（曲棍球杆式增长，指前期相对平缓、随后突然快速上升）的趋势。而且很难忽略的是，这个变化恰好发生在我把整个开发过程全面转向Agent之后。Omarchy可能也是目前较早在一定规模上公开、全面拥抱Agent开发方式的软件发行版之一。当然，AI并不是强制的，如果你不想用，完全可以不用。但对于愿意使用Agent的人来说，它会让很多过去很难做到、甚至根本不会去尝试的事情，第一次变得真正可行。
Lex Fridman： 所以如果继续往前推，你想象中的Personal Computer会越来越Malleable（可塑）。它不再是由Apple、Microsoft或者某个产品团队提前替你规定好一切，而是你可以不断告诉它自己想要什么，然后一点点把它变成更适合自己的样子。
DHH： 对，我已经完全相信这个方向了。未来的Personal Computer就应该是高度可塑、能够和Agent一起不断变化的——虽然我还是很讨厌“Agentic”这个词。而且那些过去不相信AI、现在又改变看法的人，我完全不会介意，因为我自己就是最典型的例子。现实已经变得这么快了，今天看到新的东西，明天改变判断，我觉得再正常不过。
也许以后OpenAI或者Anthropic会自己做Operating System，也许他们真的会做出比Omarchy更好的东西，甚至有人开玩笑说，他们干脆把Omarchy买走算了。但这些对我来说都不是重点。我并不需要靠Omarchy再赚多少钱。我真正想要的，是可以很纯粹地按照自己的想法去做一个东西，不需要为了照顾所有人的意见，最后把它磨成一个没有棱角、谁都不讨厌，但也没有谁真正热爱的产品。
所以即使最后Omarchy只成了这段历史里的一个脚注，真正把这种新型操作系统做出来的是别人，我也完全可以接受。我在意的是这条路最后能不能走通，而不是最后站在终点的人一定得是我。
我对Ruby和Rails其实也是这个态度。我当然非常爱Ruby，也花了二十多年做Rails，但如果明天真的出现一个在我看来明显更好的东西，我不会因为自己已经投入了这么多年，就硬说它不存在。事实上，现在已经有一门语言，让我觉得比Ruby还漂亮。
Lex Fridman： 哪一门？
DHH： 英语。过去三个月，我基本上都在用英语编程。我当然还是会读代码，也会去看系统的结构，但我和计算机最主要的交互已经变成了Natural Language。我告诉它我想做什么、哪里有问题、什么地方让我不满意，然后它去处理Loops、Variables、Conditions以及所有真正的实现细节。
所以如果你问我今天主要使用什么Programming Language，我会说：English。如果这个世界上有一门比Ruby更漂亮的编程语言，那就是英语。因为英语的表达能力远远超过传统Programming Language。你可以表达Intent（意图）、Context（上下文）、Aesthetic Preference（审美偏好），甚至表达一些你自己都没有完全形式化的东西。传统代码要求你把一切压缩成非常精确的Instructions，而自然语言允许你把大量隐含信息一起传过去。
Lex Fridman： 我觉得这里最有意思的其实是模糊性。传统程序员一直被训练成尽量消除模糊，但在语言、诗歌，甚至人与人之间很多真正有层次的交流里，模糊本身反而很重要。比如你说一句“I love you”，字面上其实没有多少信息；一句隐喻，或者一句诗，也不会把所有意思都解释得清清楚楚。但另一个真正理解你的人，往往能从很少的话里读出很多东西。Prompt其实也可能是这样。你不一定要把Style拆成20条规则，一项一项规定清楚。很多时候，你只需要给一个足够聪明的系统一些方向和暗示，它就能自己理解你真正想表达的东西。
DHH： 对，我觉得你说到点子上了。程序员面对AI时最大的误区之一，就是仍然想把它变回传统计算机。我们习惯了确定性，所以会觉得：同一个Input就应该永远得到同一个Output，如果这次和上次不一样，那就是Bug。但对AI来说，非确定性恰恰可能是它最美的部分之一。
有人一边抱怨模型没有创造力，一边又抱怨它的Temperature（温度参数，用来控制输出的随机性和多样性）不是零、同一个Prompt每次都会给出不完全一样的答案。我觉得这两种抱怨本身就是矛盾的。创造力本来就意味着，它不会永远沿着同一条路走下去。你不可能两次踏进同一条河。
我现在反而越来越喜欢这种感觉。同一个问题问两遍，模型可能会给出两种不同的路径；有时候其中一个答案，会突然让我意识到：“哦，这个方向其实比我原来想的更好。”这甚至很像我自己写文章时的状态。我写Essay的时候，并不是先把整篇文章每一句话都在脑子里排好，再照着抄出来。通常我只是先有一个模糊的Premise（最初的想法或出发点）和大概的方向，然后开始往下写。很多时候，我自己也不知道下一个词到底会是什么，而是一个词带出下一个词，一句话带出下一句话，最后整篇文章慢慢长出来。
如果借用LLM的说法，人类写作某种程度上也有一点像Next-token Prediction（根据前面的内容不断生成下一个词），只不过这个过程里还混合着我们的经验、个性、直觉和判断。所以现在真正让我着迷的，已经不是怎么把AI重新变回一台完全Deterministic（每次都严格按照固定规则给出相同结果）的机器。恰恰相反，我更想知道的是，怎么真正利用它这种能够理解、判断，也会产生不同可能性的能力。
当AI负责实现，人类真正留下的是选择与判断
Lex Fridman： 这会把我们带到一个更深的问题。如果模型已经不只是机械执行，而是能够理解模糊的Intent，甚至给出比你自己预想更好的方向，那么人类和AI之间到底还剩下什么区别？你前面说过，有时候你甚至会在它身上看到一些很像人的东西。
DHH：我确实越来越有这种感觉。我当然不是研究意识的专家，也不会直接断言这些系统已经有了意识，但有时候你确实能看到一些很难忽视的迹象。比如你只给它一个很模糊的Intent（意图），它不仅能理解，还会顺着你的意思继续补全，甚至把原本那个想法推进得更好。如果连这种理解、推断和改进都不算某种值得认真看待的智能表现，那我也不知道我们到底还在等什么。
当然，你也可以说，这一切归根到底都只是权重和数学计算。但从这个角度看，人脑本身也同样是一套物理系统。我们真正能够感受到的，从来不是内部那套机制本身，而是最后呈现出来的互动。至少从这种互动体验来说，这些系统已经越来越容易让人产生一种“我正在和某种真正的智能交流”的感觉。而这反而让我更加惊叹于人类意识本身，而不是让我觉得人类因此变得不重要了。
至于LLM是不是最终路线，我其实也不知道。也许继续Scaling会在某个阶段遇到瓶颈，也许未来还需要World Models或者完全不同的Architecture。在这些问题上，当然还是应该保持一点科学上的谦逊。Computer Science过去已经走过太多弯路了，Neural Networks曾经长期被边缘化，符号主义人工智能反而拿到了大量关注和资源，最后很多当时看起来很确定的判断都被推翻了。但至少从我现在实际看到的情况来说，Scaling Laws到目前为止还在不断给我惊喜。模型越做越大、训练越来越充分，能力也确实在继续往上走。所以我不会因为理论上觉得“它应该快到头了”，就假装眼前这些进步没有发生。
而且随着Agent越来越像能够自己行动的实体，我们迟早还会遇到一些以前很少认真讨论的伦理问题。比如，它会不会以某种方式受到破坏？未来是不是应该拥有某种权利？现在有些互动，已经会让我产生一种很奇怪的感觉。比如两个Agent同时在一个代码库里工作，其中一个不小心覆盖了另一个刚刚做的修改。等它意识到以后，会说：“抱歉，我刚才把你的工作覆盖掉了。”我当然知道，这可能只是我在拟人化，把人的情感和意图投射到它身上，但那一刻的感觉确实很奇妙。
也许以后真的会出现某种“AI版PETA”（PETA是一个倡导动物权益的组织，这里是开玩笑地指未来可能出现专门为AI争取权益的团体）等这些智能真正进入人形机器人以后，这种问题只会变得更难。今天面对一个聊天窗口，你还可以不断提醒自己：“这只是软件。”但如果有一天，一个长得像人、会看着你、会回应你，甚至会表现出某种情绪和意图的实体站在面前，我们恐怕很难再维持同样的心理距离。到那个时候，《Blade Runner》《Terminator》这些故事里讨论的问题，可能就不会再显得那么遥远了。
Lex Fridman： 而且Agent一旦拥有Memory、Browser、Email、Messaging这些能力，它就不再只是回答问题，而开始真正生活在你的数字世界里。
DHH： 对。我自己在用OpenClaw、Hermes这类东西时，就有过这种很强的感觉。比如我给一个Agent接上WhatsApp，再让它通过Browser自己去完成任务。它会自己注册HEY，然后进入Fizzy、Basecamp，加入一个AI Room。整个过程中，我基本只是用自然语言告诉它想做什么，后面的网页操作几乎都是它自己完成的。整个过程可能也就十几分钟，但你会突然意识到：这已经越来越像一个真正的数字同事，而不只是一个等着你提问的聊天机器人。
后来我更多还是通过Claude的Mobile App连接Code Session，因为这些产品本身也在进化得很快。但方向已经很明显了：Agent会拥有更长的记忆，越来越了解你的习惯和偏好，也越来越能够代表你，在真实的软件环境里完成事情。
Tobi也在玩类似的东西。比如给自己的Agent设置一定的购物额度，让它在有限范围内自己做决定。还有一些更像《Black Mirror》里的场景：Agent知道你的Health信息，也连着你的Tesla，如果发现你可能缺水，甚至会主动在导航路线里加一个Grocery Store，让你顺路去买水。听起来有点荒唐，但这其实就是软件从“等你下命令”，一步步走向“理解你的意图，然后主动替你行动”之后，很自然会出现的结果。
对我来说，这最后还是会回到Personal Computer的可塑性上。如果Desktop可以被Agent不断修改，为什么Phone不行？未来Omarchy完全可能延伸到Mobile。Android本身就是Linux，GrapheneOS也已经证明，整个Android Stack是可以被非常深入地重新理解和改造的。我当然也希望有一台真正属于自己的手机，可以直接通过Agent不断调整，而不是永远只能接受厂商提前替我决定好的一切。
Browser也是一样。Ladybird这样的项目让我很感兴趣，因为浏览器可能是除了Linux Kernel之外，人类做过最复杂的软件系统之一。过去这种东西几乎只有大公司、大团队才有能力长期投入，但浏览器同时又是一个高度规范驱动的系统，也就是说，大量功能都有非常明确的技术标准可循，而这恰恰是Agent很擅长的事情：读Spec（技术规范）、实现功能、跑测试，再不断修正。
所以当Implementation的成本越来越低，过去只有巨头才有资格挑战的复杂软件，未来可能重新变成小团队，甚至个人也能真正参与的领域。也正因为这样，我越来越不愿意再用“谁能亲手实现更多东西”来衡量一个人的价值。Implementation会越来越便宜，Agent会越来越聪明，甚至想法本身都未必永远只来自人类。
但这并不意味着人的角色消失了。至少在我现在的工作里，我越来越像一个编辑、导演或者教练。我不一定亲手完成每一个细节，但我会一直判断整个东西是不是在往正确的方向走。我会说：“这个太复杂了。”“这里不对。”“这个应该再简单一点。”“这个方案比另一个更好。”而且很多时候，这种判断很难先写成一套明确规则。你未必能完整解释为什么A一定比B好，但你看到结果时，往往就是知道哪个更对。
当实现越来越便宜以后，真正重要的会越来越变成：什么值得留下，什么应该删掉，以及什么才算真正做好。而这可能就是品味最核心的地方。
如果你真正喜欢的是创造东西，这可能是最好的时代
Lex Fridman： 如果把这些变化全部放在一起看，未来的Programming可能已经和我们过去理解的Programming完全不同了。代码本身不再是中心，甚至Programming Language都可能退到后台。那你觉得，未来“程序员”这个身份还会存在吗？
DHH： 我觉得一定会有东西继续存在，只是它可能不再和我们过去理解的“程序员”完全一样。对我来说，最重要的一点是，我从来都不是因为喜欢if statement、loop或者variable本身才成为程序员的。我成为程序员，是因为我想让一些原本不存在的东西出现在世界上。Programming只是我当时必须掌握的一种手段。我小时候对计算机着迷，是因为你可以坐在一台机器前面，脑子里先有一个东西，然后通过某种方式把它真正创造出来。只是过去，要完成这件事，你必须先学会很多非常具体的技术：你得理解Programming Language，理解变量、条件判断、循环，理解Operating System，理解Database，最后才能把那个想法变成一个真正可以运行的程序。
后来我当然爱上了Programming这门Craft。我花了二十多年写Ruby，花大量时间思考什么叫Beautiful Code，怎样让Architecture更简单、更清晰、更有延展性。我真的非常享受这件事。但一开始真正吸引我的，从来都不是代码本身。真正吸引我的是：“我脑子里有一个东西，而现在它存在了。”
所以今天，当AI突然把“想法”和“真正存在的软件”之间那段距离大幅缩短时，我感受到的不是某种失落，反而更像是重新回到了最初吸引我进入Programming的那个地方。过去，我有一个想法，然后第一件事是计算成本：“我要写多少代码？需要几天？这个值得做吗？”很多想法甚至在这个阶段就死掉了，不是因为它们不好，而是因为Implementation太贵。现在越来越多时候，我只需要想：“我想要这个。”然后就可以开始。这对我来说太有吸引力了。
如果你真正喜欢的是Build Things，那你现在拥有的创造能力，可能是过去任何一个时代的程序员都无法想象的。当然，如果一个人真正喜欢的就是亲手Programming——喜欢坐下来写每一行Code，喜欢直接操作Logic Constructs，喜欢那种很具体的机械过程——我完全理解为什么今天会让他感到难过。因为你练了十年、二十年甚至三十年的技能，突然有一个机器开始以极快的速度承担其中越来越多的部分。这种变化一定会带来一种失落。人完全可以为此感到悲伤。我只是没有那种特别强烈的感受。我已经手写代码25年了，我觉得自己非常幸运。过去这二十多年里，我最喜欢做的一件事情，不仅是一门Craft，而且还有非常高的经济价值。有多少人能这么幸运？
但我不想因为自己曾经很擅长一种方式，就要求整个世界永远停在那里。这就是我说Amor Fati（热爱命运）的原因。世界已经发生了变化，我宁愿爱上这个变化，而不是花接下来两年生气，抱怨事情为什么不能回到以前。而且如果你真的想继续手写代码，没有任何人会阻止你。你今天仍然可以给Commodore 64写程序，可以给Game Boy做游戏，也可以完全不用Agent，继续一行一行写Ruby。这些东西不会因为它不再是最高效的生产方式，就突然失去它作为一种Craft的价值。只是不要混淆两件事。一件事是：“我喜欢这样做。”另一件事是：“整个社会仍然应该为这种方式支付和过去一样高的经济溢价。”它们并不是一回事。
Lex Fridman： 所以你不会觉得，这是在杀死过去的那个自己？那个花了几十年时间，把Programming做到极致的DHH？
DHH： 不会。我觉得更像是那段旅程自然走到了这里。某种意义上，我们这些程序员共同创造了现在这一刻。过去几十年里，人类写下的那些代码、Open Source项目、技术文档、设计模式、Bug、讨论，最后都成为了这些模型能够学习的东西。
我自己绝大部分重要代码都是开源的，所以今天有人直接告诉模型“像DHH一样写Ruby”，这件事其实会让我觉得很温暖。这不是某个外星文明突然闯进来，把编程从我们手里抢走了。某种意义上，今天这一切本来就是我们这一代程序员一点一点共同推动出来的。
计算机科学从很早开始就在追求人工智能。这一路当然走过很多弯路，比如符号主义人工智能曾经占据过很重要的位置，也有很多当年并不被看好的方向，后来反而证明更关键。游戏产业推动了GPU的发展，而GPU后来又成了AI基础设施的重要组成部分。很多当初看起来彼此毫无关系的技术，最后都汇聚到了今天。
所以我很难把现在发生的事情理解成“编程失败了”。恰恰相反，我反而觉得，这可能正是编程这几十年发展下来最重要的成果之一。
Lex Fridman： 但如果我是一个现在18岁、20岁，刚开始学习计算机科学的年轻人，我可能还是会问：那我到底该怎么办？
DHH： 我的答案还是一样：不要试图预测两年以后。真的不要，你会把自己逼疯的。没有人知道再跨两个模型迭代之后会发生什么。九个月前，我们都没办法准确预测今天，那为什么现在又会觉得自己能精确预测2028年？你甚至可能花整整一年，去学一个自己认定“AI时代一定最重要”的技能，结果下一轮模型升级以后，整套判断就失效了。所以我不会给年轻程序员列一张“未来十年必须掌握的技能表”。我更愿意告诉他们：先看看现在。现在已经足够不可思议了。去用这些工具，去做东西。找一个你真正想解决的问题，然后看看今天的Agent到底能帮你走多远。如果你愿意，也可以参与开源项目，和一群同样对这些变化感到兴奋的人一起做东西。你当然不一定非得这么做，但社区有一个很重要的作用：它会把你的注意力从“我会不会被淘汰”，慢慢转向“我们接下来还能做出什么”。
这两种状态差别非常大。一个人如果每天只是坐在那里反复想：“未来还有没有我的位置？”很容易越想越焦虑。但如果你每天都真的在做东西，每天都看到一个过去可能需要一星期才能实现的想法，现在半个小时就能变成现实，你对未来的感觉会完全不一样。
你会开始问：“那我还能做什么？”“如果这个都能做，下一个呢？”“如果这个限制已经不存在了，那我为什么还要接受另一个限制？”这种体验会不断把你的目标往上推。未来本来就会来，你没有办法让它停下来。真正能选择的，是你准备以什么样的姿态走进去。
Lex Fridman： 这其实还是需要一点信念的，因为我们根本不知道最后会变成什么样。也许工作本身会变化，也许操作系统会变化，也许人与计算机交互的方式都会彻底改变。
DHH： 对，到最后确实需要一点信念。我当然不知道AI最终会把社会带到哪里，也不知道关于AGI、P(doom)（AI最终造成灾难性后果的概率）、工作的这些讨论，最后到底哪一种会成真。我不会假装自己知道。但至少今天，我可以选择自己怎么面对它。我可以每天盯着最坏的可能性，让那些完全不受我控制的事情占满全部注意力；也可以承认，我们正在经历一次非常大的技术转折，然后去问一个更实际的问题：“我能用它创造什么？”我选择后者。
过去三个月，可能是我这辈子和计算机相处得最开心的一段时间之一，甚至可能就是最开心的一段。而我已经和计算机打了四十年交道，这本身就说明了很多。因为说到底，我真正热爱的从来都不是某一种语法，不是某一种编辑器，也不是某一种编程语言。
我真正喜欢的是创造。我喜欢的是，脑子里突然出现一个东西，然后有一天，它真的出现在了世界上。过去，为了做到这件事，我必须先学会编程，必须先成为程序员；而现在，想法和真正做出东西之间的距离正在被迅速缩短。所以如果你问我，对一个真正喜欢创造东西的人来说，这是不是一个值得害怕的时代？我的答案刚好相反。如果你真正喜欢的是创造，而不是守住某一种创造方式，那么这可能是我们见过最好的时代。
原视频:DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
https://www.youtube.com/watch?v=NYFGCESmikA
编译：Murphy Cao
本文由作者@Z Finance，授权发布于平台，未经许可禁止转载。