2005 年，美国空军在招标书里写明，要的是「真正现成的软件：不加修改，谁都能买到」。它想用一套系统，替换掉几百个在全球管零件、油料和飞机的老程序。在空军看来，买商业软件，就能省掉大部分定制开发。2006 年的一份策略也写明，项目不对软件做任何修改。
可软件一碰上空军原来的做法，事情就变了。据承包商说，它提出让空军的流程去适应软件时，空军不肯，反过来要求改软件。2012 年，国防部叫停了这个叫 ECSS 的项目。十多亿美元花了出去，没有交付任何能用的功能。参议院的调查报告说，这是「浪费了 11 亿美元纳税人的钱，白费了八年的努力」。其余经过见案例。
本质与偶然
工具能省下写代码的活，却替不了你决定要做什么。
提出布鲁克斯定律的计算机科学家弗雷德·布鲁克斯，在 1986 年的一篇论文里讲了这个道理。他借用亚里士多德的说法，把软件工作分成两部分。本质，是软件的概念结构：有哪些数据、彼此什么关系、系统要做哪些事。偶然，是把这个结构用编程语言写出来、塞进机器里的那些活。
布鲁克斯写道，过去的大进步，大多是在对付偶然的部分：高级语言、更快的上机周转、更好的工具。可除非偶然的工作占到全部工作量的九成以上，否则就算把它压到零，效率也翻不了十倍。所以他展望「此后十年」，给出的判断是：「没有任何一项单独的进展，无论是技术还是管理方法，能指望让生产率、可靠性或简洁性提高哪怕一个数量级。」
他还写道：「构建软件系统最难的单一环节，是准确地决定要做什么。」
买来的软件不会替你做决定
布鲁克斯并不悲观。「怀疑不等于悲观，」他写道。许多小的改进，只要「有纪律、持之以恒地」推进，合起来「确实能带来一个数量级的提升」。「没有捷径，但有路可走。」他的第一条建议，是能买的就买，别自己造。他写道，软件大众市场的兴起，是「软件工程最深远的长期趋势」。
ECSS 正好显出这条建议的边界。买现成的软件，本来是想省掉大量偶然的活，虽然买来的三个产品后来还得自己拼起来。买不来的，是怎么订零件、怎么管维修的决定，而这才是本质的问题。软件预设的答案和空军习惯的答案一冲突，据承包商说，空军选择了改软件。参议院调查人员把失败主要归于抵触改变业务流程、缺乏领导、风险没有管住。
布鲁克斯的其他几条建议，直接对着本质：快速做原型，弄清用户到底要什么；一块一块地把系统「养」大，别一口气建成；找到并培养出色的设计者。
设想一家小慈善机构，买了一套捐赠人管理系统，想整顿乱糟糟的筹款工作。如果事先没人商定，一位捐赠人的关系归谁管、认捐什么时候才算到账，新系统可能只是把同样的混乱，排成了更整齐的表格。
AI 是不是那颗银弹？
AI 编程工具是最新的候选，早期证据两头都有。2023 年发表的一项实验里，开发者要用 JavaScript 写一个小型网页服务器。能用 GitHub Copilot 的一组，完成任务的平均用时比不用的一组少了 55.8%。
乔尔·贝克尔等人 2025 年的一项随机对照试验，看的是更难的情形：16 位经验丰富的开发者，在自己熟悉的大型开源项目里完成 246 个真实任务。开工前，他们预计 AI 工具能把用时缩短 24%；做完后，他们觉得缩短了 20%。实际上，允许用 AI 的任务，用时反而多了 19%。作者提醒，这个结果针对的是 2025 年初的工具和这一种场景。
布鲁克斯的二分法提供了一种解读。一个清清楚楚、规格明确的小任务，主要是偶然的活，正是工具擅长压缩的那种。在一个庞大、成熟的项目里改东西，本质的成分更多：得知道这段代码是干什么的，改动不能弄坏什么。这只是一种解读，两项研究都没有检验过。
回到 2005 年，空军买到了它想要的软件。它买不到的，是关于自己该怎么干活的那个决定。