📌 好文共赏 | Editor’s Pick
原文：Why senior developers fail to communicate their expertise 作者：Tuhin Nair（nair.sh） | 发布于：2026-05-12 | 阅读时长：约 7 分钟
一句话推荐理由：当所有人都在喊 “AI Agent 让程序员过时” 的 2026 年，这篇短文用一个文案人的眼光，把 “资深开发者的直觉为什么是对的、但说出来又像在自我辩护” 这件事拆得干干净净——并且给出了一个非常可操作的应对框架：Speed 系统 / Scale 系统的双层解耦。
为什么值得读
最近一年，关于 “AI 是否会替代程序员” 的讨论已经被反复榨干，绝大多数文章的套路无非两种：要么是技术派的 “看我让 Claude 一晚上写了个 SaaS”，要么是悲观派的 “我们正站在白领工作消失的悬崖边”。这两类文章的共同问题是：它们都在谈替代率，不谈系统的两种不同目标。
Tuhin Nair 的视角非常特别——他不是程序员出身，而是个文案。文案这门手艺最在意的就是 “同一句话对不同受众意味着不同的事情"。他把这个透镜对准了 “AI 会让开发者消失” 这句话，发现了一个被忽视的事实：这句话在 CEO/PM/销售耳朵里和在资深开发者耳朵里，激发的是完全不同的潜意识。前者听到的是 “终于可以不再被开发的瓶颈卡住了”，后者听到的是 “等等，那以后这些代码坏了谁负责？"——而这种听觉错位的根源，不是态度问题，而是结构问题。
如果你做过一段时间的资深开发者、Tech Lead 或者架构师，你大概率有这种体验：你跟产品/老板解释 “为什么这个东西不能现在就上”，对方眼神空洞礼貌微笑——你说的每个词都对，但好像就是没传进去。这篇文章告诉你：那不是你不会沟通，是因为你和对方在谈的根本不是同一种风险。
而且它不只是诊断，还开了药方。这一点比 80% 的同类文章都要扎实。
核心观点提炼
1. 资深开发者的本质：一个"问题回避者”
Nair 的开场是个挺刻薄但又精准的观察：他把资深开发者分成两类。第一类喜欢炫新工具、喜欢搬运 HN 上的"最佳实践”，热衷于在团队里推动 “X 公司就是这么做的”。第二类则反复地问 “我们真的需要这个吗？““不做会怎样？““能不能先凑合一下、以后真的痛了再说？”
原文：Ah, baby, this is my senior developer. The avoider, the reducer, the recycler. They want to avoid development as much as they can.（来源：nair.sh）
第二类才是他心目中的"真·资深”。这个判断看起来反直觉——按理说，资深开发者应该是技术储备最深、最爱写代码的人才对？但 Nair 的解释一针见血：这群人之所以倾向于不写，是因为他们职业生涯里被复杂度反复教育过。每多一行代码、每多一个 if 分支、每多一张表，都是未来某个凌晨三点被 PagerDuty 叫醒的概率分量。这种 “对增量复杂度的本能恐惧”，恰恰是经验的结晶，不是懒惰。
我读到这一段时心里咯噔一下。因为这正是为什么资深工程师跟年轻同事开会时常常显得 “扫兴”——年轻人提出一个新功能，资深的反应是 “能不能不做”。表面看是消极，本质上是对系统熵增的极度警觉。
2. 业务侧怕的不是复杂度，是不确定性
Nair 接下来引入了一个非常清爽的双循环模型：
- 第一个循环：营销、销售、PM、CEO 都活在这里。他们的目标是 “把东西推到市场→获得反馈→再迭代”。这个循环的怪兽叫 uncertainty（不确定性）。
- 第二个循环：付费客户使用现有服务。这个循环的目标是 “服务持续运转、可调试、可扩展”。它的怪兽叫 complexity（复杂度）。
这个二分法看似简单，但它解释了为什么 CEO 总觉得 “再快一点没问题”、而资深开发者总觉得 “再快下去会爆炸”——他们其实是在对抗两只完全不同的怪兽。CEO 烧的是营销预算和窗口期，每多一周不验证假设就是真金白银的损失；资深开发者守的是 SLA 和 on-call 周转，每多一份复杂度就是真金白银的运维债。
这一段最妙的地方在于，它把"工程师 vs 业务"的永恒矛盾从"性格差异"重新定义成了”目标函数差异"。两边都没有错，只是在最小化不同的损失项。
3. 沟通失败的根源：把复杂度说成"工程问题”
那为什么资深开发者总是"说不清"自己的价值呢？Nair 的答案非常直接：因为他们在用一种听起来像"工程师在为自己辩护"的方式去谈一个其实是风险管理的问题。
当一个资深开发者说 “我们不能这样实现，因为会产生技术债务”，对方听到的是 “他不想干活、要重构、要更多时间”。但如果他能换一种说法——把语言切换到对方关心的维度上，沟通就会立刻畅通。Nair 提议了一个非常实用的"魔法短语”：
原文：‘Can we try something quicker?’（来源：nair.sh）
这句话之所以好用，是因为它同时打中了两边：‘quicker’ 承认了业务侧的核心诉求（速度），‘something’ 暗示可以换一种实现路径，’try’ 留下了"先试试看、不完美也行"的弹性空间。资深开发者借此完成了"reduce / reuse / avoid"的本职工作，但用的是业务听得懂的语言。
我觉得这是整篇文章里最值得抄进笔记本的一段。它本质上是把"复杂度管理"翻译成了"速度优化"的语言——同一个工程动作，换一个 framing，就从"挡刀"变成了"加速"。
4. AI 把这个矛盾推到了悬崖边
文章到这里完成了诊断，但真正的高潮在后半段：AI 让两个循环之间的张力被放大到了前所未有的程度。
为什么？因为 AI Agent 极大地加速了第一个循环（speed/uncertainty 那个）——任何人都能让 Claude 在一个晚上写出一个能 demo 的功能。但与此同时，AI 对第二个循环（stability/complexity 那个）是一种净负作用：它生成的代码可理解性差、可调试性差、可教学性差，更糟的是——
原文：AI does this and takes no responsibility.（来源：nair.sh）
这句话短到只有六个字，但份量极重。资深开发者干的所有那些事情——审 PR、写文档、追责、值 on-call——本质上都是在 承担责任 这件事上的人类资产。AI 可以生成代码，但它不会半夜被叫起来回滚，也不会在事故复盘会上承认 “是我的判断失误”。
这就把矛盾推向了一个非常尖锐的境地：业务侧获得了前所未有的速度，但稳定性侧失去了越来越多的可控性。如果不做点什么，两个循环就要互相撕裂。
5. 出路：Speed 系统与 Scale 系统的双层解耦
Nair 给出的方案是这篇文章里最具操作性的部分：与其让一个系统同时背两个目标，不如把它拆成两套系统。
- Speed 版本：服务第一个循环。AI Agent、初级开发者、营销人员、甚至非技术员工都可以在这里加东西。目标不是干净，是"够 demo / 够测试假设"。
- Scale 版本：服务第二个循环。由资深工程师设计，强调稳定、可理解、可扩展。它跟在 Speed 版本后面，吸收已经被市场验证的部分。
这其实是把"小说家先写呕吐稿、再请编辑精修"的工作流，搬进了软件工程。资深开发者从"作家"转型成了"编辑"——不再为每一个特性的诞生负责，而是为哪些特性配得上进入主线代码负责。
我觉得这个比喻特别准。它跟近些年企业界的 “双速 IT（bimodal IT）"、”innovation lab vs core platform" 思路其实是同一回事，但 Nair 把它建立在了一个更扎实的人性基础上——不同的人怕不同的怪兽，所以让他们去管不同的循环。
我的延伸思考
在中国的语境下，这篇文章其实戳的是另外一个隐痛：国内大量"全栈"团队从来没有过明确的 Speed/Scale 分层。一个产品经理拍脑袋提需求、一周内上线、两周后挂掉、半年后又重写——这套循环在国内中小公司是常态。Nair 的双系统思路在这里有一个隐含前提：你的组织得先承认这是两件不同的事。否则 Speed 版本和 Scale 版本到最后都会被压成同一个充满 hotfix 的烂泥塘。
我自己在过去几年带团队的经验也印证了这一点：最难的不是技术分层，而是说服老板"为什么你看到的 demo 不是产品"。Nair 那句 “Can we try something quicker?” 之所以好用，是因为它绕开了这个最痛的辩论——你不用先教育对方"什么是技术债"，你直接给他他想要的速度，把复杂度管理藏在你这一侧。这是工程师作为成年人的智慧。
当然，文章也有可以质疑的地方。第一，双系统真的能维护吗？大部分公司连一个系统都管不好，再造一个意味着双倍的工具链、CI、人手。Nair 没有讨论运营成本，这是这篇文章的一个明显缺口。第二，“AI 不负责任"这个论点其实在快速演变——随着 Agent 的可观测性、回滚能力、责任归属设计的进步，“无人承担"这件事可能会慢慢被吸收进产品流程（参见 OpenAI 最近关于 Agent 安全护栏的几篇博文）。如果有一天 AI 真的能承担一部分 on-call 责任，资深开发者的护城河又要被推到哪里？这是一个值得继续追的题目。
它让我想到几篇相关的延伸阅读：Martin Kleppmann 《Designing Data-Intensive Applications》里关于 evolvability 的那一章，本质上讲的就是 Scale 系统的成本曲线；以及 Gergely Orosz 在 The Pragmatic Engineer 上多次写过的 “Tech Lead 的真正工作是说不”。Nair 这篇可以看作是它们在 AI 时代的一次浓缩重写。
谁应该读这篇文章
- 资深工程师 / Tech Lead / 架构师：必读。你大概率会在文中读到自己每次开会时说不清的那种感觉。文中那句 “Can we try something quicker?” 直接抄进你的沟通话术库。
- CTO / 工程总监：把这篇文章当成跟 CEO 解释 “为什么我们不能只追速度"的脚本，比你自己写半天 deck 都好用。
- 产品经理：尤其推荐给那些经常觉得 “工程师又在挡刀” 的 PM。这篇文章不教你怎么催工程师，它教你 听懂工程师在挡什么。
- AI 创业者 / Agent 工具开发者：Nair 那句 “AI takes no responsibility” 是当下所有 Agent 产品要面对的真问题。如果你在做 AI 编程工具，这是一个必须严肃对待的产品设计约束。
- 职业初期开发者：这篇文章是一份非常诚实的 “未来 5 年你要往哪修炼” 的地图——不是 prompt 工程，而是承担责任的能力。
阅读原文
强烈推荐花 7 分钟读完原文，文中的两张手绘双循环示意图非常清晰，是这篇文章 framing 力的来源：
👉 Why senior developers fail to communicate their expertise — Tuhin Nair (nair.sh)
读完之后，建议在脑子里做一件事：把你最近三个月内一次"挡刀失败"的对话回放一遍，看看如果当时你说 “Can we try something quicker?"，对方的表情会不会不一样。
