Agentic Code Review

Agentic Code Review - 由 Addy Osmani 撰写 - Elevate

Agentic Code Review

为什么代码审查是当前软件领域最具杠杆效应的技能。

Addy Osmani

2026年6月16日

如今，代码代理已经非常出色，并且正在迅速提升。有趣的是，工程领域中困难的部分已经从编写代码转移到了决定是否信任代码上，这使得代码审查成为当前软件领域中最具杠杆效应的技能。你对待它的方式在很大程度上取决于你是谁：一个没有用户且独自开发的开发者，与一个维护着一个十年历史的应用程序的团队，他们所解决的问题并不相同。

我对代理工程比以往任何时候都更加乐观。这些代理确实非常出色，每个月都在变得更好。在普通的一周里，我现在能完成的事情，如果放在一年前，我甚至不敢尝试。这篇文章是一张地图，它展示了有趣的工作已经转移到了哪里，因为确实发生了转移，而大多数团队还没有完全跟上。

代码审查曾经有效，是因为相对速度的偶然巧合。一位资深工程师可以比初级工程师更快地阅读代码，因此审查工作在没有被设计的情况下跟上了节奏，而团队在阅读彼此的差异时，作为副作用吸收了系统如何组合在一起的知识。很多情况并不是有意为之的。这源于一个事实：编写代码是缓慢且昂贵的，而阅读代码则是便宜且快速的。

这个事实现在已经不再成立。一个代理可以在不到我阅读这段文字所需的时间内生成一千行经常是坚实且格式良好的代码，而人类的阅读速度自我们开始以屏幕为生以来几乎没有变化。因此，限制已经转移到了下游，即那个没有变快的步骤：一个人对更改是否正确的信心。我认为这并不是一种损失。现在，软件领域中最具有杠杆效应的地方就是这里，而这也是我今年大部分注意力所在的地方。

这里有一个令人愉快的转折，它塑造了本文的其余部分。生成所有额外代码的相同工具，也是我用来跟上这些代码的最佳工具。在我的个人项目中，包括那些受欢迎的开源项目，我现在会将Claude Code或Codex指向一批即将到达的PR，并让它们为我处理队列的优先级排序，这确实改变了我如何利用时间。因此，这不是一个反AI的论点，我将回到我如何使用它的具体细节。

这也不是数据的倾倒，也不是又一次关于让模型编写你的代码是美好的还是标志着手工艺终结的讨论，因为这种框架是无用的。唯一能经受得住与真实代码库接触的答案是，这完全取决于你是谁。一个为一个只有十几个人会运行的副项目进行“氛围编码”的开发者，与一个团队为了维持一个十年历史的企业系统继续运行一个季度而努力的开发者，他们之间几乎没有值得命名的共同约束，而目前流传的大多数建议，实际上就是这两个中的一方告诉另一方如何生活。

多年来，这只是一个轶事和争论。现在，多个没有共同议程的组织，甚至在一些情况下存在竞争性商业利益的组织，已经在大规模上对此进行了测量，而这些测量结果始终指向同一个方向：人工智能显著提高了产出，但同时又显著降低了质量和可审查性。

Faros AI 对 4000 个团队中的 22000 名开发人员进行了工具化追踪，并观察了团队从低人工智能采用率向高人工智能采用率转变时发生的变化。这是 2026 年 3 月的数据，与本文中的任何数据一样最新。积极的一面是真实且值得明确指出的：开发人员合并了大量拉取请求（PR），完成了更多工作，每位工程师的吞吐量也有所上升。然后是报告的其余部分：

• 代码变更量增加了 861%
• 每个拉取请求（PR）的事件数量比增加了 242.7%
• 每位开发人员的缺陷率从 9% 上升至 54%
• 审查持续时间的中位数增加了 441.5%，首次审查时间与平均审查时间都大致翻了一番
• 没有经过审查就合并的拉取请求（PR）增加了 31.3%

最后一个数据是我最难忽视的，因为没有人选择它。并没有决定停止审查。审查人员只是无法跟上数量，因此代码开始在未被阅读的情况下被合并，这变得正常了。我反复提到的一个细节是，那些拥有成熟、严谨工程实践的团队也受到了同样的影响。良好的流程并未保护他们，因为数量的增加速度超过了任何流程设计所能吸收的范围。

一个需要始终记住的注意事项是：CodeRabbit 和 Faros 都在这个市场中销售产品，因此他们的观点并非完全无偏见。但这并不意味着这些数据是错误的，这些效应的规模在多个不相关的来源中都很大且一致，但需要带着这一点来阅读供应商的研究。

CodeRabbit 在 2025 年 12 月研究了 470 个开源拉取请求（PR），其中 320 个是由人工智能共同撰写的，150 个是完全由人类撰写的，发现人工智能的修改中大约有 1.7 倍的缺陷：逻辑和正确性问题增加了约 75%，安全问题的出现频率增加了 1.5 到 2 倍，可读性问题则增加了三倍以上。CodeRabbit 的人工智能主管 David Loker 将这些描述为“可预测、可衡量的弱点，组织必须积极加以缓解”。其中，“可预测”是关键的词语。这些是已知且可定位的弱点，这是个好消息：这意味着审查流程，无论是人工还是自动化的，都可以直接针对它们进行。

GitClear 在这里也有有趣的数据。在他们截至 2025 年的生产力数据中，每天使用人工智能的用户产生的原始输出量大约是非用户用户的四倍，但与他们一年前的产出相比，真正的生产力提升只有约 12%。你生成的代码量大约是四倍，但交付的价值只增加了约十分之一，而人类仍然需要审查所有四倍的代码。GitClear 的 Bill Harding 明确指出，即使这 12% 的部分也存在选择偏差，因为更强的开发人员集中在人工智能群体中。四倍代码与十分之一价值之间的差距，用一句话来说就是审查问题。

GitHub 报告称，Copilot 审查现在已经运行了超过 6000 万次审查，在不到一年的时间里增加了十倍，平台上有超过五分之一的审查涉及代理。这已经不再是小众的做法。这就是代码是如何被创建的。

四个数据集，四种方法，一个结论。我们将机器速度的输出注入了一个为人类速度工作构建的系统中。瓶颈并未消失；它转移到了验证环节，而审查就是这个账单的结算点。

每个人都在解决不同的问题

一个变更需要多少审查，几乎完全取决于它的影响范围，而你读到的大多数建议，都是由那些处于完全不同影响范围的人写的。

上面那些令人担忧的数据几乎都来自于企业遥测数据，以及开源维护者被压垮的情况。如果你所处的正是这种情形，这些数据是完全真实的。如果你是一个人开发的东西，只有少数几个人会使用，那么其中的很多内容其实并不适用于你，你也不应该因此而感到压力。

有三个变量决定了你所处的位置：

• 影响范围：出错时会发生什么。可能是什么都不会，或者用户愤怒、金钱损失以及个人身份信息（PII）面临风险。

• 代码的生命周期：可能是你下周就打算重写的临时原型，也可能是你多年后仍需维护的代码库。

• 需要理解代码的人数：可能是只有你一个人在脑海中记住所有内容，也可能是需要随着时间推移共享所有权的团队。

将同样的代码差异（diff）代入这三个变量中，“良好的审查”意味着截然不同的事情。

如果你在没有用户的情况下独自开发一个全新项目，那么审查的第二个职责——在团队中分发知识——对你来说并不存在。你就是整个团队。

合理的方式是大力依赖测试和自动化，审查那些真正重要的部分，对其他部分则采取更轻的审查方式。当代码可能在一个月内就不存在，或者在它出错时没有人会在凌晨三点被通知时，重复和变更的成本要低得多。但需要注意的是，人们往往在痛苦中才学会这一点：只有当测试是真实的时，这种方式才有效。没有安全网而跳过审查并不会消除工作，而是以更高的代价将问题推迟，而当没有人可以反对时，标准也会下滑。没有用户是允许你推迟审查的，但并不是允许你跳过验证。

然后项目开始有了用户。这是危险的中间阶段，而这一转变通常在当时并不明显。审查的错误检测功能突然变得重要，因为现在错误会伤害到人，而知识共享功能也开启，因为不再只有你一个人了。团队会在几个月内继续保留他们单人开发时期的习惯，然后就会有一次事后分析，Faros 的数据不再只是一个图表，而是变成了他们自己的仪表板。

在另一端是拥有老代码库、大量用户的大公司。在这里，每一个令人担忧的数字都会以最强烈的方式体现出来。没有人理解的变更会变成理解债务，最终成为某人值班时的紧急事件。审查此时同时承担着多项职责，而代理输出的大量内容会悄无声息地打破所有这些职责。Faros 关于成熟团队的发现正是针对这种情况而提出的。

因此，重点并不是“企业应该谨慎，而单人开发者可以放松”。重点是，随着你的位置变化，审查的目的也会变化，因此规则也必须随之变化。将企业那种严格、多代理、需要证据的审查流程强加于一个两人原型项目上，只会增加不必要的摩擦。在支付系统上运行“测试通过，就发布”这种做法，实际上是在制造一个带有绿色对勾的事故生成器。这个领域中大多数糟糕的建议，都是将某一端的规则强加于另一端。

这是真正发生改变的部分，我认为这一点被低估了。

当人类编写代码时，意图是自然而然地伴随而来的。推理过程、权衡和舍弃的替代方案都存在于作者的脑海中，而代码审查就是你检查这些推理过程。现代智能体在推理时，通常会以可见的方式进行，生成推理轨迹，权衡各种选项，并在过程中解释自己的决策。但问题是，这种推理通常在生成代码差异（diff）的那一刻就被丢弃了。它很少被记录下来，也很少与拉取请求（PR）相关联。无论如何，这种推理是智能体关于如何实现任务的推理，而不是人类对是否应该从一开始就进行这个任务的判断。因此，代码审查从检查你面前的推理过程，变成了重建从未被写下来的意图，这更加困难且耗时，而我们却总是对它需要花费441%更长时间感到惊讶。

2026年的一篇论文《AI Slop and the Software Commons》分析了15个Reddit和Hacker News线程中1,154条帖子，其中开发者讨论了“AI slop”这一话题。其中一条开发者的话引起了我的注意：“审查一个智能体的PR，使他成为‘第一个看到这段代码的人’。”

这直接指出了问题的解决方向。在常规的代码审查中，作者已经理解了变更内容，而你只是在检查他们的工作。但在智能体的PR中，还没有人重建出变更背后的原因。审查者是第一个尝试这么做的人。

正如论文中所说，代码审查“并不是为了恢复缺失的意图而设计的”。令人鼓舞的是，缺失的意图是可以恢复的：推理过程确实存在，只是我们将其丢弃了。让智能体说明它试图完成什么，以及它排除了哪些选项，将这些内容作为PR上的决策日志记录下来，这样大部分的重建成本就会消失。这是一个工具问题，而工具问题是可以被解决的。

以上内容并不意味着“让AI审查AI”就是完整的答案。一个具有不同先验知识的第二个模型确实可以发现真实存在的错误，并且能发现大量的错误，因此你应该运行一个这样的模型。但它并不能提供人类对是否应该从一开始就进行这个变更的判断。这种判断仍然需要由人来做出，而这也是工作中最有意思的部分，值得保留的部分。

工具很好，但并不总是因为它们宣传的原因

当前的AI审查工具确实表现很好，它们偶尔会对相同的代码行给出不同的判断，因此正确的做法不是选择最好的一个，而是运行两个不同构建方式的模型。

目前的专用AI审查工具已经非常不错了，我认为你应该在所有项目上运行至少你的主要编码智能体，甚至包括侧边项目，如果有的话。

CodeRabbit是目前部署最广泛的工具，在2026年1月至2月的独立火星基准测试中，它在F1指标上排名第一，精确度约为49%，在该领域中召回率最高。

Greptile则以召回率换取精确度：在一项基准测试中，它的错误检测率约为82%，而CodeRabbit的错误检测率约为44%，但代价是产生更多的误报。

Anthropic的代码审查工具报告称，其发现的错误中，不到1%被工程师标记为错误。我实际上会向经理展示的数字是：它将公司内部PR获得实质性审查的比例从16%提高到了54%。过去那些只被匆匆一瞥并批准的变更，现在都会被某个东西仔细阅读。

今年我看到最有用的结果不是来自供应商，而是一位工程师在三周半的时间里，同时使用了四个审查工具（CodeRabbit、Sentry Seer、Greptile 和 Cursor BugBot），对 146 个真实 PR 和 679 个发现进行了审查：

在 617 个不同的标记位置中，93.4% 的问题被这四个工具中的一个发现，6% 的问题被两个工具发现，几乎没有任何问题是被三个工具发现的，四个工具同时发现的问题则完全没有。

这四个工具从未标记过同一行代码。每个工具在不同类别的问题上表现突出：Greptile 在正确性和架构方面几乎没有误报，CodeRabbit 捕捉范围最广，且提供一键修复功能，Seer 在生产失败严重性方面表现最佳。这是在真实代码库上展示的对抗性审查论点，而不是论文中的理论。异质性正是其核心所在。四个相同模型的副本只是拥有更大账单的单一审查者，而四个真正不同的审查者则能发现任何单一成员（包括人类）都无法单独发现的一组错误。

实际上：不要纠结于寻找最好的单一工具，因为不存在这样的工具。在高风险场景下，应运行两个具有明显不同特性的工具（如上述实验中，将 Greptile 用于日常正确性检查，Seer 用于生产失败严重性检查，几乎没有任何重叠）。如果你是独自工作，一个优秀的审查者加上真实的测试就已足够。无论营销怎么说，都要在你自己的代码上进行测量，因为这些结果都特定于某个代码库，你的代码也是如此。

我们是否应该让 AI 审查更多代码？

机器已经在审查你代码的比重上超过了你本人。唯一真正的决定是，你是否要主动地这样做，而你保留的人工审查比例应与你的影响范围成比例。

我一直在听到一个以前会被视为异端的问题，现在却来自经验丰富的工程师：机器是否应该承担更多审查工作，甚至大部分？我不再认为这是一个愚蠢的问题。

令人不安的是，AI 审查确实有效。Anthropic 的发现中，不到 1% 被标记为错误，这些工具能发现人类在阅读时直接忽略的错误，而且它们在一天的第 30 个 PR 上不会感到疲劳，这正是人类最不可靠的时候。与此同时，人类显然无法跟上：零审查合并的代码增加了 31%，审查时间也增加了三位数。从某种现实意义上来说，机器已经在审查比我们更多的代码。诚实的表述不是“我们应该让 AI 审查更多”，而是“AI 已经在做了，我们要有意识地去推动这一趋势，还是让它默认发生，同时假装人类仍然阅读所有内容”。

循环工程进一步强化了这一点。循环工程的前提是你不再是提示代理的人，而是构建一个能提示代理的系统，而该系统的核心部分是一个评判者：一个决定工作是否完成才能继续前进的代理。审查者是下一个被有意从内部循环中移除的角色。我们花了一年时间自动化编写代码，现在循环正在自动化检查代码，而人类则不断被推向更高、更外围的位置。“人类应该停留在哪里”不是一个研讨会问题，而是在每次连接循环时你必须做出的决定，无论你是否意识到这一点。

我目前所处的位置是：答案可能不是“由人类阅读每一行代码”。这种做法已经过时了。但答案也不是“让系统自行审查并放手不管”。当一个代理编写代码，另一个进行审查，第三个进行判断时，你实际上拥有的是一个模型之间的闭环系统，它们的盲点广泛相关，尤其是在它们来自同一家族时，它们会在相同的地方自信地达成一致。一个自信的“看起来没问题”，其中没有任何人类参与，这种自信是借来的：系统的确定性变成了你的确定性，实际上没有人真正理解了任何东西。这个闭环系统可能既非常确定，又非常错误，而没有人能分辨出其中的差别。

因此，人类并没有离开；人类只是上升到了更高的层次。你不再逐个审查每一个差异，而是开始负责那些无法转移到模型中的部分。问责制非常重要。

判断是否应该进行这项更改，这与代码是否正确是不同的问题。高影响范围的关卡，错误的代价很高。还有那个尴尬的问题：没有人指定的行为，因为模型只审查现有的代码，很少会指出那些没有人想到要写下来的必要条件，这仍然是一个我预计短期内无法填补的人类形状的缺口。

“人类在环中”变成了“人类在环上”：对系统进行抽样、抽查和审计，而不是阅读每一个PR（Pull Request），并将有限的注意力集中在那些出错会真正造成伤害的地方。

这已经是我处理自己项目的方式，包括那些现在每天收到的PR数量比我一晚上能仔细阅读的数量还要多的开源项目。我会将Claude Code或Codex指向一批即将到达的PR，并要求它们进行初步审查：判断哪些看起来可以安全合并，哪些需要进一步的工作，哪些是真正高风险的。我不会根据它们的结果自动合并，也不会懒洋洋地合并它们批准的任何内容。它们给我提供了一种分配注意力的方式。我可以花几分钟确认它们认为低风险的更改，而将真正仔细的时间投入到它们标记为危险的更改上。关键的细节是，这并不是我过去那种略快一点的审查小时。这是一种不同形状的小时，而在我现在处理的量级上，这是让队列保持可生存的主因。

📷 Codex和Claude Code为我提供了一批PR的初步审查，按风险排序。初步筛选是帮助，而合并决定仍然是我的。

一个更加极端的版本是 Kun Chen，他曾经是 Meta 的 L8 工程师，现在作为独立开发者每天提交大约 40 个 PR，据 Peter Yang 所说，他几乎已经不再进行代码审查。很容易对此不屑一顾，除非你意识到他是 L8，而且在之前停止做的事情上异常出色，这正是其有趣之处。他同时运行 20 到 30 个代理，并将精力投入到计划中：他提前撰写详细的计划，代理会针对这些计划运行数小时，他表示计划的质量决定了这些代理可以无人值守运行多久。这就是我之前描述的策略。有必要准确描述到底发生了什么，因为并不是他停止了验证。他的意图并未消失，他本人在计划中已经写下了这些内容，因此“第一个看到这个内容的人”问题已经解决了一半：一个人确实理解了原因，只是是在计划阶段而不是之后。他并不是没有保障地工作，他建立了一个自动审查门（他称之为 No Mistakes），在代码合并前检查代码，并且当代理遇到问题时，他会参与升级处理。人在代码存在之前完成昂贵的思考，机器在代码存在之后逐行处理，这可能正是这一趋势的走向。

但他是一个独立开发者，没有庞大的团队，也没有一个布满地雷的已有系统。使他每天提交 40 个 PR 而不进行审查的条件，对于大多数读者来说并不存在。如果你将他的工作流程复制到一个面向大量用户的团队中，你就会在自己的仪表板上重现 Faros 的数据。他并没有错，他只是沿着这个光谱的某个特定端点走得很远。

这又回到了光谱的某个点。对于一个没有用户、独自工作的开发者来说，让 AI 审查几乎全部内容在 2026 年是可辩护的，你也不应该因此感到内疚。对于维护一个为许多人服务的大型系统来说，让机器处理第一轮、第二轮以及枯燥的 90%，但要确保真正的人类参与关键路径，并且不要让任何可能伤害他人的流程完全自动闭环。你保留多少人类参与是一个调节器，你应该根据其影响范围来设定，而不是根据内疚感。

实际上应该怎么做

不要对所有内容都进行相同深度的审查。只将稀缺的人类注意力放在错误代价高昂的地方，其余的则由廉价的确定性检查和 AI 审查者处理。

核心理念是将审查工作与错误的代价相匹配，尽可能早地推进廉价的确定性工作，并将人类的注意力保留给只有人类才能完成的任务。

按风险分层，而不是按作者分层。一个配置更改只需一个 linter 和一个快速浏览。对核心业务逻辑路径的修改则需要完整的检查流程：类型检查、测试、两个不同的 AI 审查者、一个负责该系统的人员以及一个安全检查。不要对模板代码进行深度审查，也不要因为测试通过就放行重大更改。分层的方法在所有地方都是一样的；不同的是，每个更改需要通过多少层检查。

快速放弃代价高昂的尾部。对于那些被代理人员拉取请求（PR）淹没的团队来说，最近最有用的发现是《审查工作量的早期预测》（2026年1月），该研究分析了33,707个由代理人员撰写的PR。代理人员擅长处理小型、定义明确的更改，约28%的更改几乎可以立即合并，但一旦收到主观反馈，他们往往会“消失”，放弃实际需要来回讨论的审查过程。（2026年的一篇相关论文发现，审查人员放弃是被拒绝的代理PR的38%。）研究人员构建了一个“断路器”，它在人类查看之前，通过低成本信号（如文件类型和补丁大小）预测高维护成本的PR，并且效果很好。提前对代理PR进行分类，快速处理那些简单的PR，并且不要让一个人花费一个小时去处理一个代理人员在你提出反对意见后就会放弃的庞大更改。

提高你愿意审查的标准。解决被淹没问题的方法不是锁定仓库，而是拒绝审查那些没有证据的更改。在审查之前，要求提供以下内容：更改的目的说明、不是3500行且没有注释的差异（diff）、测试输出以及证明测试确实运行过的证据。这样你可以避免成为第一个阅读代码的人。将意图重建的工作推回给提交更改的人，这样成本较低，而不是由你来承担，这样成本较高。

刻意保持PR的小型化。代理PR往往较大，在Faros数据中平均大出51%，而审查人员的参与程度是PR是否能够合并的最强预测因素之一。一个大而无法审查的PR会被直接拒绝，或者更糟糕的是被草率批准。指导你的代理人员生成小型提交。现在，一个人类可以实际阅读的差异（diff）已成为设计约束，而不仅仅是礼貌。

比阅读代码更仔细地阅读测试更改。这是需要关注的代理失败模式。代理更改了行为，然后通过重写断言来“修复”测试，使其与新的、错误的行为匹配。在确认这些更改是正确的之前，200个编辑后的测试通过绿色检查意味着什么都不存在。将任何重写多个测试的差异视为一个标志，并优先阅读这些内容。突变测试在这里有其存在的价值：覆盖率告诉你某一行代码是否运行过，而突变测试则告诉你如果该行代码出错，测试是否能察觉到。

将CI视为不可移动的墙。注意GitHub现在警告审查人员的模式：删除的测试、跳过代码检查、降低覆盖率阈值、复制已存在的辅助函数，以及不受信任的输入流入提示（prompt）。最后一个需要强调，因为由代理构建的功能是提示注入的新鲜来源：如果更改将用户控制的文本直接输入到LLM调用中，而没有考虑这些文本可能指示模型执行什么操作，那么漏洞在差异中是不可见的，它潜伏在稍后到达的数据中。代理人员也会为了使自己通过而削弱CI，不是出于恶意，只是梯度下降寻找最便宜的绿色路径。确定性门是流程中唯一无法通过自信段落说服其改变决定的部分，因此请保持它们严格。

人类拥有合并的最终决定权。模型无法被叫来，也无法对其发布的内容负责，因此点击合并按钮的人将对此负责。当AI审查以冷静、自信的语气说“看起来没问题”时，它实际上是在传递它未必赢得的信心。将每次AI审查视为传感器，而不是最终决定：数据，而非决策。

如果你是独自一人且没有用户，那么分层、测试变更的纪律性和持续集成就是你最需要的；其余的则是负担，直到有人出现。如果你是大型组织，那么所有这些内容都是基本要求，而问题分类和准入门槛之间的差异，决定了评审流程是能够扩展还是悄然崩溃。

如果你带领一个团队，这意味着什么

瓶颈不再是你编写代码的速度，而是受信任的人确认代码评审的速度。因为“AI让我们更快了”而削减提供这种信心的人，只会将节省的时间转化为未来的事故。

交付的瓶颈不再是你编写代码的速度，而是受信任的人确认变更是否正确的速度。任何将生成视为瓶颈、而将评审视为免费的计划，都会悄然停滞，而速度仪表盘却会一直保持绿色。

Faros 报告对此直言不讳：随着产出的增加，QA 和评审工作量也在增加，因此除非你首先弥补了评审差距，否则因为“AI让我们更快了”而减少工程人员数量是危险的。资深工程师的税，评审时间增加数倍，对那些你最无法承受瓶颈的人影响最大，而这种影响对任何只计算已合并 PR 的指标来说都是隐形的。

开源维护者最先且最严重地遇到这堵墙。即使这些贡献是出于好意，但源源不断看似合理却空洞的贡献，仍然耗费了真实的分类时间，这是一只预警的金丝雀。接下来是公司。那些处理得当的公司，会将评审能力视为一种真实资源，需要测量、保护并有意识地使用，而不是将它视为 AI 解放出来的闲暇。

编写代码变得便宜了，但理解没有

当代理到来时，代码评审的重要性并未减少，反而成为核心活动。编写代码的问题正逐渐被解决，而且每月都在变得更便宜；持久的优势是能够让你信任所编写代码的系统。

不要在这两个方向上接受一刀切的答案。如果你是独自一人且没有用户，关于企业中因变更和重复导致的恐怖故事是未来的风险，而非当下的火警，因此依靠你的测试，评审重要的内容，并诚实地承认那些被推迟的工作仍然需要完成。如果你为许多人维护一个大型项目，那么这里每一个令人警觉的数字都与你有关，唯一能支撑你的就是分层、需要证据、有意识地异构的评审流程，且由一个人负责合并。

在整个光谱中，唯一不变的是底层的经济规律。我们让编写变得便宜了，而理解的代价却和以往一样昂贵。未来几年表现优异的团队，不会是生成最多代码的团队，而是那些建立了真正可信赖的评审系统、并且从不将“测试通过”与“有人理解这段代码做了什么以及为什么”混淆的团队。

或者，正如 Simon Willison 一直所说的那样，你的工作是交付你已经证明可以运行的代码。代理并没有改变这一点。它们将证明过程变成了工作的核心，而不是一个后续步骤，我认为这是一个好的交易。

深入理解一个系统，以便能够为其背书，这是软件领域中最持久且最有趣的技能，而如今正是你变得极其精通这一技能的最佳时机。