阿里-雷扎·阿德尔-塔巴塔巴伊，Gitar 的创始人和 CEO – 采访系列

阿里-雷扎·阿德尔-塔巴塔巴伊，Gitar 的创始人和 CEO，是一位资深的工程领导者，他的职业生涯跨越了硅谷一些最具影响力的科技公司，包括 Uber、Google、Facebook、Intel、AMD 和 IBM。在 2023 年推出 Gitar 之前，他曾担任 Uber 的高级工程总监，在那里他帮助领导了公司的开发者平台计划，并在 Google 负责过 Site Reliability Engineering 领域的领导角色，负责诸如 Communications、Photos、Social、Cloud 和技术基础设施等产品。

早期，他曾在 Intel Labs 和 Facebook 的 HipHop VM 团队从事编译器技术、虚拟机、并行计算系统和硬件优化工作，同时还在 斯坦福大学 教授高级编译器设计课程。他的数十年背景使他在编程语言、基础设施可靠性、开发者工具和大规模系统架构方面拥有丰富的经验，这使他成为人工智能驱动的软件工程领域的杰出人物。

Gitar 致力于解决人工智能辅助软件开发带来的日益增长的问题：验证和确保大量机器生成代码的安全性，该代码现在正流入企业系统。该平台使用人工智能代理来自动化代码审查、调查 CI/CD 流水线故障、识别错误和漏洞、建议修复并直接集成到现有的工程工作流中，通过诸如 GitHub、GitLab、Jenkins、Jira 和 Slack 等工具。与其仅仅在人工智能代码生成方面竞争，该公司将自己定位在所谓的“代理质量门”周围，帮助工程团队在软件开发日益转向自主和人工智能辅助编码工作流时保持可靠性、安全性和运营监督。

您曾在 Uber、Google 和 Intel Labs 领导工程工作，负责大型开发者平台和基础设施。您从这些经历中获得了哪些具体经验，促使您创立 Gitar，并为什么专注于代码验证而不是代码生成？

在 Uber、Google、Facebook 和 Intel Labs，我曾在不同规模的开发者平台上工作，一个相同的教训不断出现：开发者体验是一个竞争优势。优秀的工具可以吸引和留住最好的工程师，并让公司快速行动。开发者希望快速、无干扰的工具，让他们保持专注并自动化繁琐的工作。但是，开发者工具非常碎片化，大多数公司仅仅为了将一个连贯的体验拼凑在一起，就会消耗大量的工程资源。我亲眼见证了解决这个问题的潜力有多大。

人工智能改变了这个等式，使得比以前更有可能自动化开发者工作流中的更多部分。代码生成已经被很好地覆盖，但这只是将瓶颈转移到下游，即验证、重构和维护我们现在以前所未有的速度生产的代码。这就是 Gitar 的关注点。随着人工智能编写更多代码，稀缺资源不是生成；而是被交付的代码的信任、正确性和可维护性。代码验证是工作流中决定人工智能生成的代码是否可以安全地进入生产的部分，这是一个更难、更有价值的问题需要解决。

随着人工智能生成代码的兴起，许多团队现在面临着所谓的代码过载问题。这个问题在企业内部有多严重，团队在哪里挣扎最多？

变化不在于编写代码。编写代码的部分已经比大多数团队能够吸收的速度要快。变化发生在之后的所有事情上。人工智能工具正在以团队无法审查的速度生成稳定的拉取请求，这在系统中产生了压力，这些部分以前不需要处理这种输出水平。

每个更改仍然需要通过验证。代码审查、CI、安全检查、批准。这些都不会因为代码是生成的就消失。曾经可管理的流程已经变成了积压。团队不再被想法或实施所阻塞。他们被阻塞在信心上。这个可以交付吗？它是安全的吗？它会破坏一些微妙的东西吗？

这就是现在的摩擦所在。不是在创造，而是在没有引入风险的情况下将代码交付到终点。

该行业大多专注于更快地生成代码。您为什么认为验证被忽视了，为什么它现在变得更加重要？

因为代码生成下游的系统没有以相同的速度演进。当输出增加时，下游的一切都受到压力。拉取请求变得更大、更频繁。CI 故障开始堆积。审查周期被压缩，因为没有人有时间对每个更改进行深入审查。

质量开始下降，不是因为工程师不在乎，而是因为数量迫使他们做出妥协。平台团队承担了更多的负担，处理管道问题、故障排除、试图让一切顺利进行。高级工程师最终变成了协调员，拼凑日志、诊断问题、决定什么是安全的合并内容。

团队面临一个选择，这两个选项都不太好。快速推送代码并稍后处理回归，或者减慢速度并保护质量，但接受速度会下降。这种紧张局势现在正出现在各个工程组织中。

Gitar 使用人工智能代理来处理代码审查、测试和持续集成（CI）工作流。这些代理与传统的静态分析工具和基于规则的管道有何根本不同？

区别不仅仅是表面上的。一个真正的代理需要做的不仅仅是响应提示。它需要处理多步骤的工作、规划、使用工具、跟踪上下文并在没有不断输入的情况下推进任务。

大多数系统都不符合这个标准。它们生成输出，但它们不管理执行。当这些工具被放入真正的工作流中时，差距很快就会显现出来。它们不减少复杂性。在很多情况下，它们添加了另一层，需要有人来管理。

这就是为什么对话正在从“我们是否拥有代理”转变为“什么工作实际上可以被可靠地处理”.

信任是软件开发中自动化的一个主要障碍。Gitar 如何确保其验证过程对于团队来说是可靠的？

有效的模式很简单。将工作分解为较小的步骤。定义明确的边界。持续验证输出。在风险决策中保持人类的参与。

代理可以审查代码并表明容易被忽略的潜在问题。它们可以分析 CI 故障、分组相关错误并指出可能的根源。它们可以建议修复，并在某些情况下以受控的方式应用它们。

这减少了工程师需要执行的manual triage 的数量。它不会将工程师从循环中移除，但它改变了他们花费时间的位置。大多数系统都有检查点，而不是完全独立的系统。

您的平台允许团队创建自己的代理。自定义对于企业采用来说有多重要，您看到的一些最有趣的用例是什么？

自定义对于企业采用至关重要。每个平台团队都在花费大量资源将 CI 定制为其公司的特定需求，这传统上需要定制脚本、配置、工具集成、日志处理器和现代开发基础设施中组合在一起的其他胶水。

Gitar 折叠了这项工作。平台团队可以使用自然语言提示编写自定义检查，这使他们能够验证使用传统程序分析很难或不可能的事情，例如标记模糊翻译的用户面向字符串或验证 AGENTS.md 文件的更新。他们还可以在拉取请求上自动化自定义工作流：将 PR 链接到 Jira 问题、为未解决的审查评论打开后续票、自动重试不稳定的测试或将自定义待办事项列表追加到 PR 摘要中。

最有趣的用例往往是我们没有预料到的。团队比任何供应商更了解他们的代码库和他们的痛点，所以当你给他们一个将“我们希望 CI 只是检查 X”转化为 10 行提示的基本组件时，他们会立即开始自动化我们默认情况下不会构建的东西。这正是我们想要的。

现代工程团队依赖于一个复杂的工具栈，如 GitHub、GitLab 和 Jira。Gitar 与现有工作流集成而不是尝试替换它们有多重要？

采用取决于满足开发者在他们已经存在的地方的需求。工程师不希望有另一个需要学习的界面、另一个需要检查的仪表盘或更多需要在工具之间切换的上下文。他们希望现有的工作流变得更快、更安静。因此，与 GitHub、GitLab、Jira 和其他工具进行深度集成对于我们来说不仅仅是一个很好的功能；这是整个策略。

但我们的雄心壮志更进一步。我们不仅仅试图将自己置于这些工具之中；我们正在自动化跨越这些工具的工作流。PR 审查、票据链接、后续任务、不稳定测试的重试，所有这些都应该在后台自动发生。我们正在推动更远：一个代理直接编辑 PR 以解决代码审查反馈和解决 CI 故障，并最终处理符合团队政策的更改的批准和合并。开发者的角色从驱动每个步骤转变为设定意图、审查结果和处理异常。

最终状态不是开发者登录的新工具。它是现有工具在开发者不知不觉中做更多事情，这样开发者就可以专注于真正需要他们判断的工作。

您曾经建议，人类代码审查最终可能成为例外而不是常规。要让组织感到舒适地接受这一转变，需要发生什么？

信任是逐步建立的，而不是一次性完成。组织需要看到，使用他们自己的代码，人工智能可以找到真正重要的 bug 和漏洞，并以高精度和高覆盖率执行他们的自定义规则。从那里开始，通往自主合并的道路是一个自然的进展，通过四个日益增加信任的层次。

第一层是检测。团队建立了对代理能够找到真正问题的信心，并且假阳性率很低。一旦这种信心得到建立，他们就让人工智能自动阻止 PR，当它找到关键问题时。

第二层是修复。人工智能不仅仅标记问题；它还修复它们，解除 PR 阻塞，并在没有人工干预的情况下使 CI 变绿。信任意味着代理可以精确地解决问题和 CI 故障，而不会破坏任何东西。

第三层是批准。一旦团队看到代理可靠地将 PR 变绿，他们就让人工智能在他们定义的规则下批准 PR。给组织对自动批准条件的明确控制，这使得这一步骤感觉安全，而不是鲁莽的。

第四层是合并。人工智能将更改合并，同样是在团队感到舒适的条件下。这个步骤有自己的标准：代理必须精确地解决合并冲突，而不会引入回归或破坏主分支。这比人们意识到的更重要，因为提交吞吐量的增加会导致冲突频率的增加，而吞吐量正在由于人工智能生成更多代码而激增。大的单体仓库已经感受到这一点；其他人即将感受到这一点。

转向人工智能作为默认审查者的转变不是一次信仰的飞跃。它是一个梯子，组织一步一步地攀登，随着证据的积累。

随着人工智能承担更多的编码过程，您如何看待未来几年中高级工程师的角色演变？

高级工程师已经转向协调角色，拼凑日志、诊断问题并决定什么是安全合并的内容。这不是任何人计划的角色。这是对系统在负载下崩溃的反应。

随着代理承担更多重复的验证工作，工程师仍然留在循环中，但他们在堆栈中向上移动。他们花费的时间更少是手动排查问题，更多的是做出关于应该交付什么以及为什么的决定。

Gitar 最近 筹集了 900 万美元 来扩大平台。您对这笔资金的首要优先事项是什么，未来 12 到 18 个月的成功是什么样的？

资金将用于两个优先事项。第一个是市场推广：我们正在扩大我们的企业动作，并投资开发者意识，以便那些可能受益于 Gitar 的团队实际上知道我们存在。第二个是产品：我们正在继续建设我们的愿景，实现完全自主的代码验证和质量，这意味着更深入的代理能力、更广泛的工作流覆盖和与开发者已经使用的工具更紧密的集成。

在接下来的 12 到 18 个月内，成功看起来像是一个有意义的企业客户群体，他们在整个代码库中运行 Gitar，一个开发者社区，他们将我们视为人工智能驱动的代码验证的默认选择，并且有明确的证据表明我们的代理随着时间的推移正在执行更多的审查、修复和合并工作。 如果我们走在正确的轨道上，一年后我们的对话将不是人工智能是否可以验证代码，而是团队将验证管道的多少交给了代理。

感谢这次精彩的采访，希望读者能够通过访问 Gitar 来了解更多信息。