GitHub 的 Copilot AI 能否让开发人员重新获得乐趣？

GitHub 研究人员比较了开发人员使用 Copilot 的 AI 辅助编写代码的速度与依赖标准开发人员实践的团队。

为了衡量 AI 辅助开发人员的工作效率，GitHub 的研究人员最近进行了一项实验，比较了使用其 Copilot 代码完成工具的一组与仅依赖人类能力的一组的编码速度。 

GitHub Copilot 是一项 AI 结对编程服务，于今年早些时候公开推出，每位用户每月 10 美元或每位用户每年 100 美元。自推出以来，研究人员一直很想知道这些 AI 工具是否真的会转化为提高开发人员的工作效率。问题是，要确定正确的指标来衡量性能变化并不容易。 

Copilot 用作代码编辑器的扩展，例如 Microsoft 的 VS Code。它以多种编程语言生成代码建议，用户可以接受、拒绝或编辑这些建议。这些建议由 OpenAI 的 Codex 提供，这是一个将自然语言转换为代码的系统， 基于 OpenAI 的 GPT-3 语言模型。 

请参阅：什么是编码，它的用途是什么？初学者指南

在研究了 AI 代码建议对 10,000 多名开发人员生产力的影响后，Google Research 和 Google Brain 团队在 7 月得出结论， 关于相对性能速度的争论仍然是一个“悬而未决的问题”。尽管得出结论，传统的基于规则的语义引擎与大型语言模型（如 Codex/Copilot）的组合“可用于显著提高开发人员的工作效率，更好地完成代码”。 

但是，您如何衡量生产力呢？今年早些时候，其他研究人员使用 24 名开发人员的小样本发现，Copilot 不一定能提高任务完成时间或成功率。但是，它发现 Copilot 确实为开发人员节省了在线搜索代码片段以解决特定问题的工作量。这是一个重要指标，表明当开发人员跳出编辑器来解决问题时，像 Copilot 这样的 AI 工具可以减少多少上下文切换。    

GitHub 还对 2,600 多名开发人员进行了调查，询问了诸如“人们是否觉得 GitHub Copilot 提高了他们的工作效率？”其研究人员还受益于对大规模遥测数据的独特访问，并于 6 月发布了这项研究。除其他外，研究人员发现，60% 到 75% 的用户在使用 Copilot 时对自己的工作感到更满意，在编码时感到不那么沮丧，并且能够专注于更令人满意的工作。

“在我们的研究中，我们发现 GitHub Copilot 支持更快的完成时间，节省开发人员的精力，帮助他们专注于更令人满意的工作，并最终在他们所做的编码中找到更多乐趣，”GitHub 说。

GitHub 研究员 Eirini Kalliamvakou 博士解释了这种方法：“我们进行了多轮研究，包括定性（感知）和定量（观察）数据，以组合全貌。我们想验证：（a） 用户的实际体验是否证实了我们从遥测中推断出的内容？（b） 我们的定性反馈是否适用于我们的庞大用户群？

参与原始研究的 Kalliamvakou 现在在此基础上进行了一项涉及 95 名开发人员的实验，该实验侧重于使用 Copilot 和不使用 Copilot 的编码速度问题。

这项研究发现，使用 Copilot 的小组（45 名开发人员）平均在 1 小时 11 分钟内完成了任务。未使用 Copilot 的小组（50 名开发人员）平均在 2 小时 41 分钟内完成。因此，拥有 Copilot 的组比没有 Copilot 的组快 55%。

Kalliamvakou 还发现，有 Copilot 的组完成任务的比例更高——Copilot 组有 78% 的人完成任务，而没有 Copilot 的组有 70%。

该研究本质上是有限的，因为它只比较了开发人员在 JavaScript 中编码 Web 服务器时的速度，而没有比较涉及其他语言（如 Python 或 Java）的其他任务。此外，它没有评估代码的质量。 

而且该实验没有关注有助于生产力的因素，例如上下文切换。然而，GitHub 的早期研究发现，73% 的开发人员报告说 Copilot 帮助他们保持了流程。 

在一封电子邮件中，Kalliamvakou 向 ZDNET 解释了这个数字在上下文切换和开发人员生产力方面的意义。 

“报告'保持流畅'当然意味着更少的上下文切换，而且我们有额外的证据。77% 的受访者表示，在使用 GitHub Copilot 时，他们花在搜索上的时间更少，“她写道。

“该声明为开发人员衡量了已知的上下文切换，例如查找文档，或访问 Stack Overflow 等问答网站以查找答案或提出问题。借助 GitHub Copilot 将信息引入编辑器，开发人员无需经常退出 IDE，“她解释说。 

但是，仅使用上下文切换来衡量 AI 代码建议的工作效率提高并不能显示全貌。还有 “好” 和 “坏” 上下文切换，这使得很难衡量上下文切换的影响。 

请参阅：数据科学家与数据工程师：对这些职位的需求如何变化

Kalliamvakou 解释说，在典型的任务中，开发人员会在不同的活动、工具和信息源之间频繁切换。 

她指出，2014 年发表的一项研究发现，开发人员在切换之前平均花费 1.6 分钟在一项活动上，或者平均每小时切换 47 次。 

“这只是因为他们的工作性质和他们使用的众多工具，所以这被认为是 ”好的“ 上下文切换。相比之下，由于延迟或中断，存在“糟糕”的上下文切换，“她说。

“我们在早期的研究中发现，这会严重损害生产力以及开发人员自身的进步感。上下文切换很难衡量，因为我们没有一种很好的方法来自动区分“好”和“坏”实例，或者当切换是完成任务的一部分时，而不是何时导致开发人员的流程和生产力中断。然而，有一些方法可以通过我们在研究中使用的自我报告和观察来衡量上下文切换。 

至于 Copilot 在其他语言中的表现，Kalliamvakou 表示她有兴趣在未来进行实验。

“这当然是一个有趣的实验。这些对照实验非常耗时，因为我们试图让它们变得更大或更全面，但我想在未来探索其他语言的测试'，“她说。 

Kalliamvakou 在一篇博文中发布了 GitHub 大规模调查的其他主要发现，详细介绍了它寻求寻找最合适的指标来衡量开发人员的生产力。