如何运行生成式 AI 开发人员工具实验
快速阅读: 据《新堆栈》称，Devexperts通过实验评估GitHub Copilot和Cursor AI等生成式AI工具对开发效率的影响，发现Copilot在提高吞吐量方面表现一般，而Cursor在新环境开发中表现更佳。公司允许开发者自主选择工具，并持续收集反馈以优化开发体验。
如何运行生成式AI开发者工具实验
2025年4月27日 上午7:00
由 詹妮弗·里金斯
**照片来源：伊莫·韦格曼**
**Unsplash**
编辑注：詹妮弗·里金斯代表DX撰写了这篇文章。
作为一家专注于经纪解决方案的软件开发公司，Devexperts必须在创新速度与高度监管行业的谨慎需求之间取得平衡。这包括考虑像生成式AI（GenAI）这样的热门技术工具。在过去两年中，Devexperts一直在评估AI工具以提高开发人员生产力，特别是代码生成器。作为工程师，团队使用科学方法进行高度可测量的实验。
首先，他们对GitHub的Copilot进行了测试，结果有好有坏。然后他们假设并测试了Cursor AI代码编辑器，以此验证生成式AI开发者工具的潜力。现在，他们为开发人员提供了生成式AI编码助手的选择。Devexperts在这里分享了支撑其GenAI实验的开发人员指标，以便您可以与您的团队一起测试生成式AI。
**你能像GitHub开发人员一样表现吗？**
2022年9月，GitHub发表了一篇文章，称其工程师使用Copilot完成任务的速度提高了55%。这启发了Devexperts去测试Copilot，看看他们的开发人员是否也能取得类似的结果。
Devexperts从2024年8月1日至11月1日进行了一项现场实验，涉及五名软件工程师。随后他们又进行了回顾性分析，增加了另外50名参与者。两者的实验结果都以GitHub的55%增长为基准，时间指标反映了((100%/55%)-1)*100% ≈ 120%的预期吞吐量增长。
总体而言，公司希望观察到以下三个趋势：
– 工程师明显提高编码速度。
– 工程师明显增加完成的任务数量。
– 工程师保持相同的工作质量。
Devexperts团队也已经阅读了其他组织的足够多的实验报告，因此预计解决方案规模和返工需求显著增加的风险确实存在，所以他们也希望密切关注这一点。
实验和事后分析都试图通过以下指标衡量开发人员体验的各个方面：
– **个人周期时间**：从首次提交编写到拉取请求（PR）合并的时间。
– **打开时间**：拉取请求中最早提交时间和PR打开之间的时间。
– **合并时间**：拉取请求打开到合并之间的时间。
– **讨论周期**：拉取请求上人们之间的对话来回次数。
– **拉取请求大小**：添加、更改或删除的代码行数。
– **PR吞吐量**：在特定时间段内合并到主代码库的拉取请求数量。
– **创新率**：编写全新代码的代码变更百分比。
– **维护率**：更新超过三周旧代码的变更百分比。
– **返工**：过去三周内更新的代码变更百分比。
根据GitHub的标准，Devexperts发现，在其五人工程师试点中，只有九个期望中的三个——即55%的改进——得到了实现。该公司确实看到了讨论周期减少了69%，PR吞吐量增加了176%，超过了这些期望。
还有其他积极的变化，包括周期时间和合并时间的减少，但改善幅度不如GitHub工程师所经历的那样大。
创新率下降了14%。这意味着在三个月的试验期间，开发人员花在解决独特问题上的时间减少了。
最后一个指标，返工，是生成式AI的一个重要考虑因素，因为67%的开发人员发现他们在调试AI生成的代码上花费了更多时间。Devexperts经历了返工增加了200%，维护增加了30%。另一方面，尽管大多数组织在看到代码生成器带来的复杂性和代码行数增加的同时，这五名工程师却意外地减少了15%的代码行数。
“我们可以得出结论，在现场实验中，GitHub Copilot并没有达到我们阅读其文章后预期的结果，”负责该实验的软件工程过程架构师德国·特贝耶夫总结道。
他认为结果足够有说服力，相信如果正确的过程到位，速度是可以实现的：“PR吞吐量显著增长的事实告诉我们，如果任务流程得到有效处理，就可以实现期望的速度提升。”
**不同的开发人员，不同的结果？**
第一次试点的结果呼吁进一步探索Copilot，并扩大样本受众。
为了另外50名工程师，Devexperts在采用GitHub Copilot之前和之后的三个月内重新计算并检查了相同的指标。现场实验和回顾性分析的结果非常不同。
“使用GitHub Copilot，我们的工作量减少了20%，任务完成速度快了45%，并且保持了相同的质量水平，”特贝耶夫说。“最显著的改进是在审查阶段。”
对于GitHub来说，这个更大的群体保持不变但未显著提升其创新水平，同时减少了返工。最重要的是，这个团队经历了显著的吞吐量下降。
在回顾性分析中，这些工程师完成的工作较少，但速度更快。然而，在现场实验中，他们没有看到速度的提升，但却观察到了生产力的提升。
由于他们发现定量结果与预期不符，特贝耶夫预测回顾性分析和设计可能存在一些缺陷，因此需要更多的实验。“在Devexperts，我们无法充分隔离开发过程或收集足够强大的工程师队伍来提供稳定的结果。”
总体而言，事情趋势向好，大多数开发人员感知到的生产力提升不是可以忽视的问题。这可能是成长过程中遇到的问题，或者需要审查公司的流程和工作流。
**开发人员的定性体验**
数字很重要，但仅到一定程度。定性数据，包括开发人员的主观感受，同样重要。通常，对生产力的感知可能会影响实际表现。
Devexperts使用DX工程智能平台每季度运行一次开发人员生产力调查，称为快照。其中包括询问：平均而言，多亏了GitHub Copilot，你每周节省了多少时间？
– 每周2小时以上。
– 每周1-2小时。
– 每周2小时以上。
– 每周31-60分钟。
– 每周1-30分钟。
– 每周31-60分钟。
– 没有时间节省。
只有17%的开发人员表示他们认为Copilot帮助他们每周至少节省一个小时，而40%的人表示使用代码生成器没有节省任何时间，这远低于行业普遍水平。
开发人员还可以分享具体情境下的个人经验，这取决于具体情况。Copilot似乎更适合完成新功能的基本代码行，而在处理现有代码库时效果较差。
正如高级软件工程师亚历山大所说：“它非常适合一些简单但繁琐的任务，比如生成一些测试数据、对象、JSON等。有时它确实擅长生成一些单元测试，但这里的有效性严重受限。”
尽管Copilot减轻了一些他的负担，但他仍然不相信它能应对常规编码，他将其称为“不太适用”的典型Kotlin-Java后端开发堆栈。
几位开发人员还抱怨流行的AI编码助手在修复错误方面完全没有帮助，因为它无法处理更大代码库的上下文。随着在更复杂的代码库中隔离部分的能力变得越来越困难，Devexperts研发主管德米特里·德宾尼夫表示，LLM理解代码上下文以提供准确建议的能力将变得越来越关键。
“Copilot让编写新功能变得更容易，有时还能方便地完成句子。它对处理基本类和模型表现良好，但在错误修复或提出建议方面帮助不多，而这正是我在项目中的主要工作内容，”软件开发人员亚历山大回应道。“在我看来，像ChatGPT和Claude这样的其他解决方案迄今为止表现得更好。Copilot绝不是一个变革者。”
一名觉得Copilot最有用的前端开发者回答说，如果去掉它，他会很怀念，并且遗憾的是Android Studio里没有集成它。
在下一轮实验中，从2024年10月30日到2025年1月30日，之前使用过Copilot的Devexperts的11名开发者开始将Cursor的代码补全器融入到他们的工作中。
这个Cursor小组的测量最初是基于从初次提交到合并拉取请求所用的时间这一指标。然而，他们发现这是一个不可靠的真实来源，因为它波动较大且范围有限，因为它只“部分”捕捉了完成任务所需的时间。
“在实际环境中进行实验时，很难仅隔离一个因素——比如Copilot或Cursor的使用。不同的工作量、假期安排、实验周期短、不同代码库等因素既增加了实验设计的难度，也显得尤为重要，”Devexperts研发主管德米特里·德尔贝涅夫说道。“此外，实验的短暂持续时间——三个月——使得难以观察到有意义的趋势。”
定量结果显示了一些亮点。与Copilot相反，使用Cursor时，他们在错误修复方面提高了5%-10%。但再次强调，最大的进步是在全新开发环境中提升了80%，效果显著——通常需要三到四天的任务现在缩短到了一天。
但由于定量数据不够直观，德米特里·德尔贝涅夫表示，“我们更多依赖开发者的主观反馈而不是纯粹的定量测量来分析结果。”
他在LinkedIn的一篇文章中指出，客观测量在软件开发中仍然存在许多局限性，甚至可能干扰目标的实现并产生误导性的激励机制。
Devexperts的定性反馈集中在三个问题上：
– 你会继续使用Cursor吗？
– 你会继续使用Copilot吗？如果是的话，是单独使用还是与Cursor一起使用？或者都不使用？
– 任何自由评论？
即使考虑到这段时期较短，根据DX提供的更多定性数据，整体定性结果更偏向于Cursor：
– 11名开发者中有8名在实验结束后选择继续使用Cursor，而两名开发者表示不会再使用Cursor。
– 四名受访者选择继续使用Copilot，无论是否有Cursor，而七名开发者放弃Copilot改用Cursor。
Cursor的最大缺点是，作为VSCode集成开发环境的分支，它需要更换成另一种集成开发环境。德米特里·德尔贝涅夫解释说，这对大部分前端开发者来说是可以接受的，但后端开发者更倾向于使用其他集成开发环境。
这也启发企业架构师维克多·伊萨耶夫在没有任何指导的情况下运行了一个Cursor代理AI代码助手的概念验证，让开发者自行试验。它再次在重复性工作中表现出色，但在更复杂的人类问题解决工作中表现较差。
“我的看法是，它能自动化80%花费20%时间的工作，”伊萨耶夫说。“它擅长那些标准、定义明确的事情，需要大量的样板代码或制作已知如何制作的东西，这极大地提高了效率。”
但与Copilot类似，随着任务和代码越来越复杂，他发现它或多或少变成了时间消耗。他说，这同样适用于包括“从零开始构建项目、增加额外功能、重构代码、创建测试以及引入认证和授权等架构层”的任务。
这些实验的关键点在于，它们都没有涉及对Devexperts或其客户的知识产权进行训练。德米特里·德尔贝涅夫表示：“我认为，在恰当、安全且可靠的方式下组织与代码库和文档相关的上下文工作是LLM应用时实现合理生产力提升的最大难题。”
与此同时，考虑到所有这些结果——并且考虑到整个目标是改善开发者体验——Devexperts如今允许开发者自主选择AI开发工具。它将购买Copilot或Cursor的高级许可，并持续收集开发者的反馈意见。
**趋势故事**
YOUTUBE.COM/THENEWSTACK
技术发展迅速，不要错过任何一集。订阅我们的YouTube频道以流媒体播放我们所有的播客、采访、演示等。
**订阅**
组
创建于草图。
詹妮弗·里金斯是一位讲述科技文化方面的讲故事者、记者、作家，同时也是活动和播客主持人，帮助分享文化和技术碰撞的故事，并翻译我们正在构建的技术的影响。她已经……
**了解更多关于詹妮弗·里金斯的信息**
**分享这个故事**
(以上内容均由Ai生成)
