There Is Still No Silver Bullet · cekrem.github.ioOf 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.<br>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 😵💫.<br>The essence and the accident
Link to heading<br>Brooks splits the work of software into two piles.<br>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.”<br>The accident is that labor of representing. Syntax. Build tooling. Boilerplate. The twenty-something nearly identical factories (gotta love Java, right?). The typing.<br>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.<br>(Neither of them said code is easy, mind you, though half the internet is currently misquoting them on that.)<br>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.<br>He even reviewed AI In 1986
Link to heading<br>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.<br>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.<br>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.<br>The mirror
Link to heading<br>If Brooks is right that tools compress only the accident, then every AI productivity claim is accidentally a confession:<br>Your AI speedup is a measurement of how much of your job was accident.<br>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...