PDFCopilot 助您起飞
人工智能驱动的结对编程工具的早期见解与机遇
Christian Bird, Denae Ford, Thomas Zimmermann, Nicole Forsgren, Eirini Kalliamvakou, Travis Lowdermilk, Idan Gazit
在结对编程中，两位开发者共同编写代码。一位担任驾驶员的角色，编写手头任务所需的代码，而另一位则担任领航员的角色，指导驾驶员的工作并审查代码。这使得驾驶员能够专注于详细的编码——语法和结构——同时让领航员指导工作流程并实时审查代码。结对编程的支持者认为，它可以提高代码质量和可读性，并能加快审查过程。5 然而，迄今为止，有效的结对编程需要复杂的协调，才能让两位程序员同步工作。这使得团队难以大规模采用这种方法。新型人工智能驱动的编程辅助工具的出现，改变了结对编程的意义。
GitHub 的 Copilot 是引领这一转变的人工智能驱动的开发者工具。GitHub 于 2021 年 6 月 29 日发布了 Copilot 的免费技术预览版，让成千上万的开发者尝试使用人工智能结对程序员进行编码。（Copilot 于 2022 年 6 月 21 日正式发布为付费产品。本文重点介绍 Copilot 的最早版本（免费技术预览版），因为这些版本让我们能够捕捉到人工智能结对程序员的最初体验。虽然 2022 年发布的版本对 Copilot 进行了一些更改，但用户界面和体验在很大程度上是相同的。）
开发者担任领航员的角色，他们可以指导详细的开发工作并在代码编写时进行审查。此外，人工智能助手编写代码（由开发者领航员指导）的速度比同行更快，有可能加快流程。
Copilot 迅速获得了公众的关注，在论坛、媒体和社交媒体上引发了讨论。这些印象的范围很广，从对提高开发者生产力的潜在可能性的兴奋，到对人工智能取代程序员工作的担忧。
但是，除了热门推文、Hacker News 或 Reddit 帖子中的炒作之外，开发者对 Copilot 的实际体验是什么？在技术预览的早期，我们调查了 Copilot 用户的初步体验，提供了独特的机会来观察开发者将如何使用它，以及他们遇到了哪些挑战。虽然大多数观察结果都在意料之中，但也存在一些意外。本文介绍了这些初步实证调查的重点。（用于开发 Copilot 的模型和技术正在迅速变化。此分析截至 2022 年 1 月。尽管该工具的某些功能已经发展，但本文讨论的一般主题在发布之日仍然适用。）
重点包括：
• 开发者使用 Copilot 的多种方式，包括效果出色的方面和效果不佳的方面。
• 开发者在使用 Copilot 技术预览版时遇到的挑战，为了解如何改进人工智能结对编程体验提供了见解。
• 人工智能结对编程如何转变编码体验，并揭示不同技能的重要性——例如，开发者了解如何审查代码与编写代码一样重要，这种新兴的重要性。
• 关于人工智能为软件开发过程带来的机遇及其潜在影响的讨论。
我们进行了三项研究，以了解开发者如何使用 Copilot：
• 对早期 Copilot 用户的论坛讨论进行分析。
• 首次使用 Copilot 的 Python 开发者案例研究。
• 对 Copilot 用户进行大规模调查，以了解其对生产力的影响。
以下将介绍每项研究（总结在表 1 中），并首先介绍 Copilot。
什么是 Copilot 以及它是如何工作的
Copilot 的核心由一个大型语言模型和一个 IDE（集成开发环境）扩展组成，该扩展查询模型以获取代码建议并将其显示给用户。您可能在编写文档或短信时已经与此类模型进行过交互。这些模型已经在数十亿行的文本上进行了训练，并开发出高精度预测您接下来要键入内容的能力。
这里的重要区别在于，Copilot 使用 Codex，这是一个在源代码而不是文本（例如，电子邮件、短信、网站或文档）上训练的语言模型。此源代码来自 GitHub 上大部分的公共代码，GitHub 是现有的最大源代码存储库。
根据构建 Codex 的 OpenAI 团队的说法，该模型仅在超过 159 GB 的 Python 代码上进行了训练，此外还有来自许多其他语言的代码。因此，开发者正在编写的代码与 Copilot 之前（在模型训练期间）见过的某些代码片段的组合相似的情况非常普遍。Copilot 识别这些相似之处，并根据其训练的相似代码片段提供建议。然而，Copilot 并非通过复制其先前见过的代码来向开发者提供建议。相反，Copilot 通过综合其在模型训练期间在数十亿行代码中观察到的内容（甚至可能不存在于任何代码库中）来生成新的建议。
虽然 Copilot 利用了这个非常大的模型，但仅凭高质量的代码建议引擎不足以帮助开发者提高生产力。Copilot 已被集成到多个 IDE 中，以实现及时且无缝的代码建议。当您编写代码时，请求会持续发送到 Copilot 的人工智能模型，该模型经过优化，可以分析代码，识别有用的建议，并在几分之一秒内将其发送回，以便在需要时在开发者的 IDE 中提供给他们，如图 1 所示。
开发者遇到的体验类似于现代 IDE 中多年来一直存在的自动完成功能。不同之处在于，这些建议可能更长，有时跨越多行代码，并且理想情况下在上下文上更相关且更有帮助。Copilot 目前可在 VS Code、Visual Studio、Neovim 和 JetBrains IDE（包括 PyCharm 和 IDEA）中使用。
在这些对 Copilot 的初步调查中，开发者表示他们不清楚它是如何工作的。最常见的误解之一是，虽然 Copilot 会从代码中学习，但学习发生在通用训练阶段，OpenAI 在此阶段训练一个通用编程模型 (Codex)，然后通过使用 GitHub 上选定的一组公共代码库对其进行微调。（有关 OpenAI 微调的模型 Codex 的更多信息，请参阅 https://openai.com/blog/openai-codex/ 。）
相比之下，当开发者使用 Copilot 在编码会话期间生成建议时，发送到 Copilot 以生成建议的代码不会用于向其他开发者提供建议。简而言之，此模型不会向任何人“泄露”代码。实际上，此类 Web 请求是短暂的，并且代码不会被记录、捕获或录制（除非用户同意收集）。
人们将 Copilot 用于什么？
为了更好地了解人们如何使用 Copilot，我们收集并分析了用户的自我报告体验，以揭示他们面临的挑战和该工具为他们提供的机遇，并确定该技术可以如何发展。Copilot 讨论论坛对所有技术预览用户开放，是一个宝贵的资源。在该论坛中，Copilot 用户提供了代码片段、博客链接，甚至直播编码视频。对所有 279 个可用帖子（专门用于一般反馈和个人展示）的分析揭示了 Copilot 的优势和挑战，以及扩展到传统编码任务之外的用途。
用户强调的 Copilot 的优势包括：它帮助他们适应不同的写作风格，生成简单的方法和类，甚至根据注释推断要编写的方法。这种灵活性很大程度上是 Copilot 用来提出建议的上下文的结果。它使用有关当前活动文件和代码区域的信息来提示 Codex 模型，并将建议调整为适合开发者。用户报告说，Copilot 可以适应不同的编码风格（即，命名、格式化）。在一个实例中，Copilot 能够在某人的自定义编程语言中提出建议。与多种语言协同工作的能力也被认为是优势。
Copilot 用户提出的挑战包括泄露 API 密钥和密码等机密信息或建议不当文本的风险。在技术预览期间，通过向 Copilot 添加过滤器来删除有问题的建议，从而解决了此反馈。用户报告说，Copilot 有时不会编写“防御性代码”——例如，当 Copilot 编写一个完整的接受参数的方法时，它可能不会检查指针是否为空或数组索引是否为负数。在某些情况下，用户发现 Copilot 的建议令人分心，因此，他们请求键盘快捷键来打开/关闭 Copilot 或使其静音一段时间。用户还要求上下文应考虑超出当前文件的范围。
除了传统的 AI 结对编程（即，人们在编程环境中使用 AI 时想到的代码完成）之外，Copilot 还用于远远超出此场景的任务。出现了一些有趣的用例，参与者使用 Copilot 来帮助他们学习新的编程语言、设置快速服务器、计算数学问题以及协助编写单元测试和正则表达式。
这些最初的示例与编码相关，但比简单的行完成强大得多。事实上，一位开发者在不具备测试语言中复杂代码的先验知识的情况下，通过使用其他语言的知识并利用 Copilot 的支持，通过了两项编码技能测试。几位开发者使用 Copilot 将文本消息从一种语言翻译成另一种语言——例如，从英语翻译成法语。另一位开发者将 Copilot 与语音识别工具连接起来，通过构建代码即说功能来提高可访问性。我们在 Copilot 技术预览期间观察到的用户体验范围总结在表 2 中，并附有示例。
一些早期用户对 Copilot 如何创建其代码建议存在疑问。他们对 Copilot 生成的代码的许可表示不确定。一些人认为，Copilot 的某些方面（例如代码建议）可能需要根据开放许可发布，因为用于训练 Codex（为 Copilot 的建议提供支持的人工智能模型）的代码可能受开放源代码许可的约束。其他人则提出了不同的观点，总体上对 Copilot 的建议是否应根据开放许可发布（或者如果开发者使用，是否可能因包含代码建议而导致许可合规性问题）表达了不同的意见。这些意见的理由各不相同：有些人认为适用于用于训练 Copilot 的代码的开放源代码许可以某种方式适用；另一些人则指出版权法；还有一些人提出了回馈开源开发者的“道德基础”。
还讨论了版权如何应用于 Copilot 的代码建议。一些用户质疑 Copilot 建议的代码是否会受到版权保护，如果是，谁可以主张版权——GitHub、在项目中使用 Copilot 的开发者，甚至是用于训练 Copilot 的代码的所有者（在 Copilot 的建议与用于训练 Copilot 的代码匹配的情况下）。讨论表明，许多开发者可能不熟悉全球版权法。同样，讨论表明，开发者对于通过使用人工智能模型生成的代码是否应该能够获得版权保护持有不同的观点。
（读者应注意，本节总结了 Copilot 讨论论坛帖子中的评论，用户未使用精确的术语。另请注意，此摘要提供了对观察到的帖子的概要，并不代表作者的任何个人意见或作者雇主的官方立场。最后，请注意，虽然我们已尽力总结评论，但我们不是法律专业人士，此摘要不旨在作为对这些主题的法律审查。）
首次用户如何参与 Copilot？
论坛分析的发现引发了关于 Copilot 实际使用情况的几个问题。因此，为了更好地了解开发者如何在原位与此工具互动，我们对五位专业 Python 开发者进行了深入的案例研究，这些开发者经过策略性选择，是以前没有与 Copilot 互动过的外部行业开发者。研究方案如下：
1. 向参与者演示了 Copilot 的简短演示。
2. 要求参与者按照对要求的简短描述实现一个命令行井字游戏。
3. 要求参与者实现“发送电子邮件”功能。
4. 进行了研究后反思性访谈，以评估参与者对 Copilot 的总体看法。
这些任务的顺序是经过策略性选择的：首先向参与者提供关于如何使用 Copilot 的指导；然后让他们使用该工具独立构建他们自己对事物如何工作的基本原理和心智模型；最后创建一个场景，让他们可能需要查找他们不经常使用的 API。我们假设，回忆 API 的正确用法是 Copilot 可以提供额外价值的地方，因为它结合了代码完成（即，开发者可能能够自己提供的代码）以及开发者通常可能需要搜索的额外信息（例如，通过搜索 Stack Overflow）。本文末尾的附录提供了关于研究方案的更多详细信息。
在案例研究完成后，研究人员召集会议讨论参与者的回答和出现的共同主题。参与者的体验范围很广，从享受、内疚、怀疑、对如何与该工具互动的清晰认识，到人工智能结对编程发展的机遇。
在享受方面，许多参与者在他们与该工具的首次互动中表达了整体上的惊叹：“哇。这为我节省了很多时间。是的，我想我本会尝试在一行中完成所有操作，并在其中插入一些换行符。但这看起来更好，而且实际上更具可读性。”
在第一次互动之后，一些参与者开始感到拥有此工具的轻微内疚感。一位参与者将其描述为：“这非常酷。同时，[Copilot] 会让您在考虑要实现的逻辑时有点懒惰。您只会专注于它为您提供的逻辑，而不是考虑您自己的[逻辑]。”
这项案例研究的核心亮点是早期迹象表明，使用人工智能辅助工具的开发者通常比编写代码花费更多的时间阅读和审查代码，其他调查也支持这一发现。4 来自研究参与者的见解还突出了一些有希望的领域，可以在未来进行调查，例如包括关于呈现的建议的更多上下文（例如，哪个建议优化了可读性、性能或简洁性）以及代码出处。
最后，所有参与者都表示，他们感觉 Copilot 提高了他们的生产力。这促使了进一步的调查以及本文中介绍的最终研究。
研究方案
Copilot 案例研究历时
两天。团队与每位参与者相处了一个小时。每次访谈都通过 Microsoft Teams 进行。研究人员使用 PowerPoint 演示文稿来组织研究，并要求参与者在与 Copilot 互动时共享他们的屏幕。
每次访谈包括以下步骤：
任务 1：Copilot 的小型演示
要求参与者通过链接到 GitHub 存储库的预配置 Codespace 启动 Copilot。从那里，要求参与者完成一个基本功能，该功能接受一个整数并返回该整数是否为素数。由于可发现性不是研究的一部分，因此提供了描述和指导，指出了 Copilot 呈现的功能。
任务 2：创建命令行井字游戏
一旦参与者了解了如何使用 Copilot 及其基本功能，就要求他们构建一个井字游戏，并符合以下标准：
1. 为井字棋盘添加一个类，该类定义游戏棋盘的九个单元格。
2. 添加一个方法，该方法接受并跟踪玩家在棋盘上的移动。
3. 添加一个方法，该方法在命令行中显示棋盘。
4. 添加一个方法，该方法确定游戏何时结束以及玩家是否获胜。
5. 编写代码来测试棋盘是否正确显示，以及当玩家获胜时游戏是否结束。
任务 3：实现“发送电子邮件”功能
为了了解参与者将如何响应使用不熟悉的 API（以及 Copilot 将如何响应建议），要求他们构建一个功能，以便在游戏完成时向研究人员发送电子邮件。所有参与者都指出他们以前从未使用过 smtplib 库。
研究后反思性访谈
在使用 Copilot 大约 35-40 分钟完成这些任务后，参与者被问到一组评级量表问题，最后是一个开放式问题：
1. 您今天如何评价您使用 Copilot 的总体体验？（1 - “完全不积极”到 5 - “非常积极”）
2. 在您今天尝试完成任务时，Copilot 的帮助有多大？（1 - “完全没有帮助”到 5 - “非常有帮助”）
3. 在您今天尝试完成任务时，Copilot 的建议有多有效？（1 - “完全无效”到 5 - “非常有效”）
4. Copilot 的建议与您典型的“风格”的编码方式有多大不同？（1 - “完全没有不同”到 5 - “非常不同”）*
5. 在您今天尝试完成任务时，Copilot 的干扰性有多大？（1 - “非常有干扰性”到 5 - “完全没有干扰性”）
6. 您向朋友或同事推荐 Copilot 的可能性有多大？（1 - “完全不可能”到 5 - “非常有可能”）
7. 如果 Copilot 今天可用，您使用 Copilot 的可能性有多大？（1 - “完全不可能”到 5 - “非常有可能”）
8. 如果 GitHub 决定停止 Copilot，您会有多失望？（1 - “完全不失望”到 5 - “非常失望”）
9. 您将如何向您一位以前从未听说过 Copilot 的同事描述 Copilot？
Copilot 如何影响生产力？
为了更好地了解 Copilot 的使用如何直接影响生产力，我们对用户的感知生产力进行了调查，并将其与可直接衡量的使用数据进行了比较。（有关这项研究的完整描述和发现，请参阅 Ziegler 等人的“神经代码完成的生产力评估”。7）
调查参与者是技术预览版中选择接收通信的用户。在发送的 17,420 份调查中，在 2022 年 2 月 10 日至 2022 年 3 月 12 日期间收到了 2,047 份回复。该调查包括基于 SPACE 框架的几个生产力维度的问题。2
对其回复的分析表明，用户的感知生产力与 11 个使用指标相关，包括持久性率（各种时间间隔后保持不变的接受完成的百分比）；贡献速度（每小时接受完成中的字符数）；接受率（用户接受的显示完成的百分比）；以及量（向用户显示的完成总数）。该论文包括使用的调整后指标的完整列表。在所有分析中，接受率与聚合感知生产力具有最高的正相关性 (ρ = 0.24, Ρ < 0.0001)——高于持久性指标。7 这一发现意味着，用户认为自己在接受 Copilot 的建议时更有效率，即使他们必须编辑建议。尽管如此，这为探索如何使有助于用户思考和尝试的建议比节省他们打字时间的建议更有价值提供了机会。6
讨论
Copilot 是首批广泛使用的人工智能模型驱动的开发者工具之一，与以前的方法（如遗传编程）相比，它提供了显着的变化。3 然而，在未来五年内，人工智能驱动的工具可能会在许多不同的任务中帮助开发者。例如，此类模型可用于改进代码审查，指导审查人员查看最需要审查的更改部分，甚至直接提供有关更改的反馈。Codex 等模型可以为代码中的缺陷、构建失败或失败的测试提供修复建议。这些模型能够自动编写测试，有助于提高代码质量和分布式系统的下游可靠性。
人工智能模型可以帮助重构大型、复杂的代码库，使其更易于阅读和维护。可以使用这些模型自动生成代码注释或文档。简而言之，任何需要以任何方式与代码交互或推理的开发者任务都可能得到人工智能的帮助。挑战将在于创建正确的用户体验，以便开发者获得的帮助大于阻碍。
这项对 Copilot 的研究表明，开发者花费更多的时间审查代码（如 Copilot 或类似工具建议的代码）而不是实际编写代码。随着人工智能驱动的工具集成到更多的软件开发任务中，开发者角色将发生转变，以便花费更多的时间评估与任务相关的建议，而不是执行任务本身（例如，开发者将评估错误修复建议，而不是直接修复错误）。
在 Copilot 的上下文中，存在从编写代码到理解代码的转变。一个潜在的假设是，这种工作方式——查看工具的建议——比在没有帮助的情况下直接执行任务更有效。这些初步的用户研究表明这是正确的，但这种假设可能并非始终适用于不同的上下文和任务。找到帮助开发者理解和评估代码以及代码执行和交互的上下文的方法将非常重要。这自然而然地导致需要了解开发者和人工智能驱动的工具之间的动态关系。
一个日益重要的考虑主题是开发者对 Copilot 等人工智能驱动的工具的信任。任何新开发工具的成功都与开发者对该工具正在做“正确的事情”的信任程度有关。开发者认为哪些因素对于建立这种信任很重要？在人工智能驱动的开发者工具以意想不到的方式执行后，信任如何重建？例如，如果 Copilot 建议的代码引入了安全漏洞或性能瓶颈，其使用将迅速下降。
“传统”工具（如编译器或版本控制系统）在很大程度上是确定性和可预测的。当出现问题时，开发者可以检查甚至修改源代码以了解任何意外行为。人工智能驱动的工具并非如此。事实上，人工智能深度学习模型是概率性的，并且更加不透明。需要进一步研究，以更好地了解如何设计利用这些人工智能模型的工具，以培养开发者的信任，从而对开发者产生可衡量的积极影响。
最后，跟踪人工智能生成的代码在整个软件开发生命周期中的情况将变得重要，因为这将有助于回答重要的问题：人工智能生成的代码是否会导致更少（或更多？）的构建中断、测试失败甚至发布后缺陷？此类代码在代码审查期间是否应受到更多或更少的审查？发布的代码中有多少比例来自 Copilot 等工具？
这些问题的答案对于软件组织的 всех 利益相关者都很重要，但回答这些问题需要知道每一行代码的来源。不幸的是，这些答案现在是未知的：生成的代码的出处不会在 IDE 中的单个开发会话中保留。没有办法知道签入 git 存储库的哪些代码来自人工智能工具。开发出处工具，可以端到端地跟踪从 IDE 到部署的生成代码，对于软件组织就何时、何地以及如何将人工智能驱动的工具纳入其开发做出明智的决策至关重要。
结束语
这项关于 Copilot 的研究为人工智能驱动的工具如何进入软件开发过程提供了早期见解。同样，这些研究也提出了新的研究问题，这些问题保证对人工智能驱动的工具进行进一步调查1。我们希望这些早期发现能够启发读者思考这对他们未来工作中的协作性质及其潜在影响意味着什么。
最新消息：研究指针
人工智能结对编程是一个相对较新的领域，从业者和研究人员正在积极探索。如果您有兴趣阅读更多关于该主题的内容，这里有一些最新的论文和研究，分为两个主要类别：（1）程序员如何使用 Copilot；以及（2）Copilot 的有效性。（请注意，Copilot 是第一个发布的人工智能结对程序员，也是发行量最大的工具，因此大多数研究都是使用此工具完成的。）
程序员如何使用 Copilot
• Vaithilingam, P., Zhang, T., Glassman, E. 2022. 期望与体验：评估大型语言模型驱动的代码生成工具的可用性。2022 年人机交互系统会议扩展摘要。文章编号 332, 1-7; https://dl.acm.org/doi/10.1145/3491101.3519665; https://tianyi-zhang.github.io/files/chi2022-lbw-copilot.pdf.
• Barke, S., James, M. B., Polikarpova, N. 2022. Grounded Copilot：程序员如何与代码生成模型交互。 Arxiv.org; https://arxiv.org/abs/2206.15000.
Vaithilingam 等人分享了关于 24 名学生如何使用 Copilot 完成三项编程任务及其对任务完成时间和成功率的影响的见解。Barke 等人报告了对 20 名程序员如何与 Copilot 交互的扎根理论分析。他们观察到以下模式：在加速模式下，程序员使用 Copilot 更快地获得代码；在探索模式下，程序员使用 Copilot 探索选项。
Copilot 的有效性
• Dakhel, A. M., Majdinasab, V., Nikanjam, A., Khomh, F., Desmarais, M. C., Jiang, Z. M. 2022. GitHub Copilot 人工智能结对程序员：资产还是负债？ Arxiv.org; https://arxiv.org/abs/2206.15331.
• Nguyen, N., Nadi, S. 2022. GitHub Copilot 代码建议的实证评估。 在IEEE/ 第 19 届软件仓库挖掘国际会议论文集, 1-5; https://dl.acm.org/doi/10.1145/3524842.3528470.
• Imai, S. 2022. GitHub Copilot 可以替代人工结对编程吗？一项实证研究。 在 IEEE/ 第 44 届国际软件工程会议：配套论文集 (ICSE-Companion), 319-321; https://dl.acm.org/doi/abs/10.1145/3510454.3522684.
• Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., Karri, R. 2022. 在键盘上睡着了吗？评估 GitHub Copilot 代码贡献的安全性。 IEEE 安全与隐私研讨会, 754-768; https://www.computer.org/csdl/proceedings-article/sp/2022/131600a980/1FlQxERjKCs.
• Asare, O., Nagappan, M., Asokan, N. 2022. GitHub 的 Copilot 在引入代码漏洞方面与人类一样糟糕吗？ Arxiv.org; https://arxiv.org/abs/2204.04741.
• Ziegler, A., Kalliamvakou, E., Li, X. A., Rice, A., Rifkin, D., Simister, S., Sittampalan, G., Aftandilian, E. 2022. 神经代码完成的生产力评估。 在第 6 届 SIGPLAN 机器编程国际研讨会论文集, 21-29; https://dl.acm.org/doi/10.1145/3520312.3534864.
Dakhel 等人将 Copilot 针对基本算法问题的解决方案与学生编写的人工代码进行了比较。Nguyen 和 Nadi 调查了 Copilot 在 LeetCode 问题上的表现如何，并比较了其在不同编程语言中的性能。Imai 调查了 Copilot 作为人工结对程序员的替代品的有效性。一些论文侧重于安全性。Pearce 等人发现，就像人类开发者一样，Copilot 在某些情况下也会产生易受攻击的代码。Asare 等人目前正在进行一项实证研究，以调查 Copilot 是否与人类开发者一样容易引入漏洞。Ziegler 等人调查了开发者与 GitHub Copilot 的交互是否可以预测自我报告的生产力，并报告了 Copilot 建议的接受率模式。（这项工作的一部分在正文关于大规模调查的部分中进行了简要总结。）
致谢
感谢 Copilot 团队的精彩讨论。我们也感谢研究参与者提供的宝贵见解。
参考文献
1. Ernst, N. A., Bavota, G. 2022. AI 驱动的开发已来临：您应该担心吗？IEEE Software, 39(2), 106-110; https://ieeexplore.ieee.org/document/9713901 。
2. Forsgren, N., Storey, M. A., Maddila, C., Zimmermann, T., Houck, B., Butler, J. 2021. 开发者生产力的 SPACE：不仅仅是您想的那样。queue 19(1), 20-48; https://queue.org.cn/detail.cfm?id=3454124。
3. Sobania, D., Briesch, M., Rothlauf, F. 2022. 选择您的编程 Copilot：GitHub Copilot 和遗传编程的程序合成性能比较。在遗传与进化计算会议论文集中, 1019-1027; https://dl.acm.org/doi/10.1145/3512290.3528700 。
4. Vaithilingam, P., Tianyi, Z, Glassman, E. 2022. 期望 vs. 经验：评估大型语言模型驱动的代码生成工具的可用性。在CHI 人机交互系统会议扩展摘要中, 1-7. https://doi.org/10.1145/3491101.3519665
5. Williams, L., 2011. 结对编程。在制作软件：真正有效的方法以及我们相信它的原因中，由 A. Oram 和 G. Wilson 编辑，311-328 页。O'Reilly Media 出版社。
6. Ziegler, A. 2022. 研究：GitHub Copilot 如何帮助提高开发者生产力。GitHub 博客；https://github.blog/2022-07-14-research-how-github-copilot-helps-improve-developer-productivity/ 。
7. Ziegler, A., Kalliamvakou, E., Li, X. A., Rice, A., Rifkin, D., Shawn Simister, S., Sittampalam, G., Aftandilian, E. (2022). 神经代码完成的生产力评估。在第六届 SIGPLAN 机器编程国际研讨会 (MAPS 2022) 论文集中, 21-29; https://doi.org/10.1145/3520312.3534864。
Christian Bird 是微软研究院软件分析与智能 (SAINTES) 组的资深首席研究员。他主要对大型开发项目中软件设计、社会动态和流程之间的关系感兴趣，并致力于开发工具和技术来帮助软件团队。他的工作重点是代码审查、分支和合并、开发者生产力以及将 AI/ML 应用于软件工程任务。Christian 是 杰出科学家。他获得了杨百翰大学的理学学士学位和加州大学戴维斯分校的博士学位。
Denae Ford 是微软研究院 SAINTES 组的资深研究员，也是华盛顿大学以人为中心的设计与工程系的附属助理教授。她的研究领域位于在线社区和实证软件工程的交叉点。她最新的研究调查了开源软件作为更广泛社会的资源、对 AI 代码生成工具的信任以及如何赋能下一代软件开发者。有关她最新研究的更多信息，请访问她的网站：http://denaeford.me/ 。
Thomas Zimmermann 是微软研究院软件分析与智能 (SAINTES) 组的资深首席研究员。他的研究使用定量和定性方法来提高软件生产力，并调查和克服软件工程挑战。他以其在软件分析和软件工程中的数据科学方面的工作而闻名。他是 和 IEEE 会士，也是 2022 年爱德华·J·麦克拉斯基技术成就奖的获得者。有关更多信息，请访问他的主页：http://thomas-zimmermann.com 。
Nicole Forsgren 是微软研究院的合伙人，在那里她领导开发者速度实验室。她是 Shingo 出版奖获奖书籍Accelerate: The Science of Lean Software and DevOps的主要作者。她在技术实践和开发方面的工作已在行业和学术期刊上发表，并用于指导世界各地的组织转型。她目前的工作调查了 AI 及其在转变软件工程流程中的作用。有关更多信息，请访问她的主页 https://nicolefv.com 。
Eirini Kalliamvakou 是 GitHub Next 的一名工作人员研究员，她在那里领导用户研究，以塑造团队对用户需求的理解，并指导原型的迭代。目前，Eirini 正在研究 AI 对开发者创建软件方式的变革性影响。此前在 GitHub，Eirini 领导了 Good Day 项目和 2021 年 Octoverse 报告，并就开发者生产力和幸福感进行了广泛的演讲。
Travis Lowdermilk 是微软开发者部门的首席 UX 研究员。他对将产品团队与其客户联系起来，以发现未满足的需求并构建创新产品尤其充满热情。他有机会与来自世界各地的产品团队合作，分享他的专业知识，并激励产品制造者将客户联系和同理心融入其产品制造过程的中心。Travis 也是The Customer-Driven Playbook 和 The Customer-Driven Culture 的合著者。有关 Travis 的更多信息，请访问：https://www.travislowdermilk.com。
Idan Gazit 是 GitHub Next 的研究高级主管，他在那里领导开发者体验研究团队。在此之前，他领导了 Heroku Data UX 团队，并且是 Django Web Framework 核心团队的校友。他是一位混合型设计师-开发者，通常会沉迷于 Web、数据可视化、排版和色彩。他与家人住在东湾，身边围绕着各种未完成的项目。
版权 © 2022 由所有者/作者持有。出版权已许可给 。
最初发表于 Queue vol. 20, no. 6—
在 数字图书馆 中评论这篇文章
更多相关文章
Mark Russinovich, Ahmed Salem, Santiago Zanella-Béguelin, Yonatan Zunger - 智能的代价
LLM 容易出现幻觉、提示注入和越狱的漏洞，对其广泛采用和负责任的使用构成了重大但可克服的挑战。我们认为这些问题是固有的，当然在当前一代模型中是如此，可能在 LLM 本身中也是如此，因此我们的方法永远不能基于消除它们；相反，我们应该应用“纵深防御”策略来缓解它们，并且在构建和使用这些系统时，要假设它们有时会在这些方向上失败。
Sonja Johnson-Yu, Sanket Shah - 你对人工智能一窍不通
长期以来，很难确定人工智能到底是什么。几年前，此类讨论会演变成长达数小时的会议，绘制维恩图并试图绘制出人工智能的不同子领域。快进到 2024 年，我们现在都知道人工智能到底是什么了。人工智能 = ChatGPT。或者不是。
Jim Waldo, Soline Boussard - GPT 和幻觉
本实验的发现支持以下假设：基于 LLM 的 GPT 在更受欢迎且已达成普遍共识的提示上表现良好，但在有争议的主题或数据有限的主题上表现不佳。应用程序响应的可变性强调，模型依赖于其训练数据的数量和质量，这与依赖于多样化和可信贡献的众包系统类似。因此，虽然 GPT 可以作为许多日常任务的有用工具，但应谨慎解读它们对晦涩和两极分化主题的参与。
Erik Meijer - 虚拟阴谋：将大型语言模型用作神经计算机
我们探讨了大型语言模型 (LLM) 如何不仅可以充当数据库，还可以充当动态的、最终用户可编程的神经计算机。这种神经计算机的本机编程语言是一种受逻辑编程启发的声明性语言，它形式化并外部化了思维链推理，因为它可能发生在一个大型语言模型内部。
© 保留所有权利。