编译 | 段小草 + 2.5 Pro

由人类来创制的代码，会于这个2025年走向消亡。代码审查这项工作，会在接下来的2026年走向消亡。

一当人类按人类的速度去编写代码，便已然开始跟不上代码审查的节奏了。我与每个交流过的工程组织呀，都暗藏着同样不可告人的秘密呢：PR 呈现搁置多日的状况，审批仅仅流于形式罢了，审查者漫不经心地去浏览那足足 500 行的 diffs，是因其有着自身要忙活的工作呀。

我们自认为代码审查属于质量关口之一，然而几十年来，好多团队在并未逐行审查的情形下，依旧发布了产品。曾有一位资深工程师跟我讲，代码审查一直到2012至2014年前后才开始广泛流行，只是我们这些人中记得这事的没几个了。

就算存在审查，问题依旧会冒出来。我们掌握了打造能够应对故障的系统，缘于我们认可光靠审查是不行的。这一情况在功能开关、灰度发布以及即时回滚等层面有所呈现。

我们必须放弃阅读所有代码

在一项数据中，该数据涵盖了1,255个团队，还有超过10,000名开发者，其中高度采用AI的团队，其完成的任务量增加了21%，并且合并的pull数量增加了98%，然而PR审查时间却增加了91%。

存在两件事，它们正以指数级的速度在增长，一件是变更的数量，另一件是变更的规模。我们没有办法去消化这么多的代码，就是这样。并且，开发者们一直都在表明，审查由 AI 生成的代码，相较于审查同事所编写的代码，需要投入更多的精力。团队产出了更多的代码，之后又花费了更多的时间去审查它。

这场战斗，我们靠手动代码审查是不可能赢的。代码审查作为一项具有历史性的审批门禁，它现在已然无法适应现有的工作形态了。

AI 代码审查仍然是审查

仅为我们争取时间的是AI代码审查工具，要是AI编写代码，接着由AI审查代码，就这个过程而言，我们为何还需要一个漂亮的审查UI来展示它，虽说AI代码审查或许有价值，然而它们最终会朝着开发周期的左侧迈进，并且在审查周期之间，并没有理由耗费CI资源以及管理版本控制。

对于人类编写代码且需他人检查的情况而言，PR 提交之后进行审查是具备意义的；当 AI 智能体编写代码之际，“新的视角”仅仅是又一个存在同样盲区的 AI 智能体；此处的价值落在迭代循环上，而非处于审批门禁这儿。

据经验所知，AI智能体并非一直可靠，人们自然而然会这么想：我曾抓到AI做了蠢事，所以我得持续检查它。手动验证可行时，这种直觉有它的道理。然而在当下规模，这已行不通。并且情况只会愈发糟糕。

从审查代码到审查意图

答案是把人类的检查点朝着上游去移动，要是不再审查代码的这个想法听起来蛮可怕的话，那让我来提醒你，在软件开发期间，检查点的位置是曾有过变化的，我们从瀑布模型的签准转变至持续集成，我们能够再度移动它。

采用规范驱动开发这种形式（Spec-）正演变成与AI协同合作的主要途径。人类需要进行审查的是规范（specs）、规划、限制以及验收准则，并非500行的差异对比。

于这个全新范式里，规范成了事实的 sole 源头，代码变为规范的产物，故而你无需审查代码，你审查的是步骤，你审查的是验证规则，你审查的是代码必须履行的契约。

环路之中的人的审批，从“你所编写的代码是正确的吗？”转变为“我们是不是在运用正确的约束去解决正确的问题呢？”，人类最为宝贵的判断力应当在第一行代码生成之前就发挥功效，而非在那之后。

通过分层构建信任

我们需要达到多大的舒适度，才能停止阅读代码？

规则形式如下：

代码禁止由人类编写

代码禁止由人类审查

大语言模型于遵循指令方面并不擅长，它们会出现偏离情况，并且这种偏离情况还较为频繁，它们在自我验证这一方面也是不可靠的，哪怕代码已然处于“着火”状态了，它们依旧会很自信地告知你代码能够正常运行，解决办法并非是让大语言模型去进行验证，而是要让它编写一个用于验证的脚本，把重心从单纯的判断转向最终所产生的产物。

信任存在分层状况，这便是瑞士奶酪模型，即不存在任何一个单独的门禁可捕获全部问题，你把不完美的过滤器逐一叠加其上，直至它们的漏洞不再处于对齐状态，那么我们还能在哪些地方去设置审批门禁呢？

第一层：比较多种选项

比起要求一个 AI 智能体做对，不如安排三个 AI 智能体，让它们采用不同方式去尝试，而后选择最佳结果，让它们相互竞争。在软件工程的历史当中，选择的多样性所产生的成本，从来没有像这样低过。

选取的进程并不必然得是人工手动操作的。你能够依照哪一个输出经过了数目最多的验证步骤、哪一个产出了规模最小的差异、哪一个并未引进全新的依赖项去开展排序。竞争催生了一种仅凭单一尝试无法获取到的信号。

第二层：确定性护栏

理应有那么一种具备确定性的方式用来实施验证方面的工作事宜。其中有着测试这一环节，还有类型检查这一内容，另外存在契约验证这一情况——此等种种事物并不附带任何个人观念，只是专门陈述相关事实而已。

相比于向一个大语言模型询问“这能用吗？”，倒不如去定义一连串能够产出“通过/失败”结果的验证环节，AI智能体没办法跟一个失败的测试进行协商，它要么符合规范，要么不符合。

这些护栏本身可以被定义为多个层次：

步骤的验证，应当于代码编写之前予以定义，并非在事后，为确认已有的代码，而凭空去捏造。要是AI智能体同时进行代码编写以及测试，那你仅仅是将问题进行了转移——此刻，你必须信任AI智能体能够测试正确的事物东西。验证的标准codejock skin builder，需源自规范，而非源自实现。

第三层：人类定义验收标准

那么，人类的价值体现在哪里？在上游，定义成功的标准。

这便是行为驱动开发，即那个（-，BDD）再度变得关键的所在，BDD向来是个不错的想法，拿自然语言去撰写描绘预期行为的规范，接着把这些规范自动化转变为测试，然而它始终未曾全面普及，由于当你自己还要去编写代码之际，编写规范感觉好似是额外增添的工作。

有了AI智能体之后，情况发生了反转。规范不再属于额外的工作范畴，它摇身一变成为了主要的产物结果。如此一来，你仅仅只需要进行书写：

由AI智能体来负责达成实现，BDD框架承担验证职责，除非出现失败状况，不然你任意时刻都无需去阅读实现代码。

这属于人类于开展自身所擅长之事：对 “正确” 的释义予以界定，对业务逻辑以及边缘状况进行编码codejock skin builder，于可能出现差错之处展开思索。AI 智能体承担起将意图转变为代码的职责。BDD 规范化作你的验证层面——其具备确定性、自动化特性，且在首行代码编写之前就已完成定义。

由人类编写验收标准，由机器验证。这才是真正重要的门禁。

第四层：作为架构的权限系统

此AI智能体所能够接触的是哪一些东西，什么样的情况是需要进行上报的，这些均变成了架构决策，并非是事后的用于补救的措施。

把权限当作一种“全有或全无”设置的，是大多数AI智能体框架，AI智能体存在两种情况，要么有shell访问权限，要么没有，可有一点很关键，那就是粒度，一个用于修复工具函数中bug的AI智能体，并不需要访问你的基础设施配置，一个编写测试的AI智能体，也不需要修改CI流水线。

范围理应尽可能地狭窄，与此同时还得让AI智能体得以完成具备效用的工作。要是任务是“修复utils/dates.py中的日期解析故障”，那么AI智能体对于文件系统的访问权限应当仅仅局限于该文件以及其测试文件。并非整个代码库。也不是“src/和tests/”。只是限于和此任务存在关联的文件。

上报触发装置，其自身同样具备相当的重要性。存在着一些特定的模式，像触及认证逻辑这一情况、对数据库模式进行修改之行径、添加新的依赖这样的举动，均应当被自动地标记出来，进而交付给人工去进行审查，不管AI智能体在面对这些情况时有着多么充足的自信。

第五层：对抗性验证

AI智能体中，一个得负责去开展工作，另一个担当验证重任，二者之间彼此不信赖，而这恰是最为关键之处。

这是一种古老的模式，正因如此，首先，你的QA团队不应当向你的工程经理汇报，其次，编写代码的人不应该是唯一审查它的人。

有了AI智能体，在此架构方面你能够将这一点予以强制执行。进行编码的AI智能体并不清楚负责验证的AI智能体会去检查些什么。同时，承担验证工作的AI智能体也没办法通过修改代码而让自身的工作变得更为轻松。它们于设计层面就是具有对抗性的。

还能够更进一步，让第三个AI智能体去尝试破坏第一个AI智能体构建的事物，专门针对边缘状况以及失败模式。如同红队、蓝队那样，不过是自动化方式的，且于每次变更之时都进行运行。

结论：何为“优质代码”的标准正在改变

一个关于AI智能体的系统，其激励机制是这样的：赋予一个任务，我有没有能力去完成它呢？我可不可以让给予我任务的人感到满意呢？有关AI智能体的成功，从来都不是被长期的准确性或者业务需求从内部推动的。

我们的工作就是将这些要求编码到约束中。

由AI智能体生成的代码，再由AI智能体去阅读，在此情况下，“优质代码”的模样会愈发趋于标准化。针对一个全新的代码库而言，因默认标准会更为统一，所以你所需提供的指导将会更少。

未来是：快速交付，全面观测，更快回滚。

而不是：缓慢审查，依然漏掉 bug，在生产环境中调试。

在真正重要的决策发生的上游环节，我们没办法在阅读速度上超越机器，我们所要做所具有的是在思考深度方面比它们更胜一筹。

说到底，要是AI智能体可以出色地处置代码，那我们能不能读懂它，又有啥关联呢？

如有侵权请联系删除！