AI 代理开发如何改变程序员工作流：从编码转向审查

我们成了总编辑，却从未有人训练过我们

我现在的大部分工作日看起来是这样的：我写一个 prompt 描述我想要什么。一个 agent 生成一份 diff。我读一遍，要么批准它，要么要求修改。重复这个过程，许多次，直到功能完成。

问我们是否成了"prompt 工程师"？你问的是错误的问题。Prompt 措辞是一项薄弱的技能，下午就能学会。在经历了二十七年的旧方式编码之后，真正改变的是这份工作对你注意力的影响。打字更少。审查更多，在这个量级和速度上，职业生涯中没有什么能让我为之准备。

诚实描述的循环

剥离营销辞汇，agent 开发就是一个审查循环。你描述一个结果。agent 提议一个实现。你根据对"正确"意味着什么的心智模型来检查它——针对这个代码库、这个边界情况、这个架构——然后你要么接受它，要么用更多上下文推回。

这不是一项新活动。这就是代码审查，除了另一边的作者永不疲倦，永不推回，并在几秒内生成一个看起来合理的 diff，无论它是否正确。数量改变了一切。当审查成为瓶颈而不是打字时，这份工作的重心就跟着移动了。

不同的疲劳类型

过去的方式是阵发性的压力。你会遇到一个 bug，为它花上一下午，感受到一个拒不讲通的堆栈跟踪带来的特定沮丧。压力很大，但节奏是你自己的。打字很慢。调试会强制暂停。无论你是否想要，节奏中都存在内置的松弛。

Agent 编码消除了这种松弛。Agent 不会按照你的注意力跨度来调整自己。它只是一个接一个地持续生成 diff，速度比你自己打字快得多。要很好地审查，你需要持久的、专注的注意力，维持在过去只在困难部分才会出现的水平。再也没有自然的空隙让你的大脑重置，因为生成从不放缓来让你追上。花上整个下午在这上面，比花整个下午卡在一个顽固的 bug 上产生的疲劳是不同的，经历了二十七年的旧节奏后，这种疲劳有时仍会让我措手不及。

"Prompt 工程师"是个错误的名字

这里真正重要的技能从来不是 prompt 措辞。它是在看到 diff 之前就知道什么是正确的：为什么一个查询需要索引，为什么一个迁移在并发写入下是不安全的，为什么一个"可运行的"抽象会在六个月后造成伤害。这种判断不来自 prompt 实践。它来自于构建过东西、破坏过东西、为错误付出过代价。

现在从 agent 工具中获得最多收益的人不是那些拥有最聪明 prompt 的人。他们是能看着生成的代码并立即发现那一行微妙错误的人，因为他们在某个时刻自己写过完全相同的 bug。Prompting 是界面。工程判断仍然是这份工作。

五年后这会走向何方

有三件事似乎对我来说很可能，顺序不分先后。

审查成为我们训练的技能，而不是我们容忍的技能。现在我们大多数人学习代码审查是作为一项次要技能，是你在学会编写之后才做的事。如果指定和判断变成了主要循环，那么很好、很快且不盲目同意地审查，必须成为我们有意识地改进的东西，就像我们曾经有意识地改进算法一样。

我们开始围绕审查者疲劳进行设计，而不仅仅是审查者速度。现在大多数工具都是为了让 agent 能多快地生成 diff 而优化。真正的约束是人类能维持多久的高注意力审查而不使质量下降。我预期会有更小、更频繁的检查点，在你深入 diff 本身之前对改动内容和原因的更好总结，以及更有意识的节奏控制，因为现在让审查者筋疲力尽才是真正的瓶颈，不是代码生成。

好与坏的工程师之间的差距扩大，而非缩小。Agent 工具是一个乘数，而乘数会放大已有的东西。具有强大判断力的工程师审查更快并发现更多。没有判断力的工程师批准更多 bug，速度比以前更快。"能生成可运行代码"的下限下降。"可被信任来发布它"的上限没有动，或变得更有价值，正因为它更稀有。

我不那么确定的部分

让我担心的不是循环本身：而是如果更少的人花费多年以艰难的方式构建判断，这种让循环工作的判断是否能存活下来。审查只有在与你审查的模型一样好，而那个模型过去通常是通过自己写数千行代码，写得糟糕，然后修复它而构建的。如果下一代工程师在真正写过之前就审查，我还不知道那是否会更快地产生相同的直觉，或是一代无法区分一个合理的 diff 和正确的 diff 的审查者。

所以不，我不认为我们正在成为 prompt 工程师。我认为我们正在成为自己代码的总编辑，而编辑得好是一项自成一体的工艺，我们大多数人仍在工作中学习。那个问题在接下来的五年里会走向何处，是我真正好奇的部分，而不是我有一个整洁答案的部分。

原文发布于 albertoarena.it

如需进一步行动，你可以考虑屏蔽此人和/或报告滥用