返回资讯中心
外部精选
软件工程
#开发者实时流

Addy Osmani 改口:AI 生成代码不必逐行人工审查

来源标题:The Code Nobody Reads

Addy Osmani 推翻两年前的旧建议,认为不必再逐行审阅 AI 生成的代码,但每处改动仍需有人负责审查并决定是否发布。他提到,这类审查可由 agent 主导,或在敏感场景中由人与 agent 混合完成。他还引用 Teleport 的案例指出,安全漏洞的发现成本已大幅降低,但漏洞分类和可利用性确认仍依赖人工。

Hacker News 最新saikatsg2026/11/3 · 4 天前30 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

Addy Osmani 2026年9月28日 184 17 20 分享 两年前我写过一篇关于 AI 辅助编程的文章,其中一条建议是逐行审查生成的代码。今天我会给出非常不同的建议。 我现在想说的是:你不需要读完所有代码。每一处改动仍然需要某种审查,也仍然需要一个对上线决定负责的人。变化在于,仔细人工通读每一行不再是提供这种审查的唯一方式,也不总是最佳方式。有些代码可以主要由 agent 审查,敏感部分则可以人机混合审查。 Teleport 在一个季度里发现了过去两年的安全漏洞。十三名工程师、前沿模型、自己的代码库:发现的高危漏洞数量几乎是前两年总和的两倍。我感兴趣的是这对队列意味着什么。发现的成本降低了好几倍。分诊没有,确认哪些漏洞真正可利用仍然需要人读代码。发现的速度快过修复的速度,你只是把一个未知的积压换成了一个已知的积压。在把这一套用到你自己的代码库之前,值得一读。阅读原文 → https://fandf.co/4r3xdeX · 由 Teleport 赞助。#ad 这篇文章讲的是我认为应该用什么来取代逐行审查,以及如果什么都不取代会发生什么。 上周 Thorsten Ball 发了一份清单,列出他对软件开发未来的十六条信念。第一条是“代码审查将会消亡”。我同意其中大部分内容,至少在方向上同意,不过第一条我会换个说法。逐行阅读对大量代码来说正在成为过去。审查——也就是有人决定什么上线并为此负责——不会消失。像他那样的清单无法告诉你每一条多快会到来,或者在行业的哪些部分先到来。这才是我真正与人分歧的地方。 同一周,一篇截然不同的文章 ^ 走得同样远。一位在大公司入职两周的工程师写道,他每天的工作就是对着没人读的代码按回车。超过八百万人看到了它。我不认为这两篇文章互相矛盾。一篇描述的是目的地。另一篇描述的是公司没修路就一路开过去会发生什么。 简而言之,我的观点是:一旦每个行业有了其他可靠的理由去信任代码,它就会停止逐行阅读大部分代码。 这次不同之处在于,写代码的东西无法像过去的代码生成器那样被认证,因为它不能可靠地两次给出相同答案。所以信任必须来自我们在它周围建立的检查机制。一个团队或一个行业多快到达那一步,取决于两项成本:检查没人读过的工作的成本,以及撤销检查漏掉的失败的成本。 我应该事先说明,我并不中立。我在帮助构建一个写代码的工具。当人们说 Thorsten 是卖铲子的人、叫大家都去挖时,他说因果关系是反过来的:他构建 agent 是因为他相信它们。对我来说也是如此。 我怀念旧方式的什么吗?老实说,是的。在我的一本 JavaScript 书的最开头,我写过好代码就像写给下一位维护它的开发者的情书。我是认真的。那是在 AI 之前,那时我们很多人都关心代码本身的手艺。我喜欢 Thorsten 那句话:现在还有意大利鞋匠,但看看你的脚。事情会变。我换来的能力是能非常快地重塑黏土,以及去构建那些否则我会琢磨好几年却从不动手的东西。 2013 年,微软的研究人员研究了代码审查,问开发者为什么要做。发现缺陷是首要答案。评论内容却讲了另一个故事。在研究人员分类的 570 条审查评论中,只有 14% 是关于缺陷的。其余是关于教学、共享上下文、建议更好的方法以及维护团队规范。审查从来就不主要是关于 bug 的,这也是为什么“机器会审查它”这个答案比听起来要弱。 抓 bug 是机器越来越擅长的那部分。在 Anthropic,一个自动化的 Claude 审查器几乎在每个 PR 上运行,工程师标记其发现为不正确的比例不到 1%。自它启用以来,获得实质性审查评论的 PR 比例从 16% 升到了 54%。它不批准任何东西。用 Anthropic 的话说,“那仍然由人来做决定。”在一次回顾性分析中,Anthropic 发现对每处改动的自动审查本可以在 claude.ai 过去事故背后的 bug 到达生产环境之前,捕获其中大约三分之一。 对于一个从不疲倦的审查者来说,三分之一已经很多了。但它也告诉了你一件令人不安的事:那些 bug 大多数都从仔细盯着改动看的人眼皮底下溜了过去。我的猜测是,因为那些在生产中失败的代码,在 diff 里往往看起来没问题。 2026 年第二季度,典型的 Anthropic 工程师每天合并的代码量大约是 2024 年的八倍,用 Anthropic 的话说,工程师是在“指挥和审查,而不是打字”。没有人会仔细读八倍多的代码。从内部看,我们的工作方式和我过去习惯的非常不同。我们每天在大量产品面上生成大量代码,不再每一行都经过仔细的人工阅读。几乎每处改动都会得到自动审查,仍然由人批准合并,深度由那个人决定。这个改动需要仔细的手动审查吗?我们现有的工具在这里够好吗?这是系统里足够敏感、需要额外审查的部分吗?如果代码通过了测试、在测试中表现良好、在生产中运行没有问题,那就是一个相当不错的信号。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →