编码助手是一个明显的优势生成式人工智能淘金热中的早期用例，但承诺的生产力提高即使存在，也没有达到预期目标。
许多开发人员表示人工智能编码助手可以提高他们的生产力，但最近的一项研究表明衡量他们的产出，发现没有显着的收益。根据 Uplevel（一家提供编码和协作数据见解的公司）的研究，使用 GitHub Copilot 还引入了 41% 的错误。
该研究测量了拉取请求 (PR) 周期时间，或将代码合并到存储库中，以及 PR 吞吐量、合并的拉取请求数量。它发现使用 Copilot 的开发人员没有显着的改进。
Uplevel 使用客户生成的数据，将大约 800 名开发人员使用 GitHub Copilot 在三个月内的输出与他们在三个月内的输出进行了比较
除了衡量生产力之外，Uplevel 研究还考察了开发人员倦怠的因素，结果发现 GitHub Copilot 也没有提供帮助。使用编码工具的对照组和测试组在标准时间之外花费的工作时间都减少了，但当开发人员不使用 Copilot 时，减少得更多。
Uplevels 研究是由好奇心驱动的该公司产品经理兼数据分析师马特·霍夫曼 (Matt Hoffman) 表示，随着人工智能编码助手的普及，生产力将大幅提高。8 月份发布的 GitHub 调查发现，97% 的软件工程师、开发人员和程序员表示使用 AI 编码助手。
我们看到不同的研究表明，“这对我们的生产力确实有帮助”，他说。我们也看到有些人说，你知道吗？我必须成为一名[代码]审阅者。
GitHub Copilot 的代表没有对这项研究发表评论，但指出最近的一项研究称开发人员编写代码的速度提高了 55%使用编码助手。
霍夫曼说，Uplevel 团队还进行了研究，希望看到一些生产力提升。
我们团队的假设是，我们认为 PR 周期时间会减少，霍夫曼说。我们认为他们能够编写更多代码，而且我们实际上认为缺陷率可能会下降，因为您正在使用这些新一代人工智能工具来帮助您在代码发布之前对其进行审查。
Hoffman 承认，除了 PR 周期时间和 PR 吞吐量之外，衡量开发人员生产力的方法可能还有更多，但 Uplevel 将这些指标视为开发人员产出的可靠衡量标准。
In此外，Uplevel 并不建议组织停止使用编码助手，因为这些工具正在迅速发展。
我们听说人们最终比过去更多地成为此代码的审阅者，并且您可能有一些错误的想法霍夫曼补充道，相信代码会按照您的预期运行。您只需密切关注正在生成的内容即可；它能实现您期望的功能吗？
在一线，开发团队报告的结果好坏参半。
定制软件开发公司 Gehtsoft USA 的开发人员还没有看到该公司首席执行官 Ivan Gekht 表示，基于大型语言模型 (LLM) AI 的编码助手可显着提高生产力。Gehtsoft 一直在沙盒环境中测试编码助手，但尚未将其用于客户项目。
使用大语言模型来提高您的工作效率要求大语言模型的能力与实际人类和实际用户具有竞争力他说，要知道如何最有效地利用大语言模型。大语言模型不具备批判性思维、自我意识或思考能力。
编写几行代码和成熟的软件开发之间存在差异，Gekht 补充道。他认为，编码就像写句子，而开发就像写小说。
他补充道，软件开发需要 90% 的大脑功能来理解需求、设计系统并考虑限制和限制。将所有这些知识和理解转化为实际代码是工作中更简单的部分。
与 Uplevel 研究一样，Gekht 也发现人工智能助手会在代码中引入错误。当使用不同的提示开发代码的不同部分时，人工智能生成的代码的每次新迭代最终都会变得不太一致。
理解和调试人工智能生成的代码以及故障排除变得越来越具有挑战性他说，变得如此资源密集，以至于从头开始重写代码比修复代码更容易。
云服务提供商 Innovative Solutions 的编码助理体验，有很大不同。该公司首席技术官 Travis Rehl 表示，通过使用 Claude Dev 和 GitHub Copilot 等编码助手，该公司的生产力得到了显着提高。该公司还使用自主开发的 Anthropic 集成来监控拉取请求并验证代码质量。
根据开发人员票证完成的速度、客户的周转时间，Rehl 发现开发人员的生产力提高了两到三倍可交付成果和票据质量，通过代码中的错误数量来衡量。
Rehls 团队最近使用编码助理在 24 小时内完成了一个客户项目，而同一个项目需要他们大约 30 天的时间他说，在过去。
不过，Rehl 表示，一些关于编码助理的炒作（例如建议他们将取代整个开发团队而不是简单地补充或重塑他们）是不现实的。他补充道，编码助手可用于快速分出代码或通过重新编写代码段来优化代码路径。
对编码助手的期望应该降低，因为他们不会编写所有代码，甚至不会编写所有正确的代码他说，在第一次尝试时。这是一个迭代过程，如果使用得当，开发人员可以将编码速度提高两到三倍。