Senior Engineer 会不会成为前 AI 时代的遗产？
最近我越来越强烈地感觉到一个问题：
会不会没有新的 Senior Engineer 了？
这里 Senior 的定义：能独立定义问题，能看懂系统结构，能判断一个方案是不是会污染未来三年的维护成本，能在一堆“看起来都能跑”的解法里选出那个组织上、工程上、风险上都最健康的解法。
本身，这些资深工程师就是稀有资源，现在 AI 在软件工程领域的革命，说不定会让这些人才更加罕见。
培养一个工程师
以前培养工程师的路径大概是这样的：
Junior 接需求，写代码，踩坑，被 review，被线上事故教育，被系统复杂性毒打。几年之后，如果人足够聪明，且所在环境足够复杂，他会逐渐拥有一些“工程直觉”：
- 一个数据源新增，需要尽可能采用已有的数据链路，因为可以复用现有的基础设施，已有的契约，和已建设的可观测性工具；不这样，破坏监控一致性，这类方案会在统计上显著增加未来每日均摊工作量；
- 语义大于实现，为了实现功能破坏原有语义是减分项；
- 这个测试不是 happy-path 跑过就行，因为这个系统真正复杂的地方不在 happy path，而在状态空间爆炸后的边界行为；
等等等等。
每条直觉，都来自于之前的数次毒打，以及解决过程中对问题的深入思考。问题是，现在有了可以托付大部分事情的 Agent，Junior 可能不再经历这套完整的毒打了。
工程能力和产出能力的区别
很多人会觉得 AI 会抹平差距：现在一个 Junior 写不出来的脚本，丢给模型就跑了；以前改不动的模块，现在有大模型帮忙梳理、改写；以前要求人给出答案的问题，现在问模型就能得到一个看起来很正经的解释。
于是表象上看，好像大家的差距正在被拉平：谁写代码，谁问模型，谁拿出来的产出差不多。但我越来越觉得，这只是表面幻觉。它拉平的只是“你能生成多少行代码”的能力，严格说是“生成文本”的能力，不是工程本身的能力。
因为那些真正让一个工程师和另一个工程师不一样的东西，是看不见也摸不着的：
- 比如，这段代码，虽然能让某个功能过关，但你有没有意识到它会让系统里的某个不变量失守？
- 比如，这个抽象，看起来优雅，实则会在未来半年里制造一次难以排查的线上事故。
- 再比如，当你想用一个 None / NaN / 空字符串去表达“没数据”时，你是不是想过将来会有多少链路因为这一点点语义歧义而全部混乱？
- 又比如，当业务急着上线一个功能时，为了快点满足需求，你是不是敢在工程上破坏掉现有的全局约束？这个代价你真的算清楚了吗？
这些东西，大模型不是完全不能学，也不是永远不能判断。但在今天的工业环境里，它并不天然知道哪些规则是你们系统里被历史验证过的硬约束。它能帮你“解决问题”，却不知道你们系统为什么定义了这些规则；它知道代码长什么样，却不知道那条看似最简单的数据链路背后有多么珍贵的状态一致性；它可以读到设计文档，却未必能理解某个分层抽象是你们几年前因为一次事故才被迫建立起来的防线。
让任何一个真正的资深工程师讲讲自己的设计原则、设计理念、设计偏好，最后基本都会讲到一些血与泪的教训。
而 AI 最可怕的地方在于，它可能帮 Junior 跳过了这些教训。
当我们用 Harness Engineering 让 AI 自己全权完成设计-实现-验证的闭环，用人类无法理解的 It just works 式解决方案+代码实现系统，最终拿到我们想要的功能，美好的体验背后，也忽视了培养资深工程师时必要的过程 —— 发现问题、理解问题、解决问题、反思问题、避免问题。
AI 产出的 Magic Spells
我为什么说 AI 的很多解决方案是 It just works？倒不是否定它们的能力。恰恰相反，是因为它们很多时候确实能工作。但问题是，它工作的方式不一定适合人类长期接管。
AI 的思维方式和人类是不一样的。它沉淀出来的设计文档、问题记录、上下文摘要，往往信息密集、繁杂、跳跃、局部自洽但全局不顺。对模型来说，这些东西可能很有用，因为它们能在 Session 里快速重建上下文；但对人来说，读起来经常像在读一堆压缩过的咒语。
代码也是类似。有时候 AI 写出来的代码会充斥着大量冗余注释、局部防御、奇怪的抽象、互相矛盾的意图，以及一种非常不人类的思维惯性：它可以运行，测试也可以过，功能也可以交付，但你很难说这个东西是一个人类组织愿意长期维护的系统资产。
所以 It just works 不是在否定 AI 的工程能力，而是在指出另一个问题：它能交付，不代表它能传承。
传统软件工程里，一个系统不只是给机器跑的，也是给人理解、修改、排障、复盘、迭代的。代码是写给机器执行的，但首先是写给人维护的。AI 时代这件事开始变得微妙：如果未来大部分代码都由 AI 生成、AI 修改、AI 解释、AI 验证，那么代码是否还需要符合人类的理解方式？
从效率角度看，也许不需要。从组织延续角度看，这就是一个很大的问题。
因为一旦系统进入“人类只能使用，但无法真正理解”的状态，工程组织就会发生根本性变化。过去我们说技术债，是因为人还看得懂债在哪里，只是不愿意还。未来可能会出现一种新的债：系统本身能跑，Agent 也能继续改，但人类已经无法低成本建立完整心智模型 —— “这玩意是 WTF ？”
这可能不是传统意义上的技术债，而是一种理解债。
我们必须拥抱 AI，否则效率损失会让我们被时代淘汰。这个结论没有争议。但拥抱 AI 的代价，也可能是我们逐渐失去深入理解“软件工程”的过程。
断层
传统 Senior Software Engineer 大概率不会立刻消失，但“通过传统路径成长出来的 Senior Engineer”很可能会越来越少。因为那条路径依赖大量亲手处理复杂系统的反馈，依赖 review，依赖事故，依赖长期维护，依赖在一堆局部正确的方案里不断判断哪些东西会变成未来的债。更因为这条路径正在被 Agent 接管。
未来新的角色可能会逐渐产生。它可能叫 Senior Harness Engineer，抑或是别的什么东西。这个 Role 不一定亲自写最多代码，但能定义系统不变量，设计约束，构造验证闭环，决定哪些东西可以交给 Agent，哪些边界必须由人类拍板，哪些产物必须保持人类可理解，哪些地方可以接受 It just works。
但是这类能力的成长，是否存在路径依赖？我不知道。因为我目前能做这些事情，恰恰因为我是 Senior Engineer。
我们现在可能正站在一个分水岭上：一边是前 AI 时代最后一批靠复杂系统毒打长出来的 Senior Engineer，另一边是 AI 原生时代逐渐出现的新型工程师。
中间可能会有一段断层。而这个断层，才是真正让人担心的东西。
