HubSpot规模化AI采用的工程实践:从Copilot试点到Agentic编程

本文详细介绍了HubSpot工程团队如何从2023年夏季开始,通过策略性的试点、建立专门的AI开发体验团队、数据驱动决策以及提供定制化工具,将AI编码助手的使用率从零提升至90%以上,并最终构建了包含400多种工具的内部AI生态系统。

情境是关键:HubSpot如何规模化AI采用

本文旨在成为赋能产品、用户体验和工程团队系列文章的开篇。我们将重点讨论我们如何在与编写代码相关的背景下,处理和扩展AI的使用。

AI从根本上改变了我们在HubSpot构建软件的方式。过去两年,我们从谨慎的实验,发展到在整个工程组织中实现了AI编码工具几乎普遍的采用。 这一转变并非一蹴而就。它需要战略投资、组织承诺和学习的意愿。随着我们与其他工程领导者分享经验,我们发现许多团队在将AI采用范围从概念验证和早期采用者进一步扩大时,面临着类似的挑战。与外部团队的交流使我们相信,我们获得的经验教训可以帮助其他人更有效地走好这段旅程。

工程组织中AI编码助手的采用率 [数据已脱敏]

最初只有代码补全

我们在2023年夏季开始尝试使用GitHub Copilot。我们的联合创始人Dharmesh和Brian给予了我们所需的启动推动力。Dharmesh最近使用GitHub Copilot构建了ChatSpot,体验良好,因此他和Brian推动我们对该工具进行评估,并将我们与行业内其他看到成功案例的领导者联系起来。

我们的概念验证成功验证了该工具的潜力,几个因素促成了我们的成功:

  • 高层支持让一切变得更容易。 Dharmesh和Brian的支持极大地加速了我们的试点过程。这有助于我们的法务、安全和工程团队为达成目标形成共识并产生紧迫感。
  • 我们运行了一个足够大的试点项目: 我们的策略是让整个团队参与进来,以便他们可以共同采用和学习,这些团队拥有不同的经验水平、不同的使命,并在不同的领域工作。我们给了团队两个多月的时间来试用。
  • 我们在赋能上投入了精力。 我们组织了设置/培训课程,并创建了一个渠道,供人们提问并分享哪些方法有效或无效。
  • 我们测量一切。 我们将现有的工程速度测量方法应用于试点。这有助于我们检查自身的偏见。起初我们持怀疑态度,但看到可衡量的影响逐渐削弱了我们的怀疑。

初步结果令人鼓舞:获得了积极的定性反馈,以及在不同资历和资深的工程师中都观察到的可衡量但适度的生产力提升。我们最初的收获虽然不及当时市场上听到的一些惊人宣传,但考虑到Copilot当时每位企业用户19美元/月的成本结构,这些提升仍然意义重大。即使是适度的节省时间也证明了投资是值得的。

随着一群坚定的利益相关者看到了工具的早期价值和潜力,我们愿意保持耐心并继续投资。我们相信技术会随着时间的推移不断改进,因此我们在设置了护栏的情况下将其推广开来。随着采用规模的扩大和人们经验的增加,我们看到了越来越显著的生产力提升。

利用中央团队的力量

在HubSpot,我们长期以来一直相信中央团队创造的影响力。我们的平台团队构建基础设施、工具和护栏,使得小型自主产品团队能够在保持质量和一致性的同时快速行动。

当生成式AI出现时,我们最初依靠这些领域相关的团队(特别是管理我们GitHub设置的团队)来推动采用。但随着需求激增,待办事项呈指数级增长。我们意识到是时候创建一个专门的团队了。

我们在2024年10月创建了一个开发体验AI团队,最初的重点是:

  1. 推动编码工具的采用: 一旦我们意识到这些工具的影响,我们希望整个组织尽快加入。
  2. 增加AI工具的影响力: HubSpot有一个非常有主见的堆栈,我们希望我们生成的代码能尽可能反映这些见解。这最初从简单地分享Cursor规则文件开始,但很快演变为更复杂的工具,这些工具让代理深入了解我们的架构、库和最佳实践。(未来将有更多相关内容)
  3. 倡导与宣传: 我们希望围绕AI建立一个社区,通过收集和传播对人们有效的方法。我们创建了一个开放的论坛供人们发布关于AI的内容,并提供了启动内容以促进参与。随着采用率的增长,我们看到一个充满活力的社区逐渐兴起。
  4. 为速度调整采购流程: 我们知道我们希望尝试出现的每一种工具,但我们的采购流程是为长期谈判协议设计的,我们不能总是依靠创始人的推动来启动事情。我们希望获得按月计费的合同,并尽快开始。
  5. 建立评估能力: 我们不希望仅仅依赖定性反馈,因此我们想出了一些方法来运行试点并根据优点比较工具。我们也亲身体验到经验数据如何能够对抗先入为主的观念和怀疑。

中央基础设施团队在产品团队的日常工作的方方面面创造影响力。AI也不例外。我们最初规模非常小,只有两个拥有基础设施经验且早已高度参与AI的人。随着我们扩展到更高级的用例(其中许多将在本系列中介绍),团队逐渐成长。但创建这个团队并让这些工程师专注于此事,为我们未来的成功铺平了道路,而无需巨大的初始投资。

突破临界点

随着工程师采用这些工具,我们收集了更多数据,我们越来越确信这些工具将对我们的工程团队产生积极影响。起初,由于经验有限和成本考虑,我们保持了保守的使用规则。用户必须申请许可证并同意遵守严格的护栏。

我们提取了关于代码审查负担、周期时间、采用前后的速度比较以及生产事故率等指标。

AI采用对生产事故的影响,团队级别数据 [已脱敏] 数据持续显示出相同的结果:AI采用并未产生我们最初担心的问题。上面的散点图显示了一个例子,表明AI采用与生产事故之间没有关联。

2024年5月,我们取消了限制。然后我们主动给每个人分配了一个席位,使其尽可能容易地开始使用。采用率在一夜之间飙升至50%以上。

触及晚期多数采用者

随着采用率超过60%,增长再次放缓。在采用的后期阶段,你会遇到怀疑者,开始更好地理解当前工具的局限性,并看到更高程度的变化/风险厌恶,因此我们必须改变我们的方法:

  • 同行验证: 每当我们听说有人用AI做了有趣的事情,我们就请他们录制视频并分享出来。我们也开始自己录制每周视频,展示新功能和实际使用情况。
  • 定量证明: 我们分享了高层级数据,表明大多数人已经在成功且安全地使用这些工具。我们有意将数据保持在广泛的层面,而不是深入到精确的细节。虽然数据对于决策很重要,但我们希望人们关注明显的改进趋势,而不是陷入对精确数字的争论。
  • 提供更好的工具: 我们为多个编码助手运行了概念验证,为工程师提供更多选择,认识到不同的工具更适合不同的工作流程和偏好。
  • 定制化体验: 我们在每台机器上透明地设置了本地MCP服务器,并提供了针对我们开发环境优化的默认规则和配置。这使每位工程师从一开始就能获得针对我们特定堆栈和最佳实践的定制体验。根据我们对有效使用模式的了解,我们持续修订和改进此设置。
  • 将AI能力作为基线期望: 一旦我们达到90%的采用率,我们将AI能力作为工程师的基线期望,将其添加到职位描述和招聘期望中。到这个时候,很容易看出AI能力不仅对HubSpot是正确的方向,而且对工程师来说,在这种转型中持续成长也是必要的投资。这有助于我们在内部和外部明确承诺这项投资。

采用只是一个开始,为随之而来的一切打开了大门:利用编码代理,创建Sidekick(我们的人工智能助手,回答平台问题、创建问题、实施变更和审查PR),开发一种使用我们的设计系统快速原型化UI的方法,并构建了基础设施,使我们的代理能够在我们内部的、OpenAI的和Anthropic的MCP服务器上利用400多种工具。

下一篇:我们如何过渡到Agentic Coding(代理化编码)

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计