主任工程师正在悄然成为成本负担
两周前我参加了一个会议，我们的工程副总裁说了一句让我印象深刻的话。我们正在讨论第三季度的人员编制规划，有人提到了各级工程师的人均成本。
副总裁打开了一个电子表格。他没有说什么戏剧性的话。他只是指着主任工程师那一列说："这里我们需要进行一次严肃的对话。"
没有人回应。主任工程师们不在房间里。但每个人都知道他是什么意思。
从那以后我一直在想那个时刻。不是因为它令人惊讶。而是因为它并不令人惊讶。而这正是令人不安的地方。
1、没人愿意大声说出来的算账
我要分享一些数字。它们不是来自某个行业报告。它们来自我自己的公司，以及过去几个月我和四五个其他地方的朋友的对话。
我们公司一个主任工程师的成本大约是一个中级工程师的 2.4 倍。总薪酬、福利、全部算上。
两年前这个数学是合理的。主任工程师是那个能够审视一个系统并看到六个月后才会浮现的问题的人。是那个拯救公司免于犯下昂贵架构错误的人。是那个指导三四个工程师并让他们都变得更好的人。
现在这个数学越来越难以证明了。不是因为主任工程师变差了。而是因为 AI 弥补了他们过去填补的一些差距。
一个中级工程师配合 Cursor 或 Copilot 现在能产出代码，坦率地说，看起来很像两年前主任工程师会写的东西。不是总是。不是所有事情。但足够频繁，以至于财务人员开始注意到了。
而财务人员不在乎细微差别。
2、主任工程师以前实际做什么
我想在这里小心一些，因为我认为大多数关于 AI 取代工程师的文章都是偷懒的。他们对生产力挥挥手就算分析了。
所以让我具体说说在我团队中主任工程师在 AI 工具变得好用之前实际花时间做什么。
大约 30% 是代码审查。阅读其他人的 pull request，发现微妙的 bug，建议更好的模式，维护代码库的一致性。
大约 25% 是架构指导。"这里我们应该用队列还是直接的 HTTP 就行？""我们需要一个新服务还是可以扩展现有的？"这类决策。
大约 20% 是指导。帮助中级和初级工程师成长。结对编程。解释我们为什么做某些选择。
大约 15% 是自己写代码。通常是难的部分。迁移脚本、复杂集成、没人愿意碰的东西。
大约 10% 是会议。规划、估算、跨团队协调。
以下是过去一年中这些事情的变化。
代码审查：AI 处理了主任工程师过去能发现的大约 60% 的问题。不是架构关注点。不是"这在规模化时会有问题"的观察。但模式匹配、风格一致性、明显的 bug。这些过去每周要花好几个小时。现在花费的时间少得多。
架构指导：仍然非常需要人类。AI 在这方面确实很糟糕。它可以建议模式，但它不能理解你特定的业务背景、你团队的优势、你的部署约束。主任工程师角色的这部分是安全的。也许现在甚至更重要了。
指导：这个比较复杂，我没有干净的答案。一些指导被部分替代了。初级工程师告诉我他们从 AI 的解释中学到很多。但职业指导、"如何在这个组织中周旋"的东西，当有人挣扎时的情感支持？AI 完全做不了这些。
编写困难的代码：仍然有价值。但"困难"的定义在不断缩小。
会议：没有变化。可能更糟了。没人搞清楚如何自动化会议，说实话在这一点我觉得会议是不朽的。
3、幕后正在发生的对话
这是让我担心的部分。
我和很多不同公司的工程师交谈。不是正式的。只是朋友、前同事、我在聚会和会议上认识的人。正常的对话。
在过去两个月里，三家不同公司的三个人告诉了我某个版本的同一个故事。
领导层查看了工程预算。他们查看了主任及以上工程师与中级工程师的比例。他们问了一个版本的问题："我们真的需要这么多高级人员吗？还是我们可以用更少的高薪人员和更好的 AI 工具获得相同的产出？"
在一家公司，他们还没有对此采取任何行动。只是问了这个问题。
在另一家，他们悄悄进行了重组。两个主任工程师被调到了"特殊项目"，这是企业用语，意思是"我们还没解雇你，但你的团队已经不存在了"。
在第三家，一个主任工程师在看懂了形势后自己离开了。他告诉我他能感觉到他的经理在预算会议上很难为他的人员编制辩护。他没有等着被推动。
这些都没有上新闻。不是大规模裁员。没有头条新闻。它是安静的。是个人的。它发生在电子表格和私密的 Slack 频道里。
这就是为什么这件事很难被讨论的原因。
4、为什么这感觉不同于"资深工程师已死"的恐慌
你可能在读这篇文章时想"好吧，又一篇 AI 正在取代经验丰富工程师的文章。"我理解。我自己也读了太多那样的文章，其中大部分都是垃圾。
但我认为主任工程师的情况与资深工程师遇到的情况不同。原因如下。
资深工程师是一个广泛的类别。有些人整天写代码。有些人做架构。有些人管理人员。这个角色差异很大。所以当 AI 改变游戏规则时，不同的资深工程师感受不同。有些人轻松适应。有些人挣扎。
主任工程师是一个更具体的角色。在大多数公司，它意味着：在不直接管理人的情况下，对多个团队拥有广泛技术影响力的人。这是一个几乎完全由判断力和技术广度定义的个人贡献者角色。
而问题在于。这种广泛的判断力过去是稀缺的。你需要跨多个系统的多年经验来培养它。现在一个中级工程师配合 AI 可以模拟出一些这样的广度。不是全部。但足以让人对成本差异提出不舒服的问题。
主要是一个非常优秀的代码审查者的主任工程师？暴露了。
主要是代码库活百科全书的主任工程师？暴露了。
能够看着一个产品需求并说"这会是一场噩梦，因为 X、Y 和 Z 没人想到"的主任工程师？仍然非常安全。
问题是大多数主任工程师是三者的混合。而就业市场不会根据你最好的技能来定价。它根据平均值来定价。
5、我不断从主任工程师本人那里听到的
上周我和一个朋友喝咖啡。她是一家大约有 400 名工程师的公司的主任工程师。在那待了五年。广受尊重。那种如果她辞职会留下三个人都填补不了的空缺的人。
她告诉我一些我一直在想的话。
她说："我现在每周花两个小时做真正需要我的判断力的事情。其余的要么 AI 现在做了，要么中级工程师配合 AI 处理了。但没有人围绕那两个小时重新定义我的角色。我仍然坐在同样的会议里。我仍然被拉进同样的审查中。我只是……知道大部分其实并不真的需要我。"
然后她说："最糟糕的是我不能把这说出来。因为在我说出'我的大部分工作不需要我'的那一刻，会有人表示同意。"
我不认为她在夸张。我认为她在说实话。而且我认为很多主任工程师有同样的感觉但不会说出来。
6、如果我现在是主任工程师，我会怎么做
我要声明。我不是主任工程师。我没有他们大多数人的那些年经验。所以请带着适当的怀疑来看待这些建议。
但从我的位置看，看着这一切发生，那些看起来最安全的主任工程师正在做以下事情。
他们不再做通用的审查者，而是成为专业的决策者。他们不再审查每一个通过的 pull request，而是什么也不审查，只被拉进没有其他人能做的架构决策。他们有意让自己变得稀缺。不那么可见但更加不可或缺。
他们把自己与收入挂钩。能够说"我设计了处理我们支付的系统"或"我构建了我们最大客户依赖的集成"的主任工程师，与说"我改善整个组织的代码质量"的人在完全不同的对话中。一个是成本中心。另一个是收入依赖。
他们开始更频繁地说不。这听起来有悖直觉。主任工程师通常通过乐于助人获得晋升。随时待命。总是第一个跳进来的人。但在 2026 年，成为什么都跳进来的人意味着你在越来越多不需要你的工作中分散精力。那些聚焦的主任工程师缩小了他们的价值，而窄化的价值更难被砍掉。
他们对自己工作中哪些部分仍然独一无二地属于自己保持诚实。不是舒服的诚实。是真正的诚实。"这个会议不需要我。这个审查不需要我。这个决策确实需要我。"然后他们围绕那些需要的部分重新安排时间。
7、如果你不是主任工程师这意味着什么
如果你是中级工程师，这在某种奇怪的方式上对你其实是个好消息。你与主任级别之间的差距正在缩小。不是因为你一夜之间变得更好了，而是因为工具改变了"更好"的含义。问题是公司是否会重构角色来反映这一点，还是只是保留旧的层级制度加上新的怨恨。
如果你是初级工程师，暂时不用担心这个。真的。你有更大的事情要关注，比如学习基础知识和理解真实系统如何运作。主任工程师的政治问题在你准备好时仍然会在那里。
如果你是管理者，你可能已经知道我刚才写的一切。你就是坐在那些预算会议中的人。问题是你是否会与你的主任工程师就他们的角色需要如何演变进行坦诚的对话，还是让他们看着自己的职责慢慢消失自己搞清楚。一种方式更难。另一种更残忍。
8、我不知道的部分
我将以一些可能不太令人满意但我认为比假装我有答案更诚实的内容作为结束。
我不知道主任工程师角色是否能以当前形式存活下来。头衔可能会保留。薪资等级可能会保留。但实际工作可能在两年内看起来如此不同，以至于把它称为同一个工作感觉有些牵强。
我确实认为在那些角色中的人不是偶然到达那里的。他们是通过适应力强、聪明和有意识而到达那里的。使他们成为主任工程师的同样特质将帮助他们想清楚这个问题。
但他们必须现在就开始想清楚。因为电子表格已经打开了。VP 们已经开始了那些对话。等着被告知你的角色已经改变，比你自己改变它要糟糕得多。
我看着我的 VP 指向那一列。他不是生气。他也不是为削减成本而兴奋。他看起来很不舒服。就像他即将做一件他不喜欢的事情。
这某种程度上比他热衷于此更糟糕。
原文链接：Staff Engineers Are Quietly Becoming the New Overhead
汇智网翻译整理，转载请标明出处