过去的软件研发中，复杂问题往往由人来承载。
系统如何设计、边界如何划分、异常如何处理，这些并不会被完整写在文档里，而是沉淀在少数人身上。
经验更丰富的人，承担了更多不确定性，也成为组织中的关键节点。
这种分配方式长期存在，以至于我们很少去质疑它。
复杂系统，本来就需要更复杂的人来驾驭。
但最近，一些变化开始出现。
从自然语言理解需求，到任务拆解，再到代码生成与自动验证，AI 正在逐步参与到软件研发的多个环节。
这些能力最初看起来是分散的，但当它们被串联起来时，一种新的可能性开始出现。
原本需要由人来处理的复杂问题，开始被外化出来：
被表达，
被拆解，
被约束，
被验证。
复杂度不再完全停留在个体经验中，而是逐渐转化为系统的一部分。
如果从更细的角度来看，这种变化并不是“整体迁移”，而是发生在不同层次上。
在软件研发中，复杂度大致可以分为三类：
第一类是执行复杂度。
也就是写代码、处理细节、修复问题，这些围绕“实现”展开的工作。
第二类是表达复杂度。
包括需求如何被描述、任务如何被拆解、上下文如何组织，以及约束如何明确。
第三类是系统复杂度。
例如问题的定义、系统边界的划分、架构选择，以及各种 trade-off。
变化首先发生在执行复杂度这一层。
随着 Coding Agent 等能力的提升，越来越多的实现细节开始可以由系统完成。
执行复杂度，正在从人迁移到系统。
但复杂度本身并没有消失。
当执行这一层被接管之后，原本被掩盖的部分开始显现出来。
表达复杂度开始变得更加重要。
任务是否被清晰表达，约束是否被明确，直接决定了系统能否正确执行。
而系统复杂度也随之变得更加关键。
因为一旦系统参与执行，边界如何定义、流程如何组织、结果如何验证，都需要被明确下来。
这带来的变化，并不首先体现在“执行更快”。
真正的变化，发生在承载复杂度的位置上。
过去，复杂度集中在人身上；
现在，部分复杂度开始进入系统。
当这种转移发生时，一些原本依赖经验维系的能力边界，也会随之被重新定义。
这也解释了最近一些看似分散的现象。
有人在构建 AI 原生工作平台，让系统直接承接任务；
有人在讨论 Harness Engineering，让执行变成一个可控的系统；
也有人在不断强化代码生成能力，让“实现”本身变得更廉价。
这些变化指向的方向并不完全相同，
但它们背后，可能是同一个趋势：
系统，开始接管一部分原本属于人的复杂度。
当这种迁移持续发生时，差距也会开始改变。
过去的差距，更多体现在：
谁经验更丰富，
谁理解更全面，
谁能在复杂情况下做出更好的判断。
而现在，一个新的分界线正在出现：
不再是谁更会做，而是谁能把问题转化为系统，并让系统稳定运行。
当执行复杂度被系统接管后，系统复杂度开始变得更清晰，也更关键。
