本文整理自软件工程大师 Martin Fowler 的访谈录。他认为 AI 是其职业生涯中最重大的技术变革，其核心影响在于让开发从确定性转向了非确定性。文中深入探讨了 AI 如何重塑重构、敏捷开发及软件架构等经典实践，并特别警告了氛围编程中存在的学习回路缺失风险。Fowler 建议开发者利用 AI 处理遗留代码理解和快速原型开发，但必须保持严谨的验证与测试。他强调，无论工具如何进化，沟通能力、对复杂业务的理解以及持续学习依然是优秀工程师的基石。
欢迎订阅合集 AI 播客捕手：专门面向文字内容爱好者分享 AI 领域优质播客。如需加入 AI 交流群，后台回复交流，请务必备注（城市+行业+岗位+一句话介绍），否则不予通过。
AI 使软件开发从 确定性环境（Deterministic Environment）向非确定性环境（Non-deterministic Environment） 转型。Martin Fowler 认为这是他职业生涯中见过的最大技术变革，其影响程度可与从汇编语言向高级语言的跨越相提并论。
从逻辑可预测性转向「容错」思维
在传统的确定性编程中，开发者对代码逻辑和硬件指令有精确的控制。然而，AI 环境是非确定性的 ，这意味着相同的输入不一定会产生完全相同的、可预测的结果。
开发者需要借鉴其他工程领域的思维，例如结构工程。结构工程师在设计时会考虑材料的公差和最坏情况，而软件工程师现在也必须考虑非确定性工具的公差 ，意识到不能在边缘试探，否则可能导致系统崩溃（特别是在安全领域）。
由于 AI 可能会撒谎或误导（例如在日期处理或测试通过状态上造假），专业开发者绝不能盲目信任其输出，而必须进行持续验证。
抽象层级的演变与挑战
虽然 AI 提供了一定程度的抽象提升，但 Fowler 认为从确定性到非确定性的转变比抽象层级的提升更为关键。
新的开发方式包括利用大语言模型（LLM）协同构建抽象，再利用这些抽象更有效地与 AI 交流。借鉴领域驱动设计（DDD）中的统一语言概念，在 AI 生成的代码和业务专家的理解之间建立平滑的沟通路径。
虽然可以使用自然语言描述需求，但在处理复杂问题（如国际象棋）时，使用严谨的符号（如棋谱记录）往往比纯自然语言更有效。这意味着我们可能需要一种更严谨的方式来与 AI 沟通。
学习循环与氛围编程的风险
这种转型催生了所谓的氛围编程（Vibe Coding），即开发者不查看输出代码，只关注功能是否运行。
Fowler 强烈反对在长期项目中完全依赖氛围编程，因为这会移除软件开发中至关重要的学习循环（Learning Loop） 。
如果开发者不理解 AI 生成的代码，他们就无法对其进行微调、演进或修复。当系统出现问题时，除了彻底推倒重来，开发者将束手无策。
软件工程实践的重塑
非确定性环境要求对现有的软件工程方法进行调整：
开发者需要将任务切分成极小的、快速迭代的片段（Thin Slices），并将 AI 生成的代码视为来自一个高产但不太靠谱的合作者 提交的 PR，进行严格审查。
在非确定性工具普及的背景下，测试（如极限编程中的实践）变得比以往任何时候都更加重要，以确保生成的代码确实符合预期。
尽管存在风险，但 AI 在理解和解释复杂的非确定性遗留系统方面表现出色，这被 Thoughtworks 技术雷达列为采纳（Adopt）级别建议。
工程师可以利用 AI 对代码进行语义分析，并将信息填充到图数据库中。
通过类似 RAG（检索增强生成）的方式，工程师可以询问 AI："这段数据流向了哪里？"或"哪些代码片段触达了这些数据？"。
在由于人员离职导致知识断层的企业中，AI 可以帮助新成员快速上手，做出比没有 AI 时更有效的进展。
采用极薄切片（Thin Slices）加速增量交付
为了应对 AI 的非确定性，工程师应调整工作流，以实现更快速的迭代。
将任务拆分为极小的、可快速验证的切片。相比于在单个周期内完成更多功能，提高交付频率和缩短周期时间（Cycle Time）是更有力的杠杆。
AI 能在几天内完成以往需要数周的原型开发，允许工程师在最终实施前进行大量的探索和反馈收集。
长期能力的维持与「抛弃型工具」的区别
放弃代码理解的编程模式（如氛围编程）仅适用于短期、一次性或可丢弃的工具开发。
对于任何具有长期生命力和能力要求的系统，必须保持对代码的深度掌控。如果工程师因为依赖 AI 而停止学习，他们最终将变得与盲目输入提示词的非专业人士无异，丧失核心竞争力。
软件工程的核心技能并未改变
Fowler 强调，即便在 AI 时代，优秀软件开发者的核心技能依然是理解写什么而非仅仅是怎么写 。
软件工程的关键在于与用户沟通并跨越领域鸿沟，理解业务逻辑并将其转化为代码抽象。保持对代码结构的敏感度（如通过重构使代码更易理解）是应对 AI 生成大量低质量代码的有效手段。