如果你依然认为与AI竞争的致胜关键在于编码能力，那么你已经输了。这只能证明你既不了解这个行业是如何运作的，也不了解行业里的人究竟在解决什么问题。

不止编程

我最近沉溺于勇哥的视频切片不能自拔——勇哥是一个餐饮自媒体博主，主要帮助人们解决餐饮经营中遇到的各种问题，例如营业额不佳，菜品选品等等。你会发现大到餐馆的选址、加盟的品牌，小到菜单定价设计、推广策略都会影响餐馆的经营状态。而大部分消费者关心的味道以及服务相比上面提到的各类元素，对于一家餐馆生死的影响不值一提。而归根到底最决定这笔生意是否能够持续下去的关键因素其实是人，也就是餐馆老板本身，如果他始终是以局外人的视角在经营，也天真的以为只要把菜品和服务做好，顾客就会怪怪的排队上门，那么这家餐馆在开的那天其实就已经死了。

软件开发行业同样如此。我最近读到一篇有趣的推文，大意是说第一波想要借助AI能力自己单干的人已经开始重新找工作了。因为他们错误的把手艺当做了生意——AI的确能够写代码没错，但它无法为你找到客户，无法为你定价，无法找到市场上还未被人挖掘的需求。

我一直认为开发者成长的标志之一，是开始尝试用不同的视角来审视自己的工作，这会让你多几分对工作本质的理解。如果你有尝试成为一名独立开发者，你就会发现难不是把产品做出来，难的是如何把它卖出去，甚至只是让更多的人知道它；如果你有担任过团队的 team lead，你就会发现难的不是让团队产出代码，而是让团队稳定产出高质量的代码；如果你的工作是为甲方提供咨询服务，那么难点不是让技术方案的实施，而是说服甲方同意方案并且提供资源让项目落地。

说到底软件开发是一门综合学科，编码只是其中的一个环节。从这个角度看，AI无法替代人类的地方还有很多。

在混乱中穿行

我对软件交付的总结是：在混乱中穿行。

我之前倾向于将开发者的工作简单粗暴的总结为解决问题——这么定义也没错，但是在今天我们讨论的上下文中，它忽略了软件交付过程极为重要的两点特性：1) 交付过程是混乱且充满不确定性的；2) 并非所有问题都能够被解决以及被解决。

而编码并不满足上述两个条件，因为绝大部分情况下，编码的确定性极强。只要需求确定，产出代码不过是时间的问题，甚至开发者还能够依据交付压力的不同交付不同质量的产品。

最近半年我一直在听说“前端已死”，认可该观点的人不仅认为前端已死设计已死，且后端开发被AI取代也不过是时间的问题罢了；而反对的声音认为其实是前端的工作内容发生了偏移，又或者对开发者的技能提出了新的要求。在我看来判断技术可否被AI取代的标准不是具体的框架或者语言，而是它解决的问题具有多大的不确定性。从这个角度上看，我认为当下招聘中的热门岗位，例如 Agent 工程师可能也只是昙花一现，如果他的职责只是使用既定框架例如 LangChain 来构建 Agent 的话。

真正的混乱在于编码之外，例如当有P1级别的线上问题发生时，开发者应该如何第一时间解决问题？

有经验的工程师不会将它当做一个技术问题而是一个策略问题来解决：当然能够在短时间内将代码漏洞修复上线是再好不过的事情，但如果在有限时间内无法从海量日志中找到任何的线索，同时考虑到宕机的每分每秒都是实实在在的金钱损失，那么应该怎么办？

我经历过不少类似的事件，但每次的解决方案都不尽相同：回滚代码理论上可行，但大部分时候这个方案没法却没法落地，因为代码的上线总是会随着数据库的更改，已经添加的列以及填充进去的数据没法被轻易删除；又或者我们定量定性分析：这个P1问题的影响究竟有多大，虽然它造成了宕机，但是它发生的概率极小并且重启能够稳定修复，那我们会建议将问题先降级。

为什么“将问题降级”会是一类解决方案：因为在这种情况下我们在解决已经不是单纯的技术问题，而是在解决甲方的焦虑，在解决我们甲方干系人他们职业生涯的一次危机，在解决乙方的一次信任危机。这也是为什么在解决此类问题的过程中，我们要务必要与利益方、管理团队沟通进展，说明影响以及安抚情绪。

依据条件下整理洞见，做出判断，定制方案，随机应变——这些是AI无法替你完成的。

我相信你也听说在当下Software Architect或者Principal Engineer这样的职位依然是安全，其背后也遵循的是同样的原理：架构师永远不可能一意孤行的做出决定，他需要同时考虑到客户偏好，交付周期，维护成本，团队能力等等等等。这里没有一个公式总是可以让他高枕无忧的去套用，这些才是开发者个人的独一无二的地方。

注意力经济

说了这么多，我只是想“售卖”我最近学习到且十分认同的一个观点：注意力经济（Judgment Economy）：当下那些带来价值的人，是那些能够在压力和不确定条件下做出明智判断，制定战略并且让众多参与者凝聚在共同目标之下的人。其价值的衡量标准是人们对他的信任度、他的影响力以及决策的可靠性。

在这个前提之下有三种能力显得格外重要：

• 首先是能够让团队内部以及团队之间对其目标的协调能力，这是影响力、领导力与外交能力的综合体现。要知道在组织里任何的决策既不来自于个体的一厢情愿，影响到的也不仅仅是有限的个体。想要做你认为正确的事情，落地能力是其次，发起者需要具有推动它的能力，后者比前者更加重要。
• 其次是规划能力，即将海量信息转化为可选策略以及长期规划。例如确定项目的技术演进方向，因地制宜的设计项目架构都属于这个范畴
• 第三种能力是综合创造力，即能够制定跨学科的创新性的解决方案。这对开发者的技术广度提出的要求，意味着开发者不能一味的套用自己的熟悉的技术栈，除了开源技术以外，云厂商服务、SaaS产品或者PaaS产品等都应该纳入技术选型的范畴。

以上关于“注意力经济”的理论并非是我的原创，而是来源于我最近读到的一篇文章《How To Future-Proof Your Career In The Age Of AI》，这是一篇值得推荐的深度长文，有兴趣的读者可以阅读原文来了解该理论的来龙去脉。

很明显上述三种能力要求并不是大部分公司里初级开发者能够掌握的，绝大部分初级开发者被排除在决策层之外而专注在一线执行开发任务，方案和需求自上而下的传达到他们这里。更不乐观的是，这些技能无法通过除实践以外的方式习得，你必须只有亲自去参与决策，去从0到1将一个方案落地才能摸清楚其中的门道。这件事没有人能帮到你，你只能从所在的组织内，从周围去寻找机会，越快越好。

我最近在Reddit上看到一个问题：如果AI替我完成了90%的代码，我还有什么能够引以为豪的呢

这是一个“我是否会被AI所替代”试金石：如果除了编码之外，你真的对其他软件开发里的其他实践没有任何洞见，那么这会是一个危险的信号。

开发者应该寻找新的角色与职责，来避免与AI的长项直接竞争，从对代码负责转为对交付负责，这样的机会仍然存在。