当 AI 开始写代码,软件工程还剩下什么?——解读《ThoughtWorks 技术雷达 Vol.34》

ThoughtWorks 是一家全球领先的技术咨询公司，专注于帮助企业在数字化转型中采用现代技术，提升业务和技术能力。它成立于 1993年，总部位于美国芝加哥，但在全球范围内有多个办事处。ThoughtWorks 为不同领域的企业提供技术解决方案，重点关注 软件开发、技术创新、敏捷实践、数字化转型 和 产品设计。

当 AI 已经能写代码，软件工程这门学科，还剩下什么？

在最新发布的《ThoughtWorks 技术雷达 Vol.34》中，以往聚焦工具、框架和架构的变化，这一期是在重新定义“什么是工程”。

回看前几期技术雷达：

• 早期： 云原生、微服务、DevOps

• 中期： 数据工程、平台工程

• 近期： 生成式 AI、LLM 应用

到了 Vol.34：AI 不再是工具，而开始成为“参与者”。

这意味着过去的软件系统，本质是“人写代码 → 机器执行”。

而现在，正在变成：人定义目标 → AI 生成实现 → 人约束结果。

在传统软件工程中，评估一个技术看几个维度：稳定性、性能、社区成熟度、生态。但在 AI 时代开始失灵。不再面对一个“稳定工具”，而是一个持续变化、行为不完全可预测的系统。

结论： 技术评估正在从“静态判断”变成“动态实验”。评估的不再是技术本身，而是“系统在特定约束下的表现”。

技术雷达提出一个非常关键的判断：保留原则，放弃模式。

过去几十年，软件工程沉淀了大量“最佳实践”，如分层架构、设计模式、微服务拆分原则。

这些东西的前提是：代码是人写的、逻辑是确定的、系统是稳定的。

但在 AI 生成代码的世界里，代码可以随时重写，结构可以动态变化，模式失去了稳定存在的基础。

然而，原则反而变得更重要。

• 可测试性： 如果 AI 生成的代码无法验证，那它就是废纸。

• 可演化性： 既然代码是生成的，系统必须能够快速吸收新的生成结果而不崩溃。

• 简单性： 越简单的系统，越容易被 AI 准确理解和维护。

工程的重点，从“如何设计结构”变成了“如何定义边界与约束”。

在 Vol.34 中，一个关键词是：Agent。

与传统软件不同，Agent 会自主决策、调用外部工具、访问数据。这种带来了新的风险：“权限饥渴的智能体”。

风险预警：

• 提示词注入： 用户指令可能篡改 Agent 的顶层逻辑。

• 数据泄露： Agent 在调用工具时可能无意中暴露敏感上下文。

• 非预期操作： AI 可能在尝试解决问题时，误删数据库或错误调用付费 API。

安全的核心从“防人”变成了“防 AI 的行为失控”。

过去我们做 API 鉴权，现在我们需要为 AI 打造一套“数字笼子”。

这是整期雷达最重要的一个概念：约束工程。简单说：未来的工程，不是写代码，而是约束 AI。

1. 用测试约束 AI

过去是“写代码 → 写测试”，现在变成“写测试 → AI 生成代码 → 用测试筛选”。测试不再是验证工具，而是生成代码的“模具”。

2. 用护栏限制行为

这包括输入限制、输出格式控制、权限边界。你不再相信 AI“会做对”，而是要确保它“做不坏”。

3. 持续验证，而不是一次交付

传统软件是线性的交付过程，AI 系统则是“生成 → 验证 → 再生成 → 持续校正”的闭环。系统是“活的”，需要被持续监控。

软件工程的本质，从确定性系统变成了概率性系统。

• 确定性系统： $f(x) = y$。同样的输入，永远得到同样的输出。

• 概率性系统： $f(x) \approx y$。同样的输入，可能得到不同的输出。

这引入了一个危险的概念：认知债。

它不同于技术债。技术债是代码写的烂，以后要重构；

而认知债是你不再理解系统为什么这样工作。当代码规模由 AI 快速膨胀，而人类由于认知带宽有限无法完全解析逻辑时，这种债务会指数级增长。

回到最初的问题：当 AI 能写代码，人类还做什么？

工程师将从 编码者转变为 约束设计者。

你的工作内容将发生如下位移：

1. 定义目标： 准确描述业务需求，而非逻辑实现。

2. 设计边界： 规定 AI 绝对不能踩的红线。

3. 构建验证系统： 打造能够自动过滤错误代码的“质检流水线”。

4. 控制风险： 在概率性的输出中寻找确定性的工程交付。

换句话说：你不再直接构建系统，而是构建“构建系统的系统”。

这是一场软件工程范式的重写。

它带来的不是更简单的开发过程，而是：

• 更复杂的控制问题

• 更高的系统不确定性

• 更严苛的工程纪律

当代码变得廉价，约束就变得昂贵。 未来真正稀缺的能力，能够在高阶抽象层面设计出让系统始终在正确边界内运行的能力。

1. 智能体时代的AI产品经理：入门到精通