DHH 最近在 The Pragmatic Engineer 的访谈里，讲了一件比“AI 写代码更快”更重要的事：他写代码的起点变了。
过去，他是 code first。打开编辑器，自己先进入问题，卡住了再找 AI 解释、补充或给第二意见。现在，他说自己的日常工作已经变成 agent first。先把一个任务交给 agent，让它读代码、改文件、跑命令、给出 diff；然后人再回到编辑器里看变化、判断方向、修改细节、决定是否合并。
这不是一个工具偏好的变化，而是开发工作流的重排。
Autocomplete 时代的 AI 像一个不断插嘴的实习生，试图在你写完句子之前猜下一个词。Agent harness 之后，AI 变成了一个可以离开你的光标、自己进入工作现场的人：它能用终端，能读文件，能查资料，能运行测试，能提交一个完整草稿。
于是工程师的核心动作从“亲手把每一行代码打出来”，转向“制造一个足够好的工作环境，然后对产物施加判断”。
真正的变化不是模型，而是工作现场
DHH 对 AI 的态度转变，很容易被写成一个简单故事：原来怀疑，后来真香。但他自己的解释更准确：观点没有变，事实变了。
早期代码补全没有解决他的核心问题。它打断心流，频繁猜错，而且把人压回到“接受或拒绝下一个 token”的狭小动作里。对一个有强烈代码审美的人来说，这种帮助甚至会变成噪音。
Agent-first 不一样。它不是在人的句子中间插一段，而是拿走一整个待办事项，返回一个可审查的结果。
DHH 描述自己的工作台：左边是 NeoVim，右边开着多个 agent，一个跑 OpenCode，一个跑 Claude Code，底部留着终端。很多任务先从 agent 开始。他给出意图，等它产出变化，再看 git diff。如果方向对，就提交；如果不对，就自己改，或者继续让 agent 收敛。
这里的关键不是“AI 比人强”，而是任务边界变了。
以前，一个工程师要先决定是否值得投入一段完整时间。要不要看一个积压很久的 PR？要不要研究一个不熟悉的 DBus 问题？要不要尝试一个很可能走不通的性能优化？这些问题的真实成本不是写代码，而是启动成本、上下文成本、验证成本和心理成本。
Agent 把这些成本压低以后，很多“也许有价值，但不值得现在做”的事情，突然变成了“先让它跑一轮看看”。
高手获得的不是省力，而是更大的判断半径
访谈里最有意思的例子，是 DHH 处理 Omachi 的积压 PR。
过去，250 个 PR 摆在那里，他知道每个都要花时间读、判断、试错。很多 PR 不是没有价值，而是需要他进入陌生细节：这个改动方向对不对？实现是不是符合项目风格？有没有更干净的写法？值不值得为它付出一段完整注意力？
后来他让 Claude 直接 review URL。90 分钟里，他处理了 100 个 PR。结果并不是全部合并。只有一小部分可以直接进；有些问题是对的，但实现不够好，于是让 agent clean room 重写；有些看完以后判断不该要；还有一些由 agent 帮他解释为什么当前路径不成立。
这件事说明 agent 对资深工程师的价值，不只是替他写代码，而是扩大他的判断半径。
资深工程师原本就擅长这些事：看架构是否协调，判断风险是否可控，知道一个实现是不是“像这个项目里的代码”，知道什么时候应该合并、重写、拒绝或搁置。Agent 把更多候选方案推到他面前，让他可以用同样的判断能力覆盖更多工作。
这也是为什么 DHH 认为当前阶段受益最大的不是初级工程师，而是高级工程师。因为 agent 产物仍然需要验证。你要能看出它哪里对、哪里错、哪里只是能跑但不该进主线。
AI 没有取消经验，反而把经验变成了加速器。
低成本探索会改变团队的野心
AI 编码最容易被量化的指标是速度：PR 数、代码量、节省了多少小时。但 DHH 提到的另一个变化更大：团队开始做以前不会立项的事。
37signals 有人做了一个 P1 性能优化项目。通常性能优化会盯 P50、P95、P99，因为这些指标更容易和用户体验、系统容量、业务价值联系起来。优化最快 1% 的请求，看起来像一个很难说服团队投入的项目。它太像“有趣但不划算”的工程洁癖。
但 agent 把探索成本降下来以后，这类项目的经济账变了。一个工程师可以带着直觉让 agent 跑起来，把一组小改动变成十几个 PR，几天内完成过去很难排上优先级的事情。DHH 说这个 P1 项目把大约 4ms 的请求压到 0.5ms 以下。即使你不关心这个具体数字，背后的机制也值得注意：AI 让“试一下”的成本降低了。
当试错成本下降，团队的野心会从“只做确定值得做的事”，变成“让更多直觉先变成可评估的草稿”。
这会改变 roadmap。不是所有项目都要排进两个月周期，不是所有探索都要先写完整方案，也不是所有想法都要等到有人愿意连续投入一周。很多东西可以先变成 plan、diff、demo、benchmark，再由人决定是否继续。
这时管理的重点也会变。团队不只是在压缩执行时间，而是在重新定义什么值得进入执行。
品味不是被替代的部分，而是最后的闸门
DHH 反复讲“beautiful software”。这不是审美洁癖，也不是怀旧。他的判断很直接：美的系统往往更接近正确。
这个观点放到 AI 编码里，反而更重要。
如果代码是人一行一行写出来的，风格偏差会慢慢显现，团队可以通过 review、pairing、重构来纠正。现在 agent 可以一次性产生很多代码，坏味道也会一次性放大。能跑不等于该合并，测试过不等于符合系统的长期形状。
所以 agent-first 并不是“让模型写，人在旁边看热闹”。更像是把人的手从局部敲击里抽出来，放到更高层的判断上：
| 旧动作 | 新动作 |
|---|---|
| 亲自探索每条实现路径 | 让 agent 快速生成候选路径 |
| 手写第一版代码 | 审查第一版 diff 是否站得住 |
| 靠记忆维持项目风格 | 把风格、约束、测试和工具做成环境 |
| 把时间花在实现细节 | 把注意力花在边界、风险和取舍 |
| 等问题足够重要再动手 | 先低成本做一轮可评估草稿 |
这里最稀缺的能力是品味，但不是抽象的“我觉得好看”。它包括：知道产品真正要解决什么，知道一个接口是否自然，知道一个组件是否贴近媒介，知道一段代码是否属于这个系统，知道一个改动会不会给未来留下债。
DHH 对 37signals 设计师的描述也在同一条线上。他们不只是把规格画漂亮，而是要找出规格应该是什么；不只是做视觉，而是懂 CSS、HTML，甚至能碰一点 JavaScript 和 Ruby。Agent acceleration 会让这种人更强，因为他们能把产品判断直接推进到可运行的形状。
换句话说，AI 不是只奖励“会写代码的人”，它开始奖励“能把判断落成软件的人”。
程序员的价值从实现瓶颈转向约束设计
DHH 提到 “peak programmer”，这个说法容易引起焦虑。它不一定意味着优秀工程师不值钱了。更准确的说法是：靠“实现稀缺”支撑的溢价会松动。
过去，很多组织里最贵的资源是能把需求变成代码的人。产品经理可以知道想做什么，设计师可以知道界面应该如何，但真正落地要等工程师。实现是瓶颈，所以会写代码的人拥有议价权。
当 agent 让实现变便宜，价值就会移动到新的瓶颈上：
| 新瓶颈 | 具体表现 |
|---|---|
| 问题选择 | 什么值得做，什么只是噪音 |
| 任务塑形 | 怎么把模糊意图切成 agent 能完成的工作 |
| 环境供给 | 代码库、CLI、测试、文档、权限、上下文是否适合 agent 工作 |
| 结果验证 | diff 是否正确，风险是否可控，行为是否可上线 |
| 产品判断 | 用户到底需要什么，什么体验才算完成 |
| 审美标准 | 代码和界面是否属于这个系统 |
这也是为什么纯粹“只想坐在那里写代码”的位置会变窄。不是因为写代码不重要，而是因为手写实现不再天然稀缺。除非你强到能在关键领域持续超过现成 agent，否则更大的价值会来自把业务、产品、架构、工具和验证连起来。
对工程师来说，这不是简单的转岗建议，而是工作定义的变化。以后更强的人，可能不是写得最多的人，而是能让十个 agent 在正确边界内产出，并且知道哪些结果该留下的人。
今天最值得学的，是给 Agent 修路
DHH 还有一个很实用的判断：不要等 AGI。今天的 agent 还不完美，所以要为今天修路。
他试过让 OpenClaw 自己注册 Hey.com、Fizzy.do，再进入 Basecamp 项目介绍自己。这个实验让他意识到，agent 最终可能可以直接操作现有产品，不需要人类专门铺设入口。但现实是，如果想让它稳定进入工作流，CLI、MCP、权限、结构化输出、可审查记录仍然有价值。
所以 37signals 开始为 Basecamp、Hey、Fizzy 等产品做 CLI。重点不是让人类更喜欢命令行，而是让 agent 有一条清晰、可组合、可记录的工作路径。
这件事对今天的团队很有启发。不要只问“我们要不要用某个 AI coding 工具”，还要问：
- 代码库有没有清晰的测试入口？
- 常见任务能不能用命令行复现？
- 文档能不能让 agent 快速知道边界？
- PR 里的成功和失败是否容易判断？
- 重要约束有没有写进可执行检查，而不是只存在于老人脑子里？
- 设计、产品、工程判断能不能沉淀成 agent 可用的上下文？
Agent-first 的底层能力，不是把一个聊天框接进 IDE，而是让软件系统变得更适合被代理执行、被快速验证、被人类审美收口。
最后的反常识：别把自己烧干
这场访谈还有一个容易被忽略的尾声：DHH 说，睡眠、健康、饮食不能拿来换更多 agent 工作。
这听起来像生活建议，但其实也是工程建议。Agent-first 会制造非常强的多巴胺循环。一个小时能推进过去一天的工作，一顿午饭能让多个计划来回 ping-pong，积压已久的问题突然开始移动。对喜欢计算机的人来说，这会非常上头。
但 AI 不是限时折扣。它下个月还在，明年还会更强。真正需要长期训练的，是人的判断系统：你能不能持续保持清醒，持续保持品味，持续知道该让 agent 做什么、不该让它碰什么，以及什么时候应该关掉终端。
DHH 的新写法不是“人退后，AI 接管”。更准确地说，是人换了一个位置。
人不再总是第一时间下场敲代码，而是先让 agent 把可能性铺出来；人也不是最后消失，而是在 diff、产品形状、系统美感和上线风险处重新出现。
这可能就是 agent-first 对工程师最现实的要求：少一点手工实现的自我感动，多一点对工作现场的设计；少一点迷信模型会自动变好，多一点对产物的苛刻判断。
代码会越来越容易生成。真正难的，是知道什么值得生成，什么可以合并，什么必须删掉。
资料来源
- The Pragmatic Engineer 访谈笔记：DHH’s new way of writing code，2026-04-08。