如果你看到这样一句话：
“AI Agent 才是软件开发的未来。开发者已经不再必要，他们只会拖慢企业前进的速度。”
你会有什么反应？
我给出的答案可能有些反直觉。如果你是一位真正资深的软件开发者，而且你完全认同这句话，那么我反而会开始怀疑你的专业能力；但如果你并不是长期负责复杂系统的人，却觉得这句话非常合理，那么我认为，你大概率是正确的。乍一看，这种说法似乎自相矛盾，但它其实揭示了当前 AI 讨论里一个非常核心的问题：同一句话，在不同的人耳中，往往代表着完全不同的含义。
我本身是一名文案写作者，因此我习惯从“受众”角度理解问题。在我看来，现在关于 AI 的很多争论，并不是谁更懂技术，而是不同人实际上在面对不同的问题。对于许多资深开发者来说，他们已经亲自体验过各种 AI Agent、代码生成模型和自动化工作流，也确实感受到了这些工具惊人的效率，但与此同时，他们又隐约感觉到哪里“不太对劲”。问题在于，大多数人并不能准确地把这种直觉表达出来，于是这篇文章的目的，就是尝试替这些开发者把那种难以描述的不安翻译成人类语言。
很多人会感到疑惑：既然如此，为什么又有不少知名工程师、技术意见领袖，甚至经验丰富的开发者，也在不断宣称“程序员将死”？
我认为，原因其实并不复杂，因为不同的人所面对的“工作循环”本身就不同，而这会彻底改变他们理解 AI 的方式。
为了说明这一点，我先讨论什么才是真正的资深开发者。很多人以为，资深开发者最重要的能力是写出复杂架构、设计高级系统、掌握大量技术细节，但我认为，真正成熟的资深开发者往往最擅长的事情，恰恰是“避免开发”。
我把自己在团队里见到的资深开发者分成了两类。
第一类人总是在讨论新的工具、新的框架、新的最佳实践，他们会不断提到某家公司采用了什么架构、某篇 HackerNews 文章推荐了什么技术方案，或者最近又出现了什么令人兴奋的新东西。这类人通常经验丰富，也很擅长社交，但我并不喜欢他们，因为他们的思维模式总是在往系统里“增加东西”。
而另一类开发者则完全不同。他们最常说的话是：“我们真的需要这个吗？”、“如果不做会怎么样？”、“能不能先凑合一下，等以后真正重要了再说？”我非常认同这种开发者，因为他们真正害怕的是一件事情：复杂度。
在真正长期维护过大型系统的人眼里，复杂度几乎是一切问题的源头。每增加一个特殊逻辑、一个新的数据库表、一个新的服务模块，系统都会变得更难理解一点、更难调试一点、更难维护一点。复杂度并不会立刻毁掉系统，它更像一种慢性病，刚开始时团队感觉不到问题，但随着时间推移，整个系统会逐渐变成没人真正理解的巨大黑盒。最终，任何小改动都可能引发连锁反应，每一次上线都像是在拆炸弹，而团队的开发效率也会被慢慢吞噬。
然而，令人尴尬的是，公司里的大多数人并不能真正理解这种恐惧。原因在于，他们害怕的根本不是复杂度，而是不确定性。
我把企业简化成两个循环。第一个循环属于市场、销售、产品经理和 CEO。在这个循环里，人们最关心的问题是：“这个方向到底行不行？”、“用户会不会买单？”、“这个功能有没有价值？”他们最大的敌人，是市场不确定性。因为没有任何商业决策能够保证成功，所以唯一能做的事情，就是不断尝试、不断上线、不断获取反馈，然后根据反馈快速调整方向。在这种环境里，速度自然就成了最重要的东西，因为谁能更快进入市场，谁就更有机会降低不确定性。
而 AI 恰恰极大强化了这种逻辑。AI 可以帮助团队更快生成代码、更快做原型、更快验证需求，因此从业务角度来看，它几乎像一种革命性的生产力工具。很多人因此开始相信：既然 AI 已经可以高速生成代码，那么软件开发本身似乎也会越来越廉价。
但问题在于，当公司真正拥有客户之后，第二个循环就会出现。
这个循环不再关心“探索”，而是开始关心“稳定”。系统必须持续运行，支付不能中断，线上服务必须可靠，Bug 必须有人能修，代码必须有人看得懂，新人也必须能够接手系统。于是，资深开发者开始拼命控制复杂度，因为他们真正负责的，并不是“把功能做出来”，而是“保证整个系统能够长期稳定运行”。
这时候，双方的矛盾就出现了。
业务团队关心的是如何更快降低市场不确定性，而资深开发者关心的是如何控制系统复杂度。于是双方虽然都在讨论“开发”，但实际上讨论的根本不是同一个问题。业务团队希望的是“更快上线”，而资深开发者担心的是“系统越来越危险”。当资深开发者不断强调维护成本、长期复杂度和技术债务时，这些话对于业务部门而言往往毫无说服力，因为他们真正焦虑的是：如果现在不上线，会不会直接失去市场机会。
我对此给出了一个非常精准的总结：你不能用自己的问题，去解释别人的问题。
资深开发者之所以总是显得“保守”“拖慢进度”，并不是因为他们不懂业务，而是因为他们一直在用“复杂度管理”的语言沟通，而公司其他人真正关心的，却是“如何更快减少不确定性”。这两套语言天然无法对接，于是沟通自然失败。
真正优秀的资深开发者，其实非常擅长一件事情：用尽可能少的建设，完成真正需要完成的目标。当团队想做复杂的新功能时，他们可能会先在现有界面放一个按钮测试用户行为；当团队想搭建完整的数据分析系统时，他们会先思考：“我们到底想验证哪个决策？”很多时候，他们甚至会直接使用 Google Forms 之类现成工具，因为他们非常清楚，公司真正需要的往往不是“完整系统”，而只是“验证问题”。
于是我提出，每个资深开发者都应该学会一句话：
“Can we try something quicker?”
“我们能不能先试一个更快的方法？”
这句话之所以厉害，是因为它同时满足了双方的需求。它既承认业务真正需要的是速度，也保留了工程上的克制；它没有直接否定需求，而是把“减少复杂度”重新翻译成了“更快降低不确定性”。我认为，这才是资深开发者真正缺失的沟通能力。
而文章最有意思的部分，其实是关于 AI 的最后讨论。很多人现在会说，既然 AI 已经可以高速生成代码，那么为什么还需要资深开发者去控制复杂度？反正代码生成越来越便宜，开发速度越来越快。
我认为，问题恰恰就在这里。
因为 AI 可以生成代码，但它并不会对系统负责。
AI 极大强化了“速度循环”，却同时在破坏“稳定循环”。如果 AI Agent、初级开发者、非技术人员，甚至老板本人，都开始不断往系统里添加代码，那么最终得到的，很可能是一个没人真正理解、但又越来越庞大的系统。这样的系统或许能够极快上线，但稳定性、可维护性和可调试性都会持续下降，最后整个系统会逐渐变成一个危险的黑盒。
于是我提出了一个很有意思的未来构想。我认为，也许未来的软件开发会被拆成两个系统：一个负责“速度”，另一个负责“稳定”。
第一个系统可以被称为 “Speed System”。这个系统专门用于快速试错，允许 AI 大量生成代码，允许快速实验、快速上线和快速验证需求。在这里，可维护性并不是最重要的问题，重点只有一个：尽快获取市场反馈。
而第二个系统则是 “Scale System”。这个系统由资深开发者负责维护，它强调稳定性、可理解性、可扩展性和长期维护能力。那些已经被市场验证有效的功能，最终会被重新工程化之后，再进入这个真正长期运行的系统。
在这种结构下，AI 和业务团队更像是在快速生成内容，而资深开发者则更像“编辑”。他们负责筛选、重构、稳定化和长期维护，让系统真正能够持续运行。
也正因为如此，我最后提出了一个非常有意思的问题：
未来的资深开发者，也许不再是“软件作者”，而会更像“软件编辑”。