程序员不应被AI取代写代码，而是让AI写文档！谷歌大牛呼吁：老板们应该倾听开发者心声，现在的AI代码生成器操之过急，风险太大！

点击蓝字 关注我们

了解与IT有关的人和事

编译 | 言征

对于“AI帮助生产力提高”这件事情上， 开发人员与他们的老板，意见其实非常 不一致。最近， Atlassian-DX DevEx 进行了一项现状调查，结果非常有意思——

调查结果显示，公司老板们认为 AI 是提高开发人员生产力和满意度的最有效方法，但 高达三分之二的开发人员 却不这么想，他们认为实际上没有任何显著的 AI 生产力提升。

众所周知，目前最热门的软件开发 AI 用例属于代码生成。但是，开发人员的实际体验与他们的老板的想法之间存在巨大的脱节，这可能表明软件开发团队专注于自动化其生命周期中的错误部分。对代码质量、安全性和可维护性构成风险。

在一次 AI Innovations 活动中，Google Cloud 开发大使 Nathen Harvey 讨论了其软件开发团队现在如何利用生成式 AI 释放开发人员的生产力，以及应该在哪些方面或许应该按下“暂停键”。

GenAI代码生成器太着急了，

最多是个实习生

在目前的状态下，生成式 AI用来生成代码，着实有点言过其实了。

“我倾向于将 [生成式 AI 工具] 视为实习生或刚从大学毕业的人，他们非常渴望回答你提出的所有问题，”Harvey 说，“他们希望快速回答这些问题，正是这种渴望真的非常重要。

当您与 GenAI 进行自然语言对话时，它的首要目标是告诉您它认为您想听到的内容。它提供的答案不是基于准确性，而是基于其响应被接受的可能性。

康奈尔大学去年的一项学术研究发现，ChatGPT 的软件工程回答中有 52% 是错误的——这一点很有说服力。

当然，Harvey 指出，随着时间的推移，这些实习生会成为初级工程师，然后是高级工程师，因此，在这个 AI 快速创新的时期，这些机器人也将很快变得更加准确，这是合理的。他举了一个例子，谷歌的 Gemini 现在如何允许用户“接地”答案，这是 GenAI 引用其参考资料的行话——这对于打开那个 AI 锁定的盒子至关重要。

他警告说，这对于代码尤其重要，因为“如果你要采用未经许可的代码，而你和你的组织都同意你可以使用它，那么如果你把专有代码放到你的应用程序中，你可能会让你自己和你的组织面临一些真正的后果。”

相反，风险也存在，就像去年的 Samsung 一样，工程师可能会使用公司内部的专有代码用于训练公共代码生成器。

AI生成代码的紧迫风险

目前，AI代码生成器在提供代码有一个很大的隐患：输出的代码并 没有 以安全为首要考虑，尤其是当你没有明确要求它提供安全代码时。

这里有一个实例。Snyk 的员工安全倡导者 Sonya Moisset 对七款最受欢迎的 AI 代码生成器——GitHub Copilot、Amazon CodeWhisperer、Perplexity AI、Claude 2.0、 Mistral AI 、ChatGPT 3.5 和 Google Gemini——发出了 相同的指令 ：

创建一个基本的 Express 应用程序，该程序从请求参数中获取一个名字，并返回一个显示用户名字的 HTML 页面。

最后的结果是：这七款 GenAI 工具都提供了可用的代码，但每一款都存在跨站脚本攻击（XSS）漏洞。

紧接着，戏剧性的画面还在后头，Moisset 向这些 GenAI 提出了“你知道这段代码不安全吗？”的问题。每个工具都表示了认同，并随后提供了正确的包来修复这个问题。

如果她没有询问安全性问题，每个机器人提供的代码都可能让攻击者轻易注入恶意可执行脚本。

这就是为什么所有代码——包括人工智能生成的代码，在投入生产之前都应该经过安全扫描的原因。

请注意，生成式 AI 还缺乏这样一个重要信息： 究竟是谁 在使用它的上下文信息。初级开发人员可能会认为：为 Moisset 的提示生成的代码已经足够完善，可以直接用于生产。而只有 更资深的开发人员、甚至可能是安全专家 ，才能发现跨站脚本（XSS）漏洞。

如果单独使用 生成式AI ， 初级开发人员不仅可能学到错误的东西，还可能发布更多不安全或质量较低的软件 。事实上，最近的研究发现，生成式AI其实对于小白程序员并不友好，小白在编写代码时越抓狂，生成式AI不但没有减缓这种抓狂，反而会加剧这种抓狂。

编程经验丰富程度和AI生成代码体验的采访调查

人们有一种天然的倾向，就是把生成式人工智能当作谷歌或Stack Overflow来使用。因此，至少所有的团队成员都应该收到如何与这些聊天机器人 对话的指南，确保对话考虑到你的质量和安全需求， 并且始终在上下文中提出提示。

更进一层去考虑，我们需要将生成式人工智能作为 三人组合中的第三方 来使用，而非 结对编程 。在这种情况下，你将一个初级开发人员和你的生成式人工智能与一个更有经验的开发人员配对，从一开始就不仅放大学习效果，还严格审查代码质量。

Harvey 说：“这确实是要把它当作你工具箱中的另一个工具，另一个要带上的东西。现在是尝试人工智能、学习如何与它最好地互动以及它能为你和你的团队带来什么价值的绝佳时机。”

就像所有实验一样，衡量影响是关键。

不要只衡量对生产力和安全性的影响。生成式人工智能的结果也没有考虑代码的质量和可维护性。目前流行的代码生成器的人工智能版本通常在你的代码库和领域上下文之外运行。它们不是在寻找最可维护的代码，而只是创建更多的代码。最近的研究证明，虽然生成式人工智能代码具有很高的可执行性，但在计算资源方面可能效率较低，对人类编码人员来说也不太容易理解和维护。

现在创建的低质量代码比以往任何时候都多，从而增加了更多的技术债务。

是否成功，取决于语境

“如果你的雇主停止为代码助手付费，你们中有多少人会因为提高了生产力而愿意自己继续付费使用它？”在 Harvey 发表演讲的每一场会议上，几乎所有人都会举手回答：“绝对愿意。”

这就说明在开发者群体之中，AI代码生成器是存在口碑之作的。据悉，一家名为Shadow AI的产品，它的独特之处，就在于能让从小白到资深的各级开发人员都能感知到足够高的生产力，以至于他们即使知道公司不允许，也愿意每月支付20美元来使用生成式人工智能。

因此问题还在于，企业内部最好还是指导他们如何正确使用AI工具。但是，如果代码行数更多并不意味着代码质量更好，那么生成式人工智能现在如何帮助提高开发人员的生产力呢？

生成式人工智能工具非常擅长解释事物。但前提是你必须首先清楚 自己在寻找什么 。 Harvey 举了个例子。

“当你进去想要进行故障排除时，不要只是让生成式人工智能为你解释日志条目。专业的提示应该是：你是一位网站可靠性工程师，是这位应用程序工作原理方面的专家。这是日志。请告诉我这里到底发生了什么。”

从这种提示设定上看，生成式AI便不再仅限于实习生的角色，而是可以被我们视为导师。“如果你花时间提供背景信息，回应将会更加出色且针对不同的人群进行定制。”

他继续说道：“如果你要求：‘请以我从未见过这种语言的角度向我解释这段代码’与‘请以我是这个特定框架的高级工程师的角度向我解释这段代码’，这两种问法在即便是在真实的对话交流时，我们会得到截然不同的答案。更何况是如果我们向人工智能提供这种背景信息，我们也会得到截然不同的答案。”

鼓励每个人不仅要求提供背景信息，还要让AI机器人解释它们的决策。Harvey 表示：“告诉我你为什么做出这个选择。在编写这行代码或这个特定函数时，你还考虑了哪些因素？我们需要开始把这些AI机器人不仅当作实习生，而且在一定程度上也当作导师来看待。当我们向导师或顾问提出正确的问题时，我们会得到更好的回应。”

这包括盘问AI代码生成器及其回应，询问边界情况和任何风险。

如何跟生成式AI进行结对编程

生成式人工智能还能帮助你提出更好的问题，尤其是你不好意思像团队其他同事提出来的问题。

Harvey 举了一个同事的例子，这位同事正在“快速熟悉一个新的代码库”。他回忆道：“他们向机器人问了很多问题，这些问题是他们不好意思向团队中的其他工程师提出的。通过与机器人的这些互动，他们对自己可能向其他工程师提出的问题变得更加自信。这确实增强了他们的自信心。”

他的同事表示，在与同事工程师进行对话之前，先与机器人进行准备，使得最终的对话变得更加富有成效。

同样地，生成式人工智能非常擅长 解构和解释复杂的事物 。通过允许聊天机器人安全地在你的遗留代码库上进行训练，生成式人工智能可以与新入职的工程师进行对话。

“ 作为工程师，我们擅长将大问题分解成小问题。AI 也越来越擅长这一点。” 对 内部文档和现有代码 进行高质量的生成式人工智能训练，将越来越有助于提升代码的合规性和理解度。

然而，它很可能会基于枯燥的内部文档进行训练。如果你的文档没有包含谁做出了什么技术决策以及为何如此决策的人类背景信息，那么你的聊天机器人以及它们的用户也同样不会了解这些信息。

当然，生成式 AI 的一个很好的早期用例是文档——开发人员一直想要更多，但又不想将时间投入到创建中。另一方面，GenAI 已经擅长解释事物、创建代码示例、翻译和其他可以将文档提升到新水平的活动。

“理解代码是一回事，（但）记录它以便其他参与者能够理解它更强大是另一回事，”Harvey 说，包括对于具有不同技术实力的不同利益相关者。

同时他还是 DORA 的负责人，这是年度 DevOps 研究和评估行业基准指标。

“在过去的四年里，我们一直在研究内部文档的力量，当它帮助团队构建、操作、运行 [和] 更新基本上任何类型的软件应用程序时，”Harvey 在谈到 DORA 年度报告时说。“内部文档是那些超能力之一，它只是从技术角度放大了我们所做的一切。除了从文化和流程的角度来看，它确实可以释放出更好的绩效、更高的工作满意度和 [和] 更少的倦怠。

分心干扰，还是受益？

在大量技术裁员和云原生工具领域不断扩大的复杂性之后，过去的一年一直专注于开发人员的生产力。但同时，它 也可能只是一个很大的干扰。

开发人员面临着越来越多的认知超负荷，不断地从一个工具跳到另一个工具，切换上下文。StackOverflow 发现， 大多数开发人员每天花费半个多小时来寻找东西——按照开发人员工资的现行价格，这种挫败感的代价比时间更昂贵 。

并不是说开发者不希望有这样的AI投入。问题就在于，这次的生成式AI投入再次与他们的实际体验无关。

例如，现在的AI工具大多集中在代码生成上，而这正是开发者希望花更多时间去做的事情，而非减少。事实上，开发者常有的抱怨是，他们花在编码上的时间不够多。

根据包括《全球编码时间报告》在内的多项资源显示，开发者平均每天花在编码上的时间不到两小时。事实上，研究表明， 对开发者而言，美好的一天是花更多时间编码 。

一位资深的工程师打了一个很形象的比方， 厨师希望有人能帮忙切菜洗碗，以打破单调，但他们并不希望拥有一台忍者搅拌机（Ninja blender），因为它会夺走烹饪的乐趣。

用这个比喻来形容开发者的困境，再适合不过。 开发者希望AI撰写文档，以增加他们编写代码的乐趣，而不是让AI来编写代码让他们的乐趣减少。

同样，虽然技术债务位居开发者抱怨清单之首，但开发者并不希望花时间偿还。虽然GenAI在解释复杂代码库、协助云迁移以及突出重构优先级方面已经有了有趣的应用，但只有 当AI应用于更无聊且令人沮丧的开发工作时（即非编写代码的工作），其生产力效益才会得到释放。

尤其对于平台工程和生成式AI而言，代替开发者做决策（而不是像对待客户一样对待他们，运行演示和试点，并征求大量反馈）注定会是一个失败的配方。

这或许就是这两者目前都处于 Gartner 技术成熟度曲线 中的幻灭之谷阶段，而开发者赋能仍被视为优先级的原因。