Tariq Shaukat：如何对 AI 生成的代码建立信心

我是 Sonar 首席执行官 Tariq Shaukat。今天我想讨论，企业如何建设真正有效的软件工厂。为了说明这个挑战，我先从实体工厂讲起：20 世纪 80 年代，即使是不错的汽车，零部件接缝也可能有明显空隙。

我记得一则 Lexus 广告：一个钢珠滚过汽车的接缝。这个画面传达了一种不同的方法：不再一味追求产量、事后修复问题，而是设计生产流程，力求一次交付正确、减少返工并提高客户满意度。

这并不是一个孤立的改变。更大的理念是为质量设计工厂：质量优先于产量，修复系统而不只是处理症状，设计能够一起制造和装配的部件，并在问题出现时解决。在这种方法中，任何人都可以叫停生产线，而不只是管理者。

我也在现代软件开发中看到了这些理念。敏捷、看板、持续集成，以及站点可靠性工程中的错误预算等实践，都体现了如何建立有效生产系统的共同问题。如今，智能体改变了这套系统必须应对的规模。

我引用了一项异步编码智能体研究：代码行数增加了 2450%，提交次数增加了 240%。这些数字来自所引用的研究，并不意味着每个团队都会出现同样的变化。最直接的结论是，代码产出可能变得更加充裕。

我介绍了 Sonar 即将发布的开发者调查：5% 的受访者表示已经运行智能体软件工厂，34% 预计一年后会这样做；金融服务领域受访者的比例为 39%。这些是我展示的调查结果，不是对未来实际采用情况的观察。

这也涉及安全问题：帮助构建软件的智能体，同样可能帮助攻击者发现和利用弱点。我提到 Satya Nadella 关于模型相关内部风险的讨论，以及对工程化隔离、人工控制和可靠操作流程的需要。

第一个挑战是，在流程中加入人工环节，并不会自动解决规模问题。在我引用的研究中，代码量增长了 2450%，提交量增长了 240%，而发布量只增长了 30%。产生更多更改不等于安全交付更多更改；从创建到发布的路径也需要关注。

我把一个相关问题称为“认知屈服”。在我引用的一项研究中，AI 建议正确时，人们有 93% 的时间会认同它；建议错误时，约 80% 的时间也会认同。我用这些数字质疑，仅仅加入人工审查者是否就能保证独立审查；结果受该研究的具体条件限制。

第二，智能体可能难以应对大型、复杂的代码库。我引用一项代码翻译研究：在 1 万行代码时表现较好，到 5 万行时表现下降。另一项研究发现，完成一项任务的令牌消耗有 30 倍差异；我认为这与在陌生代码库中寻找路径所需的工作有关。

我把代码导航问题比作选择前往纽约的出发点。从附近出发比从远处出发更快、更省钱。为智能体提供有用的代码库地图，可以减少它寻找起点所需的工作。

第三，较长任务中的错误可能不断累积。我展示了一张 METR 任务时长图：其中模型约 16 小时的时长是在 50% 成功率下测得的，并不保证可靠完成。我的意思是，当要求更高的成功率时，任务时长会呈现不同结果。

举例来说，如果 20 个步骤各自独立，且每一步成功概率都是 95%，全部成功的概率约为 36%。这是一个简化的数学例子：真实步骤可能相互依赖，恢复措施或验证也可能改变结果。

第四，我质疑只让大语言模型充当裁判时判断是否一致。我引用一篇论文：根据模型和情境不同，完全相同的重复评估中，有 7% 到 17% 的判断发生变化。我还引用研究称，一个简单的追问就会让部分模型改变答案；这些数字仅适用于讨论的研究。

第五，当漏洞利用可能发生得很快时，事后响应就更困难。我认为，预防需要被设计进软件工厂，而不应完全依赖后续响应。

我们的“代码信心公式”有四个组成部分。第一是明确意图：在智能体能够可靠地朝目标工作之前，必须清楚说明目标和标准。第二是“引导机制”；我强调它不同于只防止偏离的护栏，而是帮助智能体保持正确方向。

第三是独立、充分的验证，发现的问题应得到处理，而不是被推迟。第四是一致、可审计、可重复的证据，表明检查确实发生过。我把四个要素表示为乘积：如果关键要素缺失，我认为人们对整体结果的信心可能降到零。

当我们帮助客户和合作伙伴设计这些工厂时，会询问他们如何表达意图、引导智能体、独立验证结果并生成证据。这张图是组织这些问题的框架，而不是证明某一种工具能够保证结果正确。

随后我介绍了 Sonar Vortex，这是 Sonar 的一款产品，旨在智能体循环中结合意图、引导和验证。我报告，在展示的案例中，令牌消耗最多降低 36%，提交代码中的问题最多减少 92%。这些是公司报告的结果；幻灯片没有提供足够细节，无法推广到所有工作负载。

在验证方面，我主张结合确定性方法和智能体方法，并为每项任务选择合适的计算资源。Sonar 最初是一家验证公司，因此这也是我看待问题的角度。我介绍 SonarQube 是公司在这一领域的产品。

我描述了一项涉及 1000 多名客户的调查，比较 SonarQube 用户和非用户报告的积极影响。我引用的相对差异分别是：对安全影响的感知高 81%，上市时间高 34%，故障频率高 76%。这些是调查中报告的比较；演讲没有证明这些差异仅由产品造成。

最后，我强调证据：团队需要表明他们通过了适用的质量门槛，以及内部控制或标准。无论涉及内部控制、汽车标准还是其他要求，目的都是让验证可见且可重复。

我的结论是，代码正变得充裕，而信心仍然稀缺。未来的软件工厂应该被设计成让人们对交付结果有信心，而不只是生成更多代码。