DHH：AI agent 接管实现之后，程序员还剩下什么
Lex Fridman 对谈 DHH：从 Opus 4.5、Omarchy 到 Basecamp，理解 AI 接手代码实现后，方向、架构与品味为何成为新瓶颈。
节目资料
- 播客：Lex Fridman Podcast
- 主持人：Lex Fridman
- 嘉宾：David Heinemeier Hansson（DHH），Ruby on Rails 创造者、37signals CTO、Omarchy Linux 创造者
- 原集标题：#501 – DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux
- 发布日期：2026 年 8 月 27 日（北京时间；官方页面发布于 8 月 26 日）1
- 原集：观看 YouTube 完整视频
DHH 的判断发生了变化，判断标准却没有变：他一直在寻找能让自己写出好软件的工具。去年他嫌弃自动补全和聊天机器人，因为这些工具只是加快原来的工作；今年他认为 AI agent 已经改变了工作本身。12
分水岭是 agent，不是聊天框
DHH 把 2025 年 11 月 24 日视为一个具体分界点。对他来说，Opus 4.5 的变化不只在模型更聪明，还在于 agent harness 能调用工具、检查自己的工作、修正结果，并把任务拆给多个子 agent。原来模型帮助程序员完成一小段实现；后来模型可以沿着一条相对完整的路径完成任务。1
他把这段变化分成几层。最早，程序员仍然要告诉模型去哪里、怎么走，再审阅产出。到了访谈所说的“今年夏天”，DHH 只需给出一个模糊的问题，agent 会提出路线，自己完成更多实现。DHH 仍会检查，但在他熟悉的领域里，自己已经从驾驶者变成了监督者。2
这个经验有明确边界。DHH 认为常见的 Web CRUD 项目可能接近 100% 由 AI 生成代码；安全关键系统、自动驾驶和核电站软件仍然需要更严格的人类审查。他说的“100%”是个人实践中的代码生成比例，不是所有软件项目都适用的工程标准。1
Omarchy 说明了什么
DHH 在 Omarchy Linux 的新版本开发中，几乎没有亲手写入最终发布的代码。他负责判断功能形状，审阅系统关键部分，也会略过一部分辅助界面代码。这种工作方式之所以成立，至少有三个条件：项目由他直接掌舵，他熟悉系统的目标，agent 生成的改动会回到他能理解的整体结构里。1
这也是他对“agentic engineering”与“vibe coding”区别的实际解释。两者都可能让 AI 写大部分代码，但前者要求人类持续提供方向、约束和品味；后者如果只剩下“看起来能跑”，就容易让局部改动侵蚀整体架构。
Basecamp 暴露了另一面
37signals 在 Basecamp 5 的经历让 DHH 看到，成熟产品很难简单复制单人项目的速度。早期团队让设计师直接用 agent 做功能，单个 pull request 也许都说得过去，合在一起却破坏了原有架构，最后需要人类手工清理。1
DHH 的解释是，大型组织的瓶颈常常不在实现，而在沟通、审批和共同形成判断。AI 可以把实现做得很快，却不会自动提供产品愿景、好问题和好品味。团队如果没有足够多值得实现的想法，代码产量提高只会让更多平庸想法更快落地。
因此，程序员工作的核心正在向三处移动：说清楚要解决的问题，判断结果是否符合系统结构，以及为最终选择承担责任。AI 接手的主要是实现过程，人类仍然要决定什么值得做、怎样才算做对。2
References
- 1Lex 官方逐字稿页面
lexfridman.com
- 2Lex 官方 YouTube 视频
youtube.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.