在一项衡量 AI 辅助开发人员生产力的任务中，GitHub 的研究人员最近进行了一项实验，比较了使用 Copilot 代码完成工具的团队与仅依靠人类能力的团队的编码速度。

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

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

Google Research 和 Google Brain 团队在研究了 AI 代码建议对其自身超过 10,000 名开发人员生产力的影响后，于 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 的小组（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 大规模调查的其他重要发现，详细介绍了它寻找最合适的指标来衡量开发人员生产力的过程。