What Nuclear Software Taught Me About AI Development

In nuclear, the question isn't "what could go wrong?"

Every software engineer thinks about failure. What's unique about building software for US nuclear power plants isn't that we think about failure more — it's that we think about it differently.

The question we ask isn't what could go wrong? What happens when multiple things can go wrong simultaneously?

Fault trees. Defense in depth. Redundancy at every layer. The assumption is never that your system will be stress-tested by one unlikely failure. It's that multiple unlikely things will happen at once, and your software needs to have accounted for that before it ships — not during the incident.

This shapes everything downstream: how requirements are written, how architecture is reviewed, how code is tested, how deployment is planned. You don't get to discover the edge case in production. You have to imagine it first.

That habit — imagining the simultaneous failure — is what I brought with me when AI coding tools arrived. And it's what most teams adopting AI have never had to develop.

When AI arrived, I saw a junior developer.

The first generation of AI tools capable of writing real code landed at roughly the skill level of a junior developer. Capable. Fast. Confident. And deeply dependent on the quality of direction it received.

I'd spent years studying SDLC, DevOps, Agile, and TDD. I'd watched software done wrong at close range — the kind of wrong that piles up quietly and falls over spectacularly. I recognized the pattern immediately.

A junior developer without mentorship, clear requirements, and structured review produces plausible work that creates expensive problems. A junior developer operating at 10x speed, without any of those structures, creates expensive problems at 10x speed.

Garbage in, garbage out — that's not new. What's new is the velocity at which garbage multiplies.

I could see the train wreck coming. What I couldn't find was a methodology designed to stop it.

The service that's been running for 22 years didn't survive because I was exceptional. It survived because the environment demanded precision at every stage of the process.

Requirements that left no room for interpretation. Architecture reviews that asked what happens when multiple things fail at once. Testing that went well beyond happy paths. Rollback plans written before deployment — not during an incident.

None of that is slow. That's exactly the point. It's the kind of rigor that produces software you don't have to touch again.

When I started building with AI coding tools, I didn't see a replacement for that rigor. I saw a new form of leverage — one that would make undisciplined development fail faster, and disciplined development succeed faster. The tool was not the variable. The system around the tool was.

The question was: where's the methodology?

What nuclear engineering demands is exactly what AI development is missing.

That's what Camino is.

Camino is a spec-driven development system — built for the same team that has been running nuclear-grade software for twenty years. Gated phases. EARS requirements notation. Dual acceptance gates. A rollback plan treated as a sprint artifact, not an afterthought.

It's not a framework for slowing AI down. It's a system for channeling AI's speed through the same discipline that produces software still running two decades later.

The teams winning with AI aren't the ones with the best models. They're the ones who understood that adding speed to an undisciplined process doesn't improve the process — it accelerates the failure.

Anyone can prompt. The question is whether you've built the system around it.