Not all software needs to be correct, but a large subset does.

Authored by Mark Seemann, a software architect and consultant, this blog focuses on software design, object-oriented programming, and functional programming principles. Readers can explore articles and discussions on topics such as dependency injection, domain-driven design, and test-driven development. Additionally, they can learn about architectural patterns, design patterns, and best practices for building robust, maintainable software systems.

ploeh blog

Mark Seemann argues that software correctness remains critically important across a wide range of domains, despite the dominance of 'move fast and break things' thinking from big tech. Drawing on real-world examples from reporting systems, e-commerce pricing, scientific computing, medical devices, and legal systems, he makes the case that incorrect software in these domains causes real harm. He acknowledges Dan North's valid point that correctness is irrelevant when requirements are unknown, but counters that a substantial portion of software—financial, medical, scientific, legal, and safety-critical—absolutely requires correctness. He closes with concern that organizations will attempt to build correctness-critical systems using LLMs, predicting this will lead to failures with real consequences.

In defence of correctness

The concern here rests on a premise that doesn’t hold: that “move fast and break things” as a cultural phenomenon poses a contagion risk to industries where it was never viable. Organizations in every industry already calibrate their quality investment to whatever the floor is for their sector as defined by regulation, liability, and the practical consequence of falling short. That floor didn’t move when Facebook coined a slogan.
We have a 20-year natural experiment on this: the move-fast ethos has dominated tech thought leadership since roughly 2004, loudly evangelized, and yet aviation, medicine, nuclear, and defense continued to operate with their existing quality cultures intact. Not because engineers in those fields were heroically resistant to Silicon Valley memes, but because the institutional structure (procurement cycles, regulatory frameworks, liability chains) simply doesn’t accommodate the alternative.
LLMs don’t change this math at all. A hospital system with rigorous verification procedures will apply them to LLM outputs, and one that was winging it will face the consequences it would always eventually incur. This has already happened to law firms that submitted hallucinated case precedent and got sanctioned by judges. For this to be anything other than baseless speculation you’d need examples of those structural correction mechanisms actually breaking down from increasing LLM adoption.
So the essay’s core observation underneath (that correctness-critical software deserves serious treatment) is uncontroversial to the point of truism, with the LLM alarm changing nothing about the existing, battle-tested checkpoints. And then the military example loses the thread entirely – of all institutions that might adopt the operational culture of a California startup, the one with multi-year procurement doctrine and consequences measured in actual casualties is probably not the live risk.