Tabnine 联合创始人兼联合首席执行官 Eran Yahav 教授 – 专访系列

Eran Yahav 教授是 Tabnine 的联合创始人兼联合首席执行官，同时也是以色列理工学院（Technion）的计算机科学教授。他的研究专注于编程语言、机器学习和软件工程，特别是程序综合与大规模代码分析。除了学术工作，他还联合创立了 Tabnine（最初名为 Codota），旨在将多年的研究成果转化为实用的开发者工具，帮助开创了 AI 驱动的代码补全和自动化。他的工作架起了学术界与工业界的桥梁，专注于让 AI 生成的代码在真实的企业环境中更加可靠、安全且具备上下文感知能力。

Tabnine 是一个 AI 驱动的编码平台，旨在协助开发者完成整个软件开发生命周期，从编写和调试代码到生成测试和文档。它最初作为一个代码补全工具推出，现已发展成为一个更广泛的、专注于企业的平台，集成了生成式 AI 和基于智能体（agent）的工作流，使团队能够自动化复杂的开发任务，同时保持对隐私、安全性和合规性的严格控制。Tabnine 支持数十种编程语言，并集成了主流 IDE，其目标是提高开发者的生产力，同时确保 AI 生成的代码保持可信并符合组织标准。

您在以色列理工学院从事程序分析和综合研究多年，此前也曾在 IBM 研究院工作。是软件开发中的什么问题促使您联合创立 Tabnine？您的学术研究如何塑造了公司最初的愿景？

我的学术工作专注于程序分析和综合，本质上就是教机器理解和生成代码。我的博士研究是关于程序分析的，这也是我最初几年应用研究工作的方向。通过程序分析解决软件质量问题让我清楚地认识到，一旦程序编写错误，有些问题将很难解决。可以说，预防胜于治疗。这让我确信，解决软件质量的正确途径是通过程序综合，这也是我投入大部分研究时间和精力的领域。

我最初研究的是并发程序的程序综合，试图将顺序程序自动转换为并发程序。后来，我转向了使用机器学习的、更具普适性的程序综合。

使用机器学习的程序综合也是驱动 Tabnine 的基本理念。这个如今看来显而易见的想法是：模型可以直接从大量代码语料库中学习编码模式，并实时协助开发者。这个通用理念适用于软件开发生命周期的所有阶段——从代码创建到代码审查，再到部署及其他环节。

我们的愿景始终是通过为人类开发者提供工具来增强其能力，这些工具能加速开发过程并消除摩擦。软件开发是一项创造性和解决问题的学科，我们的目标是让 AI 通过处理常规任务并帮助开发者保持心流状态，从而消除过程中的摩擦。这一愿景至今仍指引着我们，尽管技术自早期以来已取得了显著发展。

Tabnine 在生成式 AI 随着 OpenAI 等模型成为主流之前数年就率先推出了 AI 编码助手。回顾过去，自早期以来，AI 在软件开发中的作用发生了怎样的演变？行业从第一波编码副驾驶工具中学到了哪些经验教训？

最早一代的 AI 编码助手主要专注于预测。它们本质上是高级的自动补全系统，通过预测下一行代码或函数来帮助开发者更快地编写代码。

随着智能体循环的出现，情况发生了变化。AI 现在能够以更大的自主性处理任务，以至于我们可以将（经过适当指导的）智能体视为独立的初级开发者。

但这也让行业学到了一个重要教训。对于企业软件开发而言，原始模型能力是不够的。基于公共数据训练的模型可以产生令人印象深刻的输出，但它们通常缺乏对组织架构、依赖关系和惯例的了解。

这就是为什么下一阶段的演进不仅仅关乎更大的模型或更长的上下文窗口，还关乎将这些模型连接到软件构建的真实上下文中。

许多企业发现，扩展 AI 智能体需要的不仅仅是更大的模型——还需要更深层次的组织上下文。为什么您认为上下文正成为实现可靠 AI 驱动开发的真正前沿？

软件系统是复杂的关系网络。一个单一的更改可能会影响多个服务、API 或下游组件。

如今的 AI 模型非常擅长生成看似合理的代码，但它们通常在没有对这些关系的结构化理解的情况下运行。没有这种理解，AI 就无法可靠地推理更改的后果。

企业正在发现的是，AI 系统的可靠性取决于其运行上下文的质量。如果 AI 系统理解系统的架构、服务之间的依赖关系以及组织的编码标准，它生成的代码就能更紧密地贴合该系统的实际工作方式。

从这个意义上说，上下文正成为企业 AI 开发的下一个前沿。

您新的企业上下文引擎旨在让 AI 智能体对组织的架构、依赖关系和工程实践有结构化的理解。这种方法与许多公司目前依赖的常见方法（例如检索增强生成）有何不同？

检索增强生成是一项有用的技术。它允许模型在生成答案时引入相关文档或代码片段。

但仅靠检索并不能创造理解。它提供的是信息访问，而非结构。

企业上下文引擎旨在更进一步，通过构建软件环境的结构化表示来实现。它分析代码库、服务、依赖项、API 和架构关系，并将它们组织成一个描述系统实际工作方式的模型。

这使得 AI 系统能够推理组件之间的关系，而不仅仅是检索文本片段。对于复杂的企业环境，这种区别变得非常重要。

AI 编码工具正从自动补全建议演变为能够执行多步骤工作流的自主智能体。您认为在未来五年内，人类开发者和智能体系统之间的平衡将如何变化？

AI 智能体将越来越多地承担常规的开发任务。它们已经能够端到端地实现功能，包括测试和文档编写。每个开发者都将成为 AI 开发者的团队负责人。主要的挑战将是如何向这个团队传达需求，并验证生成的工件是否符合概述的要求。

然而，软件开发从根本上说是关于问题解决和设计的。人类开发者将继续定义架构、做出权衡并指导系统的整体方向。

将改变的是开发者工作的抽象层次。开发者将越来越多地编排更高级别的工作流，并与执行这些工作流部分的 AI 系统协作，而不是专注于代码本身。

换句话说，随着 AI 处理更多的机械性工作，开发者的角色将变得更加具有战略性。

Tabnine 曾指出，在某些环境中，企业用户可以看到 AI 生成代码的接受率达到 80% 左右。组织应该使用哪些指标来确定 AI 编码工具是否真正提高了开发者的生产力，而不仅仅是生成了更多代码？

关键问题不在于 AI 生成了多少代码，而在于它实际完成了多少有用的工作。

组织应该跟踪几个指标。一个是首次通过接受率，它衡量 AI 生成的代码无需修改即可使用的频率。另一个是审查周期时间——即一个拉取请求在合并前需要经过多少次迭代。

组织还应该关注开发者花在返工上的时间，以及从开发到生产的变更前置时间。

如果 AI 工具真正提高了生产力，你应该看到这些指标都有所改善。开发者花在修复生成代码上的时间更少，而花在更高价值任务上的时间更多。

企业对于将专有代码暴露给外部模型仍然持谨慎态度。”可信 AI 编码”这一概念如何解决那些减缓了企业采用 AI 开发工具的治理、隐私和合规性担忧？

信任是企业采用 AI 的最重要因素之一。

信任是实现 AI 工程师的终极挑战。我们如何信任 AI 工程师能够自主行动以完成关键的软件工程任务？我们如何确保其行为符合我们对质量、安全性以及政策合规性的期望？如果 AI 工程师要成为我们工程团队中被接受的成员，它必须像我们经过严格审查和适当入职的队友一样值得信赖。

应对这一挑战依赖于两个关键支柱：

• 个性化：让 AI 工程师深入了解您的组织、代码库和最佳实践。
• 控制：实施强大的系统，确保所有代码——无论是 AI 生成的还是人工编写的——都符合您组织的质量、安全、性能和可靠性标准。

此外，可信 AI 编码意味着让组织能够控制 AI 的部署方式，并确保集中化的治理和控制。

您曾提出，组织上下文可能成为企业 AI 堆栈中的一个基础层——类似于之前计算时代的数据库或云基础设施。那种未来的架构是什么样的？

如果你观察企业技术的演进方式，我们经常会看到新的基础设施层出现。

数据库成为管理数据的基础。云平台成为大规模运行应用程序的基础。

在 AI 时代，组织将需要一种基础设施，使 AI 系统能够理解企业的内部结构——其系统、关系和操作约束。

该基础设施层将提供结构化的上下文，供多个 AI 系统使用，无论是编码助手、支持智能体还是操作自动化工具。

从这个意义上说，上下文成为企业 AI 的共享基础。

许多公司正在构建与单一基础模型紧密耦合的编码助手。而 Tabnine 则允许企业根据需求连接不同的模型。为什么模型灵活性对于企业 AI 开发工具的长期演进很重要？

AI 生态系统正在快速发展。新模型频繁发布，不同的模型通常在不同领域各有所长。

企业不应该在模型格局每次变化时都重新设计其开发工作流。通过允许组织选择并在模型之间切换，我们提供了灵活性，有助于使其 AI 战略面向未来。

模型灵活性还允许组织在性能、成本、隐私要求和部署约束之间取得平衡。

从长远来看，企业很可能在多种模型并存的环境中运营，开发平台的设计应该考虑到这一现实。

对于今天正在评估 AI 开发平台的 CTO 和工程领导者来说，组织在部署 AI 编码工具时最常犯的错误是什么？如何避免这些错误？

一个常见的错误是只关注模型能力。更大的模型无疑是一个关键组成部分，但在真实环境中的可靠性取决于 AI 对其运行系统的理解程度。

另一个错误是在部署 AI 工具时没有考虑治理和安全要求。企业需要围绕代码访问方式、模型部署方式以及输出验证方式制定明确的政策。

最后，组织有时期望 AI 能立即带来生产力提升，却没有调整工作流程或提供足够的上下文。成功的部署通常涉及将 AI 集成到现有的开发流程中，并将其与组织的代码和架构连接起来。

当这些要素结合在一起时，AI 才能成为软件开发的强大加速器，而不仅仅是另一个工具。

感谢您精彩的采访，希望了解更多信息的读者请访问 Tabnine。