Aaron Stannard, the creator of Akka.NET, recently wrote a piece that crystallized a question I’ve been circling for months. He introduced a concept he called the “blast radius of failure” — the idea that AI’s ability to substitute for existing software scales inversely with the consequences of getting it wrong. The lower the stakes, the easier the substitution. The higher the stakes, the wider the moat.

It’s an elegant framing, and I think it captures something real. But I’ve been trying to figure out whether it’s a permanent feature of the landscape or a temporary lag — whether the moat holds or whether it’s already eroding.

The examples are piling up, and they don’t all say the same thing. Anthropic’s Nicholas Carlini ran sixteen autonomous Claude instances in parallel for two weeks and produced a C compiler — written in Rust, from scratch — that can compile and boot the Linux kernel on three architectures. It handles PostgreSQL, Redis, FFmpeg, Doom. Cost: roughly twenty thousand dollars. Google engineer Jaana Dogan reported that a coding agent reproduced in one hour what her team had spent a year building. And Tailwind CSS usage grew 126% year-over-year even as 75% of Tailwind Labs’ engineering team lost their jobs — AI tools had made the company’s premium templates, once its primary revenue source, essentially worthless.

These are different phenomena wearing similar clothes. Tailwind’s code wasn’t substituted — its business model was. Dogan’s system was rebuilt fast, but whether the reproduction captured the institutional knowledge embedded in the original is an open question. And Carlini’s compiler — the most technically impressive of the three — passes 99% of GCC’s torture tests but generates less efficient code than GCC with all optimizations disabled, frequently broke existing functionality as new features were added, and lacks an assembler and linker entirely. Carlini himself noted that “the thought of programmers deploying software they’ve never personally verified is a real concern.”

The gap between “tests pass” and “production-grade” is exactly where Stannard’s blast radius lives.

It maps to a spectrum. At one end: UI components, templates, workflow tools, point solutions — things where the consequences of failure are contained. A buggy component is a bad user experience. An incorrect template wastes someone’s afternoon. At the other end: databases, payment infrastructure, authentication systems, anything safety-critical or regulated. A subtle bug in a database’s replication logic can corrupt data across an entire organization. A flaw in payment processing loses real money. The blast radius isn’t just technical — it’s regulatory, legal, reputational. And the moat is compound: validation requirements, switching costs, trust accumulated over years of production use, integration depth that makes ripping something out as expensive as building it was in the first place.

The spectrum is persuasive. But description isn’t explanation.

Fred Brooks offers the sharpest lens I’ve found. In his 1986 essay “No Silver Bullet,” Brooks distinguished between two kinds of complexity in software. Accidental complexity is the difficulty that comes from our tools and processes — boilerplate, configuration, glue code, the friction of getting the machine to do what you mean. Essential complexity is the irreducible difficulty of the problem domain itself — the requirements that exist because the world is complicated, not because the tools are bad.

AI is extraordinarily good at eliminating accidental complexity. That’s what the C compiler example really demonstrates: a hundred thousand lines of code generated from scratch, handling the normal cases, in two weeks. That’s what vibe coding does at smaller scale — produce working software fast by eliminating the friction that used to consume most of a developer’s time. The boilerplate melts away. The glue code writes itself.

The blast radius moat is really a claim about essential complexity — the irreducible difficulty that remains after accidental complexity is stripped away.

And essential complexity is where the hard problems live. The edge cases that exist because customers do unexpected things. The regulatory requirements that evolved over decades of case law. The failure modes that only surface under load, at scale, in production. Richard Cook’s “How Complex Systems Fail” articulates this with uncomfortable precision: complex systems are always partially broken, running in degraded mode, with multiple latent failures coexisting at all times. Safety isn’t a property of the software. It’s continuously produced by human practitioners who adapt in real time to conditions that were never specified in the requirements.

When AI passes the tests, it demonstrates competence in the normal operating envelope. But essential complexity lives in the abnormal — the latent failures, the novel combinations, the 3am incidents that never made it into a postmortem, let alone a training dataset.

What makes this a moat — not just a preference — is epistemological. High-blast-radius systems have the loosest evaluation loops for the things that matter most. A subtle bug in replication logic doesn’t surface when the tests pass — it surfaces six months later, during a network partition at peak traffic. This is the demand-side wall from The Absorption Gap operating at the systems level: production speed has outpaced the ability to verify.

But the boundary between essential and accidental complexity is not fixed. AI is reclassifying it — in large part by tightening the very evaluation loops that kept high-blast-radius systems out of reach.

Consider mocks. Test mocks have historically been shallow, annoying to maintain, and too simplified to capture real-world behavior. But AI can now produce increasingly representative simulations of complex systems — stateful API mocks that model error conditions, rate limits, eventual consistency. If you don’t need to wait hours for a real infrastructure deployment because your mock is good enough, you’ve just tightened a feedback loop that used to be painfully loose. Testing that once required production environments becomes fast and cheap.

But there’s a ceiling. A mock that captured every error condition of the real system would just be the system itself — a 1:1 map the size of the territory. The value of an abstraction is precisely that it’s lossy. Where the useful asymptote sits is, I suspect, unknowable in advance.

Or consider vibe coding. Engineers — myself included — tend to dismiss it as unreliable, error-prone, insufficient for serious work. And it still is, for many definitions of serious. But Clayton Christensen’s insight about disruption was precisely that the incumbent always sees the new entrant as inadequate. That’s the nature of low-end disruption. It starts where “good enough” means something different. A startup shipping an MVP in a week has a different quality bar than a bank’s core transaction system. And vibe coding is improving faster than most engineers want to acknowledge.

Testing tells a similar story. Unit testing is nearly trivial for AI, and integration testing is catching up. End-to-end testing is harder. And real-world testing — the kind where you discover that your system behaves differently under load, with real users doing things nobody anticipated — is still paid for in sweat and tears. But AI is compressing the lower levels and reaching into the higher ones. The line is moving.

I work in software. I have decades of accumulated experience — production incidents, architectural mistakes, hard-won intuitions about what breaks and why. I have a professional investment in the idea that this kind of knowledge matters and can’t be easily replaced. Believing that the blast radius moat is durable is the comfortable position for someone like me.

Christensen’s entire body of work is a catalog of incumbents who believed exactly this. Every incumbent tells themselves a version of the story I’m telling now: our complexity is essential, our knowledge is irreplaceable, our moat is real. Sometimes they’re right. Often they’re not.

I believe the moat is real today. Systems that handle money, store authoritative data, manage safety-critical processes, or operate under regulatory scrutiny are genuinely harder to substitute — not just psychologically but structurally. The uncodified knowledge, the war stories, the tribal memory of how things actually fail — these constitute essential complexity in Brooks’ sense. AI can’t yet replicate what was never written down.

But the line is moving. AI is reclassifying complexity from essential to accidental faster than most people in my position want to admit. The feedback loops are tightening. The testing frontier is advancing. Things that required real-world exposure last year might be simulable next year. And every line of code that AI makes cheaper to write is also a line of code that will need maintaining — bit-rot doesn’t care who wrote it.

Essential complexity is real. But so is the tendency to mistake accumulated accidental complexity for something irreducible. Getting it wrong in one direction means complacency. Getting it wrong in the other means panic.