DHH 在 Rails World 2026 上说，37signals 已经不再把手写代码当成正常业务。八个多月前，也就是 2026 年 1 月，他还在文章里写，自己做不到 90% 以上代码由 agent 写。
他现在维护 Omarchy，一个把 agent 接到系统里的 Linux 发行版。
我写过《AI 替代的是任务，不是程序员》，那篇讲被替代的是什么。这篇讲另一半：外包之后，资深工程师和架构师该留下什么。
具体实现和重复的操作可以交给 AI。质量、安全、合规和长期系统不行。架构师的新职责是决定哪些地方永远不能交出去。
1. DHH 为什么转向
DHH 的转变有时间线。2026 年 1 月，他写《Promoting AI agents》，说 agent 已经能做出生产级贡献。但他也说，对他而言，专业工作里的纯 vibe coding 目前仍是愿景，自己做不到 90% 以上代码由 agent 写。当时他用的词是监督式协作。
到 2026 年 9 月的 Rails World，他宣布 37signals 已把手写代码变成异常状态，自己也从专业程序员退休。
这一节给的是解释，材料来自他的公开自述和项目文档，不是独立测量。模型、默认值、制度，三件事叠在一起，他才愿意把整条流程交出去。
模型先过了他的门槛。2025 年 11 月 24 日，Anthropic 发布 Claude Opus 4.5。他感受到的不是分数涨了，而是可以把任务整个交出去，等结果回来验收。
2. 画家为什么没有消失
他为什么把这一天看得这么重，要从一段家史说起。
1900 年，柯达推出 Brownie，售价 1 美元，第一年卖出去 15 万台，拍照第一次变成普通家庭负担得起的事。在这之前，请画家画一幅王室全家像要以年计。他说他的高祖父 Laurits Tuxen 画丹麦王室那幅就用掉三年。
相机普及之后，画家没有消失。他给出的去向是印象派和立体主义这类相机拍不出来的东西，Tuxen 自己后来也用相机拍了肖像。他把 Claude Opus 4.5 放在 Brownie 同一个位置上：不是模型第一次出现，而是第一次便宜到普通开发者也能用。
这个类比能说明工作会变形，不能说明责任会消失。相机替掉的是「记录长相」，软件替掉的是「把需求变成实现」。肖像画不承担生产事故，软件要管权限、资金和患者数据。所以画家转型的故事能说明方向，推不出速度和边界。
默认值已经铺好。Rails 二十年攒下的目录、命名、迁移和测试结构，给了 agent 一张稳定的地图，Rails 官方 AI 页面也把约定优于配置写成 agent 的效率来源。
他自己新做的 Omarchy 走同一条路，把 agent CLI 预置成 launcher，首次运行才下载，主题和崩溃诊断都接到 agent 上。约定优于配置从框架搬到了桌面。
他有权改制度。他是 CTO 和共同所有人，能决定重写哪个产品，也承担得起后果。Basecamp 5 已经发布，演讲里说它是 agent 加速的，但仍包含大量手写代码。真正激进的是 HEY 的下一代，他现场还在纠结叫什么名字，要做 6 个原生端加 Rust 后端。
3. 该学的是修流程，不是不看代码
DHH 最有价值的说法是把手写代码当成异常状态，而不是「我不再写代码」。agent 失败时，人可以短暂接管。接管之后要回头修机器和工厂，让同类问题下次由系统处理。
他自己举过一个例子。2026 年春天做 Basecamp 5 时，几个设计师各自用 agent 写功能。单个 PR 看起来都合理，20 至 30 个合起来，架构就变得像瑞士奶酪。
团队当时的结论是模型不行。他后来说这是错的。Jared Norman 的说法更接近问题本身：没人协调的改动，不管来自 agent 还是人，都会把架构改坏。两种原因都存在，只是协调缺失比模型能力更容易被忽略。
两条修法是我从「修工厂」这句话拆出来的，不是 DHH 的原话。
一条按错误频率走。同类错误第二次出现，补一条测试。第三次出现，改设计。
另一条顺着重复走。有效的 prompt 升成项目规则。手动步骤写成脚本。脚本接进 CI，再变成门禁。门禁误报太多，就修评测集，而不是放宽标准。
做完之后，同类失败下次会被测试和门禁拦住。资深工程师的位置也跟着变，重点工作变成定义目标、验收条件、失败模式和恢复方式。
不过把实现当黑盒是有前提的。他说如果永远不用看 Rust，Rust 就很好，也说会从外部验收这个黑盒。不过能这么说的前提是接口清楚、结果可测、失败可回滚。演讲没有给完整的治理证据，所以这是他的工作假设，不是通用结论。
4. 资深工程师能交给 AI 什么
具体实现通常可以先交出去。
- 样板代码、CRUD 和适配器
- 测试脚手架、文档初稿、迁移草案
- 重构候选、性能实验和一次性工具
- 低风险模块的第一版实现
看代码也要分级，而不是全读或全不读。
可以低强度看的，是局部实现、样式、重复逻辑、无副作用的纯函数，以及已经被契约测试覆盖的模块。
必须高强度看的，是鉴权、支付、配额、密钥、审计、多租户隔离、迁移、删除、并发、外部副作用和不可回滚操作。
人不必读每一行，但必须读每个风险边界。
5. 哪些边界不能交给黑盒
一个模块能不能交出去，先过四个问题：错了代价多大，能不能撤回，出问题时能不能发现，监管会不会找上门。四个都不紧张，可以先交，但要留着退路。有一个紧张，就得留人看着。
这四个问题背后是一组工程前提：接口契约、行为测试、性能基线、日志告警、回滚方案、密钥和租户策略、明确的负责人。缺得越多，风险越往后移。
- 责任：AI 可以生成代码，不能承担生产事故。上线、变更、数据访问和事故响应都要有明确的负责人，出事时能追到人。
- 安全：需要一条能解释清楚的人类责任链。第 4 节那份高强度清单，就是安全审查的起点。
- 合规：医疗、金融、政府、跨境数据这些场景，监管要的是流程、留痕和责任主体，不是一段演示。
- 长期系统：一次性工具可以只看结果，五年系统还要看演进成本。半年后新人怎么理解，事故时谁能在半小时内定位，模型或供应商换了怎么办，依赖出现 CVE 怎么修。这些都写不进外部验收的演示。
安全这一类不是假设。HN 上有人举过自己的例子：agent 生成的几个 controller 各自重写鉴权，漏掉了统一的 before_action，于是有接口没做鉴权就上了线。他说自己读代码时一眼就看出来了。
边界也不必全靠人眼扫。权限矩阵、契约测试和静态检查能先把大部分标出来，剩下判断不了的交给人。
想让某一块变成黑盒，就按最小范围试。选一个低风险服务，走影子流量或者小流量，记录成功率、人工干预率、缺陷逃逸率和回滚次数。这些数字直接取现有的 CI 记录和事故单，不用另造统计。数字稳定之后，再扩大边界。
这四类划分是我从实践里归纳的，不是哪个研究给的结论。
6. DHH 的数字能信多少
DHH 提供了一个真实实验，不代表结论都能照抄。演讲第二天，Jared Norman 在《What About Rails?》里逐条拆过这些技术主张，结论和我一致。
他在演讲里说，8 月一个人写了 15 万行代码，是长期平均年产 3 万行的 60 倍。这个数字不能当生产力结论：他当场也承认行数粗糙，还说自己容忍了平时不会容忍的啰嗦 Rust，而公开材料里没有 commit 记录、审查流程和质量评分。
他还说 HEY 的新后端 CPU 减少 99%、内存减少 95%。没有 benchmark 和成本模型，这些收益可能同时来自换成 Rust、把渲染搬到客户端和业务简化，不能全记给 agent。
Rails 官方 AI 评测页上的数字更保守。复杂 Feature tickets 最高成功率约 53.3%，多数模型低得多。简单 Atomic tasks 最高 92.1%。每个 ticket 只跑三次，模型之间差几个点在波动范围内，这组数字也不等于生产成功率。
METR 的随机对照试验说明的是另一件事：开发者的自我感受不可靠。2025 年的实验里，资深开源开发者自估快了，实际用早期模型做同样的活反而更慢。METR 之后复述这组结果时给出的置信区间是慢 2% 至 39%，同时说旧结果已经过时，新数据因为选择偏差和并行 agent 的计时问题，只能弱支持提速。
同一场演讲里，他还说到年底手写代码会终结于几乎所有领域、几乎所有公司和几乎所有程序员，并把程序员之间的差距从 10 倍一路说到 1000 倍。
10 倍这个说法出自 1968 年的一项实验，之后被争论了几十年。Jared Norman 指出原文里并没有「平均 10 倍」这个结论。1000 倍没有任何测量，只是他在台上的估计。
他的样本还有特殊条件：小团队、高信任、产品可以快速回滚、创始人有最终验收权。这些不是所有组织的默认配置。
7. 先在一个项目试点
这套判断不用一次铺满。有干净起点就挑一个低风险服务，没有就先从存量系统里选一条高风险路径补门禁，四步走完再看要不要扩大。
- 列清单：把模块分成两类，能交给 AI 的，和必须人看的。
- 补前面那类：按第 5 节的清单补齐契约、测试、告警和回滚。
- 锁后面那类：给必须人看的路径写明负责人、审批方式、审计留痕和恢复方案。
- 复盘：先走影子流量或者小流量，记录成功率、人工干预率、缺陷逃逸率和回滚次数，再把 AI 犯过的错转成测试和门禁。数字稳定，再扩大范围。
第二步是前提。契约和测试不到位，后面量出来的成功率不作数。
还有一个约束要提前排。agent 生成快 10 倍，人的审查不会跟着快 10 倍，多出来的活都堆在 review 队列上。审查工作量得按新的生成速度重新安排。
这条我在《AI 替代的是任务，不是程序员》里写过，这里不重复。
在 DHH 的条件下，也就是约定成熟、环境围绕 agent 组织、他自己能定制度并承担后果，执行可以大规模外包。这不能推广成所有团队的结论。但有一条判断对谁都成立：执行可以外包，边界不能外包。
8. 参考
- Rails World 2026 Opening Keynote · 一手视频，pencils down、Rust 黑盒、15 万行和 Omarchy 的原始语境。文中引语取自该视频的机器转写字幕（YouTube ASR，轨道 URL 带
caps=asr），数字与专名已与en-orig轨比对，仍可能有转写误差 - Promoting AI agents · DHH 一手文章，2026 年 1 月仍称纯 vibe coding 对自己是愿景
- Basecamp Five · DHH 一手文章，Basecamp 5 的发布与克制表述
- Introducing Claude Opus 4.5 · Anthropic 官方公告，确认 2025 年 11 月 24 日发布
- Kodak Brownie · 二手（百科），1900 年 2 月推出、售价 1 美元、首年出货超过 15 万台
- Laurits Tuxen · 二手（百科），丹麦画家、Skagen 画家群成员，1886 年画《Christian IX of Denmark with family》。DHH 是他的后代这一说法出自上面的 keynote
- Rails and AI · Rails 官方 AI 评测页，基准数据与任务定义。委托与执行方（Rails 基金会、Evil Martians）的说法出自上面那条 keynote
- Omarchy · 官方仓库，元数据快照见
research/dhh-ai-coding/sources/omarchy-repo-meta.json（抓取于 2026-10-07，44,166 stars，创建于 2025-06-01） - METR：早期 AI 对资深开源开发者生产力的影响 · 一手随机对照试验，早期模型让资深开源开发者更慢
- METR：2026 年开发者生产力实验的方法更新 · 一手方法更新，置信区间、选择偏差与弱提速结论均出自此文
- What About Rails? · 二手评论，逐条质疑 15 万行这个数字、HEY 的性能归因和这场演讲的 Rails 路线
- Rails World 2026 Opening Keynote 讨论 · 二手社区讨论，447 分、508 条评论，对演讲褒贬都有