在 Thoughtworks 的最新报告《The Future of Software Engineering》中：人们试图标出软件工程正在发生断裂和重组的地方。当 AI 逐渐接管代码生产这一传统核心活动时，工程实践的重心正在迅速迁移，而行业仍在摸索新的稳定结构。
在过去几十年里，软件工程的严谨性主要体现在两个环节：编写代码与代码评审。开发者通过逐行阅读代码保证正确性，同时也在这个过程中学习系统、建立共识、培养工程文化。但当 AI 可以大规模生成代码时，这种模式开始松动。报告反复提出一个关键问题：如果 AI 负责写代码，那么工程师的“工程能力”究竟转移到哪里？
讨论的结论相当清晰——严谨性并没有消失，它只是迁移了位置。越来越多团队把精力从代码本身转移到更上游的规格说明。因为当代码由 AI 根据说明自动生成时，规格就成为最关键的控制点。一个模糊或错误的规格会被 AI 放大成大规模错误。为了解决这一问题，一些团队重新启用了早已存在但曾被忽视的方法，例如结构化需求语法、状态机和决策表。这些方法并不是新技术，但它们为 AI 提供了足够明确的约束，从而减少生成错误实现的概率。
另一处严谨性迁移的方向是测试体系。许多实践者发现，测试驱动开发在 AI 编程时代反而变得更重要。原因很直接：如果先写代码再写测试，AI 很容易生成“验证错误行为的测试”。但如果测试在代码之前存在，AI 就必须生成能够通过这些测试的实现。某种意义上，测试正在成为一种新的提示工程方式——它用确定性的验证机制约束非确定性的生成过程。一些团队甚至开始把代码视为可替换的产物，而把测试集当作真正的核心资产。
还有一些团队尝试通过类型系统和约束机制来限制 AI 的行为。他们不再依赖事后审查，而是尝试让错误代码在语法层面无法表达。这种思路借鉴了形式化方法的理念：通过强类型系统和明确的约束定义，让 AI 在一个安全边界内工作。规格说明负责描述“应该改变什么”，而约束则定义“哪些地方绝不能改变”。当 AI 试图突破这些边界时，系统就会显式暴露新的架构问题。
随着这些变化，软件工程的逻辑也逐渐从“手工工艺”转向“风险管理”。不同代码的风险等级并不相同：内部工具、对外服务和安全关键系统的风险差异巨大。越来越多团队开始根据业务影响范围划分验证等级，而不是默认每一行代码都需要同样强度的人工审查。工程质量不再通过逐行检查保证，而是通过风险映射与自动化验证体系来控制。
在技术实践之外，这场转变还催生了一种新的工作形态。报告提出一个尚未被正式命名的概念——“中间循环”。传统的软件开发通常被描述为两个循环：开发者个人的编码调试循环，以及 CI/CD、部署与运维构成的交付循环。但 AI 的引入让两者之间出现了新的层次：工程师需要监督、评估和修正 AI 代理的输出。
这种工作不再是直接写代码，而是将问题拆解为 AI 可以处理的任务，判断 AI 的结果是否可信，并在多个并行的 AI 产出之间维持系统架构的一致性。擅长这项工作的工程师往往具备强大的系统理解能力和快速判断能力，他们不必阅读每一行代码，却能迅速判断结果是否合理。这种能力过去常被视为经验积累的一部分，而现在正在成为核心职业技能。
AI 的引入还改变了企业内部的技术结构。报告提出“代理拓扑”的概念，借鉴了团队拓扑理论。当 AI 代理成为组织中的新参与者时，系统架构不仅映射人类团队结构，也开始映射代理之间的协作关系。与人类不同，代理可以被无限复制并部署在多个团队中。例如，一个数据库专家代理可以同时服务多个团队，从而避免传统组织中专家资源的瓶颈。
然而，这种能力也带来了新的问题。AI 代理可以在几天内清空开发待办事项，但组织内部的决策、审批和跨团队依赖仍然保持着“人类速度”。结果不是交付更快，而是新的瓶颈出现。许多团队发现，限制开发效率的不再是工程能力，而是决策能力。当 AI 产生的方案多于管理层能够理解和批准的数量时，组织结构本身就成为系统的限制。
在报告中还讨论了软件系统的另一个长期目标：自愈与自我改进。理论上，AI 可以监控系统运行状态并自动修复问题，但现实距离这一目标仍然很远。大多数组织缺乏基本的前提条件，例如完整的变更记录、明确的代理权限体系以及足够强的回滚机制。事实上，许多专家认为，在实现 AI 自动修改代码之前，更重要的是构建完善的回滚、特性开关和可观测性系统。换句话说，真正的自愈能力首先来自工程基础设施，而不是 AI 本身。
更难解决的问题是知识的隐性化。资深工程师在处理故障时依赖大量经验判断，例如某个错误码往往意味着数据库连接池问题，而某个 CPU 峰值可能来自缓存失效。这些知识很少被系统化记录，却在关键时刻发挥作用。要让 AI 参与故障处理，组织必须把这些隐性经验转化为结构化知识图谱，让代理能够理解历史背景和上下文。
技术变化之外，软件工程职业本身也在重新排列。开发者体验和生产效率曾长期同步提升，但 AI 让两者出现分离。一些公司发现，即使开发者感觉更疲惫、认知负担更高，整体产出仍然在上升。这种“效率—体验悖论”迫使组织重新思考工程文化：是否应该继续以开发者体验为核心目标，还是将重点转向 AI 与人的协同效率。
与此同时，角色边界也开始模糊。工程师越来越多参与产品定义，而产品经理则被迫进入开发工具环境。设计、产品与工程之间的界线逐渐变淡。在这种结构变化中，资深工程师的重要性反而上升。他们拥有更强的系统理解能力，因此在监督 AI、协调架构方面更具优势。相反，初级工程师并没有被 AI 淘汰。AI 工具让他们更快越过学习曲线，并且年轻工程师往往更容易适应新的工具模式。
总体而言，未来很难确定，而当下可以确认的是：代码生产正在自动化，但工程思维并没有消失，而是迁移到规格、测试、架构和风险管理等新的位置。软件工程正在从“写代码的职业”逐渐转变为“设计与监督复杂系统的职业”。在这个转变过程中，技术、组织结构以及工程文化都在同步重塑。真正的挑战不是 AI 是否会写代码，而是当代码不再是稀缺资源时，工程师应该把精力投入到什么地方。