开发者反思：AI代理接手写代码后，人类还需阅读代码吗

2023年我写过一篇文章《GitHub Copilot 会让你成为更差的程序员吗？》。当时，Copilot 是 AI 进入主流编程领域的首批尝试之一。我的主要预测是：

在某些方面我是对的，但在另一些方面，我完全没看到更广泛的变化。在那篇文章里，我谈编程时更多是在说实际敲代码这件事，没有把软件工程当作一个更宏观的话题来考虑。而现在，我是在给 agent 写提示词、做引导，而不是亲手敲代码。

从历史上看，“计算机”曾经指的是一个人。当计算设备被发明出来时，它们执行的代码是由人类编写的。后来，高级语言和编译器接管了编写机器码的角色。今天，计算机执行的代码——至少在我的世界里——几乎完全是由 agent 写的。现在的高级语言是英语，是我提供给 agent 的提示词。

好吧，确实。我不再写代码了。那审查代码呢？如果说写代码需要 1 倍的努力，那审查代码大概需要 0.25 倍。今年早些时候，AI 辅助编程的速度大约是手动编程的 4 倍。以那个速度，手动审查代码还是合理的。而今天，感觉更像是 100 倍。再用同样的方式审查代码已经不现实了。

我的解决方案是用工具和 AI 来支撑这种规模的审查。我审查的对象正从代码行转向 API 契约、架构变更、不变量、算法、schema 和规格说明。

编程语言和编译器有着定义明确且具体的行为。从高级语言到机器码的转换是精确的。而我用英语给 agent 的提示词通常不是。agent 也不总是写出优秀的代码。这意味着我仍然需要确认：

最顶尖的 agent 往往似乎能直觉地“领会”我的提示意图，但我发现其他模型就比较吃力。它们可能思考得太浅，或者只处理 bug 的表象而非根因。

我发现（尤其是对前沿 LLM 而言），有了可靠的规则和指导文件（AGENTS.md、CLAUDE.md）、代码审查技能、章程、代码地图和包地图之后，agent 更擅长发现 bug、执行一致的风格——而且是系统化地做这些事。

我正让它们做越来越多的代码审查。随着时间推移，我仍然阅读 diff 的 PR 比例在下降。审查一个变更并不总是需要我读它的实现。

那些我肯定不需要读代码的变更，是仅限于单个文件或包、不涉及 API 或包接口改动的变更。当变更跨越包边界，或涉及超出简单 CRUD 的东西时，我至少会瞄一眼。

agent 会做我提示它们做的事，而我常常不会告诉它们去思考工作的长期后果。¹ 作为一名架构师（尤其是作为技术创始人），我知道今天做的决定可能影响明天、一周后、甚至一年后的事情。这让我在设计或实现时更加谨慎。目前，这些决定仍然是我想要理解实现细节的。

LLM 每周都在进步。这些局限和问题都是暂时的。就像 SQL 一样——人类声明查询应该返回什么，由机器的 planner 和 executor 决定执行方式——未来最重要的是我如何定义意图和目标，然后让机器和 agent 去想办法执行。

我从自身经验中学到的是，我现在构建软件的工作更多是关于思考架构（软件涉及的结构和流程）、需求、规格说明和 UX。事实证明，这些东西推理起来比单个代码行、比如何最好地写某个 for 循环要复杂得多。

我已经有段时间没手写什么像样的代码了。我的编程能力可能有点生疏了。但我进步很大的是软件设计与架构，以及对复杂性的推理能力。

我仍然会想，那些还没积累够练习量的初级程序员会怎样。我通过写代码、并在自己的错误中摸爬滚打学到了很多。那种经验在未来是否仍然值得，我不知道。毕竟，懂汇编已经不像从前那么有用了。

所以问题不是我是否会停止阅读代码。那一定会发生。问题是到达那一步需要多久。

即便我提示它们去那样做，也不等于它们被训练得能直觉地做到。参见 https://funnelstory.ai/blog/engineering/reasoning-is-trained-not-prompted ↩︎