Tessl 称 75% 的 PR 已无需人工复核即可合并

作者 @Simon Rendon Arango 和 @Colin Hallett

概览

• 团队：Tessl 工程团队，在一个 monorepo 上运行软件工厂
• 规模：每周超过 1,200 个由 agent 编写的拉取请求（PR）
• 挑战：审查每一个由 agent 编写的 PR，既不让工程师淹没在噪音中，也不让审查成本攀升
• 解决方案：Tessl Code Review 基于团队自身的标准运行

关键结果

挑战

Tessl 工程师的大部分工作都通过 agent 完成。正因如此，我们每周的 PR 数量超过 1,200 个，也正因如此，审查开始拖慢一切。

它也成为我们最大的可变成本。从未合并的 PR 和审查-修复轮次占我们 agent 支出的超过一半。

我们之前的 AI 审查器本应分担一部分负载，但我们并不信任它。它约三分之一的发现并非真实缺陷，因此工程师最终变成了审查审查器，逐一检查每个发现，然后再检查每个修复。我们也无法将其调整到我们自己的标准，所以当它漏掉某些问题或标记了我们并不关心的问题时，我们无从更改。

解决方案

我们需要一个足够可信、能让 PR 无需人工即可合并的审查器。借助 Tessl Code Review，我们在标准审查视角之上编码了我们自己的标准，并设定了与我们所愿承担风险相匹配的审查策略。由于我们拥有这些视角和标准，我们可以看清某个发现为何被提出，并更改审查器检查的内容。正是这种控制力建立了我们的信任，任何使用 Tessl Code Review 的团队都能对自己的仓库获得同样的控制力。

依据我们自己的标准进行审查

Tessl Code Review 会依据我们团队已经为其 agent 编写的标准来检查每个 PR，包括我们的编码约定、设计系统和 AI 代码审查策略。我们之前的 AI 审查器对每个仓库都应用相同的通用规则，因此无法判断某项更改何时违反了针对我们代码库的特定规则。

为了确认我们的标准解释了这一差距，我们在一个带有人工标注缺陷的外部基准上运行了两个审查器。它们打成了平手。在我们自己的仓库上，Tessl Code Review 有我们的标准作为依据，它发现了更多真实缺陷，误报也少得多。

存在一个权衡。我们之前的 AI 审查器在低严重性发现和外观问题上更强，在我们的仓库上它捕获了一些 Tessl Code Review 漏掉的缺陷。我们之所以切换，是因为我们可以通过更新审查视角、标准或设置来自己弥补每一个差距。

当审查器反复标记同一模式时，我们会将其转化为一个验证器，即对每次更改运行的通/不通过检查。使用我们之前的 AI 审查器时，弥补差距意味着等待供应商。

结果

自我们引入 Tessl Code Review 以来，约 75% 的 PR 在无需人工纠正 agent 或讨论工程问题的情况下合并。由于需要驳回的误报少得多，工程师将审查时间花在需要人工介入的 PR 上。

审查质量

在并排对比的一周内，Tessl Code Review 和我们之前的 AI 审查工具共提出了约 1,850 条发现。Tessl Code Review 的发现中有 91% 是真实缺陷，而我们之前的 AI 审查工具为 68%。这意味着工程师每周需要阅读并驳回的误报减少了约 435 条。

在仅由 Tessl Code Review 标记的 PR 中，工程师每个 PR 修复了 1.56 个 bug，而我们之前的 AI 审查工具为 0.75 个，因此在合并前修复的真实 bug 数量翻了一倍。

Tessl Code Review 在我们 AI 代码审查政策规定始终需要人工检查的全部六种变更类型上也均领先。差距最大的是隐私（发现 27 个问题 vs 4 个）和访问控制（94 vs 34）。

这对你的账单意味着什么

在默认设置下，每轮 Tessl Code Review 固定花费 50 个积分。我们的 PR 平均需要 2.2 轮，因此每个 PR 的审查成本比使用我们之前的 AI 审查工具时低约 35%。

如果你更改模型、投入程度或审查视角的数量，你需要为使用的 AI 积分付费，每轮最低 50 个积分。我们还按每个已验证结果的成本而非 token 价格来选择模型，这有助于降低每次审查的成本。了解我们如何选择模型。

下一步

接下来，我们将利用审查来直接改进上下文。Tessl 将定期挖掘代码审查数据，并建议更新你的智能体所使用的上下文，使一次审查中的经验在下一个智能体编写代码之前就能传达给它。我们会在结果出来时分享。

在你自己的仓库上试用

Tessl Code Review 可免费开始使用，每月 1,000 个积分。将它指向一个仓库，看看它能发现什么。[免费试用]

我们如何衡量

• 并排审查：我们在一周内对 monorepo 中的每个 PR 运行了两个审查工具，总计超过 600 个 PR。
• 真实缺陷：只有当一条发现描述了会在生产环境中出现异常行为的问题时，才被计为真实缺陷：错误行为、违反契约、数据丢失、安全漏洞、崩溃或泄漏。风格、命名和偏好不计入。
• 已修复：作者在合并前修改了代码以解决该发现。
• 基准：一个外部的第三方数据集，带有经人工标注的缺陷，使用它以确保两个审查工具都没有主场优势。
• 未经人工纠正即合并：指一个 PR 在合并时没有人工纠正智能体或讨论工程问题。从 Tessl Code Review 推出时开始衡量。
• PR 数量：整个 monorepo 中每周开启的由智能体编写的 PR，来自工程师在本地运行智能体以及来自软件工厂。
• 审查成本：一轮 Tessl Code Review 的默认价格乘以我们每个 PR 平均 2.2 轮，与我们之前的 AI 审查工具每个已审查 PR 的成本进行比较。

我们在查看结果之前定义了每一个术语。

• 在一个 Swift 应用上，有一个项目将其作为必需检查运行，并使用了自定义审查视角。在单个 PR 上，它提出了 12 条必需修复的发现，其中包括两条 API 密钥标头在 HTTP 重定向中被转发的路径。这是一次凭据泄漏，而且是在我们并未针对调优的语言和领域中发现的。
• 在一个长期存在的气候科学 Python 包上，维护者解决了 219 条发现中的 216 条，有时还注明了哪个提交修复了哪一条。
• 8.5% 的 PR 经历了超过五轮审查。
• 这些 PR 占用了我们审查循环支出的 47.4%。
• 这些 PR 上大约每七轮就有一轮是由合并冲突触发的，而这些重跑中有三分之二没有发现任何新问题。