在软件工程圈子里，关于 AI 编程的讨论几乎都围绕一个词：速度。模型能不能写出好代码？能不能更快上线？能不能通过测试？Adam Bender 认为，这个问题问得太小了。
Adam 是 Google 首席软件工程师，已在 Google 工作近十四年。他参与了《Software Engineering at Google》一书测试章节的编辑，撰写了 Testing Overview，并自 2017 年起负责培训新任技术负责人。目前他正领导一项覆盖 Google 全代码库的大规模变更（Large-Scale Change），重构所有语言中的 TODO 注释——数百万行代码，他大部分可能永远不会亲自读。
Adam 在今年 Google I/O 演讲后接受了采访，他提出了业界许多人忽略的一个核心观点：编程是狭义的行为：一个人、一个程序。工程则是当许多人共同构建、需要让成果存活、上线、并在多年间持续扩展时发生的事情。AI 在前者上已经很快，但对后者几乎还未触及。
当代码生成速度提升 10 倍而工程能力跟不上时，加速的只是那些从未被自动化的压力：测试、review、文化，以及人类是否仍能理解整个系统。
为什么速度会掩盖风险
你的开发者生态是一个复杂适应系统（Complex Adaptive System）。这意味着，当它经历变化——比如引入 AI 代码生成——影响很难预测。由于我们的开发者生态在二十多年里有机演化，形成了深度的跨团队互联，系统某一节点的输出发生实质性变化，很可能带来许多意想不到的后果。
在与 Google 内外工程师交流后，Adam 发现一个值得关注的现象：许多人并未充分认识到开发者环境的“生态”特性。这也不难理解——过去 15 到 20 年间，我们的软件开发方法相对稳定，大多数变化都是渐进式的。
问题在于这两个事实的交汇：生态系统的复杂性，加上对系统间连接缺乏关注，共同创造了一种容易过度自信或对剧烈加速生态干扰的潜在风险视而不见的条件。
编程与工程的本质差异
Adam 强调，这一观点首先应归功于 Titus Winters、Hyrum Wright 和 Tom Manshreck——他们在《Software Engineering at Google》一书中提出了"Engineering is programming integrated over time"这个表述。
关键区别在于：编程是个人或 Agent 执行的狭义行为，结果是一个程序。但这个程序如果没有办法上线、维护、扩展，价值几乎为零。软件工程则发生在多人共同编程、并希望长期保持这种能力的场景下——而且要经济上可持续。
换句话说：我可以整天为自己写程序，但如果这些代码不需要与他人工作集成、不太可能被维护、几乎没有经济价值，我就可以跳过测试、文档、运维、发布管理等一系列活动。
目前 AI 展现了提升个人效率的能力，但在解决“当你希望持续增长、维护并可靠运营这些软件时出现的其他问题”上，还鲜有作为。原因可能在于：孤立的项目在语言层面非常结构化，对 Agent 系统来说更容易验证。而工程问题需要更微妙的权衡，成功标准不清晰，解决方案远没有那么结构化。
ℹ️ 点击查看 Adam 对《Software Engineering at Google》一书的完整评测。
为什么不能绕过文化直接复制工具
Adam 在书中和演讲中都举了这样一个例子：Google有一种名为“大规模变更”（Large-Scale Changes）的流程，允许公司任何工程师提议对整个代码库进行修改——如果获批，他们可以自行执行。
百万行代码改造背后的文化根基
大规模代码改动（LSC）往往涉及数百万行代码。作者正在推进一个跨语言代码库的 TODO 格式标准化重构项目，涉及数百万行代码的批量修改，而这些代码来自作者从未接触过的代码区域，改动将交由其他工程师评审通过。这种规模的协作在过去 15 年里完全依赖人工完成，没有任何 AI 辅助。
改造落地的文化前提
大规模代码改动要得以推行，必须满足以下文化条件：
- 全代码库访问权：改动发起人需要能够访问所有相关代码，无论是否直接负责这些模块。
- 测试体系完备：所有人都认可测试的价值，且改动发起人能可靠地运行这些测试。
- 改动价值共识：团队相信这类重构工作有价值，评审者愿意投入时间审核。
- 共同责任意识：代码库维护是所有工程师的共同责任，而非仅限于直接负责人。
- 标准化共识：对于 TODO 格式这类标准化议题，团队需要有统一的认知基础。
作者强调，即便构建出再强大的代码修改工具，如果没有正确的工程文化支撑，在代码的人类协作层面必然遭遇失败。只要软件涉及人、文化、流程和工具，它们就必然相互依赖。
AI 时代，Conway 定律还管用吗
Conway 最早发现了组织结构与系统产出之间的深层联系。这种联系往往隐形存在，因为工程师很少被要求思考组织运作方式，甚至可以长期忽视这一层面。AI 可能彻底改变这一现状。
AI 放大产出的能力，会让许多原本隐形的因素变得清晰可见。例如，在可靠的智能体编程环境下，组织的决策能力将面临巨大加速压力——以前有谁会认真关注高层的决策流程？
智能体不受人类协作局限约束
智能体有几个关键特征：不受时区影响、无需物理接近就能建立信任、且没有政治概念。这些恰恰是 Conway 定律产生的人类协作层面的根源。这意味着 Conway 定律可能是人类协作能力局限的副产品，智能体不会受其约束。智能体当然会有自己的组织原则，可能受其识别的激励机制影响，但这些原则不会反映人类的协作经验。
API 防线：从"君子协定"到硬性加固
作者指出一个关键变化：所有内部 API 在 AI 时代都相当于公开的——智能体不会尊重那些只靠"礼貌"维系的边界。那么团队该从哪里开始加固？
基础公式如下：
- 全量资产盘点：对所有内部 API（含无意暴露的）和数据存储建立清单。智能体能找到一切，且永不疲倦。
- 风险优先级公式：开发能反映组织核心关切的评估模型，按重要性排序需要加固的资产。
- 平台工程路径：为智能体和人类 alike 打造清晰的成功路径，锁死其他所有路径；若当前缺乏锁定能力，优先建设这一层，至少先阻止智能体在生产系统执行任何破坏性操作。
- 内部可观测性：建立完善的内部监控，随时掌握 API 和数据的访问动态。
代码库谁来守护
如果无人书写代码，一年之后谁来监督不断膨胀的代码库？答案是可能无人看管——这是个严峻问题。当下普通软件系统的复杂度已超出任何个人可靠推理的范围，但人类规模的团队仍能驾驭。若系统规模扩大 10 倍而理解能力没有同步提升，安全变更的能力将彻底丧失，系统的演进和维护都将严重受阻。
作者从 LLM 开发早期就持续倡导：花在"理解工具"上的时间应与花在"生成工具"上的时间相当。然而这一观点的接受度仍不及预期。
测试工具的瓶颈
作者补充说明，自己是测试章节系列的编辑，并撰写了《测试概述》一章。现有集成测试工具仍不完善，并非因为缺乏尝试——Google 有规模不小的团队在构建更优的集成测试工具，但距离理想状态仍有很长距离。问题根源在于：除非团队将集成测试视为与并发性、可靠性同等重要的系统级核心属性，与系统同步演进，否则底层系统的复杂度会迅速超出构建系统级测试的能力。真正优秀的集成测试需要系统从设计之初就明确考虑可测试性，但多数团队没有余力投入这类基础建设——或许 AI 能让这类投入变得更具可行性。
测试泛滥：AI 批量生产单元测试的陷阱
首先崩溃的，很可能是单元测试——因为 AI 太擅长写它们了。Google 在 AI 时代之前就吃过这个亏：生成大量看似有用的测试其实价值极低，它们要么与其他测试重复、缺少精确的断言、测试结果不稳定，要不维护成本高到令人厌烦。另外，如今几乎所有团队都要求所有测试通过才能发布代码——测试越多，同时通过所有测试的难度就越大，哪怕每条测试本身都很可靠。
将近 14 年的 Google 经历教会我一件事：好东西也可能过量，测试也不例外。这不是在劝退测试，而是呼吁更加有意识地重新思考：当代码生产成本趋近于零时，我们该如何验证软件质量。
知识掌控危机：AI 生成的代码越来越难理解
目前 AI 确实让这个问题雪上加霜，因为行业投入几乎全部集中在代码生成上。验证一段生成的代码是否正确，远比验证一段关于系统健康状态的微妙指导容易得多——这在逻辑上可以理解。
让代码走上坡路（hill-climb towards correct code）的机制已被充分理解，实现成本也相对低：快排就是快排，测试起来很简单。但诊断生产系统中的新错误，需要将完整系统状态装入上下文窗口，再结合对高度定制化系统特性的指导——这类系统在全球范围内都找不到类比。据我了解，这仍然是一个悬而未决的问题。
AI 在这方面的潜力是巨大的，因为它极其擅长识别模式和预测结果。我们真正缺少的，是一场大规模的"上下文工程"（context-engineering）练习——让系统对 AI 更加透明、可预测。
用 6 个月教会 10 年判断力：50 个 Agent 在手的新人怎么带
说实话……我也不知道答案。从 2017 年起我就在 Google 带新任技术负责人（TL），有一点始终不变：光靠听课或参加讨论组，很难学到判断力、形成直觉。真正的直觉来自做判断、采取行动、感受后果——这个循环才是新开发者需要更多体验的东西。
我正在尝试的一个思路是角色扮演游戏（RPG）。Google 的 SRE 团队用一种叫"Wheel of Misfortune"（灾难之轮）的 RPG 形式取得了不错的效果，参与者模拟事故场景并尝试解决。
我和朋友 Titus 多次讨论过这个问题，他认为采用学徒制技术（如结对编程）是向新开发者快速传递高带宽经验的绝佳方式。我认为他说得对，更深度的人际连接确实是加速工程经验传递的好方法。
另一个建议是：每一位新入职的软件工程师都应该学一些系统论和系统思维。了解通用系统动力学和系统模式，能帮助你为所面对的复杂性建立分析工具和心智模型，尤其能帮你在 Agent 越来越擅长处理的代码行之上的抽象层次获得清晰度。它不等同于深度直觉，但足够强大，可以产生类似的效果。
从周一早上开始：质量工程师的实际行动路径
第一件事：定义你的系统和业务中"质量"的真正含义。找出技术和业务影响力指标，能在质量下滑前给出前瞻性信号。这不是一项轻松的工作，很可能你原先认为重要的东西，在业务负责人眼里并没有那么关键。但围绕"什么才重要"开启对话，会让问题出现时的应对顺畅得多。
如果周一只能做两件事，第二件是：试着绘制你的开发者生态地图——包括所有技术和文化部分，并推演出代码产量提升 10 倍后的二阶、三阶后果。
发挥创意，别忽视那些你多年来视为理所当然的生态暗角。当编程生产力真的提升 10 倍时，一切都将重新洗牌。
内容简介
本书每章围绕四个维度展开：法律规定了什么、来源是什么、何时适用、在项目中如何落地。部分章节还串联了经典概念，如"两个披萨原则"（Two-Pizza Rule）、眼镜蛇效应（Cobra Effect）以及冒名顶替综合征（Impostor Syndrome）。
该书定位为案头参考工具书，适合在实际工作中遇到相关问题时随手查阅。
权威背书
该书邀请了行业资深人士撰写序言：
- Dr. Rebecca Parsons，Thoughtworks 前首席技术官（CTO Emerita）
- Addy Osmani，Google Cloud AI 工程总监（Engineering Director）
全书由来自 Google、Amazon、Uber、Oracle、Yelp、Nutanix、CodeScene 等公司的 20 位工程师与技术负责人审阅。
未来软件工程对话
以下为与 Adam Bender（Google 首席软件工程师）的访谈内容，探讨软件工程的未来走向。
评论