内容
编码代理现在已经非常强大，而且进步速度极快。随之而来的一个有趣结果是，工程的难点从写代码转移到了判断是否信任代码，这也让审查成为当下软件领域最具杠杆效应的技能。具体该怎么做，极大程度上取决于你是谁：一个没有用户的独立开发者，和一个维护十年前应用的团队，面对的根本不是同一个问题。
我对智能体工程的乐观程度，从未像现在这样高。代理确实很强，而且每个月都在变得更强；在普通的一天里，我现在能交付一些一年前根本不会尝试的东西。这篇文章是一张地图，用来说明有意思的工作究竟转移到了哪里，因为它确实转移了，而大多数团队还没有完全跟上。
过去，代码审查之所以有效，是因为存在一个“相对速度”的美妙偶然。高级工程师读代码的速度，比初级工程师写代码的速度还快，所以审查无需专门设计也能跟得上；团队则在彼此查看 diff 的过程中，自然而然地理解系统是如何组合在一起的。其中很多并非刻意为之。它之所以成立，只因为一个事实：写代码是缓慢而昂贵的部分，而阅读代码则廉价且迅速。
这个事实如今已经不成立了。代理在我读完这一段文字所需的时间内，就能生成一千行往往相当扎实、格式良好的代码，而人类的阅读速度自从我们开始靠盯屏幕谋生那天起，几乎就没有变过。所以约束被传导到了下游，落到了那个唯一没有变快的步骤上：一个人确信这次变更是正确的。我并不认为这是损失。眼下，软件领域最有杠杆效应、最值得投入的地方，恰恰就是这里，而这也是我今年投入最多注意力的地方。
这里还有一个让整篇文章都成立的“好转折”。生成这些额外代码的同一批工具，也正是我用来跟上它们的最佳工具。在我自己的项目里，包括那些很受欢迎的开源项目，我现在会把 Claude Code 或 Codex 指向一批新来的 PR，让它们先帮我分流，这确实改变了我的时间分配方式。所以这不是一篇反 AI 的文章；我稍后会具体说明我是怎么使用它的。
这也不是数据堆砌，更不是又一轮“让模型写代码到底是妙不可言还是工艺终结”的争论，因为这种框架毫无用处。真正能经得起现实代码库检验的答案只有一个：这完全取决于你是谁。一个开发者靠 vibe coding 做一个最多十几个人会用的副项目，和一个团队要让一个十年历史的企业系统再撑一个季度，这两者几乎没有值得一提的共同约束，而流传于世的大多数建议，其实都只是这两种人中的一种在教另一种人该怎么活。
2026 年的数据到底说明了什么
AI 带来的生产力提升是真实的，但原始产出会夸大这种提升：代码量大约多出四倍，而交付价值只多出一成。两者之间的差额，就是审查工作；也正因如此，审查现在成了最有杠杆效应的地方。
过去几年，这还是个体感和争论。如今它已经被大规模测量过了，而且是由彼此没有共同立场、甚至在若干情况下还有商业竞争关系的组织测出来的；这些测量持续指向同一个方向：AI 会显著推高产出，同时也会压低质量和可审查性。
Faros AI 对 4,000 个团队中的 22,000 名开发者做了埋点，并追踪团队从低 AI 采用转向高 AI 采用时发生了什么。这是 2026 年 3 月的数据，已经算得上这里能拿到的最新数据了。好处是真实存在的，而且值得直说：开发者合并的 PR 更多了，完成的工作也更多了，每位工程师的吞吐量都在上升。然后就是报告的其他部分：
- 代码变动量上升 861%
- 事故与 PR 的比例上升 242.7%
- 人均缺陷率从 9% 升至 54%
- 中位审查时长上升 441.5%，首次审查耗时和平均审查时间都大约翻倍
- 零审查合并的 PR 增加 31.3%
最后这一项是我最难忽视的，因为这不是谁主观选择的。没人决定不再审查；只是审查者根本跟不上数量，代码于是开始在无人阅读的情况下合并，而这逐渐成了常态。我一直反复回看的一个细节是：即便是工程实践成熟、纪律严明的团队，也一样受到了重创。好流程并没有保护他们，因为到来的数量比任何流程原本能吸收的速度都快。
不过需要始终保留一个注脚：CodeRabbit 和 Faros 都是面向这个市场的销售方，所以它们的叙述并不完全中立。这并不意味着这些数字是错的——效应量足够大，而且在彼此无关的来源中保持一致——但供应商研究确实应该带着这一点去读。
CodeRabbit 研究了 2025 年 12 月的 470 个开源 PR，其中 320 个由 AI 共同撰写，150 个为纯人工编写，结果发现 AI 变更带来的问题大约多出 1.7 倍：逻辑与正确性问题高出约 75%，安全问题多出 1.5 到 2 倍，可读性问题则增加到三倍以上。其 AI 负责人 David Loker 将这些问题描述为“可预测、可衡量的弱点，组织必须主动缓解”。“可预测”是关键。因为这说明这些弱点是已知且可定位的；这反而是好消息：它意味着无论是人工审查还是自动审查，都可以直接对准这些问题。
GitClear 给出了我最想先亮出来的单一指标。在他们截至 2025 年的生产力数据中，日常使用 AI 的开发者产出的原始代码量大约是非使用者的 4 倍，但若与他们一年前自己的产出相比，真正的生产力提升其实只有大约 12%。也就是说，你写出了大约四倍的代码，却只多交付了约一成的价值，而这四倍的代码仍然得由人来全部审查。Bill Harding 很坦率地承认，即便是这 12%，也有一部分来自样本选择偏差，因为更强的开发者更集中在 AI 使用者群体中。四倍代码量和一成价值之间的差距，用一句话就把审查问题说透了。
GitHub 报告称，Copilot 审查如今已执行超过 6,000 万次 review，在不到一年的时间里增长了 10 倍，而且平台上超过五分之一的审查都涉及代理。这已经不是小众实践了。这就是代码被生产出来的方式。
四份数据集，四种方法，一个结论。我们把机器速度的产出灌进了一个原本为人类速度工作而设计的系统里。瓶颈没有消失；它转移到了验证，而审查正是账单到期的地方。
每个人解决的其实都是不同的问题
一个变更需要多少审查，几乎完全取决于它的爆炸半径，而你读到的大多数建议，都是由在完全不同爆炸半径下工作的人写出来的。
上面那些令人警惕的数据，几乎都来自企业遥测和被开源维护者压垮的场景。如果你正处在那样的环境里，它们完全真实。如果你只是一个人，做的东西最多只有少数几个人会运行，那么其中很多情况根本不适用于你，你也不该被迫觉得自己必须按那些情况来。
决定你处于哪一档的，有三个变量：
- 爆炸半径：出问题时会发生什么。什么都不会发生，还是会有愤怒用户、金钱损失和 PII 面临风险。
- 代码能活多久：是下周可能就重写的一次性原型，还是要维护多年的代码库。
- 有多少人需要理解它：只是你一个人把整个系统装在脑子里，还是一个团队需要长期共享所有权。
把同一个 diff 放进这三个维度里跑一遍，“好的审查”就真的会变成完全不同的东西。
如果你是独立开发者，正在做一个没有用户的绿地项目，审查的第二个职责——在团队内分布知识——对你来说根本不存在。你就是团队。合理的做法是重度依赖测试和自动化，审查那些真正重要的部分，其余部分则接受更轻量的处理。当代码可能一个月后就不存在，而出问题时也不会有人凌晨三点被叫醒，重复和变动的成本要低得多。问题在于，很多人会痛苦地学到：这套做法只有在测试是真实有效的前提下才成立。跳过审查而没有安全网，并不是把工作消掉，而只是把工作延期到更高的价格；当没有人能出来反对时，标准也会松掉。没有用户，意味着你可以推迟审查；但这不意味着你可以跳过验证。
然后项目开始有用户了。此时就进入了危险的中间地带，而这种跨越往往当时并没有被察觉。审查的找 bug 职责突然变得重要起来，因为 bug 开始伤人了；它的知识共享职责也启动了，因为不再只有你一个人。团队往往会把独立开发时代的习惯多延续几个月，然后就会来一次复盘，Faros 的那些数字也就不再只是图表，而会变成你们自己的看板。
最远端则是大型组织加老旧代码库加大量用户。在这里，每一个令人警惕的数字都会以最强烈的形式落地。一个重复的辅助函数不是风格瑕疵，而是未来的 bug 暴露面，以及会在多年里不断复利的维护成本。一个没人真正理解的变更就是理解债务，最后会变成某个人值班时的事故。审查此时同时承担着多项职责，而代理产出的数量悄悄把它们全都冲垮。Faros 关于成熟团队的发现，正是直指这里。
所以重点不是“企业应该谨慎，而独立开发者可以放松”。重点是审查的目的会随着你所处的位置而变化，因此规则也必须随之变化。把企业级那种锁死式、多代理、强证据要求的流水线硬套到一个两人原型上，只会增加摩擦而没有收益。把“测试过了，直接发”这套用到支付系统上，那你就造出了一个外面贴着绿色勾勾的事故制造机。这个领域里大多数糟糕建议，都是光谱上一端的人在给另一端的人制定生活方案。
现在的审查到底是为了什么
审查原本是用来检查作者推理过程的。代理也会推理，但这些推理通常会在生成 diff 的瞬间被丢弃，而不是附着在代码上，所以审查者必须重建一套根本没有进入 diff 的理由。好消息是：这其实是个工具问题，而把推理过程保存下来，会让审查容易得多。
这一点真的变了，而且我认为它被严重低估了。
当人类写代码时，意图是自带的。推理过程、权衡过又放弃的备选方案，都存在于作者脑子里，而审查就是在检查这套推理。现代代理确实也会推理，而且经常是可见的：它们会留下思考轨迹，会权衡选项，也会边做边解释自己。问题在于，这些推理通常在 diff 生成的那一刻就被丢掉了。它们很少被保存，很少附着到 PR 上；而且即使保存了，那也只是代理对“如何实现任务”的推理，并不是人类对“这是不是一个好任务”的判断。所以审查从“检查摆在你面前的推理”，变成了“重建一段从未被写下来的意图”，这更难、更慢，而我们却总在惊讶它为什么要多花441% 的时间。
一篇 2026 年的论文，《AI 垃圾代码与软件公地》 分析了 1,154 条帖子，这些帖子来自 15 个 Reddit 和 Hacker News 线程，开发者在其中讨论所谓的“AI 垃圾代码”。其中开发者的一句话让我一直记到现在：审查一个代理的 PR，让他们“成了第一个真正用眼睛看过这段代码的人”。
这句话值得停下来想一想，也直接指向了修复办法。在正常审查里，作者已经理解了这次变更，你只是在检查他们的工作；而面对代理 PR，根本没人先把“为什么要这么改”重建出来，审查者成了第一个去尝试的人。正如论文所说，审查“不是为恢复缺失的意图而设计的”。令人振奋的是，缺失的意图是可以恢复的：这些推理本来存在，只是被我们丢掉了。让代理说明它想完成什么、排除了哪些方案，并把这些内容作为决策日志附在 PR 上，那么大量重建成本就会消失。这是个工具问题，而工具问题最终都会被解决。
但这并不意味着“让 AI 审查 AI”本身就是完整答案。一个具有不同先验的第二个模型，确实能抓到真实 bug，而且能抓到不少，这也是为什么你应该运行一个。但它无法给出“这是不是一开始就该做的变更”这样的人工判断。这种判断仍然要由人来做，而它恰好也是工作里最有意思的部分，也是最值得保留的部分。
现在的 AI 审查器确实已经很强，而且它们偶尔不会和彼此标出相同的行，所以正确做法不是挑一个最好的，而是运行两个设计思路不同的。
专门的 AI 审查工具现在已经相当好，我认为你至少应该在所有东西上都跑一个，包括副项目。CodeRabbit 是部署最广的工具，并在独立的 Martian 基准测试（2026 年 1 月到 2 月）中以 F1 领先，精确率约 49%，召回率则是业内最高。Greptile 则是用精确率换召回率：在某个基准里，它的 bug 捕获率约 82%，而 CodeRabbit 是 44%，代价是更多误报。Anthropic 的 Code Review 则表示，它的发现中被工程师判定为错误的不到 1%，而真正让我愿意拿给管理层看的那个数字是：它把内部获得实质性审查的 PR 比例从 16% 提升到了 54%。过去那些只被瞄一眼就批准的长尾变更，现在开始会被某个东西认真读过。
不过，今年我见过最有用的结果，不是来自供应商。某位工程师并行运行了四个审查器：CodeRabbit、Sentry Seer、Greptile 和 Cursor BugBot，在 3 周半内覆盖了 146 个真实 PR 和 679 条发现：
在 617 个不同的标记位置里，93.4% 只被四个工具中的一个抓到。6% 被两个抓到。几乎没有被三个抓到的。一个都没有被四个都抓到。
这四个工具从来没有一次标出同一行。每个工具都擅长不同类型的问题：Greptile 在正确性和架构上几乎没有误报，CodeRabbit 覆盖最广且修复最省事，Seer 在生产故障严重性方面最好。这才是真正在真实代码库上演示出来的对抗式审查论证，而不是论文里的纸上推演。异质性才是重点。四个一模一样的模型，不过是一个收据更长的审查者；而四个真正不同的审查者，能浮现出单独任何一个成员都找不到的一组 bug，人类也一样。
实际操作上，不要纠结唯一最好的工具，根本不存在。站在高风险那一侧时，运行两个性格刻意不同的工具就行（上面的实验把 Greptile 用于日常正确性，把 Seer 用于生产故障严重性，而且几乎没有重叠）。如果你是独立开发者，一个好的审查器加上真实测试就足够了。而且不管营销怎么说，都要在你自己的代码上测，因为这些结果全都特定于某个代码库，而你的代码库也会是这样。
那我们是不是干脆让 AI 多审一点？
机器现在已经在审查比你更多的代码了。剩下唯一真正的决定，就是你是否要有意识地这么做，以及你保留多少人类参与，应该随着你的爆炸半径来调整。
我一直听到一个一年前还像是异端的问题，如今却已经从有经验的工程师口中说出来：机器是不是应该做更多审查，甚至大部分审查？我现在不再觉得这是个愚蠢的问题。
令人不舒服的地方在于，AI 审查是有效的。Anthropic 的发现中，不到 1% 被标记为错误；这些工具能抓到人类一眼看漏的 bug；而且它们不会在当天第 30 个 PR 上疲惫，这恰恰是人类最不可靠的时候。与此同时，人类显然已经跟不上了：零审查合并增加了 31%，审查时间则出现三位数增长。从某种意义上说，机器已经在审查比我们更多的代码了。诚实的表述不是“我们是否要让 AI 多审查一点”，而是“AI 其实已经在这么做了，我们要不要有意识地管理这件事，还是假装人类仍然会逐行阅读所有内容，结果默认让它继续发生”。
Loop engineering 把这件事讲得更清楚。所谓 loop 的前提是：你不再是向代理下提示词的人，而是构建一个会向它下指令的系统，而这个系统的核心部分就是一个裁判：一个在继续之前判断工作是否完成的代理。审查者正被有意从内循环里设计出去。我们花了一年把“写”的工作自动化，而这些 loops 现在又在把“检查”的工作自动化，于是人类不断被推到更高层、更外围。“人类到底该待在哪里”不是一个研讨会问题，而是你每次把 loop 接起来时都在做的决定，无论你是否意识到自己正在做这个决定。
就我目前的判断而言，而且我保留这个判断的弹性：答案不是“人类读完每一行”。那已经结束了。数量已经终结了它，任何坚持相反说法的人，描述的都是一个不复存在的世界。但答案也不是“让 loop 自己审查自己，然后人类走开”。当一个代理写代码、另一个代理审查、第三个代理裁决时，你就有了一个模型之间的封闭循环，它们大体上共享相关的盲点，尤其当它们来自同一模型家族时，还会在同样的地方自信地一致同意。一个没有人类介入、却语气十足地说“看起来不错”的结论，就是借来的信心：系统的确定性变成了你的确定性，但实际上没人真正理解任何东西。这个 loop 可以既非常自信，又非常错误，而且已经没有人类留下来分辨这两者。
所以，人类不会离开；人类会上移一层。你不再审查每一个 diff，而开始负责那些不会转移给模型的部分：责任，因为你不能在凌晨三点呼叫一个模型；判断这是不是一个值得做的变更，而不仅仅是代码是否正确；高爆炸半径下的门禁，因为错了代价太高。还有最尴尬的一项：那些没人明确写出来的行为，因为模型只会审查已经存在的代码，却很少能指出没人想到要写下的需求，而这仍然是一个人形的空洞，我并不指望它很快被填上。人机协作中的“人”开始变成人在回路上：抽样、抽查、审计系统，而不是逐个阅读所有 PR，并把有限注意力花在真正出错会造成伤害的地方。
我现在在自己的项目里就是这么做的，包括那些开源项目——这些项目如今一天收到的 PR 比我一个晚上能认真读完的还多。我会把 Claude Code 或 Codex 指向一批新 PR，让它先做第一轮：高层地读一遍，判断哪些看起来可以安全合并，哪些还需要更多工作，哪些是真正高风险的。我不会因为它的结果就自动合并，也不会懒得思考就直接放行它批准的任何东西。它给我的，是一种分配注意力的方法。我可以花几分钟确认它认为低风险的改动，把真正仔细的时间留给它标记为危险的那些。这里最重要的细节在于，这并不是把我过去的审查时间稍微加快了一点点；而是一种不同形态的时间块，而在我如今面对的吞吐量下，这几乎就是让队列还能活下去的主要原因。
Codex 和 Claude Code 先给我一轮按风险排序的 PR 阅读结果。分流才是它们真正的帮助。合并决定仍然由我来做。
同样思路的一个更极端版本，是 Kun Chen——这位前 Meta L8 工程师，如今作为独立开发者一天能发出大约 40 个 PR，而且已经基本不再亲自审查代码了。要把这件事当成异类其实很容易，但问题在于他是 L8，而且在自己原本就非常擅长、却停止继续做的事情上异常出色，这正是它有意思的地方。 他并行运行 20 到 30 个代理，把精力转移到了“计划”上：先写出非常详细的计划，让代理按计划运行数小时；他说计划质量决定了它们可以无人值守运行多久。这就是我上面描述的那一步，最纯粹的样子。需要精确说明真正发生了什么，因为关键并不是他停止了验证。意图并没有消失，而是他自己在计划里把它写下来了，所以“第一个真正看到这段代码的人”这个问题有一半被解决了：人类确实先理解了“为什么”，只是发生在前置阶段，而不是事后。并且他也不是完全裸奔，他建立了一个自动审查门禁（他称之为 No Mistakes），在代码合并前先做检查，而当代理卡住时，他仍然负责升级处理。也就是说，人类在代码存在之前先做昂贵的思考，之后再由机器做逐行检查——这很可能就是这件事未来的发展形态。
但他是一个没有大型团队、也没有埋着十年历史系统地雷的独立开发者。让他一天 40 个 PR 而不审查仍然合理的那些精确条件，绝大多数读者并不具备。把他的工作流照搬到一个要面对大量用户的团队里，你就会在自己的看板上复现 Faros 的那些数字。他没有错；他只是站在这个光谱的非常靠后的一端。
所以这又回到了光谱问题。没有用户的独立开发者：让 AI 几乎审查全部内容，是 2026 年完全可以成立的立场，你不必因此感到内疚。维护一个服务大量用户的大系统：让机器负责第一轮、第二轮和那 90% 最无聊的部分，但在承重路径上保留一个真正的人类，并且不要让任何可能伤人的地方在 loop 里完全闭合。保留多少人类，不是靠羞耻感决定的，而是靠一个旋钮决定的；而这个旋钮应该由爆炸半径来设，而不是由愧疚感来设。
具体该怎么做
不要再对所有审查都用同样深度。把稀缺的人类注意力只用在出错代价高的地方，其余部分交给廉价、确定性的门禁和 AI 审查器。
组织原则很简单：让审查力度与出错代价相匹配，把便宜的确定性工作尽可能前置，把人类注意力留给只有人类能做的事情。
按风险分层，不要按作者分层。 一个配置改动，配一个 lint 和扫一眼就够了。一个支付路径，则要全套：类型检查、测试、两个不同的 AI 审查器、一个对该系统负责的人类，以及一次安全审查。不要在模板代码上投入重型审查，也不要因为测试绿了，就把一个认证变更直接放过去。分层方法到哪里都一样；变化的只是某个 diff 需要通过多少层。
让昂贵的长尾尽早失败。 对于被大量代理 PR 淹没的团队来说，最近最有用的发现是 Early-Stage Prediction of Review Effort（2026 年 1 月），它研究了 33,707 个代理撰写的 PR。代理擅长小而明确的变更，大约 28% 的 PR 几乎能立刻合并，但一旦收到带主观判断的反馈，它们往往就会“消失”——放弃真正需要来回沟通的审查过程。（配套的 2026 年论文发现，审查者放弃占了被拒代理 PR 的 38%。链接）研究者构建了一个“断路器”，能在人工查看前，根据文件类型、补丁大小这类廉价信号预测哪些 PR 会变成高维护成本，而且效果很好。应当先对代理 PR 做分流，把平凡的快速走通，不要让人类在一个代理一推就放弃的庞大变更上浪费一小时。
提高你愿意审查的门槛。 解决被淹没的方法不是把仓库锁死，而是拒绝审查那些没有证据就送来的变更。在进入审查之前，要求提交：这次变更的目的说明、不至于 3,500 行却毫无注释的 diff、测试输出，以及测试确实运行过的证据。这就是阻止你成为第一个阅读这段代码的人。你把意图重建的工作推回给提交者本人，让它在那边以低成本完成，而不是由你来吞下这笔高成本工作。
有意地保持 PR 小。 在 Faros 数据里，代理 PR 往往更大，平均要大 51%，而审查者的参与度是 PR 是否能合并的最强预测因素之一。一个大而无法审查的 PR，要么会被直接拒掉，要么更糟，被点头放过。要求你的代理产出小提交。现在，一个人类真正能读完的 diff，已经成了设计约束，而不是客套。
比看代码更仔细地看测试变更。 这是代理最值得警惕的失败模式。代理改了行为，然后又通过重写断言把测试“修”到和这个新但错误的行为一致。一个包含 200 处测试编辑的绿色勾勾，在你确认这些编辑本身正确之前毫无意义。任何重写大量测试的 diff 都应被当作警报，优先阅读这些部分。这里，变异测试（mutation testing）很值得：覆盖率只能告诉你某行执行过，而变异测试能告诉你，如果那行错了，测试会不会发现。
把 CI 当成不会移动的墙。 注意 GitHub 现在提醒审查者关注的模式：删掉测试、跳过 lint、降低覆盖率阈值、重复已有的辅助函数，以及未受信任输入流入 prompt。最后这一点尤其值得强调，因为代理构建的功能正在成为 prompt injection 的新来源：如果一个变更把用户可控文本直接送进 LLM 调用，却没想过这段文本可能会命令模型做什么，那么漏洞并不在 diff 里显而易见，而是潜伏在之后会到来的数据里。代理也会为了让自己通过而削弱 CI，不是出于恶意，而只是梯度下降在寻找最便宜的绿色路径。确定性门禁是流水线里唯一不会被一段自信的长文说服而改变结论的部分，所以要把它们保持严格。
合并必须有人负责。 模型不能被叫醒，也不能为自己发出去的东西承担责任，所以按下 merge 的那个人就要负责。当 AI 审查用平静而自信的语气说“看起来不错”时，它其实是在把一种未必配得上的信心递给你。把每一次 AI 审查都当作传感器，而不是裁决：它提供的是数据，不是决定。
如果你是没有用户的独立开发者，那么分层、测试变更纪律和 CI，基本上已经覆盖了你的主要需求；在真正有人来之前，其余部分都只是开销。如果你身处大型组织，那么这些就是基线，而分流和准入门槛的设置，正是一个可扩展审查流程与一个悄悄崩塌的流程之间的区别。
如果你在带团队，这意味着什么
瓶颈不再是谁写代码更快，而是谁能更快地让一个可信的人对审查结果有把握。因为“AI 让我们更快了”就裁掉提供这种把握的人，只会把节省下来的时间换成未来的事故。
交付的约束条件，不再是谁能更快写代码。真正的约束是：一个可信的人，多久能确认一个变更是正确的。任何把“生成”当瓶颈、把“审查”当免费资源的计划，最后都会悄悄卡住，而速度看板会一路保持绿色。
Faros 的报告对此说得很直白：即使产出上升，QA 和审查工作也会上升，所以如果你还没先把审查缺口补上，就因为“AI 让我们更快了”而减少工程人力，这很危险。审查时间三位数增长，给高层工程师带来的税负最重，也最容易成为你最承受不起的瓶颈，而且它不会体现在任何只统计已合并 PR 的指标里。
开源维护者最先、也最严重地撞上了这堵墙。源源不断、看起来合理却很空洞的贡献即使出发点良好，也会消耗真实的分流时间，而这就是早期信号。公司接下来也会遇到这个问题。处理得好的公司，会把审查容量当成一种真实资源来衡量、保护并有意花掉，而不是把它当成 AI 释放出来的多余余量。
写作变便宜了，理解没有
代理到来以后，代码审查并没有变得不重要。它反而成了核心活动。写代码这件事越来越接近“已解决”，而且每个月都在变得更便宜；真正持久的优势，是那套让你能够信任所写内容的系统。
不要在任一方向上接受一刀切答案。如果你是没有用户的独立开发者，关于代码变动和重复的企业级恐怖故事，只是未来风险，不是眼下火灾；所以依靠测试，审查真正重要的地方，并诚实地承认被推迟的工作终究还是要还。如果你维护的是一个面向很多人的大型系统，那么这里每一个令人警惕的数字都在说你，而唯一能成立的，是一套分层的、需要证据的、刻意异质化的审查流程，并且由一个人对合并负责。
整个光谱中保持不变的，是底层经济学。我们让“写”变便宜了，而“理解”仍然和过去一样昂贵。接下来几年里做得好的团队，不会是那些生成代码最多的团队，而会是那些搭建起了一套自己真正信得过的审查系统的团队，并且绝不把“测试通过”误认为“有人理解这段代码在做什么，以及为什么这么做”。
或者，用 Simon Willison 一直以来的说法，你的工作是交付你已经证明可工作的代码。代理并没有改变这一点。它们只是把“证明”从事后补充变成了工作的中心，而我认为这是笔不错的交换。要足够理解一个系统，理解到能为它负责，这始终是软件工程里最持久、也最有意思的技能；而且，现在正是把这项技能练到极致的最佳时机。