夜雨聆风
软件工程正在被AI重塑——8大洞察
图：Thoughtworks Future of Software Development Retreat，2026年2月，Deer Valley，Utah
开篇：一个没有答案的聚会
2026年2月，美国犹他州，Deer Valley。全球软件行业顶尖的一批人——Martin Fowler、Thoughtworks CTO Rachel Laycock、资深工程师、架构师们——围坐在一起，探讨一个没人有确定答案的问题：
“AI负责写代码，那工程本身去哪了？”
这就是Thoughtworks”软件开发的未来” Retreat。三天激辩，没有发表宣言，没有制定路线图。最大的收获，是一个共同的问题清单。
本文综合了Martin Fowler的全程记录、CTO Rachel Laycock的复盘笔记、以及多位与会者的真实分享，整理成以下八个核心洞察。
来源：Martin Fowler官方博客（2026年2月18日）+ Thoughtworks CTO Rachel Laycock复盘文章。均有据可查。
一、严格性去哪了？
Chad Fowler开场时说了一句被广泛引用的话：
“如果我们对代码的重视程度下降了，那我们的严格性就必须转移到别的地方去。”——Chad Fowler
AI正在取代大量编码工作——但工程的本质是严格性（rigor）。当代码不再需要人亲手写，严格性就必须找到新的载体。
Martin Fowler记录了分会场里反复出现的问题：AI负责写代码，工程去哪了？没有人给出相同的答案，但所有人都认同——这个问题很紧迫，不能回避。
二、AI是什么？它只是个放大器
图：Rachel Laycock的核心观点——AI放大你已有的优势，也会放大你已有的问题
Thoughtworks CTO Rachel Laycock在The New Stack采访中反复强调同一个观点：
AI被称为’伟大的颠覆者’，但它实际上只是一个加速器——无论你已有的东西是好是坏，它都会加速放大。AI已经被验证对个人开发者的工作和代码编写速度有显著影响。但是，由于写代码从来就不是瓶颈——如果传统的软件交付最佳实践还没有到位，这个速度放大器就会变成债务加速器。——Rachel Laycock，Thoughtworks CTO
AI会放大你的流程弱点，而不是帮你弥补它们。在流程不成熟的情况下引入AI，只会让问题更快暴露。
三、Supervisory Engineering：一个新中间层正在浮现
图：Supervisory Engineering——在AI代理和最终目标之间建立一个监督层
Martin Fowler总结了与会者讨论出的一个重要概念：“监督工程”（Supervisory Engineering）——这是继”编码”和”架构设计”之后浮现的一个新的工作类别。
Supervisory Engineering负责三件事：
- 指导AI代理完成复杂任务
- 评估AI输出的质量和准确性
- 校准信任边界：告诉团队何时依赖AI，何时需要人工复核
这不是一个新的职位，而是一个新的职责类别——Martin Fowler将其描述为”中间循环”（Middle Loop），介于执行层和战略层之间。
Staff Engineer的角色正在随之演变：从直接写代码，转向代理编排（Agent Orchestration）和治理。产品管理与工程的关系也面临重新谈判——当AI可以快速实现功能时，”做什么”的决策比”怎么做”更核心。
四、被忽视的代价：AI正在增加认知负担
图：AI辅助开发带来的认知负担——上下文膨胀、监控负担、知识流失三重风险
AI正在增加开发者的认知负担（cognitive load），并可能导致疲劳和倦怠。
这个问题有三个维度：
- 上下文膨胀：AI生成的代码量大到难以全部review，认知超载
- 监控负担：监督AI代理的工作，本身就需要持续注意力
- 知识流失风险：过度依赖AI，团队成员对系统的集体理解会退化
与会者提出的应对策略：建立规律的”人工检查点”、加强团队内部知识共享、从关注开发速度转向关注理解深度和系统健康度。
当AI接管了执行层，谁来理解系统？这个问题如果不刻意解决，团队会逐渐失去对系统的掌控力。
五、语言的演进：代码不需要人类可读？
图：编程语言演进——从汇编到AI原生语言，关注点从代码转向验证
更简洁、更安全的编程语言，在约束AI生成的代码方面可能更有价值。与会者讨论了专为AI代理设计的新语言——这类语言甚至可能不需要人类可读。
当人不再写代码，而是描述目标——Verification（验证）就比Code（代码）本身更重要。你关心的是AI代理的行为和结果，而不是它产生的源代码格式。
代码最终会从人类视野中消失。就像当年汇编被高级语言取代一样——我们不再直接操作机器码，但AI可以直接操作更低层的表示形式。
六、”自愈”和”自我提升”：两个被混淆的概念
图：Self-Healing（回归已知状态）vs Self-Improving（自主优化向更优状态）
会议对”自我修复系统”做了重要区分：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
Agent Subconscious（代理的潜意识）——由知识图谱驱动的系统，从历史事故中学习：为每个事故建立知识图谱记录原因、影响、修复路径；新AI代理启动时自动查阅这些图谱，从历史失败中学习。
此外还提出了”全系统变更超级账本“的概念：跨所有系统的变更记录汇总，由生成式AI聚合，为人类和AI代理两者提供可读的全局视图。
七、TDD：向AI表达意图的最强语言
图：测试驱动开发——在AI时代重新被发现的价值
Retreat中，一位重度使用AI编程工具的用户说了这句话，被Martin Fowler记录下来：
“感谢你持续倡导TDD（测试驱动开发）。TDD对我们有效使用LLM至关重要。”
核心逻辑：当AI负责写代码时，测试用例就是你和AI之间的”规范语言”。先写失败的测试，就是在给AI一个清晰的边界。
研究数据：Martin Fowler团队使用5000个真实程序、6种不同LLM测试发现，在健康代码库中，LLM重构产生的缺陷风险降低了30%。在不健康的代码库中，这个数字会显著更高。代码健康度，是选择AI工具的前提条件。
八、安全：整场Retreat最被低估的话题
图：AI安全三大风险——Agent权限过宽 / 提示词注入 / 新的攻击面
安全分会场的参与人数最少，但讨论的内容最令人警醒。一位大型企业的安全负责人分享：刻意将AI采用速度压慢，保持在领先水平约两个季度之后。
“我们不是在规避所有风险。我们只是需要管理它们。”——某大型企业安全负责人
三大AI安全风险：
- Agent的工具权限过宽
——特别是邮件等高危操作，一旦被攻破影响范围极大 - 提示词注入（Prompt Injection）
——恶意指令被混入AI上下文，导致非预期行为 - 新的攻击面
——AI系统的复杂性创造了传统安全工具无法覆盖的盲区
“其他工程学科在设计中会融入显著的安全系数。我们做到了吗？如果没有，我们的失败会比倒塌的桥梁更危险。”——Martin Fowler
平台团队需要在AI应用开发中扮演”快速通道”的角色——既要让AI落得容易，又要让安全不成为阻碍。平台思维是解决安全矛盾的关键。
结语：问对比答更重要
“我走进那个房间，以为会学到一些走在更前面的人的经验。那些坐在桌边的人，是软件行业最聪明的一些头脑。但没有人把所有问题都想明白了。不确定性比确定性更多。关于如何很好地使用AI，关于它对生产力真正的作用，关于角色如何转移，关于影响会怎样、事情会如何演变——所有人都在一边走一边找到答案。是的，我们离开时问题比答案多。但至少，我们现在对应该问哪些问题有了共同的词汇表。这可能是最有价值的收获。”——Annie Vella，Thoughtworks Future of Software Development Retreat 参会者
Annie Vella的这段话，是整场Retreat最真实的注脚。
从Martin Fowler到Rachel Laycock，从Chad Fowler到Grady Booch，所有人的共识是：AI是加速器，不是灵丹妙药。它会把你已经做对的事情放大，也会把你忽视的问题放大。
在AI浪潮中，真正的问题不是”我能不能用AI”，而是：
-
我的软件交付最佳实践到位了吗？ -
我的代码库健康吗？ -
我的团队能承受AI带来的认知负担吗？ -
我的安全护栏到位了吗？
先回答这些问题，AI才能真正成为你的优势。
延伸阅读：