我在指挥 coding agent，而不是写代码

我已经不再亲手写代码了。我在指挥 coding agent——目前用的是跑在 Opus 上的 Claude Code——而我自己负责架构、spec 和 review。下面是实践中真正发生变化的部分。

什么消失了

敲键盘。 一位资深工程师过去的一天大致是 30% 读代码、20% 写代码、50% 其他事情。写代码这一项掉到了 5% 左右——剩下的只是 agent 暂时够不到的地方需要 手写的补丁，或者那些小到不值得为它写一个 prompt 的改动。

样板代码的疲惫感。 过去，做一个带 auth、validation、测试和 migration 的新 endpoint 是个两小时的活。现在它是一个五分钟的 prompt 加十分钟的 review。「我应该 为这个边界情况写个测试」这种心理负担消失了——当然有测试，是 agent 写的。

IDE。 我一多半时间都待在一个长得像终端的工具里。IDE 只在我需要读一些 agent 推理过、但没展示给我看的东西时才登场，或者是在合并前 review diff 的时候。 其余时候，整个循环就是 prompt → diff → 评论 → 下一个。

什么完全没变

架构。 该构建什么、边界在哪里、数据模型是什么、有哪些失败模式。这些都没法 委托出去。coding agent 会乐呵呵地构建你描述的任何东西。整份工作就在于描述对的 那个东西。

Code review。 agent 写的每一行，都是我要读的一行。对于我不认同的改动，我会 照样拦下来，就像拦一位 junior 工程师的 PR 一样。agent 很快，但并非万无一失—— 它会跳过断言、把控制流搞得过度复杂，偶尔还会凭空编造出 API 调用。这些都得靠你 读出来。

生产判断力。 那种直觉——某个抽象一定会泄漏、某个 index 一定会缺失、某个 异步边界在高负载下一定会死锁——没有哪个 agent 的训练数据里有这些。它们在二十年 修东西的经验里。

瓶颈挪到了哪里

新的瓶颈是 spec 的质量。如果我写的 prompt 在某条错误路径上含混不清，agent 就会锁定其中一种解读并把它发出去。如果我写的 prompt 完整但优先级搞错了，agent 就会把错的那件事做对。从外面看，这两种都像是 agent 的失败；其实两种都是 spec 的失败。

过去花在「写出正确代码」上的纪律，如今转移到了「写出正确的 spec、review 正确的 代码」上。花掉的时间 与 思考密度 的乘积大致守恒——它只是在流水线里往前 挪了。

我觉得现在的工作更有意思。我读得更多、写更多散文式的文字、在发给 agent 之前会 把同一段话重写三遍，而一天结束时，我交付的量大约是两年前的五倍。这是一笔划算的 交易。