7.1 生成式人工智能范式转变

概述与动机

在软件工程历史的大部分时间里，编写代码足够缓慢、费力，以至于原始的产出量，写下的行数、做出的提交、发布的功能，至少与真实的努力松散地相关，也不完美地与真实的价值相关。这种相关性从来都不完美，主题 3.4 用整整一个主题的篇幅讲述了为什么活动指标即使在人工智能出现之前的世界里也具有误导性，但它足够强，以至于许多组织在”更多代码通常意味着完成了更多工作”这一隐含假设之上，建立起了自己的指标项目。生成式人工智能编程助手已经彻底打破了这个假设：一个工具现在能在几秒钟内，以此前一小部分的成本，产出大量看起来言之成理的代码，而这个数量本身，对由此产生的代码是否真的能用、是否可维护，或是否服务于任何真实目的，几乎什么都说明不了。

本主题的核心主张是，这是一次范式转变，而不是一次渐进式的工具变化。一次范式转变，改变的是你现有的仪器真正衡量的是什么，而不只是它们报告出的数值。换一台车的引擎之后，车速表依然衡量车速；本书中的几项指标，却没能这么干净利落地经受住这次转变。部署频率（主题 2.10）可能会上升，因为人工智能加速了真正有价值的工作，也可能因为人工智能让生成许多琐碎的、低价值的小变更变得轻而易举；单单这个数字，已经无法再区分这两者了，而在此之前，只要保持恰当的谨慎，它大体上是能够区分的。同样的逻辑，以更强的力度适用于原始的提交数量、代码行数和拉取请求数量，主题 3.4 早已警告过不要把这些当作个人指标，现在这个风险被放大到了团队和组织层面同样相关的程度。

对大团队而言，这场转变到来的速度，快过了大多数组织测量实践所能适应的速度，而采用速度与测量适应之间的这个缺口，正是这一部分真正风险所在之处。那些继续不加调整地报告人工智能出现之前那个时代的活动指标的企业组织，冒着庆祝一项已经悄悄不再与价值相关的指标的风险；评估人工智能工具投资的政府组织，需要在做出采购或政策决定、并把它们建立在过时的测量假设之上之前，清醒地理解究竟哪些指标依然可信、哪些已经不再可信。

核心原则

这是一次关于指标衡量什么的范式转变，而不是一次渐进式的变化。 一些现有的指标已经悄悄不再意味着它们曾经意味的东西。
产出量从来就不是一个可靠的价值代理指标，现在它已经变得真正不可靠了。 主题 3.4 的警告一直都是对的；这场转变让忽视它的代价大得多。
人工智能采用速度与测量适应速度之间的缺口，才是真正的风险所在。 组织采用这些工具的速度，快过了它们重新审视自己指标的速度。
本书中并非每一项指标都受到同等的影响。 结果指标（第5部分）对这场转变的抵御力，远强于活动和原始产出指标。
这场转变是全行业范围的、持续进行的，而不是一次性的调整。 随着工具及其采用模式的持续演变，预计还会有持续的变化。

建议

明确地审计你现有的指标集，检验其在人工智能时代的有效性

浏览你当前的仪表盘，对每一项指标直接提问：一个大量使用人工智能辅助、却没有比以前产生更多真实价值的团队，会不会在这项指标上显示出改善的读数。活动计数、提交频率，以及没有配对稳定性护栏（主题 2.10）的原始部署频率，是暴露最严重的。第5部分的结果指标，逃逸缺陷率、功能采用、业务结果，相对而言更具抵御力，因为它们衡量的是真实的结果，而不是产生这些结果的活动量。

用提高的护栏关注度，专门重新审视部署频率和交付周期

主题 2.10 早已警告过替代性操纵，把有意义的工作拆分成琐碎的部署以推高计数。生成式人工智能让这种具体的操纵模式，即使是无意的，也变得极为廉价、极为容易实现，因为人工智能辅助生成的琐碎变更现在近乎免费。专门按一个团队采用人工智能辅助开发的程度，成比例地收紧你的变更失败率护栏（主题 2.10），并比以前更密切地留意部署规模趋势。

把代码评审产能当作一个新的、关键的瓶颈来对待

如果人工智能辅助大幅增加了提交评审的代码量，那么评审阶段（主题 2.9），本已常常是交付流水线中最大的等待时间来源，会变成一个更尖锐的约束。一位被要求以与以前相同的速度评估远更大量人工智能生成代码的评审者，不可避免地要么拖慢流水线，要么降低评审深度，这正是主题 2.9 早已警告过的橡皮图章风险，现在承受着显著更大的压力。随着人工智能生成代码量的上升，用提高的关注度监控评审深度和质量护栏。

不要假定人工智能生成的代码带有与人工编写代码相同的缺陷分布

早期证据和从业者的经验表明，人工智能生成的代码可能带有与人工编写代码不同的缺陷分布：看起来言之成理、却微妙地错误的逻辑，自信地生成、却不正确的边界情况处理，或者因为看起来符合惯例、显得合理，而通过了表面评审、实际上却没有真正结合系统具体背景进行推理的代码。把这当作一个值得对照你自己的逃逸缺陷数据（主题 5.1）主动检验的假设，按源代码是否大量由人工智能生成给缺陷打标签，而不要假定你的组织已经围绕它构建质量实践的历史性缺陷率关系依然不变地成立。

明确地为这场转变更新你的指标章程和治理流程

遵循主题 1.4 的治理纪律，不要让这场转变被动地发生在你的指标项目上。明确地重新审视你的指标章程，把哪些指标需要新的护栏、哪些需要退役、哪些依然可信，当作一项刻意的治理决定，而不是一次未经审视的漂移。记录下这份推理过程，因为这正是主题 1.4 所警告的、否则可能悄悄发生、直到很久以后才被发现的那种定义和背景转变。

权衡取舍：利与弊

方案	优点	缺点
不加改变地继续报告人工智能出现之前的指标	没有干扰，报告方式熟悉	冒着庆祝一项已经悄悄不再与价值相关的指标的风险
全面的指标集审计和刻意修订	恢复可信的测量	需要真正的分析工作和组织变革管理
完全放弃活动和产出指标	直接消除了暴露最严重的风险	失去了一些真正有用的背景信号（主题 3.4 的告诫）
不做全面审计就收紧护栏	实施起来更快	可能遗漏那些暴露程度不如最明显案例那么清楚的指标

核心张力是测量的连续性与测量的有效性之间的张力。组织可以理解地更倾向于继续以熟悉的方式报告熟悉的指标，因为改变一套指标项目有真实的组织成本和干扰。但继续报告一项已经悄悄不再衡量它曾经衡量的东西的指标，比干扰更糟，那是一种积极的误导。解决这种张力的办法，是把它当作主题 1.4 所描述的那种刻意的、有文档记录的治理变革，短期内会带来干扰，却是保持组织指标诚实所必需的。

与团队讨论的问题

对我们仪表盘上的每一项指标，一个大量使用人工智能辅助、却没有产生更多真实价值的团队，会不会显示出改善的读数？ 明确地用这项检验逐一走一遍你的指标；未能通过这项检验的，就是你修订护栏或让其退役的最优先候选对象。
自从采用人工智能编程辅助以来，我们的部署频率或提交量是否上升了，我们是否检查过变更失败率或缺陷率是否相应地变动了？ 拉出真实的配对数据，而不要假定一个正面或负面的结果。
我们的代码评审产能是否跟上了人工智能辅助代码量的任何增长，还是评审深度正在增加的压力下悄悄被侵蚀？ 专门检查评审阶段的指标（主题 2.9），寻找橡皮图章风险正在加剧的迹象。
我们是否按源代码是否大量由人工智能生成来给缺陷打标签，如果是，这份数据目前显示了什么？ 如果你目前没有做这种标记，讨论开始这样做需要什么条件，因为这份数据与你历史性的质量假设是否依然成立直接相关。
我们是否已经针对这场转变，刻意地重新审视过我们的指标章程（主题 1.4），还是我们的测量实践只是不加改变地延续了下去？ 如果诚实的答案是后者，那这个缺口恰恰是本主题建议首先弥补的东西。
如果我们的组织被这场转变打了个措手不及，庆祝一项已经不再意味着我们以为它意味着的东西的指标，那会是什么样子？ 这个具体、略带不适的思想实验，有助于促使我们在这种情形真正发生之前，而不是之后，进行本主题所建议的审计。

行业视角

初创公司。 快速采用人工智能工具很常见，也常常是一项真正的竞争优势，但让采用变得有吸引力的同样那种速度，也让未经审视的指标漂移变得更有可能发生。养成把结果指标（第5部分）与你从人工智能采用中报告的任何效率收益一并检查的习惯，而不是单独报告速度改善。

小型企业。 人工智能编程辅助能够有意义地扩展一个小团队的产能，但要抵制不检查质量护栏、就把原始产出增长报告为无可争议的成功的诱惑；一个小团队吸收一个未被发现的质量问题的能力，比一个拥有更多冗余的大型组织要弱。

企业。 在这里，这种风险的规模会显著累积，因为数十个或数百个团队同时采用人工智能，可能在任何一个团队局部注意到这种模式之前，就在全组织范围内改变了指标的有效性。在组织层面进行本主题所建议的指标集审计，而不只是逐团队进行，并在中心层面明确地更新治理（主题 1.4）。

政府。 公共部门组织采用新技术往往更为谨慎，但用来评估政府技术项目的指标和基准，常常是从私营部门行业数据中得出、或与之比较的，而那些数据本身正处于同样的压力下发生变化。在用它们来设定预期或评估绩效之前，明确了解你所对标的哪些行业基准已经受到了这场转变的影响。

案例

企业。 一家金融科技公司的工程领导层注意到，在广泛采用人工智能编程助手之后的两个季度里，部署频率上升了近40%，最初在一次董事会呈现中把这直接报告为一次生产力上的胜利。一位持怀疑态度的董事会成员提出质疑，问是否检查过质量，促使一次更细致的后续分析发现，变更失败率几乎与部署频率同步上升，一旦真正审视这项配对的稳定性指标，就完全抵消了表面上的收益。该公司修订后的报告，现在在做出任何人工智能辅助生产力主张时，都明确地把部署频率和变更失败率一并呈现，避免了早先那个几乎已经公开、具有误导性的主张。

政府。 一家州政府IT部门，在为其一部分工程团队试点人工智能编程辅助时发现，每位工程师的原始代码产出大幅增加，这个数字最初在一次内部试点审查中被正面引用。一次由本书的指导被纳入该部门评估框架所促成的更细致分析，专门检查了人工智能辅助与非人工智能辅助工作的逃逸缺陷率，发现人工智能辅助群体的缺陷率略有升高，集中在人工智能工具在训练期间未曾接触过的、不寻常公民情况的边界情况处理上。这一发现并没有让试点停止，但确实导致对触及资格边界情况逻辑的人工智能辅助变更，具体、有针对性地提高了评审严谨性，解决了单靠原始产出指标永远不会揭示出来的真实风险。

商业理由：动机、投资回报与总拥有成本

主动进行这项审计的回报，是避免了因为报告一项在审视之下被发现根本没有衡量任何真实东西的指标，而遭遇公开或董事会层面的尴尬，这正是上面那个金融科技案例几乎产生的情形。一个走在这场转变前面的组织，在其利益相关方那里保持了可信度；一个被发现报告了一项空洞指标的组织，则要付出一份真实的、在很大程度上本可避免的声誉代价。

总拥有成本是审计现有指标集、收紧护栏、更新治理文档所需的分析工作，这是一笔一次性的、适度的投入，相对于继续报告一项已经悄悄不再衡量它所声称衡量的东西的指标所带来的持续风险而言。这份成本也会在一个较低的水平上重复出现，因为这场转变是持续进行的，而不是一次性的事件，随着工具和采用模式的持续演变，定期的重新审计是一套指标治理节奏中一项合理、永久的补充。

反模式与陷阱

不加改变、不加批判地继续报告人工智能出现之前那个时代的活动指标： 冒着庆祝一项已经悄悄不再与真实价值相关的指标的风险。
在没有配对稳定性护栏的情况下报告部署频率或产出量的增长： 重复了主题 2.10 的警告，只是在人工智能辅助开发下，风险显著更高。
在不检查的情况下假定人工智能生成的代码带有与人工编写代码相同的缺陷分布： 一个未经检验、可能积极错误的假设。
任由评审深度在人工智能生成代码量增加的情况下悄悄被侵蚀： 主题 2.9 的橡皮图章风险，被进一步加剧。
把这场转变当作一次性的调整、而不是一项持续的关切来对待： 工具及其采用模式在持续演变，测量实践需要跟上步伐。
在不了解所对标的行业基准本身是否受到同样压力影响的情况下与其比较： 冒着形成一种虚假的相对绩效感的风险。

成熟度模型

第一级，启动： 人工智能出现之前的指标被不加改变地报告，没有意识到人工智能采用可能已经影响了它们的有效性。
第二级，发展： 存在一些对这场转变的意识，但尚未对现有指标集进行系统性审计。
第三级，标准化： 已经进行了一次全面的指标集审计，护栏被收紧，指标在全组织范围内被记录为受影响或具有抵御力。
第四级，管理： 缺陷和质量结果被按人工智能辅助程度主动打标签、跟踪，以检验、而不是假定组织历史性的质量关系依然成立。
第五级，协奏： 组织拥有一套成熟的、持续的实践，随着人工智能工具及其采用模式的持续演变而重新审视自己的指标，并能够指出针对这场转变主动做出的具体治理决定，而不是在一个问题显现之后被动反应。

讨论思路

我们当前哪些指标，最能讨好一个大量使用人工智能辅助、却没有产生更多真实价值的团队？
自从采用人工智能以来，我们的部署频率是否上升了，变更失败率是否随之变动？
我们是否按人工智能辅助程度给质量结果打标签，那份数据会显示出什么？
我们的评审产能是否跟上了人工智能生成代码量的任何增长？
我们目前拿自己与哪个行业基准比较，它本身是否受到了这种压力的影响而发生变化？

要点回顾

生成式人工智能是若干现有指标所衡量内容的一次范式转变，而不是一次渐进式的工具变化；一些指标已经悄悄不再意味着它们曾经意味的东西。
活动和原始产出指标暴露最严重； 结果指标（第5部分）相对而言更具抵御力。
收紧护栏，尤其是变更失败率， 按人工智能辅助开发的采用程度成比例地收紧。
检验，而不是假定，人工智能生成的代码是否带有与人工编写代码不同的缺陷分布， 使用打了标签的逃逸缺陷数据。
把这当作一项持续的、而不是一次性的治理关切（主题 1.4），因为工具及其采用模式在持续演变。

参考文献与延伸阅读

Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（本主题论证在这场转变之下变得更重要、而不是更不重要的基于结果的测量基础）。
GitHub关于人工智能结对编程与开发者生产力的研究（关于人工智能辅助开发可测量效果的行业研究）。
Google Cloud的DevOps研究与评估项目，dora.dev（近年来把人工智能采用发现纳入其中的持续DevOps现状研究）。
The Tyranny of Metrics，Jerry Z. Muller著（对基于数量的指标保持怀疑的一般论证，随着产出量变得廉价而直接相关）。