策划 | 凌敏
软件行业苦降本增效久已。蔓延开去的开拓周期，遥遥无望的上线韶光，以及不断冒起的毛病，怎么看都配不上这支精兵强将的军队。天生式 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） 和变更失落败率。
以下几条基本衡量原则供参考：
衡量团队效率，而不是个人绩效。衡量成效而不是产出。查看随韶光推移的趋势，而不是比较不同团队的绝对值。用仪表板上的数据开启对话，而不是就此结束。衡量有用的东西，而不是随意马虎衡量的东西。原文链接：天生式 AI 带给软件开拓的三个幻觉：速率快、质量高、人更少_天生式 AI_张凯峰_InfoQ精选文章