一位工程师自述：AI时代写代码变便宜了，时间都花在等待上

Laurie Voss 九月写了《我们现在都是产品工程师》，十月在纽约的 AI Engineer 大会上做了演讲版本。我现场听了，会后上去感谢他把我每天的日常搬上了台面。他的判断是：agent 已经消化掉了写代码的成本，接下来是 review 和运维，留给人的工作是搞清楚该做什么、以及“好”是什么意思。我同意。我手里也正好攒了几个月自己的交付数据，于是翻出来看了看它到底说明了什么。

大约三个月里我合了 500 多个 pull request，差不多一天七个，从首次 commit 到 merge 的中位数是 20 分钟。代码现在很便宜。Laurie 那篇文章里的这部分就是事实。

时间去了别的地方。从建 ticket 到首次 commit，80 分位是 15.5 天。一个需要另一个人来 review 的 PR，等待时间中位数是 28 小时。从 merge 到在 QA 被接受，最长要 5.5 天。这些没有一项是打字。

我真正动脑子的那部分工作是外环：修掉这个 bug，然后让这一整类 bug 不可能再发生。我认为产品工程、DevX 以及（最终）形式化验证，最后都会收敛成同一件事，就在这里。

最近我一直在把两个大系统粘在一起。我在同一个 repo 上并行跑了好几个 Claude Code 会话，每个在自己的 worktree 里，每个切一小片。这就是 PR 数量离谱的原因。PR 对我来说已经不再是工作单元，而更接近于一个存档点。

我去拉这些数字，是因为我想把估算做得更好，而按 PR 数量估算显然毫无意义。

一旦我开始做某件事，它就会落地。通常当天。

首次 commit 之前的长尾，几乎从来不是“我没顾上”。而是“我们还没就这件事的含义达成一致”，或者“我们在等别人确认”。agent 做 review 只要几秒；人做 review 要等人有空，这没问题，只是慢。而 merge 了不算完成，直到有人在测试环境里看过并说可以。

真正推动我日期的东西从来不在编辑器里。多半是把那个能拍板说“行”的人拉进房间。一次两小时的工作会解决六个悬而未决的问题，每次都胜过两周的异步提问。剩下的就是把“完成是什么样”写下来，而且要赶在任何人（或任何 clanker）写代码之前。

人们开始用两个环来描述 agent 的工作，我觉得这正是产品工程师现在所做的事情的合适框架。

内环是紧的那个：写、跑、测、修。Philipp Schmid 把它描述为 agent 在单个任务内、回答你之前先检查自己的工作。Augment 的指南走得更远，认为 agent 现在自己跑完整个 pre-commit 内环，这就把人往上推了一层，并让 review 和 CI 成为新的瓶颈。这和我那个 28 小时的 review 数字几乎完全对得上。

外环是跨任务学习的一切。在 Schmid 的版本里，是记忆、技能和规则文件，让 agent 不重复犯错。在我的版本里，是对整个团队做同样的事。

日常里这看起来是这样的。一个 bug 冒出来。放大：修掉它。有 agent 在，这通常只要几分钟。然后缩小：这个 bug 为什么当初能发生，怎样才能让下次不可能发生？用一个真正的类型而不是字符串。在两个系统的边界做 schema 检查。一条 lint 规则。一道 CI 门。一个直接拒绝提交的 git hook。修一个 bug 现在很便宜。修一整族 bug 才是杠杆所在，而这恰恰是我整天在做的事。

为此我维护一个纯文本的痛点账本。每次有什么东西咬到我，就记一行：发生了什么，我怎么处理的，真正的修复应该是什么。第一次，绕过就行。第二次，根因要被修掉。大多数行最后发现是策略，不是代码。“没有固定 image tag 绝不部署。”“一个工作树一个 owner。”“没有第二个人读过的东西不进到人手里。”

在 AI Engineer Europe 的一次对话中，Linear 的 CTO Tuomas Artman 提出，agent 可以通过迭代和测试达到你要求的效果，但选对效果仍然是另一种技能。那是外环技能。知道该写下哪条不变量，也是。

如果 agent 要写大部分代码，而 review 已经跟不上（Laurie 有这方面的数字，大多数 agent 的 PR 根本没有被记录的 review），那么人能写的最有价值的东西不是代码，而是不变量。对“什么必须永远为真”的精确陈述。

“一条记录在它所依赖的东西存在之前，绝不发往下游。”“一次重试绝不创建第二份副本。”这两个都是我今年修过的 bug，而且不止一次，在我把规则写下来之前。

一旦它以一种机器能检查的形式写下来，每一个 agent 写的改动都免费受到它的约束。它可以是一个类型、一个属性测试、一个模型检查过的状态机，或者一份描述两个系统如何来回交接工作的 TLA+ 规范：信任，但验证。我在形式化这一端还很早期，计划走得更远，因为这是我所知的、把“定义好”变得足够具体、让 agent 无法与之争辩的最直接方式。

这也是我能给出的 DevX 的最佳定义：一个让错误的东西很难写出来的系统。

接下来一年左右，每个团队里工程师的产出都会看起来非常惊人。我希望从第一天起就有的仪表盘指标，是那些等待：

感谢 Laurie 的那篇文章，让我去把这些数字拉了出来。