TREX：运行您的代码的人工智能代码审查器

我是 Shlok，Greptile 的软件工程师。我们最近构建了一个代码审查器，除了审查拉取请求之外，它还实际运行代码并向您显示出了什么问题。 1976 年，Michael Fagan 发表了一篇介绍 IBM 正式代码检查的论文。开发人员会打印出清单，一起坐在一个房间里，逐行阅读代码。今天我们仍然在屏幕上阅读差异。人工智能工具使这一过程变得更快，尽管大多数工具仍然只是阅读代码。这种方法适用于许多错误，这些错误在代码中清楚地表明了自己。问题是有一整类错误根本不会出现在代码中；它们在程序运行时存在。想想需要特定状态序列的逻辑错误、页面加载后出现的 UI 回归或需要真实请求的竞争条件。您可以完美地阅读差异，但仍然完全错过这些类型的错误。静态代码审查是有上限的。它可以推理代码所说的内容。它无法告诉你它的作用。 TREX（代表“测试、运行、执行”）是 Greptile 对这一上限的回应：直接内置于代码审查中的执行层。在不浪费上下文的情况下编排代理 TREX 最初是一个与 Greptile 完全独立的产品，作为生成和运行测试的独立代理。我们希望错误会因此而浮现出来。他们没有。生成测试与查找错误不同。当单独的 TREX 代理尝试编写测试时，测试与用户尝试执行的操作无关。这产生了不必要的噪音，而且还错过了边缘情况。事后看来，这听起来是显而易见的，但我们花了比预期更多的时间来吸取这一教训。我们构建这些代理是独立的，假设它会给每个代理自己的上下文窗口。这也意味着两个代理单独运行而不共享知识。他们经常重叠，两次探索代码库的相同部分，而两个代理都不知道另一个代理已经发现了什么，最终导致计算浪费。显而易见的解决办法似乎是将它们合并为一个代理。我们尝试过，但遇到了另一个问题：处理完整审​​核的单个代理超载。在启动服务、截取屏幕截图、运行测试之间，一个代理需要干净地管理太多的上下文。解决方案是让 TREX 与主要的 Greptile 审阅者共享相同的上下文，而不是让它完全作为一个单独的产品存在。这是我们第一次在代理内部管理代理。与两个独立的代理不同，这意味着 TREX 不是从头开始。 It inherits what the Greptile reviewer agent already found, has its own context window, and is scoped to the specific problem it's been asked to investigate. Greptile 审阅者代理充当协调者。它读取差异，识别值得调查的问题，并针对每个问题启动专用的 TREX 代理，所有这些都是并行运行的。 TREX 代理拥有协调器代理的自由、计算能力和知识。一个很好的例子是隐藏在身份验证门后面的 UI 功能。本地测试意味着设置环境、处理身份验证、使功能标志处于正确的状态。子代理会自行计算出所有这些内容，并返回渲染功能的屏幕截图。设计多模式工件来展示工作 TREX 的第一个版本输出结果作为要点，列出了测试的内容和发生的情况。这是一个合理的起点，但它没有提供足够的信息。代理或人工审核员阅读诸如“测试结帐流程，发现失败”之类的要点时，不会发现它很有用。他们无法判断这个过程中哪里出了问题。如果测试失败，是不是设置的问题？断言？环境问题？我们发现该代理的早期版本有时会产生幻觉，认为它测试了某些东西有多彻底，并声称已经尝试过一些它没有尝试过的东西。要点让我们无法验证。解决方案是为每个 TREX 发现设置多模式工件来支持项目符号列表：屏幕截图、日志、API 跟踪、执行脚本。每种模式涵盖了故事的不同部分。真正重要的是全面了解针对特定问题测试的所有内容。第一个让我们惊叹不已的神器是视频。如果您推送动画更改，TREX 会捕获其播放的视频。无需打开本地环境即可准确看到动画的样子。文物也需要值得信赖。每个工件都必须为审阅者提供足够的空间来验证运行本身。屏幕截图、日志、跟踪和脚本都在那里，因此人员或下游代理可以准确查看发生的情况并进行确认。坏证据比没有证据更糟糕。工件很重要的原因，特别是对于下游代理而言，与教学的原因相同