David Heinemeier Hansson（DHH）在最近的 Lex Fridman 访谈里，讲了一个让不少开发者坐不住的转变。这位 Ruby on Rails 创始人说，在 Omarchy Quattro 项目上，所有新增代码已经全部交给 Agent 完成。他自己已经有两个月没亲手写过一行代码。

这个变化不是一夜之间发生的。13 个月前，DHH 对代码补全这类工具还抱着排斥态度。现在他的立场完全倒向 AI 编程，从“不用小工具”走到了“实现代码 100% 由 Agent 接管”。

打开网易新闻 查看精彩图片

Vibe Coding 的隐性代价

全面拥抱 AI 编程之后，DHH 在 Basecamp 5 的实践中发现了一个棘手问题。设计团队用 AI 快速生成的每个 PR，单独看都合情合理。但这些局部合理的改动堆在一起，反而会破坏系统整体架构。

问题不在单个 Agent 的能力，而在缺少统一架构约束。Vibe Coding 让实现变得很快，却把“谁来守住全局”这个责任推到了人身上。DHH 的教训是：局部最优不等于系统最优。

一个人同时跑 16 条 Agent 线程

DHH 现在的日常工作方式，是在多台机器上同时运行大约 16 条 Agent 线程。他还专门开发了工具来管理这些并行任务。实现权已经下放，但判断权、架构边界和架构审查仍然牢牢掌握在人类手里。

这种工作流带来一个直接后果：代码行数这个指标失效了。DHH 的原话是“lines of code is a stupid metric”。当代码由 Agent 批量产出，统计行数既不能衡量工作量，也不能衡量价值。

机械式编码正在受到威胁

DHH 认为，机械式编码正在受到威胁。开发者的核心价值正在向上下游转移：定义问题、约束边界、架构审查、结果验收。这些环节不产出代码，却决定系统最终长成什么样。

换句话说，程序员从“手写代码的人”变成了“总调度与审查者”。Agent 负责实现，人负责判断。这个分工一旦稳定下来，团队里真正稀缺的能力就不再是敲键盘的速度。

DHH 的转变之所以值得关注，不是因为他用了 AI 编程，而是因为他把这件事推到了极端：100% 新增代码交给 Agent，自己只做架构和调度。这个实验还在进行中，但它已经暴露了 Vibe Coding 最核心的矛盾——生成越快，越需要有人守住边界。