There Is Still No Silver Bullet
There Is Still No Silver Bullet
依然没有“银弹”
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. 在民间传说中，所有令人噩梦连连的怪物里，没有比狼人更可怕的了，因为它们会从熟悉的形象突然变异为恐怖的存在。为了对付它们，人们寻找能将其神奇地制服的银弹。
That’s how the most famous essay in software engineering opens. Fred Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering”, presented at the IFIP conference in 1986. It turns forty this year, which feels like the right moment to point out that it has never once been wrong. 这就是软件工程领域最著名论文的开篇。弗雷德·布鲁克斯（Fred Brooks）在 1986 年的 IFIP 会议上发表了《没有银弹：软件工程的本质与偶然性》（No Silver Bullet: Essence and Accidents of Software Engineering）。今年是该论文发表四十周年，现在正是指出它从未被证伪的最佳时机。
The essay’s famous claim is a prediction: “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” People mostly remember the title (if even that) and skip the argument. Which is a shame, because the argument is the part that explains the last three years of our industry better than anything written in the last three years of our industry 😵💫. 这篇论文最著名的论断是一个预言：“在技术或管理技术方面，没有任何单一的发展能在十年内带来生产力、可靠性或简洁性上一个数量级的提升。”人们大多只记得标题（如果还记得的话），却忽略了其中的论证。这很可惜，因为正是这些论证，比过去三年行业内写下的任何东西都更能解释我们行业过去三年的现状 😵💫。
The essence and the accident
本质与偶然性
Brooks splits the work of software into two piles. The essence is the conceptual construct: the interlocking concepts, the data and their relationships, the decisions about what the system should mean and do and refuse to do. “I believe the hard part of building software to be the specification, design, and testing of this conceptual construct,” he writes, “not the labor of representing it and testing the fidelity of the representation.” 布鲁克斯将软件工作分为两类。本质（Essence）是概念性构建：即相互关联的概念、数据及其关系，以及关于系统应该意味着什么、做什么以及拒绝做什么的决策。他写道：“我相信构建软件的难点在于对这种概念性构建的规范、设计和测试，而不是将其表现出来并测试其表现保真度的劳动。”
The accident is that labor of representing. Syntax. Build tooling. Boilerplate. The twenty-something nearly identical factories (gotta love Java, right?). The typing. 偶然性（Accident）则是那种表现的劳动。语法、构建工具、样板代码、那二十多个几乎一模一样的工厂类（不得不爱 Java，对吧？），以及打字输入。
If you’ve read my earlier posts in this series, that first pile might sound familiar. Peter Naur, one year before Brooks, called it the theory of the program: the shared mental model that the source code only partially represents. Two men within the same decade, arriving at the same place from opposite ends; Naur from watching a compiler team hand their program over to fresh programmers — source and documentation included — and seeing the newcomers’ patches fight the original design anyway, Brooks from watching projects miss every estimate he’d ever seen. Both concluded that the hard part of programming is building that shared understanding, and that the artifact on disk holds far less of it than we’d like to think. 如果你读过我这个系列之前的文章，第一类（本质）听起来可能很耳熟。在布鲁克斯之前一年，彼得·诺尔（Peter Naur）将其称为“程序理论”：即源代码仅能部分体现的共享心智模型。两位先驱在同一个十年里，从截然不同的角度得出了相同的结论；诺尔是通过观察编译器团队将程序移交给新程序员（包括源代码和文档），却发现新人的补丁依然与原始设计冲突；布鲁克斯则是通过观察项目总是无法达到他见过的任何估算。两人都得出结论：编程的难点在于建立那种共享的理解，而磁盘上的产物所承载的理解远比我们想象的要少。
(Neither of them said code is easy, mind you, though half the internet is currently misquoting them on that.) （顺便提一下，他们两人都没说代码编写很容易，尽管现在半个互联网都在误引他们的观点。）
And from that split, Brooks derives his prediction with arithmetic “simple enough to do on a napkin”: a tool can only compress the accident. So unless the accident is nine tenths of your job, no tool, however magical, can make you ten times faster. The essence sets the pace. 基于这种划分，布鲁克斯用一种“简单到可以在餐巾纸上计算”的算术推导出了他的预言：工具只能压缩偶然性。因此，除非偶然性占了你工作的十分之九，否则没有任何工具（无论多么神奇）能让你快十倍。本质决定了进度。
He even reviewed AI In 1986
他甚至在 1986 年就评估过 AI
Brooks didn’t just make an abstract prediction and leave the werewolf-hunting to us. He went through the silver bullets of his day one by one: Ada, object-oriented programming, program verification, graphical programming — and(!) yes, artificial intelligence and expert systems, each with its own section. His verdict was the same each time: useful, some genuinely so, but all of it aimed at the accident. 布鲁克斯并没有仅仅做出一个抽象的预言就把猎杀狼人的任务留给我们。他逐一审视了当时所谓的“银弹”：Ada 语言、面向对象编程、程序验证、图形化编程——还有（！）没错，人工智能和专家系统，每一项都有专门的章节。他每次的结论都一样：有用，有些确实很有用，但它们全都针对的是偶然性。
The AI of 1986 was not the AI of 2026, obviously. But his reasoning never depended on capability in the first place. What matters is which pile the help lands in. “The hardest single part of building a software system is deciding precisely what to build,” he writes. No tool that receives a specification can help with the fact that producing the specification is the actual work. 1986 年的 AI 显然不是 2026 年的 AI。但他的推理从一开始就不依赖于能力水平。关键在于这种帮助落在了哪一类工作中。“构建软件系统最难的部分是精确地决定构建什么，”他写道。任何接收规范的工具都无法改变一个事实：产出规范本身才是真正的工作。
Forty years of silver bullets later (CASE tools, 4GLs, UML, no-code, low-code), the essay is undefeated. Now it’s up against the strongest candidate yet, at least if we measure by hype. LLMs are probably, and I mean this sincerely, the most effective accident-compressor ever built. They write the boilerplate and scaffold the tests, and they’ll produce the twentieth nearly identical factory without a word of complaint. I use them for exactly this, in a box, with supervision. 在经历了四十年的“银弹”（CASE 工具、4GL、UML、无代码、低代码）之后，这篇论文依然未被击败。现在，它迎来了迄今为止最强劲的挑战者——至少从炒作程度来看是这样。大语言模型（LLM）可能（我是真诚地这么认为）是有史以来最有效的偶然性压缩器。它们编写样板代码、搭建测试框架，并且能毫无怨言地写出第二十个几乎一模一样的工厂类。我正是这样在受控的环境下使用它们的。
The mirror
镜子
If Brooks is right that tools compress only the accident, then every AI productivity claim is accidentally a confession: Your AI speedup is a measurement of how much of your job was accident. 如果布鲁克斯关于“工具只能压缩偶然性”的观点是正确的，那么每一个关于 AI 生产力的声明，其实都在无意中进行了一次坦白：你通过 AI 获得的提速，正是衡量你工作中“偶然性”占比的尺度。
If Claude Code really did make you ten times faster, then, by Brooks’ napkin math, nine tenths of what you were doing was the labor of representation, not the conceptual work (or in my own terms: the engineering and craft). My intention is not to insult, btw (we’ll get to the actual insult shortly). Accident is real work, somebody has to do it, and our industry has spent two decades manufacturing mountains of it (I say this as someone who has configured webpack, and enabled ephemeral storage on Azure VMs 😅). For some roles the ratio really is that lopsided, and for those roles the compression is a mercy. 如果 Claude Code 真的让你快了十倍，那么按照布鲁克斯的餐巾纸算术，你所做工作的十分之九都是表现性的劳动，而非概念性工作（或者用我自己的话来说：工程与技艺）。顺便说一句，我无意冒犯（我们稍后会谈到真正的冒犯）。偶然性是真实的工作，总得有人去做，而我们行业已经花了二十年制造了堆积如山的这类工作（我作为一个配置过 webpack、在 Azure VM 上启用过临时存储的人，对此深有体会 😅）。对于某些岗位来说，比例确实如此失衡，而对于这些岗位，这种压缩是一种恩赐。
Turn the mirror around, though: the senior engineers reporting modest gains aren’t slow adopters or Luddites in denial. They’re telling you, with a number, what their week is made of: domain conversations, design decisions, naming, review, the slow work of figuring out what the system should refuse to represent. All essence, and none of it gets faster just because the typing does. 但换个角度看：那些报告称收益平平的资深工程师，并不是因为他们接受缓慢或是在否认技术的卢德分子。他们是在用数字告诉你，他们的一周是由什么构成的：领域对话、设计决策、命名、评审，以及弄清楚系统应该拒绝表现什么的缓慢工作。这些全是本质，而这些工作并不会因为打字变快了就跟着变快。
A small example from my own desk. When I built the little Elm testimonials widget for this site, I let an AI turn a pile of messy DOM nodes into clean JSON — pure accident, and it spared me a genuinely boring half hour. Then I wrote the widget itself by hand, and it took roughly what it would have taken me in 2019. Not because I refused the help on principle (though, to be honest I would have – I did it for fun after all!), but because the hours went into deciding which states should be impossible and what the messages should mean. The hand-it-all-to-the-agent crowd tends to miss where those decisions got made: half of them happened while writing the code, fingers on keys, with the c… 举个我自己的小例子。当我为这个网站构建那个小小的 Elm 推荐组件时，我让 AI 把一堆杂乱的 DOM 节点转换成整洁的 JSON——这纯粹是偶然性工作，它帮我省去了半小时真正无聊的时间。然后我亲手编写了组件本身，所花的时间大约和我 2019 年时所需的时间相当。这并不是因为我原则上拒绝帮助（虽然老实说我会拒绝——毕竟我是为了乐趣才做的！），而是因为我花费的时间都用在了决定哪些状态是不应该存在的，以及消息应该意味着什么。那些主张“把一切交给代理”的人往往忽略了这些决策是在哪里做出的：其中一半是在编写代码时，手指敲击键盘，伴随着 c…