CI 失败了。这出乎意料。我已经把我的智能体工作流调整到这样的程度：如果我的某个智能体提交了一个测试失败的分支，我会感到惊讶。也许是 CI 偶发故障或环境问题？等等，是 SonarQube 在抱怨 App.tsx？我们是不是从 npm 引入了一个新的可疑依赖之类的？没有。SonarQube 标记这个文件是因为圈复杂度。好久没见到这个问题了。
是的。App.tsx 大约有 30 行代码，但其中 15 行实际上是 Codex 决定每行写一个的完整组件。这本身没问题，只要用 prettier 跑一遍就完事了。但这并不能解释圈复杂度。每个组件都相当复杂，包含大量显示和业务逻辑。过去的我会仔细重构它，确保代码可读。另一方面，Codex 不在乎整个组件写在一行里，更重要的是，它不介意复杂度。它一直愉快而可靠地在这个文件上迭代，实现了多个功能。
CI 工具标记了一个问题，也许正确，也许不正确。但这是一个真实系统，所以我必须深入调查。格式化文件后，我逐一检查了组件和逻辑。Codex 是否超出了典型开发人员在覆盖边缘情况方面的做法，并且稍微过度设计了？是的，但都是正确的。我没什么可抱怨的。所有的复杂度都是业务需求所必需的。所以我告诉 Codex 让 SonarQube 满意，它通过重构并将内容拆分成 10 个文件做到了。CI 通过了；事情发布了。虽然这个特定事件很快解决了，但你可以想象情况可能会糟糕得多。毕竟，这是我从未见过的代码。
这就是我们行业的发展方向：拥有一个软件系统将不再那么依赖于亲手编写它（或类似系统）；相反，最重要的是知道刚好足够的知识来判断何时出了问题，并且在需要时愿意并且能够深入挖掘。
潜水机器人与金块
想象你在一艘船上（船的类型由你决定），你的工作是从海底收集小金块。直到最近，如果你想拿到一袋金子，你需要跳入水中，游到海底，四处寻找，然后把袋子装满。如果你在清澈的浅水区，这很容易，但你可以想象这很快就会升级为更困难的事情。因此，随着浅水矿开始枯竭，你和工程师同行们建造了各种机械和工具，从越来越深、越来越危险的水域中提取黄金。这在大多数情况下效果很好，你和你的团队会仔细组装、维护、轮换机械，并不断潜入海底采矿作业以保持其运行。每隔一段时间，你就会听说一些采矿作业的崩溃，有时是由于巨大的水下压力，有时是由于事故或操作员无能。挑战在于这是一个地质非常活跃的世界，所以海底不断变化，一些矿枯竭，新的矿在不同地方出现。
不过好消息是！过去几年见证了越来越复杂的潜水机器人的发展，它们可以下潜并自行建立采矿作业。你只需告诉它们在哪里建造，它们就会下潜，只在浮出水面时给你更新和金块。事情很棒，你现在可以在船上放松，而你的潜水机器人做它们的事，你只需要担心能把多少金子塞进你的船。这是乐观派阵营。
直到……
“等着你的潜水机器人潜得太深而迷路吧”。“哈哈，你的潜水机器人带给你的东西看起来像金子，但实际上是闪亮的章鱼粪便”。随着潜水机器人的激增，你看到越来越多的恐怖故事。潜水机器人迷路并忘记它们应该建造什么。潜水机器人建造了如此复杂和怪诞的东西，以至于它们难以维护，最终被下一代潜水机器人丢弃。所有水下采矿作业都从精心设计和建造的大教堂变成了更像是杂乱无章的豪宅，隐藏着通道和潜伏的恐怖。你与作业越脱节，失败就越壮观。这是怀疑派阵营。
此处有怪物
软件工程行业（我怀疑很快会有许多其他行业）正在经历上述场景的一个版本。你可能已经知道怀疑派或乐观派哪个更符合你，即使你仍然不确定你想加入哪个阵营。
传统智慧认为，为了开发和维护一个非平凡的系统，你需要有一个适当的工作模型。我想很少有人会对此提出异议。在软件工程中，你通过直接与代码打交道来获得那个工作模型。多年和数十年的编写和阅读代码的实践为你提供了理解和负责系统所需的知识和工具。每一次生产事故，每一次深夜调试，每一次成功发布。所有这些经历都为你提供了拥有一个系统所需的视角。在这篇文章的上下文中，所有权意味着当出现问题时，你是那个被叫来的人。
智能体（divebots）正在把这一切彻底颠覆。Divebots 产出输出的速度远超任何人能够吸收的速度，而且在过去的复杂系统中，你可以假定代码在某个时刻曾经过人类之手，如今这已不再成立。现在，经验丰富的从业者有可能管理成群的 divebots，以前所未有的规模创建软件。这些操作者精通这门技艺，并运用他们相当丰富的经验来管理和架构过去需要团队才能构建的大型系统。但这暴露出了我们行业可能面临的最大挑战：我们如何培养下一代工程师？
在极端情况下，乐观派和怀疑派对这个问题的答案截然不同。一方面，有声誉卓著的声音说，要保持对这些系统的控制，唯一的方法就是阅读 divebots 产出的每一行代码。要能够亲手编写它。要能够解释每一段代码做什么，以及它如何融入应用程序的上下文。在另一个阵营，同样有声誉卓著的声音说，甚至不必费心去看代码。把你的精力集中在弄清楚要构建什么上，忘掉它是如何构建的。模型会处理它。我认为这两种观点都不对。
事实是，当今资深工程师学习的方式，即通过亲手编码、无休止的调试时间、生产事故等等，对于今天的初级工程师来说并不是一条可行的路径。需要明确的是，它在经济上不可行，这意味着公司极不可能愿意资助初级工程师数年，让他们“学习亲手做”。那是一厢情愿。经常被提出的另一种建议是“确保你理解你的智能体写下的每一行”，或者“与资深工程师结对”，或者“进行仔细的代码审查”。同样，除了也许少数几家公司之外，这都是一厢情愿。如果你认为整个行业会采纳这些做法，那我有一座桥要卖给你。联系我。
为了找出实现某种程度的精通的一条可行路径，我们必须审视拥有一个非平凡软件系统意味着什么。如果你想想你典型的架构师/负责人/CTO 以及他们如何运作，就会清楚，要取得成功，他们需要在头脑中有一个系统的模型，一张水域图。真正的问题是在什么粒度级别上？想象一个遗留的百万行代码库，它多年来由许多人编写和扩展。CTO 甚至可能编写了其中的部分代码。现在想象出现了一个生产问题，而你就是那个倒霉的 SRE，在凌晨 2 点试图弄清楚它，同时收到来自不同时区的人发来的愤怒短信。你需要什么样的系统图？你需要一张整个系统的高层、远观的图，你需要知道刚好足够的东西，以知道你需要在哪里深入，怪物住在哪里，并且你需要能够跳进任何未知的代码库，弄清楚发生了什么，推送一个热修复，并在你的事故报告中清楚地描述发生了什么。
请注意，这不是对整个系统的详细知识。我们管理复杂系统的唯一方式就是建立抽象。每一层都让我们能多构建一点，但无论你拥有什么样的图，重要的是要记住，它一路向下都是抽象，没有人真正理解所有的层。“我编写了模块 X 并对它了如指掌”和“我对系统抽象有适当的模型，能够深入任何模块并在它出问题时修复它”之间有很大的区别。亲手编码给了我们前者，但系统的所有者，那个被叫来的人，需要的是后者。
那么这张图是如何建立起来的？如果一个人从未亲手开采过金块，又怎么能指望他深入未知水域，修复 divebots 造成的烂摊子呢？
基础、广度与即时深度
复杂系统中一些最隐蔽的故障是安静的故障。就是那种大部分时候能正常工作，但系统有些不对劲的情况。也许它突然变慢了，或者错误率上升了，或者它大多数时候完美运行，但每第 19 次尝试就失败。还没到凌晨 2 点被呼叫的程度，但足以让你感觉有什么不对劲。作为系统的所有者，你需要理解系统的故障模式。作为一个行业，我们有工具来教人们如何检测和推理这些故障：基础。好消息是，几十年来我们一直在向不知情的计算机科学专业学生教授这些。我说的是数据结构和算法、网络、并发、分布式系统等等。它也不必来自正规教育，这些是你自己可以阅读和学习的主题。
打个简单的比方（如果你是资深工程师，请在这里包涵我一下），想象你派你的 divebot 去执行任务。你在浅水区，把它送到水下 2 米去收集一些金块。它 4 秒后回来，一切正常。接下来，你把它送到水下 4 米。但这次它花了 16 秒。这很奇怪。下一个任务是水下 16 米，它花了 256 秒。你明白了。显然有什么不对劲。在计算机科学中，这被称为二次复杂度，而识别它的最佳方式可能就是理解理论并知道这种东西存在。
这就引出了关于所有权的下一个支柱：广度。我有幸共事过的大多数成功工程师和工程领导者，都能就几乎任何话题展开讨论，无论是否与技术相关。他们可能是某些领域的专家，但最令人印象深刻的是他们能够借鉴并编织来自不同学科看似毫不相关的概念，并运用这些知识来解决问题。这是水域的高层地图。正是它告诉你某些海域比其他海域更危险。知识的广度让你能够说出“我们在这里下潜”。需要说明的是，我说的不是在每个可以想象的领域都具备专家级知识，而只是足以知道当事情不对劲时该去查什么。这些是引导你探索海洋的浮标。
有人问我“我们怎么教广度？开一门涵盖一切的概览课？”我当时没有好的答案。但进一步思考之后，在我看来这不是能教的东西。没有一门“万物入门 101”可以选修。我们最多能做的就是鼓励人们去阅读、探索、保持好奇。尽可能多地吸收信息。记住那些奇怪的事件、那些“糟糕”的时刻，思考它们如何与你的工作相关联。随着你积累更多经验，有意识地努力将你的日常经历与工作联系起来。我已经记不清有多少次，多年前在一个随机项目中学到的那一点知识突然出现，挽救了局面。这种经验和广度会复利增长，但必须加以维护。
所有权的最后一个支柱是我所说的即时深度。这是深入任何问题并把它弄明白的能力和意愿。即使你身处未知水域。即使你不得不进入笼子与鲨鱼共游一会儿。即使你不得不召集你的团队，登上大型正规潜艇，下潜越过巨型乌贼，去弄清楚系统出了什么问题。这是学习完成工作所需任何东西的意愿。这也是谦逊，知道何时一次下潜超出了你的能力范围、你需要寻求帮助。并非每次下潜都能独自完成；并非每次下潜都值得去做。
几个月前，在开发我的 agent 编排器时，我的 agent 和子 agent 遇到了稳定性问题和生命周期 bug。我知道我想让它们做什么，但构建这个东西的 divebot 们做得相当随意，所有 bug 一下子全冒了出来。当我坐在屏幕前，看着我的 agent 在一小时内第 n 次崩溃，并且在让 divebot 们修复自己造成的烂摊子几次失败之后，我想起多年前读过一本 Kubernetes 的书（是的，我是个书呆子），“电平触发状态机”这几个字突然出现在我眼前。于是我进行了一次下潜，比我原本打算的更深，甚至追溯到“电平触发”的电气工程起源。我带着我的 divebot 们一起，从头重新设计了核心架构。从那以后它一直坚如磐石。这次成功的重写之所以可能，主要是因为我想起了多年前读过的某些东西，并且愿意深入下去、学习完成工作所需的任何东西。
所以你从海洋（系统）的高层地图开始，理解它是一层层抽象一直到底。而且由于所有这些抽象都会泄漏，你作为系统所有者的工作就是知道在哪里下潜以及潜多深。这不再是通才与专才的对立，甚至也不是神话般的 T 型人才。
新的构建方式需要一个能够深入未知领域的通才，一个“压力下的快速学习者”，而且不是简历上那种注水说法。你实际上需要能够在与海怪搏斗的同时快速学习。这些年来我面试过很多人，当人们在简历上写“快速学习者”时，我喜欢请他们讲讲有一次不得不快速学习一个复杂系统的经历，他们是怎么做的？你的答案会是什么？
未来的所有者
所以基础可以学习，广度可以积累。而即时深度则可以练习。这三大支柱使一个人能够在系统中扩大自己的所有权份额。也许你从浅水区开始，派出你的 divebot。你有扎实的基础、不错的广度，那就去构建点什么吧。只要准备好，当东西坏掉时穿上潜水服与怪物共游。
未来谁将负责那些庞大的水下采矿作业？没人知道，但我敢打赌，会是那些能够运用上述三大支柱的人。会是那个拆开旧收音机并修好它的孩子，他对收音机一无所知，只是渴望听音乐——即使他们在把所有东西装回去之后确实多出了几颗螺丝。