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

一篇短文，记录当实现层变成 agent 之后发生了什么变化——什么保持不变、什么消失了，以及新的瓶颈落在哪里。

- **Author:** Fedor Chishchin
- **Published:** 2026-05-15
- **Updated:** 2026-10-16
- **Tags:** agents, methodology, ai-native
- **Source:** https://fedorthinks.com/zh/blog/directing-not-typing

---

我已经不再亲手写代码了。我在指挥 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 会乐呵呵地构建你描述的任何东西。整份工作就在于描述对的
那个东西。

**验证。** 我不会逐行阅读 agent 写的代码——那样无法扩展，错误也不是在那里被发现的。
我用证据证明代码能用：agent 必须保持全绿的单元测试、集成测试和端到端测试，每次提交都要
通过的严格检查（类型、lint、覆盖率），以及生产环境中的日志和 trace。agent 很快，但并非
万无一失——它会跳过断言、把控制流搞得过度复杂，偶尔还会凭空编造出 API 调用。测试和检查
每次都能抓住这些，而且不会疲倦。

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

## 瓶颈挪到了哪里

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

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

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