AI 代码审查工具有效，还是只是假装？
快速阅读: 据《红僧侣》最新报道，AI代码审查工具在提升效率和安全性方面有潜力，但开发者对其效果仍存疑。它们虽能自动检测问题，却难以替代人类协作与知识共享。未来，AI仍需与人类配合使用。
在2021年早期阶段，AI代码助手的一个典型理想应用场景是代码审查。看看Meta公司软件工程师Marius Eriksen发布的一条推文。如今，AI代码审查工具已经陆续推出并层出不穷。例如有CodeRabbit、Qodo的PR-agent、Greptile、GitHub Copilot代码审查、Ellipsis、Korbit、CodePeer、Codelantis、Bito、Graphite、LinearB、Swimm和CodeAnt AI。虽然它们的前景十分可观，但这些工具是否真正减轻了代码审查的负担，还是只是盲目自信地应对，这在开发者中仍存在激烈争论。因此，让我们花点时间来讨论这个更广泛话题的一个方面，即“AI代理与CEO们”（或所有企业领导者而言）之间的交汇点，以及“开发者希望从他们的AI代码助手那里得到什么”。
代码审查是软件开发生命周期中的一个必要但痛苦的环节。它耗时且可能带来干扰，跳过它是有风险的。AI供应商承诺提供永不疲倦、无需休息、能在几分钟内审查代码的工具。其吸引力不言而喻。谁不想更快地发现更多错误，并让人类工程师专注于业务逻辑的创造性工作呢？
当然，一些较为怀疑的开发者指出，这些工具在获得AI光环（和风险投资资金）之前早已存在，只不过当时它们被称为静态检查器。事实上，许多所谓的AI代码审查工具主要依赖于自70年代以来静态检查器处理过的既定程序。此外，AI代码审查与像Sourcegraph的语义索引及分析工具、Sonar的SonarQube以及JetBrains Qodana等代码分析工具之间存在显著重叠。
尽管如此，AI代码审查能够在不给高级开发人员带来过多负担的情况下确保质量这一概念依然令人着迷。
代表性工具在市场上可用的AI代码审查工具中，有几个特别引起了开发者的兴趣。据我亲自交谈过的开发人员所说，CodeRabbit获得了广泛的关注，同时似乎也在更广泛的社区中获得了人气。在与CodeRabbit的首席执行官Harjot Gill的一次非常有趣的播客对话中，我被这种工作负载对智能代理的高强度需求所震撼。根据Gill的说法，CodeRabbit的AI不仅仅做出一次性的判断。它会规划子任务的任务图（如安全检查、风格一致性、错误风险分析等），并在需要时生成子代理。一些任务是预设的管道阶段，但其他任务则是AI即时规划的。关键的是，该代理被鼓励“遵循多条思维链”：这种方法虽然略微增加了一些计算时间，但更加全面。由于拉取请求审查是在CI/CD中运行的，对延迟不敏感，因此CodeRabbit愿意花时间进行彻底的审查而不是快速完成。
另一个值得注意的AI代码审查工具是GitHub Copilot代码审查，它于4月正式发布。它可以自动审查PR差异以建议更改或标记问题。目前有两种类型的Copilot代码审查：选择性审查（用户可以在VS Code中突出显示代码并要求初始审查）和深入审查（用户可以在VS Code和GitHub网站上请求对所有更改的深入审查）。虽然对这个新发布的版本的评论很少，而且一些早期的测试者感到失望，但Copilot的优势在于其与开发人员现有CI/CD工作流程的紧密集成和易用性。
在最近一集的Frontend Fire节目中，主持人Jack Herrington、Paige Niedringhaus和TJ VanToll对AI代码审查工具（包括Devin）整体持怀疑态度，但承认他们愿意尝试，因为这些功能已经内置在他们的GitHub仪表板中。
一些AI代码审查工具在安全性方面找到了特定的应用场景。2021年，亚马逊推出了CodeGuru，它“通过扫描和分析您的Java和Python应用程序来帮助您提高代码质量和自动化代码审查”，随后更名为Amazon CodeGuru Security。Snyk在应用安全领域广为人知，因为它可以扫描依赖项和容器镜像，但随着2020年对DeepCode的收购，它进入了AI代码分析领域。Snyk Code利用DeepCode的功能，提供侧重于安全的AI驱动的静态分析。还有其他一些厂商主打安全的AI辅助代码审查工具，包括Hackerone Code、Turingmind和Codacy。
让我感兴趣的是这些专注于安全的AI代码审查工具的定位，因为它们暗示AI不仅可以改善由非理性因素驱动的代码，还可以改善由不完美的人类编写的代码。在这种情况下，机器的表现优于人类。专注于安全的AI代码审查工具在确保团队遵循商定的标准方面表现尤为突出。
总而言之，竞争格局如下：一些工具提供通用的代码审查协助，它们的命运将取决于其表现如何。另一些则专注于特定领域（安全扫描器、风格强制执行者），希望通过有针对性的采用“跨越鸿沟”。而大型科技公司（如GitHub和亚马逊）则直接将AI审查员嵌入平台，以方便使用，但代价是牺牲了一些灵活性。
开发者的评价：从怀疑到极度怀疑
如果你认为工程师对制表符与空格的争论有强烈的观点，那么等到你询问他们关于AI代码审查工具时，你会发现他们的意见更为激烈。他们的态度从谨慎乐观到“恨不得将其付之一炬”都有。在网络上你可以找到很多像iOS和macOS开发人员Jesse Squires这样的人，他对此有异议：
在这项研究中，我遇到的一个常见说法是AI无法真正理解他们的具体项目背景。正如一位Reddit用户所说：“上下文一直是AI代码助手工具成功的核心。”上下文为王，因此毫不奇怪，许多AI代码审查市场上的玩家声称正是上下文使他们区别于竞争对手。例如，Greptile自称是“具备完整代码库上下文的AI代码审查工具。”Kodus公司的增长主管Edvaldo Freitas也强调上下文是这些审查工具成功的关键。
另一个困扰AI代码审查工具的问题，也是使用它们的开发者经常抱怨的问题，就是处理假阳性结果和幻觉（Squires所说的“完全错误的”）。许多开发者分享了AI编造不存在的问题或提出奇怪更改的故事。全栈Web开发人员Chris Zuber在Reddit上抱怨道：
供应商认识到这个问题，并渴望克服它。许多公司提供提示指南和文档，或者建议用户在开始时投入时间定制AI的规则以符合团队的优先事项。所有这些策略都是为了提高工具的使用效果，避免无关或错误的建议。事实上，开发者抱怨这些幻觉与团队内部的懒惰和缺乏专业知识结合在一起会引发灾难。正如一位Reddit用户提到的，就Codacy而言，添加AI魔法与诸如AI生成的静态分析结果修复等功能可能是一把双刃剑，因为：
在从业者讨论AI代码审查员优点的对话中，关于初级开发人员和情绪编码者满足于取悦工具而非真正解决根本问题的刻板印象比比皆是。那些更关心如何“让静态检查器闭嘴”的用户，而不是安全或性能，今天并不能从这些工具中受益，甚至可能让负责管理它们的工程团队更加忙碌，因为它们会使代码变得更糟或引入新的问题。
这是合理的，但我从对这些非常受欢迎但仍有缺陷的工具的研究中，最感兴趣的是这种外向的反思。让我解释一下我的意思。这些自动审查员迫使团队——尤其是通常负责审查PR的工程领导——认真审视自己，结果是开发者对代码审查在成功团队中的作用和目的进行了深刻而真诚的自我反思。
一些工程师指出，依赖AI进行审查会损失人类的知识共享，这是一种微妙的成本。代码审查不仅仅是寻找错误；它也是高级开发人员教导初级开发人员，团队成员学习他们通常不会接触的代码部分，确保对设计决策的共同理解，有时还会挑战架构选择。正如一位Reddit用户解释的那样：
当人类审查代码时，他们不仅是在检查正确性。这个协作过程建立了共同的所有权，并提高了团队的整体专业水平。代码审查是编程工作中实际发生的硬功夫。如果AI完全取代了这一点，即使它做得完美无缺，它也会剥夺审查过程中最有价值但又是高层次的结果之一。
归根结底，代码审查既是关于人类合作，也是关于组织和工程团队的利益。正如IBM的Teaganne Finn和Amanda Downie总结的那样，这些工具可以提升：“效率、一致性、错误检测、[以及]增强的学习。”
毫无疑问，AI正在迅速改进，并将在SDLC中发挥越来越重要的作用，但在可预见的未来，它仍将最好地与人类和组织的智慧一起工作。
免责声明：AWS、IBM和微软（GitHub）是RedMonk的客户。
头图由ChatGPT 4o创建
(以上内容均由Ai生成)
