Gautam Korlam，Sonar 首席工程师 – 访谈系列

Gautam Korlam，Sonar 首席工程师，是一位资深的软件工程师和技术领袖，职业生涯专注于开发者基础设施、代码质量、自动化以及 AI 辅助的软件开发。加入 Sonar 之前，他共同创立了 Gitar 并担任首席技术官，构建了一个原生 AI 平台，用于自动化代码审查、诊断持续集成（CI）失败、识别根本原因并生成修复方案。Sonar 于 2026 年 5 月收购了 Gitar，Korlam 及其团队加入公司，继续在 Sonar 更广泛的代码验证平台上发展该技术。在加入 Gitar 之前，Korlam 在 Uber 工作近十年，从移动平台团队的创始工程师晋升为首席工程师。在此期间，他帮助构建并扩展了 Uber 的集中式开发者基础设施，主导了大型 monorepo 与构建系统的项目，开发了远程开发环境和 CI/CD 工具，并尝试使用开源大语言模型（如 StarCoder、OctoCoder 和 Code Llama）来提升 Uber 代码库中的 AI 辅助编码。他的早期经历还包括在 Lookout 的工程岗位、在加州大学圣塔芭芭拉分校的研究工作，以及在 Microsoft 和 Oracle 的实习经历。

Sonar 是一家专注于代码验证、自动化代码审查、代码质量和应用安全的软件公司。其旗舰产品 SonarQube 平台能够分析开发者编写的代码以及 AI 生成的代码，在代码进入生产环境之前识别错误、漏洞、可维护性问题以及其他质量缺陷，提供覆盖云端、自托管以及集成开发环境工作流的解决方案。Sonar 称其技术已被超过 700 万开发者和 22,000 家客户使用，且每日分析超过 7500 亿行代码。收购 Gitar 使其能够将 AI 原生的代码审查和修复能力纳入其中，将 SonarQube 的验证引擎与能够审查代码、诊断 CI 失败并提出或实施修复的智能工具相结合，随着软件开发日益向 AI 驱动转变。

你的职业经历从构建 Uber 的移动和开发者基础设施，到在其代码库上训练开源大语言模型，再到共同创立 Gitar 并在其被收购后加入 Sonar。这些经历如何塑造了你认为生成代码只是挑战的一部分，而可靠地验证代码可能是更难的问题的信念？

在 Uber，我负责系统中决定是否可以发布: monorepo、构建、CI 队列、测试套件的部分。让变更更容易产生会把所有压力都推到这些机制上。于是会出现更多服务以意想不到的方式交互，更多工程师等待确认他们的变更是否安全合并。

随后，我开始在我们自己的代码库上训练模型，这时不对称性变得明显。模型可以快速生成看似合理的实现。但要证明该实现能够适配真实的生产系统、遵循团队实际使用的约定，并且不会导致两个服务之间的破坏，需要更长的时间，而且大部分工作最终落在了人身上。Gitar 正是基于此而诞生，它与 Sonar 十七年来在分析方面的工作相契合。

你主张 AI 代码审查应当补充确定性分析而非取代它。哪些问题最适合通过可重复的规则化分析来识别，而 AI 能提供哪些传统技术无法实现的能力？

当属性可以仅凭代码本身决定时，基于规则的分析是合适的工具。比如污点输入流向敏感点、路径上未被捕获的空指针解引用、硬编码凭证、已知 CVE 的依赖、跨层导入等。每次运行都会得到相同的结果，并且可以指明触发的原因，这也是为何强制执行应位于该层的原因。

规则无法覆盖的是意图。没有解析器能告诉你面向用户的字符串在翻译时会产生歧义，或者一个变更声称关闭工单却只实现了工单需求的一半，亦或新的重试循环与服务其余部分处理背压的方式冲突。能够读取 diff、关联的 issue 以及完整代码库上下文的模型会发现这些问题，这些发现应当作为供人工检查的条目，而不是直接给出裁决。

AI 系统能够评估业务逻辑、开发者意图和架构权衡，但其结论是概率性的。开发团队如何在利用这种上下文推理的同时，不把 AI 审查员的输出视为必然正确？

AI 审查在传统检查遗漏的问题上发挥作用: 逻辑错误、行为与声明意图不符、单独看似合理但对特定系统错误的变更。这些结论是概率性的，因此应作为决策的输入，而非决策本身。团队通过在合并前保留确定性控制来划定边界，即自动化测试、CI 验证、安全扫描、策略检查以及负责该变更的人工。只要 AI 提出的修复能够通过与人工编写代码相同的验证，并且不因机器生成而获得特殊通道，AI 就可以在团队设定的防护措施内提出或实施修复。

我们在自己的实现中也划定了相同的边界。模型提出发现，审查结果则由代码根据这些发现的状态计算得出。解决方式也相同。当某个发现对应的代码已从 diff 中移除时，这是一项针对解析后 diff 的确定性检查，模型不得重新打开已被修复的 diff。

一般来说，应将可容错的任务交给概率层，保持状态机的确定性，并将责任留给团队。获得信任的关键在于能够提供可供检查和控制的证据，使其在每次运行时表现一致。

Sonar 正在将上下文感知的 Pull Request 审查与确定性分析和质量门结合。有效的多层验证流程应是什么样的？不同层之间应如何交互，既避免工作重复，又不让开发者被大量发现信息淹没？

确定性分析和质量门负责那些不可协商的事项，也是合并时的阻断点。上下文审查则对变更是否实现其声明的功能、是否适配代码库以及某项风险是否值得人工关注做出判断。

大量的发现往往会被忽视，效果与根本没有发现相当。我们在将信息发送给作者之前先在审查者之间去重，剔除无法验证的候选项，聚焦高信噪比的发现。在规则层面，谓词会在任何模型运行之前判断规则是否适用于当前 diff，因此大多数规则在多数变更上几乎不产生开销。所有这些都会在开发者已打开的 Pull Request 中呈现。

随着代码生成代理产生更多代码和 Pull Request，软件审查与验证会成为新的瓶颈吗？审查流程的哪些环节应当自动化，哪些决策应保留给经验丰富的工程师？

审查和验证已经成为瓶颈。事实上，我们的 2026 年代码状态开发者调查显示，团队大约在一周工作时间的四分之一用于检查和修复 AI 输出。由此可见，只有 48% 的开发者在提交前始终检查 AI 生成的代码，尽管绝大多数（96%）并不完全信任其功能正确性。

值得自动化的工作往往是机械且乏味的: 将 CI 失败归因到根本原因以免有人阅读上千行日志、判断 rebase 后某个发现是否仍然适用、复现故障、编写显而易见的修复。工程师应保留意图、设计以及对特定变更需要多少证据的判断。当高级工程师花整晚阅读日志以确定九个失败中哪一个重要时，这属于分流而非决策，正是我们应当替他们完成的工作。

AI 代码审查系统可以识别问题、提出修复并在持续集成流水线中验证这些变更。如何防止自主修复系统只追求构建成功而导致回归，或仅针对狭义的构建成功而忽视软件整体质量？

关键是不要把构建通过（绿灯）视为接受标准，因为通过的构建只能说明现有测试没有失败。

我们对自有修复系统设置的大部分约束都与范围有关。Gitar 修复导致 CI 失败的情况，并在自身提交之前检查该提交是否为绿灯，才会承担责任。它在两次后续提交后停止，而不是在红灯构建上持续迭代。当故障与变更无关，如不稳定测试或基础设施短暂异常时，会走重试路径而非修复路径，因为“让测试停止失败”是你最不希望一个强大代理去追求的目标。

随后，变更必须通过 Gitar 无法控制的层级。SonarQube 按照自身标准评估结果，质量门是合并所依赖的，而该策略由团队拥有。我们还会将变更与其声称实现的 issue 对比，需求提取与完成判断分离，防止某个在工单中悄然遗漏的需求被误认为已实现。

高效的 AI 代码审查依赖于对代码仓库约定、依赖、架构以及提议变更目的的理解。AI 审查员需要哪些上下文才能做出有价值的决策，组织又该如何在系统演进时保持这些上下文的准确性？

它需要足够的上下文来像经验丰富的审查员一样推理，而不仅仅是读取 diff 所需的最小信息。这包括变更的目的、相关代码路径和类型信息、依赖项、测试行为、仓库约定以及团队期望变更遵守的架构边界。

上下文还必须随代码一起存在。将规则和审查指南以版本化方式保存在仓库中，在服务或约定变更时及时更新，并明确架构和策略决策的所有者。否则，AI 审查员可能给出在单独看来合理，却与整体系统实际运行方式冲突的建议。

确定性分析产生一致且可审计的结果，而基于大语言模型的审查在不同运行间可能出现差异。企业应如何在受监管或安全敏感的环境中记录、复现并治理 AI 生成的发现？

审计日志应展示被审查的变更、AI 发现、所作决定以及用于验证结果的独立证据。团队可以利用 AI 加速审查和修复，同时将强制执行和批准决策基于既定政策并由人工承担责任。

工程领导者应使用哪些指标来判断 AI 代码审查是否真正提升了软件开发？他们应侧重于审查时间、漏检缺陷、误报率、持续集成失败、技术债务、开发者信任度还是其他衡量标准？

应从结果出发，而非 AI 系统产生的评论数量。我会衡量从 Pull Request 到合并的时间、诊断 CI 失败所耗时间、修复在首次验证即通过的比例，以及问题进入后期阶段或生产环境的频率。

随后关注质量信号，如误报和驳回率、重新打开的 issue、与近期合并变更相关的回归，以及开发者对发现是否可操作的反馈。合适的指标组合因团队而异，但核心问题始终一致: 我们是否在降低返工和审查等待时间的同时，未降低安全可靠软件的标准？

展望未来，你是否预期软件开发会成为一个持续循环：代理在确定性防护下生成、审查、测试并修复代码？在这种环境中，人类软件工程师的职责和所需技能将如何变化？

这种循环已经存在，团队通常按固定顺序采用: 先检测，然后修复，再根据书面的条件进行批准，最后合并。没有人会直接跳到最后一步，推动他们前进的证据是自身的代码库，而非基准。合并是我最感兴趣的环节，因为冲突频率随提交吞吐量上升，而吞吐量正是这些措施提升的目标。

增值的技能位于循环的外围而非内部。当代理字面理解你的描述时，精准定义问题及其约束变得尤为重要。同样，决定何种证据足以让变更通过——这原本是人们凭经验判断的习惯，现在必须写成政策供自动化执行。其余则是系统设计: 确定自动化工作可触及的范围、让代理无法控制的环节检查结果，以及在出错时保持可追溯。工程师将花更少时间实现代码，更多时间决定应当存在什么以及怎样的证据能证明其有效。

感谢这次精彩的访谈，想了解更多的读者请访问 Sonar。