当前位置:首页|资讯|生成式AI|人工智能

生成式 AI 并不是软件开发“神药”,开发者需警惕这三大幻觉

作者:InfoQ发布时间:2024-01-04

原标题:生成式 AI 并不是软件开发“神药”,开发者需警惕这三大幻觉

作者 | 张凯峰

策划 | 凌敏

软件行业苦降本增效久已。蔓延开去的开发周期,遥遥无望的上线时间,以及不断冒起的缺陷,怎么看都配不上这支精兵强将的队伍。生成式 AI 似乎带来了曙光,它的表现让人耳目一新,不少人会这么想:生成式 AI 能自动生成代码,成本低,可重复,即抛的能力像云上的资源,这段代码不合适的话扔掉好了,重新生成一段。这是不是意味着,不需要这么多精兵强将了?

生成式 AI 在回答我们的问题时,偶尔会抛出个煞有介事的答案,但如果你稍作检索,就会发现这个答案徒有其表:不是查无此言,就是一派胡言,这与人工智能的威名不符。这即所谓生成式 AI 的幻觉,hallucination——因为没有真实可靠的语料,它自作主张拼凑了一个假的回答。

大模型技术仍然在不断更新,能让人感知到幻觉程度也在逐渐降低。但在它被投入到具体的领域和使用场景时,幻觉效应仍在发生。在这篇文章里,我会分享下生成式 AI 在软件开发领域的应用,以及其带来的三个幻觉。

幻觉一:更快的速度

不同的软件工具厂商都在迭代更新自己的代码助手产品,最著名的是 GitHub 的 Copilot,他们宣称,可以加快程序员完成任务的速度达 55% 以上,那些清丽迅捷的演示视频看起来也如飞一般。

(图片来源:https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/)

但这是否意味着软件的交付进度可以加快 50%?

那些作为演示的代码是可疑的,更多程序员在自己的项目中采用 Copilot 的反馈似乎也表明,提速基本只会出现在一些常用的功能实现上。比如数组的排序,数据结构的初始化,或者是一些再简单不过的模板代码。

可重复的工具代码交由 AI 也就罢了。但对于一个开发中的软件而言,有多少类似的代码需要重复开发呢?这恐怕值得讨论。遑论多数时候,它们只需要一次成型,封装待用。还有数量相当可观的业务代码,程序员会以怎样的速度来进行?你可以把足够数量的业务代码交由 AI 来生成,但是否安全恐怕是一个更大的问题。

这里还有两个问题值得关注。

一是程序员对 AI 提供代码的选择。AI 如此容易提供多套方法的实现,程序员难免要尝试从中找出最优的选项。

这个好?还是那个好?咦,竟然有五种不同的实现。需要先读懂每一种代码的实现,再切换到下一种。这个实现的方法很优雅,但可惜单元测试失败了。换下一个。

程序员的好奇心被代码助手充分搅动。心猿意马,线性的思维习惯碎落一地。程序员遗忘的不只是开发纪律,还有时间。

二是软件自有生命周期。

很显然,轮到程序员开始编写代码,很多事情已经发生,而更多的事情还会继续发生,直到系统上线。这些事情包括但不限于:收集需求,理解需求(从需求说明到用户故事),测试,维护基础设施,以及那些层出不穷的修复工作。

我的意思是说,即便 AI 帮助程序员写得再快,这个阶段也只是软件生命周期中的一部分而已。早有相关的数据统计,程序员日常的工作,只有 30% 的时间是在编写代码,而更多的时间是在尝试理解他们要实现什么功能,以及设计和学习新技能上。

(图片来源:https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience/)

幻觉二:更少的 Bug

人编写的代码难免存在缺陷,这是软件质量的基本共识。而且似乎越有经验的程序员,越容易生产出隐晦的问题,要过了很久才会被发觉。线上问题更让人提心吊胆,但这样的担心很难避免。

AI 生成的代码,听起来也很高级,是不是会带来足够完美的结果?很可惜,答案可能会让人失望。

生成式 AI 背后的大模型,以互联网上大量的语料作为数据来源,尽管大模型技术一直在改善,但网络上已经现实存在的带有偏见的数据量十分可观。这也包括大量饱含缺陷的代码。这意味着程序员在代码助手中精挑细选的代码,也可能存有缺陷。因为这段有缺陷的代码,可能来自地球另一端的某个人,只是恰巧成为了地球这一端的选择。

要命的是,生成式 AI 有放大器(amplify)的功效。简单来说,就是如果程序员采用了存有缺陷的生成代码,Copilot 会记录这样的行为,在接下来类似的场景,会继续建议有缺陷或差不多的代码。AI 并不能读懂这样的代码,它只是被鼓励继续提供。我们可以预想最后的结果。

(prompt:A programmer is sitting at a computer desk, looking confused and frustrated. The computer screen shows a code editor with a pop-up window of GitHub Copilot suggesting incorrect code, symbolized by red error indicators and crossed-out lines in the code. The programmer is scratching their head, surrounded by crumpled paper, indicating multiple failed attempts. The scene conveys a sense of challenge and confusion due to the reliance on incorrect AI-generated code suggestions, leading to quality issues in software development. The room is cluttered, reflecting the chaotic situation. )

程序员要严守团队的开发纪律,保持统一的代码规范,因为这样别人才能读懂,更容易发现潜在问题并修复它。但代码助手提供的不同样貌的代码,似乎也提供了更多的混乱。

代码有缺陷,只是软件最后会爆出难以挽回的问题来源之一,甚至是很少的一部分。构建软件的过程,其实是知识生产和创造的过程。在软件生命周期不同阶段加入进来的各角色,共同理解和分析软件的需求,然后转换其为代码,也在团队和人员更替的过程中,传递这些表面为需求和代码实则为知识的信息。

但通常,知识会衰减,知识资产的传递会不可避免地出现差池。比如,读不懂代码,无法持续更新文档,整个团队又被替换,等等。这些才是软件不断产生 Bug 和问题的原因所在。人工智能并未能解决这些软件工程中棘手的问题,至少现在看短时间内做不到。

幻觉三:更少的人

AI 的代码助手看起来确实像见多识广的程序员。甚至有人愿意把它当成结对编程实践的伙伴。用人成本一直是 IT 团队头疼的问题,好手太贵,合适的人招不到,从头去培养熟练的程序员又需要太久时间。有了人工智能和代码助手的加持,是否意味着可以缩编快一半的人?

AI 和代码助手不仅无法提供上述的速度快和质量高保障外,也期待使用者要有足够经验的程序员才好,才能尽可发挥它该有的优势。这位有经验的程序员,需要有能力判断代码的优劣,判定对已有生产代码的影响,还需要有精心调整提示词的耐心和技巧。

在这篇文章里,作者讲述了她在使用代码助手时诸多要留意的问题,还有你能看到的她缜密的内心戏。因为代码助手带来的不确定性,可能会引起两类风险,一是影响到代码的质量,二是浪费时间。这里其实显示的是一位足够资深的程序员的自省能力。

也只有这样,代码助手才可以心安理得扮演见多识广的新手,而经验程序员充当守门员,她才是那个负责提交代码的人。这样说来,AI 改变的其实是编程体验。

(图片来源:https://martinfowler.com/articles/exploring-gen-ai.html,作者把代码助手想象成一个着急帮忙、固执、说话清楚但缺乏经验的角色,于是用 AI 画出了这个卡通形象)

AI 和代码助手在解决简单重复性问题上,效果显著。但在构建软件的过程中,有更多需要人和专业经验的场景来解决复杂的问题。比如软件系统日益增加的架构复杂度和范围,应付市场和业务侧的需求,跨角色之间的沟通和协作,还有那些更加时髦的涉及代码伦理和安全的问题。

虽然判断程序员是否足够专业和熟练,不像数数那样一目了然,但我们也可以说,引入 AI 和代码助手然后减员开发团队,能带来的成效是不确定的,目前看弊大于利。

写在最后

生成式 AI 的本质是模式转换,从文字的一种形式,转换成另一种形式,高级的代码助手的能力也不出其右。如果把涉足软件构建的 AI 代码助手,认为是解决诸多软件工程难题的妙方,我们恐怕只是把复杂的问题想得过于简单。

写到这里,我们一直在谈什么呢?

我们其实在谈的是,在软件开发上投资 AI 的成效该如何衡量。投资 AI 并不是简单如购买代码助手的 License,然后就可以坐享降本增效。不断询问“我们要如何衡量投资 AI 和代码助手的效果?”,不如询问“我们到底要衡量什么?”。从 DORA 定义的四个关键指标开始,是个明智的选择,它们是变更前置时间、部署频率、平均恢复时间 (MTTR) 和变更失败率。

以下几条基本衡量原则供参考:

  • 衡量团队效率,而不是个人绩效。
  • 衡量成效而不是产出。
  • 查看随时间推移的趋势,而不是比较不同团队的绝对值。
  • 用仪表板上的数据开启对话,而不是就此结束。
  • 衡量有用的东西,而不是容易衡量的东西。

点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!

今日好文推荐

网游新规致腾讯网易市值半天蒸发5200亿;吴泳铭“爆改”淘天:管理层全换成有功绩的年轻人;字节年收入超腾讯、逼近Meta|Q资讯

创始人 3 天狂砍 5 万行代码后,应用程序更快、更易使用了

选择哪种编程语言已经不重要了,提倡程序员下班后“多看看书”提升竞争力是误人子弟|独家专访亚马逊 CTO

一代更比一代强,AI 时代的至强如何为云服务保驾护航?


Copyright © 2024 aigcdaily.cn  北京智识时代科技有限公司  版权所有  京ICP备2023006237号-1