Split software into modules with contracts you can state precisely and reliability becomes something you can budget; leave the boundaries vague and the multiplication turns every small fault into a system-wide failure.
In the 1950s, when people were building guided missiles, they worked out a rule: if a machine only functions when every part functions, then the machine's reliability is the product of its parts' reliabilities. That is not a metaphor. It is multiplication.
The multiplication starts to bite
Fifty parts, each 95 percent reliable, multiply out to a machine that works about 8 percent of the time. Double the parts to a hundred and the odds of success fall below 1 percent.
Coding agents make adding just one more module almost free, so the part count climbs. Kerry Ivan Kurian's conclusion: projects will fail more often, and silently, with every part looking fine on its own and the failure living inside the multiplication.
What the failure looks like
Not a bang in the basement, but a number on a dashboard nobody can explain, or a fix that breaks something else.
Lusser's law does not know that. It treats every soft fault as if it took the whole system down, so small defects get multiplied at the rate reserved for catastrophes. Kurian's diagnosis holds up and his sourcing is solid; he just takes four thousand words to arrive at an antidote of 'build less and check what you build', advice Brooks gave in 1975.
The step he walks past
Late in the essay, almost quietly, he concedes that the arithmetic assumes parts fail independently, and that real software does not work quite like that.
But that is where the whole argument turns. A part only counts as a part if you can say what it accepts, what it emits and when. If you cannot, it is just a zoomed-in view of the system, and its failures bleed into its neighbours.
Flip that around and a component with a stated contract can be tested against the contract rather than against whatever it happens to do today. Its reliability can be established on its own, with a check that fails differently from the implementation code. When every part in the chain is like that, the product law stops being a threat and becomes a budget: you know which parts are weak and exactly how much fixing one improves the whole.
So the fix is not fewer things. It is things you can describe well. The count falls out of that as a consequence, because writing one good specification is hard work and nobody writes fifty of them on a whim.
As for who checks the agents: agents checking agents share the same blind spots. Only a specification precise enough to test against is a check they cannot negotiate with.
Why it matters
Treating failure as multiplication turns 'just add one more working module' from cheap into expensive, and that cost lands on every industry that runs on software. It is also why people who can write a precise interface become more valuable, not less, in the age of agents.
Curated from high-quality sources, with concise summaries and key takeaways.
