分析了 1.5 亿行代码发现：AI 编程助手降低代码质量

10月前

↓推荐关注↓

摘要

2023 年是 GitHub Copilot 大放异彩的一年。在短短不到两年的时间里，这款 AI 编程助手已从一个初步的原型迅速成为众多开发者和企业中不可或缺的重要工具 [1]。它的迅猛发展开启了编写代码的新纪元。

GitHub 已经发布了数份关于 AI 如何影响软件开发的增长和影响的研究。他们的一项重要发现是，开发者在使用 Copilot 时，编码速度提升了 “55%”。面对大量由 LLM 生成的代码，我们不禁要问：这些代码在质量和可维护性上与人工编写的代码相比如何？它们是不是更像经验丰富的高级开发者的精心作品，还是更接近短期合同工的零散拼凑？

为此，GitClear 收集了从 2020 年 1 月到 2023 年 12 月之间的 153 百万行代码变更记录 [A1]。这是目前已知最大的用于分析代码质量差异的高度结构化代码变更数据集 [A2]。

我们发现了一些关于代码可维护性的令人担忧的趋势。代码变更率 —— 指在编写后不到两周就被修改或撤销的代码行所占的比例 —— 预计在 2024 年将是 2021 年 AI 出现之前的两倍。我们还发现，“新增代码” 和 “复制 / 粘贴代码” 的比例相比于 “更新的”、“删除的” 和 “移动的” 代码在上升。从这个角度来看，AI 生成的代码更像是一位频繁更换工作的合同工写的临时代码，容易违反他访问的代码库的 DRY（Donot Repeat Yourself，不重复自己）原则。。

我们以一些针对管理者如何在这种逆流中保持代码高质量的建议作为本文的总结。

GitHub: “使用 AI 编程，提升效率 55%，增加代码量 46%，为 GDP 贡献 1.5 万亿美元”

这样惊人的数据背后，GitHub 的 CEO Thomas Dohmke 不仅忙于日常的 CEO 工作，还专门抽时间撰写了关于 AI 革命的博客文章和研究论文。他在 2023 年发布于 GitHub 的作品，详细叙述了 Copilot 快速普及的激动人心的故事。

来自 Dohmke 2023 年的博客文章《AI 驱动开发者生命周期的经济影响及从 GitHub Copilot 学到的经验》

Dohmke 在博客中提出，目前已有超过 20,000 家组织在使用 GitHub Copilot for Business。这紧随其在 2023 年 2 月宣布的消息，即在 Copilot for Business 推出时，“已有超过一百万人” 在使用个人版 Copilot。GitHub 在提高 AI 质量和公开透明地分享其成果方面取得了令人赞赏的进展。

到底有多少开发者正在使用 AI 编写代码？在 GitHub 2023 年 6 月与 Wakefield Research 合作的一项独立研究中，他们指出：“在美国大型公司工作的开发者中，有 92% 使用 AI 编程工具。” 他们还强调，有 70% 的开发者认为使用 AI 带来了显著好处。不过，O’Reilly Publishing 在 2023 年 8 月的一项调查显示，67% 的受访开发者表示他们还没有使用 ChatGPT 或 Copilot。这暗示了 GitHub 在市场上仍有很大的增长潜力。

AI 生成代码存在的问题

开发者之所以采用 Copilot，是因为他们相信这款工具能够加快编码速度。GitHub 的研究发现，使用 Copilot 的开发者的满意度提高了 75%。这表明开发者普遍接受了这款产品。但是，这并不意味着那些负责维护代码的人也会感到同样满意。资深代码研究员 Adam Tornhill（著有《Your Code as a Crime Scene》）对此表示怀疑：

开发者研究人员对 AI 辅助编程的影响持担忧态度

GitHub 声称，使用 Copilot 编写代码的速度提高了 55%。但问题是，有些本不应编写的代码怎么办？正如《Clean Code: A Handbook of Agile Software Craftsmanship》的作者 Robert Martin 所说，代码的阅读时间是编写时间的十倍。更快地写出低质量代码，意味着后续阅读代码的人将面临更多困难。

这只是使用 AI 助手的开发者所面临的众多挑战之一。其他挑战包括：

频繁收到增加代码的建议，却很少有关于更新、移动或删除代码的建议。这是源于文本环境中代码编写时的界面限制。
评估代码建议可能耗费大量时间，尤其是在有多个自动建议系统相互竞争的环境中，如流行的 JetBrains IDEs（参见 [11]）。
代码建议的优化并非基于和代码维护者相同的激励机制。代码建议算法旨在提出最可能被接受的建议，而代码维护者则努力减少需要阅读的代码量（即，理解如何调整现有系统）。

这些问题可能解释了为什么初级开发者比经验丰富的开发者更倾向于接受代码建议。根据 GitHub 的研究：

GitHub 的数据显示，相比经验丰富的开发者，初级开发者使用 Copilot 的频率高出大约 20%

经验丰富的开发者更深刻地理解维护代码的长期成本。如果他们更不愿使用 AI 的代码建议，那么这是否意味着初级开发者现在正以前所未有的速度贡献更多额外的代码呢？

代码变更的分类

为了探究代码质量如何随着时间变化，我们研究了在 AI 应用日益广泛的 2023 年与之前几年，代码变更类型的不同。GitClear 将代码的变更动作分为七大类别，本研究分析了其中的六种：

新增代码。指新增加的独立代码行，不包含对现有代码的小幅修改（这类修改被标记为 “更新”）。此外，新增代码也不包括那些被添加、删除后又重新加入的代码行（这些行被标记为 “更新” 和 “变动”）。
删除代码。指被移除、提交并且在随后的至少两周内没有被重新加入的代码行。
移动代码。指被剪切并粘贴到新文件或同一文件中新的函数位置的代码行。按照定义，“移动” 的操作中，提交时代码内容不变，除了代码前的空格部分可能会有所改变。
更新代码。基于已存在的代码行，通过修改大约三个词或更少的词汇来提交的新代码行。
查找 / 替换代码。这种变更模式中，同一字符串在三个或更多位置被替换为统一的新内容。
复制 / 粘贴代码。除了编程语言的关键字（例如，end，}，[）外，相同的代码内容被提交到一个提交中的多个文件或函数。
无效操作代码。微小的代码更改，如空格或同一代码块内的行号变更。这类无效操作的代码变更没有包含在本研究中。

GitClear 对代码操作的具体实例可以在其 “Diff Delta” 文档中找到。自 2020 年起，GitClear 开始按这些操作分类 git 仓库。截至 2024 年 1 月，GitClear 已分析并分类了大约十亿行代码，这些代码来自于四年间的各种来源，包括商业客户（例如，NextGen Health, Verizon）和知名的开源项目（例如，Facebook 的 React 项目，谷歌的 Chrome 浏览器）。在这些代码中，有 1.53 亿行是有意义的非无效操作的代码变更，被用于本次研究。

随着代码变更操作的不断演进，我们也在研究所谓的 “变动代码”（Churned code）的变化趋势。它并不算是一种标准的代码操作，因为一行变动代码可能涉及到多种不同的操作，如代码的 “新增”（Added）、“删除”（Deleted）或 “更新”（Updated）。一行代码要被视作 “变动的”，它必须被创建并推送到 git 仓库中，之后在随后的两周内被回退或进行重大修改。可以将 Churn 理解为最初由作者编写、提交并推送到公司 git 仓库时，那些不完整或错误的更改。

Copilot 对代码编辑操作趋势的影响

为了深入了解 Copilot 如何影响代码质量，我们对 GitClear 观察到的各种代码行操作进行了分析，这些操作按照代码编写的年份来分类（依据 git 提交记录中的 authored_at 日期 [12]）。相关的详细数据可以在附录中找到。下面是各年份的操作百分比：

	新增	删除	更新	移动	复制 / 粘贴	查找 / 替换	代码波动
2020	39.2%	19.5%	5.2%	25.0%	8.3%	2.9%	3.3%
2021	39.5%	19.0%	5.0%	24.8%	8.4%	3.4%	3.6%
2022	41.0%	20.2%	5.2%	20.5%	9.4%	3.7%	4.0%
2023	42.3%	21.1%	5.5%	16.9%	10.5%	3.6%	5.5%
2024	43.6%	22.1%	5.8%	13.4%	11.6%	3.6%	7.1%

这些数据在图表中的展现方式是这样的：左轴显示了代码变更操作的比例（这些百分比总和为 100%）。右轴和浅蓝色线条则展示了与之相应的 “代码波动” 变化。

对于 2024 年的预测，我们利用 OpenAI 的 gpt-4-1106-preview 模型，通过对现有数据进行二次回归分析得出。附录中详细介绍了我们如何使用 OpenAI 模型进行这一分析。鉴于 GitHub 报告的 Copilot 的迅猛发展以及 AI 智能体的普遍应用，可以预见 2024 年的趋势将延续 2022 年开始显现的模式，并在 2023 年得到加速。单从 2022 年到 2023 年各种操作频率的变化来看，我们可以发现三个可能影响代码质量的警示信号：

操作	同比变化
添加	+3.1%
删除	+4.8%
更新	+5.2%
移动	-17.3%
复制 / 粘贴	+11.3%
查找 / 替换	-1.3%
代码变动率 (Churn)	+39.2%

解读代码操作变化的含义

2023 年最显著的代码操作变化发生在 “代码变动率 (Churn)”、“移动” 和 “复制 / 粘贴” 这几个方面。我们在这一节将详细探讨这些变化背后的意义。

代码变动率的显著增长

所谓的 “代码变动率 (Churn)” 是指代码被推送到仓库后，接着在两周内被撤销、移除或更新的比例。在开发者亲自编写所有代码的情况下，这种情况相对较少见 ——2023 年之前，只有 3-4% 的代码会发生这样的变动。不过，在 2022 年就已经出现了这种趋势的上升，当时代码变动率跃升至 9%。值得注意的是，2022 年是人工智能编程助手 Copilot 首次以测试版形式推出，同时也是 ChatGPT 开始被广泛使用的一年。

在 2022 至 2023 年期间，AI 辅助工具的兴起与推送到代码仓库的 “错误代码” 密切相关。根据引用资料 [1] 和 [8]，如果我们假设 Copilot 在 2021 年的普及率为 0%，2022 年为 5-10%，2023 年为 30%，那么这些因素之间的相关性极高，皮尔森相关系数高达 0.98（更多关于这一计算的细节，请参见附录中的 “代码变动率与 Copilot 的相关性” 部分）。这意味着，随着 AI 辅助工具的使用增加，代码变动率也在相应增长。

随着代码变动率的普遍增加，错误代码被部署到生产环境的风险也随之增大。如果这一趋势持续到 2024 年，那么超过 7% 的代码更改可能会在两周内被撤销，这将是 2021 年的两倍。根据这些数据，我们预计 Google DORA 的 “变更失败率” 将在今年晚些时候发布的 “2024 年 DevOps 状态报告” 中有所增加，前提是该研究包含了 2023 年使用 AI 辅助的开发者数据。

代码移动越少意味着重构和复用的减少

通常在重构现有代码系统时，我们会发现代码的移动。重构的系统，尤其是代码的移动，是实现代码复用的关键。随着产品的不断扩展，开发者往往需要将现有代码重组到新的模块和文件中，以便于新功能的复用。对于经验丰富的开发者来说，代码复用的优势非常明显 —— 与新编写的代码相比，已经在实际环境中被测试并证实稳定的代码显得更加可靠。而且，经过多人修改的代码往往包含了丰富的文档，这大大加快了新手开发者对模块的理解速度。

结合 “复制 / 粘贴” 代码的增加，可以清楚地看到，当前的 AI 助手似乎在一定程度上阻碍了代码的复用。相较于进行重构和遵循 DRY（“不要重复自己”）原则，这些助手更倾向于提供一种快捷方式，让开发者重复使用现有代码。

复制 / 粘贴的代码会导致未来的维护困难

复制 / 粘贴的代码可能是长期维护代码中最大的难题之一。当开发者重复使用非关键字的代码行时，实际上是在暗示他们没有时间去深入研究之前的实现方式。这种重复添加代码的做法，将整合实现重复功能的任务留给了未来的维护者。

大多数开发者更喜欢 “实现新功能” 而不是 “审视潜在可复用的代码”，因此复制 / 粘贴的代码往往会过期仍然被使用。尤其在经验不足的团队中，可能缺乏有权威的代码维护者来移除这些重复的代码。即便是资深开发者，也需要付出巨大的努力和决心去充分理解代码，以便将其删除。

如果没有 CTO 或工程副总裁定期安排时间来减少技术债务，那么由于高层的时间压力，新添加的复制 / 粘贴代码可能永远不会被整合到支撑长期开发速度的组件库中。

根据 GitClear 的操作，只有在单次提交中重复的代码才会被计算。因此，2023 年测量到的 11% 的复制 / 粘贴比例，可能只是 2024 年代码库中悄然增加的总复制量的一小部分。

修订代码年龄趋势分析

我们使用了一个独立的方法来评估 2023 年相比之前代码质量的变化：分析 GitClear 提供的 “代码溯源” 数据。所谓 “代码溯源”，其实就是要看代码从被写出到最终被更新或删除的时间长度。

年份	少于 2 周	少于一个月	少于一年	1-2 年
2020	65.9%	8.7%	21.8%	3.6%
2021	66.7%	9.0%	20.5%	3.8%
2022	64.7%	9.9%	21.1%	4.4%
2023	71.3%	9.3%	16.4%	3.0%
2024	74.4%	9.1%	14.1%	2.4%

根据这些数据，我们可以看到：

解读代码年龄的趋势

对 “代码溯源” 的数据分析揭示了一个有趣的现象，即在 2022 年到 2023 年间，代码的更新速度加快了。特别是，不到两周就被替换的代码比例增加了 10%。同时，超过一个月的代码更新频率在 2023 年比 2022 年下降了 24%（2023 年为 19.4%，而 2022 年为 25.5%）。

这一趋势显示，在 AI 助手普及之前，开发者更可能会选择最近编写的代码进行改进和再利用。根据 Techreport 的一项调查 [5]，早在 2020 年代初，大约 70% 的项目采用了敏捷开发方法。在敏捷方法中，每个 Sprint（通常持续 2-3 周）都会规划和执行新的功能。这与我们的数据相符，表明大约在 2020 年左右，团队在每个 Sprint 结束后，可能会聚在一起讨论最近的工作成果，以及如何在接下来的 Sprint 中再次利用这些成果。

后续研究的思考题

我们能否设定激励措施来应对 2024 年代码建议引擎中普遍的 “添加后即忘记” 的问题？

尽管我们可以训练 AI 识别代码整合的机会，关键在于它何时被触发？我们需要一个新的用户界面来复查代码的删除和更新，以及潜在的新增内容。同时，那些导致团队今天无法腾出时间来减轻技术债务的管理层压力，可能也会妨碍他们采用一种假设性的 “代码清理” 工具。但如果有代码助手的开发者对探索如何整合代码感兴趣，GitClear 愿意与他们合作，详细联系方式见附录。

另一个值得关注的问题是：额外代码对开发进度的影响速度有多大？特别是对于复制 / 粘贴的代码，库中代码行数与开发者修改这些代码的速度之间几乎肯定存在负相关关系。现在的疑问是：“累积的复制 / 粘贴技术债务何时变得不可忽视？” 了解这种减速效应发生的速率可以帮助未来的工具指导管理者何时应该减少开发新功能的时间。

最后一个探索的问题是：与 2020-2022 年相比，现在发生的复制 / 粘贴代码的总比例是多少？由于 GitClear 目前仅测量单个提交中的复制 / 粘贴代码，因此整体的复制 / 粘贴量（文件中重复的所有非关键字、非注释代码行）可能是 GitClear 当前测量值的两倍。2024 年，复制 / 粘贴代码真的会占到所有代码操作的 20-25% 吗？

GitClear 将在未来的研究中探讨这些问题，并鼓励该领域的其他研究人员共享他们的数据。如果您有兴趣与 GitClear 合作进行进一步研究，请查阅附录中的联系信息。

结论：开发者为何保持谨慎？

根据我们分析的两项关键数据，2023 年代码质量面临明显下滑，这与大语言模型 (LLMs) 特别是 AI 代码助手的广泛应用密切相关。

GitHub 与 Wakefield 研究所在 2023 年的一项调查显示，开发者已经意识到代码质量的降低。当被问及 “在没有 AI 的情况下，应以哪些指标评估你的工作？” 时，他们最关注的是 “协作和沟通”，其次是 “代码质量”。

但当问题转向 “在使用 AI 时，应以哪些指标评估你的工作？” 时，他们的关注点发生变化，“代码质量” 成为了最关注的问题，而 “生产事件数量” 上升为第三大关注点：

摘自 GitHub 关于 AI 影响的调查

尽管开发者个人可能没有足够的数据来解释为什么使用 AI 时 “代码质量” 和 “生产事件” 成为更加紧迫的问题，我们的数据提供了一个可能的解释：当开发者被大量快速且简单的短期有效建议所淹没时，他们往往会不断增加代码行数，却忽视了检查现有系统是否可以优化重用。

对于那些通过 Tab 键得到复制 / 粘贴建议的经验不足的开发者来说，解决这一问题并非易事。工程领导们需要密切关注新数据，并思考这些数据对未来产品维护的潜在影响。开发者分析工具，如 GitClear，能够帮助识别问题代码的累积速度。需要考虑的关键问题有：

代码复用比例是否在下降？
代码的移动和复制 / 粘贴量是否有所变化？
开发者发现代码复用机会的难易程度如何？

关于 GitClear 如何应对这些问题的进一步讨论见 [A3]。

AI 助手和 Copilot 如何重塑开发者的角色？无疑，随着 AI 的普及，我们进入了一个代码行数增加速度空前的时代。2024 年更值得关注的问题是：谁将负责整理这一切留下的烂摊子？

引用

探索 AI 驱动的开发者生命周期带来的经济效益：GitHub Copilot 的案例分析 [GitHub]
GitHub Copilot for Business：企业级智能编程助手 [GitHub]
软件开发领域的重大变革：AI 驱动下的开发者生命周期经济与生产力分析 [GitHub]
深入了解 Diff Delta 和 Commit 组 [GitClear]
Techreport 调查显示：超过七成团队采用敏捷开发模式 [Techreport]
代码溯源：它是什么，为何重要？[GitClear]
调查显示 AI 如何改变开发者的工作体验 [GitHub]
领略下一代开发者生产力的风采 [O’reilly]
当你的代码变成犯罪现场 [Pragmatic Programmers]
敏捷软件工艺中的代码洁净之道：实用手册及其引用 [Robert C. Martin, 作者]
[JetBrains AI：提升你的编程工具，迎接新的自由 (https://www.jetbrains.com/ai/)[JetBrains]
Git 提交指南：深入了解 git-commit[Git 文档]
如何使用 Tech Debt 浏览器优化代码 [GitClear]
“不要重复自己” 原则的智慧 [Wikipedia]
X：Adam Tornhill 分享的思考 [X/Twitter]

原文：Coding on Copilot（https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on-Copilot-2024-Developer-Research.pdf）
作者：William Harding,Matthew Kloster
译文：在 Copilot 的协助下编程白皮书 ——2023 年的数据显示了代码质量面临的挑战（https://baoyu.io/translations/llm/coding-on-copilot-2024-developer-research）
译者：宝玉

- EOF -

推荐阅读点击标题可跳转

1、改几行代码，for 循环耗时从 3.2 秒降到 0.3 秒！

2、改一行代码，数组遍历耗时从 10.3 秒降到了 0.5 秒

3、有这个迹象，公司就要凉了

4、大厂程序员提倡“防御性编程”：故意把代码写得很烂

5、雷军 30 年前的病毒论文，结语最后一句是亮点

关注「程序员的那些事」加星标，不错过圈内事

点赞和在看就是最大的支持❤️

微信扫码关注该文公众号作者