AI 没有简化软件工程:它只是让糟糕的工程更容易
⚠️ 核心观点: AI 并没有让软件工程变得更简单,它只是让制造糟糕的软件变得更容易。
🔑 核心要点
- 代码从来不是难点 - 编写代码从来不是工作中最困难的部分
- 对齐问题 - 规格、测试和实现必须保持对齐,否则系统会漂移
- AI 加速漂移 - 当代码生产速度超过工程纪律时,spec drift 开始加速
- 历史重演 - 与 Visual Basic 时代相同模式的放大版
核心论点
软件行业非常努力地说服自己软件工程不再必要。现在任何人都可以做到。我称之为胡扯!
代码从来不是难点
关于软件开发最大的误解之一是编写代码是工作中最困难的部分。它从来不是。
- 把语法输入机器总是构建系统中最无聊的部分
- 困难的工作在于:决定系统应该如何行为、确定组件如何交互、确保系统随着增长保持可理解
- 这些问题需要设计决策、仔细推理,以及理解变化如何随时间在系统中传播
AI 加速漂移
大型语言模型显著加速了代码生产。这是它们最大的优势。这也是危险出现的地方。
- 当代码生产速度超过周围的工程纪律时,创造 spec drift 的力量开始加速
- 代码可以比审查它的人更快地生成
- 如果底层行为没有被清楚地理解,更快的速度只是加速了复杂性变得无法管理的时刻
对齐问题
可靠软件依赖于很少被工程外部谈论的东西:对齐。
- 系统从一个关于应该如何行为的想法开始
- 那个想法被写成规格
- 工程师将规格翻译成测试和生产代码
- 为了系统保持可靠,这三件事必须保持对齐
Spec Drift(规格漂移)
当这三者分道扬镳时:
- 规格描述系统不再实现的行为
- 测试验证部分行为但遗漏其余
- 后来的工程师被迫通过阅读可能反映或不反映原始设计的代码来推断系统真正如何行为
我们以前见过
在 1990 年代,我们听到了类似关于 Visual Basic 这样的工具的类似说法。承诺是编程已经民主化,不再需要专业知识。
今天我们看到的是同样的模式,只是被放大了。
- 不是降低构建应用程序的障碍
- 大型语言模型降低了产生代码本身的障碍
- 由此产生了诱人的信念:专业知识不再必要
飞机维护问题
现代飞机是极其复杂的系统。商用飞机包含数百万个零件和数千个互联子系统。
诊断问题不仅仅是拥有正确工具或遵循清单的问题。它需要经验。它需要判断。它需要理解这些系统在实际运行条件下如何表现。
工具帮助。手册帮助。诊断系统帮助。但这些都不能取代维护飞机的人员的专业知识。
然而,这正是软件行业现在对自己的论点。
为什么重要
这篇文章是对当前 AI 热潮的重要平衡。它提醒我们:
- 工具的改变不等于问题的解决
- 工程纪律和专业知识仍然不可替代
- AI 是放大器——既放大了好的实践,也放大了坏的实践
- Spec drift 是真实存在的威胁
评价
这是一篇关于 AI 对软件工程影响的深度反思文章。对于正在裁员和重组工程团队的领导者来说,这是必读之作。