Kerry Ivan Kurian: Exponential Failure

Kerry Ivan Kurian's essay "Exponential Failure" applies a piece of 1950s reliability arithmetic to AI-assisted software: he says that Lusser's Law means that when a system works only if every part works, the system's reliability is the product of the parts' reliabilities. Fifty parts at 95 percent each gives you a system that works about 8 percent of the time¹. Double the parts and you're under 1 percent success. Coding agents make parts cheap to add, so the count climbs, and Kurian's conclusion is that most projects will fail more often than ever, invisibly, with every part performing acceptably and the failure living in the multiplication.

Kurian describes failure well: it's a dashboard number nobody can explain, a fix that breaks something else, not a bang in the basement. But his arithmetic doesn't know that. Lusser's law is binary, and every one of those soft failures gets multiplied as if it took the whole system down.

But the diagnosis is sound and the sourcing is pretty solid. The problem is that it takes four thousand words to reach an antidote of "build less and check what you build," which is advice Brooks gave in 1975. Readers who get that far are the ones who already knew it².

The essay also concedes, late and quietly, that the arithmetic assumes parts fail independently, and that real software doesn't work quite like that. It treats this as a caveat. But it's where the whole argument turns, and he walks past it.

Parts in a serial system are only as independent as the boundaries between them. If you can't state what a part does, what it accepts, what it emits, and when, then it isn't a part. It's a zoomed-in view of a system, and its failures bleed into its neighbors. Entangled parts are what make Lusser's law a curse: the effective count is higher than the nominal count, because pairs of parts can interfere, and the per-part reliability is lower than it looks, because a failure anywhere can show up anywhere.

Well-bounded parts invert that. 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 its own inputs, by a check that fails differently from the code. When every part in the chain is like that, the product law stops being a threat and becomes a budget. You know what each part contributes, you know where the weak ones are, and improving a part improves the system by exactly the amount the arithmetic predicts.

So the fix isn't fewer things: it's things you can describe well. The count falls out of that as a consequence, because defining a contract is real work and nobody defines fifty of them on a whim³. But a hundred components with stated contracts at 99.9 percent beat twenty entangled ones at 95 percent, and Kurian's own numbers show this.

This also answers the question the essay leaves open: who checks the agents? Kurian is right that agents checking agents share blind spots. Models trained alike misread ambiguous specifications alike⁴, and a second model reviewing a first model's code catches only the mistakes it wouldn't have made itself. But a specification precise enough to test against is a check the agents don't share, and can't negotiate against in the pursuit of speed or just complimenting a human on how smart they are.

Agents are good at filling in a well-defined box. They're poor at knowing where the box's edges are, and they have no way to tell you that the edges you gave them are wrong. That work still belongs to people. It always has. The agents just raised the price of skipping it, because at finding the edges of a problem they're worse than the junior developers we all dread having to herd.