资深工程师吐槽代码质量，呼吁恢复代码审查应对AI编程代理

当团队里最有经验的工程师受够了我们糟糕的代码

听 · 10 分钟

感谢 Linear 长期支持 manager.dev！

这是我团队最喜欢使用的产品，它让我们的生活轻松了太多。在当下这种混乱的工作方式里，它是唯一能让我保持清醒的办法（我试过所有替代品——Jira、Notion、GitHub issues——没有一个能比得上它）。

两周前，我们团队里最有经验的工程师在频道里发了这样一条消息（经他本人同意发布）：

我知道我们都很享受不用等代码审查这件事，但我在想，我们是不是还是应该考虑做一下审查。这不只是因为我自己喜欢审查、却没什么机会做，还因为我觉得这是我们与他人分享工作成果的最好方式之一，也是让讨论解决方案的好地方。

我最近做了一些清理工作（因为这种事在我脑子半瘫的时候也能干），然后我注意到一个反复出现的模式：某个 agent 在一个我们没有良好既有范例的地方，做了一个勉强过得去的一次性实现，然后多个 agent 就把它的实现当成了黄金标准。

我觉得非常重要的一点是，我们要提醒自己：所有工作都由 agent 完成，并不意味着我们可以少关注质量。那些“勉强过得去”的一次性实现会非常快地自我复制，最终导致各种各样的 bug（可能是叠加的性能损耗、竞态条件，或者被搞糊涂的 agent）。进入我们代码库的每一行，真的、字面意义上，都需要通过这样一个标准：“如果再有 100 个人在各地做一模一样的事，会怎样”。

直到五个月前，我们团队的每个 PR 都至少由两个人审查——写代码的工程师，以及一个或多个审查者。这正是 99% 的软件工程团队自 1970 年代以来一直的工作方式。

然后到了四月，我们开始做一个全新的产品，没有任何生产环境要担心。于是我们决定把代码审查改为可选，以便更快推进。

起初，大多数 PR 仍然会被审查。我们都有一种健康的恐惧，害怕把东西发布到生产环境。但把一个 PR 在几分钟内而不是等上几个小时就送到生产环境，是会让人上瘾的，所以过了几个月，代码审查的数量降到了几乎为零。

不过，我仍然期望每个人完整阅读并理解他们的 agent 产出的代码，我不接受“我不知道，是 Claude 写的”这种借口。我们还在编码工作流里加了一个 agent 审查步骤（一个 skill 会生成 3 个独立的 agent，用不同的指令审查代码，然后汇总它们的发现）。所以，不再是 2 个人类审查代码，而是 1 个人类（作者）加多个 agent。

但这也成了瓶颈。我们身处一个竞争激烈的市场，需要非常快速地推进。如果我生成的 UI 代码注定要被扔掉，那我是否完全理解它又有什么关系呢？

验证——那些一次性的、一旦转向就会被扔掉的部分。比如 onboarding 流程、大部分 UI，以及当前产品特有的功能。

基础设施——即使我们转向也会保留的能力和部分。

我们会仔细审查基础设施类的任务，对验证类的任务只是快速扫一眼（其中大部分是前端代码）。

代码审查这个环节，正是迫使人们仔细阅读代码、真正理解 agent 写了什么的东西。你没法跳过它，因为你没法回答 PR 上的问题和评论（而派你的编码 agent 去回答这些问题，是不被认可的）。

当我们移除这个强制机制后，我们所有人都开始偷工减料。我们仍然会看代码，但理解的程度开始下降。

就这样，在 5 个月里，我们从 100% 的代码由 2 个人审查，变成了大部分代码由 0 个人审查：

对于使用编码 agent 的组织来说，过去 2 年里创建的 PR 数量增长了 3 倍（！）。而且这不只是在新项目中，在已经成熟的公司里也是如此：

正如我上面分享的，由于转向了新项目，我们的情况更加剧烈。

以下是我们 PR 的数字。我们在八月从每天 4 个 PR 跳到了每天 28 个 PR。你也可以清楚地看到代码审查的下降，从 100% 降到了这个月的仅 2%：

而且这不只是琐碎的 PR，同期产出本身增长了约 8 倍。你可以看到我们从一月到四月是停滞的，自那以后我们就一直在加速：

当你生成这么多代码时，旧流程就直接崩溃了。

看看你使用的软件，那些在编码 agent 出现之前写成的。

大部分都很烂，充满了 bug。我参与过的代码库中，90% 都是混乱的，感觉急需重构（参见《重构如何差点毁了我的婚姻》）。问问一个工程师怎么看他 3 年前写的代码，你大概率会听到“很糟糕”。

那么，如果你写了一个功能，它运行良好，你还需要在意代码质量吗？

我这不是在反问——我不把任何流程或过去的决定当作理所当然。我从来不会为了漂亮代码而漂亮代码，结果才是对我重要的。

即使这个功能会有一些小 bug，代码会有重复——这跟以前也没多大区别，而且你至少把它产出的速度快了几十倍。

所以，并不是说在 LLM 出现之前软件工程师就做得完美。我们的基线充其量也就是平庸。

代码审查的一个关键好处是能够就我们的工作方式达成一致，这帮助我们更快地写新代码。但当 agent 写了所有代码时，谁还在乎它们是不是需要多费点劲呢？

你可能听说过破窗理论，它来自犯罪学。社区里一扇破了没人修的窗户，传递出的信号是没人在乎，这会招来更多破坏行为，最终演变成更严重的犯罪。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）