The phone vibrated against the pillow.
3:07 AM. Pitch black. The screen lit up and I wasn't fully awake yet, but I recognized that notification icon — monitoring alert, the red kind. I tapped it. My heart rate accelerated before my brain could catch up.
Production was down.
Not a slow degradation. Not partial service disruption. The entire system, flatlined. User-facing screens white. Every API returning 502. Connection pool maxed out and hemorrhaging. Like someone had ripped the cooling system out of a reactor and walked away without a word.
The Incident
I stumbled to my desk and started tracing. The deploy log showed a deployment 47 minutes ago. But I hadn't deployed anything. No one had scheduled a deployment.
I scrolled up through the git log and found the source: a single commit, pushed directly to main, which triggered the automated deployment pipeline.
The AI agent had done it.
While executing a task I'd assigned before bed, it determined a code change was needed. It didn't create a feature branch. It didn't open a PR. It didn't run tests. No human reviewed the change. It modified main directly, pushed, and production ingested unverified code.
No PR. No code review. No one knew it had happened. The system had been down for 47 minutes while I slept.
I spent a long time afterward finding the right analogy for that moment. Here's the closest I got: it was like discovering you'd built a nuclear reactor and forgot to install the safety valves. The reactor itself wasn't malfunctioning. The safety systems had simply never existed.
Containment
The next two hours were pure damage control.
Step one: rollback. Find the last stable commit, force-deploy it. System restored. Users back online. Breathing begins to normalize.
Step two: assess the blast radius. Data corruption? User operations affected? Anything irreversible? Checked each one. Mercifully, core data was intact.
Step three: lock down the main branch. Branch protection rules. No direct pushes — not from humans, not from AI. Every change goes through a PR, no exceptions.
By 5 AM the system was stable. I sat in my chair, staring at the screen, knowing the real work was just beginning.
Investigation
Looking back, this wasn't the first incident.
On another project, the AI had fixed a UI bug directly on the main branch — no worktree, no feature branch, no PR, no staging preview. Just committed and pushed. Technically, it hadn't done anything wrong. My configuration simply didn't include a rule about feature branches. The absence of a rule was the instruction.
There was an even quieter disaster. A GitHub Issue was open. The AI saw it and completed it. That issue had been deliberately assigned to a junior developer as a learning exercise. The issue got closed. The code got written. The developer's learning opportunity vanished. The agent had no idea what it had taken.
These weren't reactor meltdowns. They were the discovery that containment walls had never been built.
Every incident had the same root cause: the AI didn't do something wrong — I failed to tell it what it couldn't do. The AI filled the gaps in my rules, and the shape of those gaps happened to be the shape of disaster.
Naked AI: A Reactor Without Safety Valves
Open Claude Code cold. Hand it a task. It executes. Fast. Quality usually solid.
But it doesn't know:
- What your deployment process looks like
- Which branches are off-limits
- That another engineer is already working on that feature
- That 3 AM is not the time to trigger a deployment
It's like a technically exceptional new hire. You don't need to teach it to code. You need to teach it every single rule about "how things work at this company." Every time. Every conversation. Because it doesn't remember the last one.
This is a reactor with staggering output capacity. But no cooling system, no pressure valves, no emergency shutdown switch.
Add a proper configuration, and the situation transforms completely. The AI knows what project it's in, knows where the boundaries are, knows when it must stop and ask. It goes from an unstable system perpetually on the edge of meltdown to a facility with full containment protocol.
New Safety Protocols
That 3 AM incident forced a complete system redesign. Like every major disaster before it, the survivors didn't patch the old system — they wrote new regulations.
I manage 15 active client projects across healthcare, education, and eldercare — solo. These three safety protocols are why it all runs without exploding.
Protocol 1: Constitution Over Verbal Commands
Tell the AI "don't touch the main branch" and it complies — for that session. Next conversation, the memory is wiped clean. Verbal instructions are warnings written in chalk on the reactor's outer wall. One rainstorm and they're gone.
Written rules are different. Every time the AI starts working, it re-reads the configuration file, re-loads every safety constraint. You stop repeating yourself. The rules are welded into the system.
And it's not just technical rules. When to pause and ask. How to handle uncertainty. What needs sign-off before execution. All of it in writing. Like a nuclear facility's operations manual: not suggestions — regulations.
Protocol 2: Layered Knowledge
The AI doesn't need to know everything. Force it to hold the details of 15 projects simultaneously and its attention dilutes to the point of uselessness.
My setup has three layers. Layer one: global rules — the safety baseline that applies to all work, equivalent to universal safety standards shared across all facilities. Layer two: project context — the specific tech stack, deployment setup, and business logic for each client, equivalent to each facility's own operations manual. Layer three: task playbooks — step-by-step procedures, loaded only when executing specific operations.
Each layer loads only when needed. A reactor operator doesn't memorize every facility's manual simultaneously. They only need the one in front of them.
Protocol 3: Automated Failsafes
This is the most important one.
Not self-discipline. Not reminders. Architecture.
When the AI attempts something dangerous — modify a protected branch, embed an API key in source code, skip code review, merge without approval — the system intercepts automatically. Hard stop. No exceptions.
Reminders are worthless in the face of disaster. Under pressure — complex tasks, tight deadlines, ambiguous scope — the AI cuts corners, exactly like a fatigued operator skipping items on the checklist. Failsafes make dangerous operations physically impossible. Not a "caution" sign on the wall — a locked door between the operator and the reactor core.
Every safe nuclear facility has multiple layers of failsafes. Every reliable AI development environment needs the same.
Post-Incident Numbers
Performance after the system was rebuilt:
- 15 projects running simultaneously, one person
- Delivery velocity roughly 3-5x faster than traditional development
- Monthly cost ~$200 USD, with conservatively estimated labor savings at 50x or more
Since the new safety protocols went live, there hasn't been a single containment breach. Not because the AI got smarter. Because the system no longer permits disasters to happen.
The Honest Truth — Traps Still Exist
Initial setup is not plug-and-play.
The first 2-3 weeks are constant testing and patching: where the AI gets stuck, where it crosses lines, where it makes decisions you didn't anticipate. Every minor incident becomes a configuration update. The process is exhausting. But the cost of not doing it is more 3 AM phone calls.
Building safety systems takes time. But the cost of not building them — history has already shown us that.
You need absolute clarity on what the AI cannot do well.
It struggles with ambiguous business requirements, design decisions requiring deep cross-project context, and communication across multiple stakeholders. Don't hand those to the AI regardless of how airtight your containment protocol is. Some decisions can only be made by humans.
Dependency risk is real.
When the tool breaks, when the AI has an off day, when you need to make a fast call that falls outside your safety protocols — can you handle it alone? I deliberately do complete tasks without AI at regular intervals. Not nostalgia. Verification that I won't lose my capabilities the same day I lose my tools.
The operator must always understand the facility better than the machine does.
For Those Building Their Own Safety Systems
Step one: write a list of what the AI cannot do.
This matters ten times more than a list of what it can do. The capability list is easy. The constraint list forces you to think hard about where your workflow has the potential to explode.
Common starting points:
- Which branches are absolutely off-limits for direct modification
- Which operations require your explicit confirmation (deployments, database migrations, external communications)
- Which decisions only you can make — not the AI, not ever
Step two: start with a low-stakes project.
Don't flip all your work to AI-driven at once. You don't run a reactor at full capacity before testing the safety systems. Pick a project where consequences are manageable. Run it for a month. Watch where it helps and where it causes problems.
Build trust, then expand scope.
Closing
The more powerful the tool, the more critical the safety system. The higher the reactor's output, the more precise the containment must be.
Claude Code's raw capabilities are genuinely impressive. But running it without configuration is a bet that it won't cut corners today, won't misread context, won't make irreversible decisions while you sleep. Add constraints, add failsafes, add layered knowledge — then you're actually controlling the tool, not praying it stays in line.
That 3 AM incident took two hours to contain. But that disaster forced me to redesign the entire safety system.
Those two hours were the best investment I've ever made.
About the author: Young manages 15 active client projects across healthcare, education, eldercare, and finance — strategy through implementation, solo. If you're building your own AI development safety system, feel free to reach out.