夜雨聆风如今，AI 工具已经能够替代大量重复性、机械性的编码工作。
AI能够在一天之内编写出过去需要程序员一个月才能完成的代码。
这是否意味着编写代码的能力已经变得无关紧要了？
软件工程师的价值究竟在哪里？编程这件事儿真的即将消失了吗？
答案恐怕并没有这么简单。
软件工程的本质是管理复杂度
长期以来，软件工程领域深谙：编程不仅仅是快速编写代码，更重要的是“管理复杂度”的艺术。
正如 Edsger Dijkstra 所言，“编程的艺术就是组织复杂性”。
Rich Hickey 也在一次演讲中这样描述编程："因为我们大脑同时能抛的球（关注的事物）是极其有限的，所以你必须做出选择：你希望手里的球有多少是偶然复杂性，有多少是问题本身的复杂性？"
这就意味着，即便 AI 可以快速生成代码，真正难解的却是需求本身带来的“本质复杂度”，以及如何在这个复杂系统中保持清晰的设计。
因此，当 AI 将大量机械化的编码交到我们面前时，我们更应该问的是：在新的环境下，软件工程师的核心竞争力究竟是什么？
要回答这个问题，我们首先需要厘清两个概念：战术性编程和战略性编程。
战术性编程与战略性编程
在 John Ousterhout 的软件设计哲学里，有一对鲜明的概念来区分编程的两种思维模式：战术性编程与战略性编程。
战术编程者的目标是“让下一个功能或缺陷快速可用”，可以接受一些权宜之计和折中手段，只要能尽快见到结果。
例如，他可能会为了加快进度而写出冗余代码、跳过某些重构步骤，完成当下的需求便转身开始下一个功能。
Ousterhout 甚至形象地把极端的战术编程者称为“战术龙卷风”。
他们编程速度惊人，迅速交付功能，但往往在代码基地里留下混乱的痕迹。
他们似乎是短期英雄，却给团队留下了日后无法承受的维护负担。
与之相对，战略编程者着眼长远，把主要精力投入到构建优秀设计上。
他们会问：“这个系统如何能够更易维护？改动一处需要付出多少代价？”
在每次开发中持续投入时间，维护代码结构的清晰和健壮。
战术性编程关注“完成任务”，而战略性编程关注“系统质量”。
Ousterhout 将两者作了简要对比：“战术编程者为完成当前任务而优化，结构上可以牺牲一些好处；
战略编程者则投入额外的努力保持系统结构的整洁，从而让后续的改动更安全、成本更低”。
战术性编程今天看似更快，但日后会付出更高成本。
偶然复杂度和本质复杂度
这两个概念的根源其实并不新鲜。
早在数十年前，软件工程的先驱就已经意识到：解决"问题的本质复杂度"决定了开发的难度。
Fred Brooks 在《没有银弹》中区分了本质复杂度和偶然复杂度。
前者源自问题本身的不可简化的复杂性，相当于战略性编程；
后者则是工具或实现方式带来的额外负担，相当于战术性编程。
AI 时代，AI 工具只能消除偶然复杂度（如模板代码、语法细节），而本质复杂度——如业务规则的深度、系统运作的逻辑——依然需要人来理解和设计。
所以，单纯强调快速写完代码而忽视系统的整体可理解性，最终就会陷入一场代码债务危机。
相反，那些能预见、抽象和管理复杂度的人，才能确保系统长期健壮。
写代码只是手段，降低复杂度才是目的。
既然复杂度是本质难题，那人类在软件工程史上是如何解决复杂度问题的呢？答案就是“抽象”。
用抽象来降低复杂度
回顾软件工程历史，每一次编程语言抽象层次的跃升，都让“减少机械劳动、提升抽象能力”成为时代主旋律。
最具代表性的转变当属从汇编语言到高级语言的过渡。
早在上世纪五、六十年代，FORTRAN、COBOL 等高级语言出现后，程序员再也不需要一行行地编写机器指令，程序开发效率大幅提升。
更高层次的抽象让软件能做更多复杂的事情，新的任务和挑战也随之产生。
结果是，虽然汇编技能的重要性有所下降，但程序员的工作重点从底层细节转向了更高层次的问题，如算法设计和系统架构。
类似地，从 C 语言到 Java 的转变中，也一样。
C 语言引入了更简洁的结构和指针抽象，而 Java 又在此基础上加了自动内存管理、跨平台特性和丰富库，极大降低了开发复杂企业级系统的门槛。
结果是，程序员不再纠结于 malloc/free 或指针悬挂等低层细节，而更多地关注面向对象设计、接口设计和业务模型。
这期间，“记忆分配的技能”重要性下降，“如何设计可扩展架构”的技能重要性上升。
从结构化编程到面向对象编程、函数式编程等，这一切看似各有侧重，但背后都在告诉我们：反复写重复代码、关注局部细节并不是工程师最大的价值，如何以更高层次的思想指导开发才是关键。
软件工具越厉害、把底层杂活（偶然复杂度）干得越干净，程序员就越不需要去操心那些琐碎的细节，越能集中在“解决真正的业务问题（本质复杂度）”上。
AI解决的是偶然复杂度问题
在整个软件开发流程里，AI 最容易搞定的就是按图索骥写代码：你把需求和例子喂给它，它帮你把代码搬出来，再顺手做个简单检查。
这些可替代任务背后的共同特点是：它们往往遵循模式、逻辑清晰、无需复杂上下文推理，都属于"偶然复杂度"范畴。
这与人类传统的“写代码”阶段如出一辙，但由于 AI 工具的大规模预训练，这个过程对 AI 而言已变得廉价。
于是，曾经占据开发者大量时间的机械性编码工作（战术性编程），如编写接口层、工具类、数据结构，开始被 AI 迅速取代。
AI无法解决本质复杂度问题
当 AI 接手了大量的代码输出和机械工作之后，人类程序员将不可避免地将精力转向那些AI难以替代的任务，也就是更具战略性的职责。
为什么如此？核心原因仍然回到软件复杂度和责任层面：AI 可以生成可工作的代码，但它很难确保整个系统从设计到维护的健壮性。
首先，AI 生成代码很容易引入质量和安全问题。AI在不自觉中可能会写出更不安全的代码，同时却对其安全性过于自信。
无论 AI 生成多少行代码，必须经过工程师设计的验证机制和严谨审查。
其次，复杂系统需要全局视角和权衡。
AI 生成单个函数时并不关心全局架构：它可能在一个地方添加冗余代码、在另一个地方重复逻辑，而不会主动优化系统结构。
这完全依赖于AI执行任务的上下文，而上下文的投喂，则完全是人的工作。
"一个缺乏设计意识的模型会倾向于复制代码块，而不是提取共享逻辑；它更愿意局部修补，而不是重新思考接口；它写出的是一个可以运行的结果，而不是同事愿意接手的干净设计"。
AI 提交的代码往往能运行但在悄悄地退化设计，把后续维护的负担留给了人类开发者。
因此，软件的长期健康和复杂度控制依然需要工程师来负责。
当编码任务被解放出来之后，剩下的挑战正是对问题的定义与分解、对系统架构的设计与演进、以及对业务价值的把控。
这些就是Brooks所言的"本质复杂度"，John Ousterhout 口中的"战略性编程"。
AI时代软件开发范式的改变
传统的开发流程是：需求 → 设计 → 编码 → 测试 → 部署。
而在 AI Agent 主导的时代，一个更加意图驱动的流程已经开始成形：开发者提供意图和约束条件，AI 代理负责规划并执行实现，最后人类进行验证，然后不断迭代。 （harness + loop engineering）
最终软件工程师的角色退居两端:
上游负责精确地表达意图、限制条件和优先级
下游负责验证结果是否满足这些意图，并对不符合的地方给出反馈。
中间的“规划—编码—测试—部署”环节，几乎全部由AI自动完成。
软件工程师的能力迁移
随着AI时代软件开发范式的改变，软件工程师的能力随之发生了迁移。
从写大量框架代码到定义业务系统
过去工程师需要熟练掌握 Spring、Hibernate、Express 等框架的细节，用它们构建应用。
未来，他们更多的任务是定义系统的整体架构、选择哪个框架和技术栈、更关注业务边界和模块划分。
例如，不再纠结于 Spring 注解的写法，而是把精力用在怎样设计微服务接口、数据库模型和缓存策略上，让 AI 来替我们生成具体的框架代码和配置。
限制技能不再是编码速度，而是用足够清晰的方式表达意图和约束。
从修复Bug到设计验证机制。
当 AI 生成了大部分代码时，问题就不再是手写一个 bug fix，而是思考如何验证代码满足需求。
这意味着开发者需要擅长定义测试用例、监控和校验策略，而不是逐行检查输出的代码。
例如，与其自己调试 AI 写出的代码，不如设计一个完善的自动化测试管道，让 AI 在提交代码时自动运行测试并修正错误。
未来的工程师要成为“验证专家”，擅长构建让 AI 自动校验的机制。
从学会各种API/框架用法到选择正确技术方案
过去开发者通常需要了解各种库和框架的使用方法，新技术层出不穷。
未来，这些具体用法可以通过 AI 自动补全和示例获取，但评估和选择技术的能力更为重要。
工程师需将视野提升到“这个系统到底适合用微服务还是单体、是用云函数还是容器、是选用现成工具还是自研”的层面。
AI 会提供多种方案样例，工程师的工作是根据业务需求和非功能性要求做权衡和决策。
从增加代码量到承担系统责任
过去衡量开发效率可能是代码行数或功能交付数量。
未来，优秀工程师的衡量标准会转向系统整体的质量：架构是否合理？系统演化是否高效？
换言之，工程师仍然需要代码技能（至少要对 AI 的输出有所理解），但重心已从写多少代码变为对最终工程结果的负责。
如上所述，软件工程师能力的迁移路径是：
过去：编码能力 → 现在：编码能力 + AI 协作能力 → 未来：战略性工程能力。
从”如何写好一行代码“转到“如何写出正确的问题定义”；
从“如何调试bug”转到“如何建立让AI自己发现并修复bug的流程”；
从“如何用框架”到“如何根据需求选型”。
同时，也需培养与人沟通、产品思维和持续学习等软实力，因为未来的协作对象更多是AI，而更复杂的架构和产品决策需要多方协同。
写在最后
尽管 AI 在加速我们撤离编写代码的工作，但它并不意味着程序员这个职业会消亡。
历史上每次技术升级也都有人怀疑：机器取代后，程序员该何去何从？
事实是，新的工具链往往诞生新的工作形式，而不是简单消灭工作。
未来优秀的软件工程师，将不再仅仅是那个敲键最勤的人，而是那个能提出正确问题、设计正确系统、利用 AI 实现功能，并对最终结果承担责任的人。
在这个从战术性编程向战略性编程迁移的过程中，往往需要经验和全局视角，需要我们持续学习和积累，不是所有人都能轻松迁移过去。
但历史告诉我们，具备抽象思维和设计能力的软件工程师终将成为稀缺资源。
正如一位专家所总结：“AI是快速的战术程序员，它需要一个在其之上思考战略的人”。
而那个人，正是我们自己。