Leadership in AI Assisted Engineering – Justin Reock, DX (acq. Atlassian)

• GenAI 对工程生产力的影响存在巨大的公司间差异：行业平均数据看似温和正面（变更信心 +2.6%，变更失败率 -1%），但按公司拆分后，最好的公司 +20%，最差的公司 -20%。平均数掩盖了真实的两极分化。
• 导致负面结果的三大失败模式：自上而下强制 100% 采用率（员工只是修改配置文件以合规）、不提供教育和实验时间、以及不知道该度量什么指标。
• 成功的组织做对的事：建立清晰的 AI 政策、给工程师学习时间而非只给材料、建立 system prompt 反馈环确保合规和信任、找到真正瓶颈而非仅优化代码编写。
• 关键案例：Morgan Stanley 的 DevGenAI 年节省 30 万小时处理遗留代码、Zapier 将工程师上手时间缩短到 2 周并因此加速招聘、Spotify 用 AI 将上下文直接推送到 SRE 频道显著提升 MTTR。
• AI 不是来取代工程师的——SWE-Bench 显示 AI agent 只能无人工介入完成 1/3 的任务；但善用 AI 的人可能取代不用 AI 的人。领导者的责任是帮助员工成功而非制造恐惧。

核心要点：行业平均数据呈现温和正面，但公司间差异极大——有公司多发 50% 缺陷，也有公司变更信心提升 20%。

• Google 内部数据称 AI 让员工生产力提升 10%，但 METR 研究（尽管有方法论缺陷）显示使用代码助手后生产力下降 19%。有趣的是，参与 METR 研究的每位工程师都觉得自己更高效了——存在"诱导心流"效应
• DORA 研究基于行业大样本：25% AI 采用度增加带来文档质量 +7.5%、代码质量 +3.4%——正面但温和
• DX 公司聚合数据（开发者生产力度量公司）：变更信心 +2.6%、代码可维护性正向、变更失败率 -1%（行业基准 4%，所以 -1% 不算小）
• 关键转折：按公司拆分后，同一指标的分布极端分化——变更信心从 +20% 到 -20%，变更失败率最差公司 +2%（等于多发 50% 缺陷）

"Every engineer that took part in this study felt more productive, but then the data actually bore out that they were less productive." — Justin Reock

核心要点：自上而下强制推行、缺乏教育和度量能力是最常见的失败原因；DORA 研究表明清晰政策和学习时间是最有效举措。

• 失败模式一：100% AI 采用率硬性指标——工程师只是每天更新配置文件就算"合规"，实际没有产生任何价值
• 失败模式二：只开通工具不提供教育——期待技术自动生效，不教最佳实践
• 失败模式三：不知道该度量什么——利用率是否真的能反映 GenAI 的全部影响？
• DORA 贝叶斯后验分布显示：最有效的举措是"清晰的 AI 政策"和"给予学习时间"（不只是给材料，而是给实验空间），这两项的置信度和正向效果都最高

核心要点：Google Aristotle 项目证明心理安全是高绩效团队最大预测因子；AI 时代这一结论更加适用。

• Google 2012 年 Aristotle 项目想找出高绩效团队特征，原以为是顶尖人才+经验丰富管理者+无限资源的组合，结果完全错误——最大预测因子是心理安全
• SWE-Bench 现实：AI agent 只能在无人干预下完成约 1/3 的任务，2/3 做不了——我们在增强（augmenting）而非替代（replacing）
• 领导者需要主动沟通而非等员工恐慌："我们用 AI 来增强你，给你更好的开发体验，提升业务吞吐量"
• 必须透明地设定意图，把 AI 与员工成功挂钩——"AI is not coming for your job, but somebody really good at AI might take your job"

"AI is not coming for your job, but somebody really good at AI might take your job." — Justin Reock

核心要点：两个维度（速度和质量）、三类指标（遥测/体验采样/自报告）、三阶段成熟度（利用率→影响→成本）。

• 两个杠杆：提升 PR 吞吐量（速度）但不能制造技术债（质量），否则只是把瓶颈踢到下游
• 三类指标：①遥测（API accept vs suggest 率，但工程师点 accept 后可能重写了每行代码）②体验采样（PR 表单加一栏"是否使用 AI"）③自报告/调研（DX 强调 90%+ 参与率、将开发体验视为系统问题）
• W. Edwards Deming：90-95% 的生产力产出由系统决定，不是个人——所以开发者体验是系统问题
• DX AI 度量框架（DXAI）：从 Utilization（谁在用、AI 辅助 PR 占比、agent 任务分配数）→ Impact（对速度和质量的实际影响）→ Cost（token 消耗、有人一天烧 $2000）
• 行业参考：Microsoft 的"bad developer day"指标、Dropbox 看 WAU/DAU + 变更失败率

核心要点：通过组织化的 system prompt 管理和 temperature 参数调整，建立对 AI 输出的信任。

• System prompt（也叫 cursor rules、agent markdown）是控制模型行为的核心杠杆——需要设置专人/小组作为"gatekeeper"，持续收集反馈并改进
• 案例：模型持续生成 Spring Boot 2 代码而非 Spring Boot 3——通过反馈环修正 system prompt 解决
• Temperature 参数：0（低 → 高确定性）到 1（高 → 高随机性），实测 0.001 时同一任务两次输出完全相同字符级一致，0.9 时同一任务产出完全不同方案
• 实践建议：不要用 0 或 1（会出奇怪结果），根据场景选择——需要确定性输出用低温，需要创意用高温
• 可用 Docker Model Runner、Llama、LM Studio 等工具本地实验

核心要点：DX 调研了每周省 1 小时以上的开发者，发现#1 高价值用例不是代码生成而是 stack trace analysis。

• DX 采样了大量每周节省至少 1 小时的开发者，让他们对 top-5 用例排序——据此编写了包含代码示例和 prompt 示例的指南
• 第一名是 stack trace analysis（解释性用例而非生成式用例）——这意味着 AI 的价值点可能不在人们直觉认为的地方
• 该指南已成为某些工程团队的必读材料
• 关键：不仅要给材料，还要给时间。必须给工程师实验空间，而非只发文档

核心要点：代码编写从来不是瓶颈——对约 14 万工程师数据分析显示，AI 节省的时间被上下文切换和会议大量抵消；需要用约束理论找真正瓶颈。

• Eli Goldratt 约束理论："不在瓶颈上节省的一小时毫无价值"——大多数组织的瓶颈不在写代码
• 14 万工程师数据：AI 带来的年化时间节省被上下文切换、中断、会议密集日等因素远远吞噬
• Morgan Stanley DevGenAI：扫描 COBOL、大型机、Perl 等遗留代码自动生成规格文档，工程师直接据此现代化重写——年节省 30 万小时
• Zapier：用 bot 和 agent 辅助 onboarding，2 周让新工程师上手（行业好的水平是 1 个月，中等是 90 天）；因此决定加速招聘而非裁员——"每个工程师能产出更多价值，我们应该更快招人"
• Spotify：SRE 场景检测到事件后，AI 自动将 runbook 步骤和上下文文档推送到 Slack 频道，消除了定位问题的关键几分钟，显著提升 MTTR

"An hour saved on something that isn't the bottleneck is worthless." — Eli Goldratt (引用 by Justin Reock)