HumanLayer 创始人 Dex Horthy：AI 编程越快，工程判断越值钱
从高中时期在 NASA JPL 开始写代码、后来创办 HumanLayer 的 Dex Horthy，在这场访谈里解释为什么 Coding Agent 越快，软件交付的瓶颈越会转向程序设计、验证与长期维护。
这期访谈的嘉宾 Dex Horthy 是 HumanLayer 创始人，也是《12-Factor Agents》的作者。他从高中时期在 NASA JPL 开始写代码，后来长期从事开发者工具和 AI Agent 工程。
我原以为这会是一场展示复杂 Agent 编排的访谈：更多并发、更多自动化、更长时间无人值守地运行。
结果视频开头，Dex Horthy 说的正好相反。
别再摆弄你的 Coding Agent 了，回去做真正的工作。
这句话不是反对 Coding Agent。恰恰相反，他已经把 Agent 放进需求、开发、评审、测试、监控和故障处理组成的软件工厂里。它反对的是另一件事：把“让 Agent 生成更多代码”误认为工作的最终目的。
当代码可以在几分钟内生成，工程的瓶颈就不再是敲键盘。问题变成了：我们是否在解决正确的问题，Agent 做出的关键决定是否合理，生成的系统能否被验证，三个月后还有没有人理解它。
我看完这期访谈后最强烈的感受是：AI 没有消灭软件工程，它只是把软件工程里最需要人的部分暴露了出来。
写代码快了，软件工厂不一定更快
传统的软件交付链路大致是这样：
提出需求 -> 设计 -> 开发 -> 代码评审 -> 测试 -> 部署 -> 监控 -> 用户反馈Coding Agent 最先加速的是“开发”。原本需要几天的实现，现在可能几十分钟就能得到一个 Pull Request。于是一个很自然的想法出现了：既然一个 Agent 能写这么快，那就同时启动十个。
问题是，后面的环节并没有按相同比例加速。
十个 Agent 可以带来十倍的代码，却不会自动带来十倍的理解能力、评审能力和线上容错能力。开发从慢环节变成快环节以后，待评审的改动开始堆积，验证开始堆积，人对系统的理解也开始落后。
这不是生产力增加，而是在新的位置制造在制品。
访谈中，Dex 回忆团队曾经尝试过一种“轻软件工厂”：人负责讨论需求和计划，但不再认真阅读 Agent 写出的代码。开始时速度很快，直到几个月后出现一个 Agent 始终无法定位的故障。人不得不重新进入一个已经失去理解的代码库，在大量欠缺维护的实现里排查了数周。
这段经历揭示了完全自动化最容易被忽略的成本：
你今天省掉的理解，可能会在未来以更昂贵的方式补回来。
Agent 会解题，不等于它会维护系统
为什么 Coding Agent 在测试和 Benchmark 上表现越来越好，却仍然可能写出让人难以维护的系统？
关键在于训练和评测到底奖励什么。
SWE-bench 的基本任务是：给模型一个真实代码仓库和 GitHub Issue，让它生成补丁，再通过测试判断问题是否解决。这比单纯补全代码更接近真实开发，也确实推动了 Coding Agent 的解题能力。
但通过测试只能证明一组可观察行为成立，不能自动证明：
- 改动是否引入了不必要的复杂度；
- 文件和抽象是否放在了正确的位置；
- 下一项需求是否更容易添加；
- 代码在连续演化几个月后是否仍然清楚；
- 测试没有覆盖的行为是否符合开发者意图。
一项针对 SWE-bench Verified 的实证研究发现，一部分被判定为解决的补丁实际上没有满足更完整的开发者测试或表现出与人工补丁不同的行为。OpenAI 后来也在编程评测分析中说明，数据污染和任务设计问题会削弱该 Benchmark 对前沿模型的区分能力。
这不意味着 Benchmark 没用。更准确的结论是：Benchmark 可以衡量某类限定问题的解决能力，但不能单独证明一个 Agent 能长期经营代码库。
测试有没有通过，可以在几分钟内得到反馈。架构是否糟糕，往往要等到几周后的下一项需求、几个月后的线上故障，才会显现代价。对于训练系统而言，前者有快速而明确的评分标准，后者没有。
所以模型自然更擅长“把眼前问题做对”，而不是“让未来的问题更容易解决”。后者仍然需要人的工程判断。
人的判断应该前移，而不是堆在代码评审里
如果最后一次性审查几千行 Agent 生成的代码，人的介入会变成一项痛苦而低效的工作。Dex 给出的解法不是取消人的判断，而是把判断移到代码生成以前。
他把一次功能开发分成四层。
| 层次 | 要回答的问题 | 应该留下的产物 |
|---|---|---|
| 产品设计 | 用户遇到了什么问题，什么结果算成功 | 用户故事、成功指标、产品说明、界面原型 |
| 系统架构 | 服务、接口、数据与外部系统如何连接 | 架构图、数据流、接口和表结构 |
| 程序设计 | 代码具体以什么形状进入现有系统 | 文件位置、类型、函数签名、调用链、测试设计 |
| 垂直切片 | 如何用最小改动先跑通一条完整链路 | 可运行、可测试、可逐步扩展的实现序列 |
这四层里，最容易被跳过的是第三层：程序设计。
架构告诉我们“需要一个订单服务和一个支付回调”，程序设计还要继续回答：回调从哪个入口进入，调用哪些函数，状态在哪里转换，幂等性由谁负责，哪些类型必须显式存在，测试应该从哪个边界观察结果。
这些决定如果没有提前说清楚，Agent 也会替你做。只是它做出的选择可能埋在几百行实现里，等你发现时，修改成本已经远高于讨论一张调用链草图。
一个实用的做法，是在 Agent 编码前让它列出：
为了实现这个功能，我必须做出哪些当前规格没有说明的决定？
其中哪些决定会影响接口、数据模型、兼容性或后续扩展？这相当于把本来会隐藏在代码里的分岔口提前暴露出来。人不需要规定每一行怎么写，只需要在最昂贵的方向性决定上介入。
垂直切片：不要等几千行代码之后才第一次运行
Agent 很喜欢横向开发：
先完成数据库 -> 再完成服务层 -> 再完成 API -> 最后完成前端这种顺序对生成代码很方便，对验证却很不友好。直到所有层都写完，人和 Agent 才第一次知道完整链路能不能工作。如果方向错了，此时已经积累了大量建立在错误假设上的代码。
垂直切片采用相反的顺序。假设要做一个“用户取消订阅”的功能，第一步不是完成全部退款规则、邮件通知和异常处理，而是先跑通最薄的一条链路：
页面上的取消按钮
↓
一个暂时只处理正常情况的 API
↓
写入一条最小状态变更
↓
页面重新读取并显示已取消它很不完整，但已经可以从用户入口验证到数据结果。确认方向正确后，再逐步加入权限、退款、重试、审计和通知。每增加一层复杂度，都有一条已经工作的链路作为参照。
这和 TDD 的价值相近：不是崇拜某个固定仪式，而是缩短反馈距离。代码越早面对真实反馈，错误方向积累的时间就越短。
Context Engineering 不是把更多文档塞进 Prompt
访谈的另一条主线是 Context Engineering。Dex 在 12-Factor Agents 中把“掌控上下文窗口”列为构建可靠 Agent 的原则之一。
这里的重点不是上下文越多越好，而是让模型在需要的时候得到正确、相关、足够的信息。
对于 Coding Agent，一个很有效的方向是把原本只存在于团队脑中的知识写进仓库：
- 为什么选择当前架构，而不是另一个方案；
- 哪些 API 合同不能破坏；
- 环境变量有哪些，但不记录秘密值；
- 支付、监控、邮件等外部系统如何连接；
- 哪些业务原则已经被明确否决；
- 发生故障时应该从哪里开始检查。
这样做以后，代码库不再只是源代码的容器，也成了系统的操作说明书。
不过文档化同样不能无限扩张。过期的文档比没有文档更危险，因为它会以一种看似权威的形式向 Agent 提供错误信息。有效的上下文工程需要同时做两件事：把重要知识写下来，并让这些知识跟着系统一起更新。
不是所有项目都需要这套重流程
对这套方法最强的反对意见是：如果每个功能都先写产品说明、架构、程序设计和垂直切片，初创团队可能还没找到第一个用户，就先把流程建设完整了。
这个反对意见成立，Dex 在访谈里也明确承认了边界。
还在寻找产品市场匹配时，最大风险通常不是代码半年后难以维护，而是花半年维护一个没人需要的产品。此时应该快速做实验，把真实东西放到用户面前。Agent 能够一步生成原型，正是它的价值。
但当系统已经有付费用户、多人协作、稳定接口或合规责任时，风险发生了变化。一次错误迁移、一次不兼容的 API 修改、一次支付状态错误，代价可能远高于提前半小时完成程序设计。
所以问题不是“要不要严谨”，而是严谨程度是否匹配当前风险：
| 当前阶段 | 更该优先控制的风险 | 合适的工作方式 |
|---|---|---|
| 原型与探索 | 做出没人需要的东西 | 快速生成、快速验证、允许丢弃 |
| 已有用户 | 改坏关键体验和数据 | 明确指标、垂直切片、自动回归 |
| 团队与规模化 | 理解断层和维护成本 | 架构与程序设计、ADR、分层评审 |
| 高风险业务 | 合规、资金和不可逆错误 | 人工审批、严格测试、灰度与回滚 |
成熟的 Agentic Engineering，不是为所有任务套同一条流水线，而是知道哪类错误可以快速修，哪类错误必须在发生前阻止。
别再优化 Token，先找到真正的瓶颈
访谈后半段提到《目标》里的约束理论：一条生产线的产出由最慢的关键环节决定。持续优化非瓶颈，只会让更多工作堆在瓶颈前面。
放到 AI 编程里，这个判断很直接：
- 如果需求一直变化，更多 Agent 只会更快地写错东西；
- 如果评审已经积压，更多并发只会制造更多待评审代码；
- 如果部署不可靠，生成速度再快也无法安全上线；
- 如果没有用户，优化多 Agent 路由不会替你找到需求；
- 如果线上问题无法观测，自动修复也不知道该修什么。
Agent 使用量、Token 消耗和生成代码行数都只是局部指标。应该衡量的是：可靠的价值以多快的速度到达用户。
所以，“别再玩 Coding Agent 了”不是一句反技术口号。搭建更漂亮的 Agent 系统很有吸引力，因为这件事本身具体、可控，还能持续带来完成工作的感觉。但如果它没有改善当前瓶颈，就只是在用工程效率逃避更难的问题。
我会怎样把这套方法落到下一次开发里
下一次把一个中等以上的功能交给 Coding Agent 前，可以先回答五个问题：
- 用户问题是什么，而不是我要增加什么页面或接口？
- 什么可观察结果能证明这个功能有效？
- Agent 将被迫替我做出哪些没有写明的决定？
- 哪些决定一旦做错，返工成本最高？
- 第一条可以端到端运行的最薄链路是什么？
执行过程中，不需要盯着 Agent 输出每一个 Token，但要保留几个明确的介入点：
产品与指标确认
↓
架构和高成本决策确认
↓
第一条垂直切片验收
↓
自动测试与真实界面验证
↓
高风险代码人工检查
↓
上线后的监控与反馈这里的人类在环，不等于人类重新手写全部代码。人的任务是提供模型难以从短期反馈中得到的东西：业务取舍、长期经验、风险判断，以及对未来变化的预期。
代码生成越便宜，这些判断越值钱。
Agentic Engineering 的终点也不是“再也不用看代码”，而是我们终于可以少花时间搬运语法，把注意力放到决定软件质量的地方：做什么、为什么做、以什么结构做，以及怎样证明它真的做对了。
延伸阅读
12-Factor Agents：构建可靠 LLM 应用的原则
Dex Horthy 整理的 Agent 工程原则，其中第三条集中解释如何掌控上下文窗口。
SWE-bench：语言模型能解决真实 GitHub Issue 吗？
SWE-bench 原始论文，说明如何用真实仓库、Issue、补丁和测试评估模型的软件工程能力。
SWE-bench 中被判定解决的问题，真的解决了吗？
对通过评测但可能不符合开发者真实意图的补丁进行实证分析，说明测试通过与完整正确之间仍有距离。
从 Coding Evaluation 中分离信号与噪声
OpenAI 对编程评测中的任务质量、数据污染和可靠性问题所做的分析。