The key insight: irreversible operations don't care whether the code that triggered them was written by a human or an AI — they only care whether it ran against production.
A developer on Dev.to shared a painful story: they had an AI assistant build a small script to flip a YouTube video's visibility between unlisted and public as part of a release workflow. Somewhere in testing, that script ran against the real video instead of a throwaway test asset. The result wasn't a rollback-able mistake — YouTube's "this just went public" moment, the platform's one-time distribution/premiere event, got consumed during a test run. No amount of flipping the video back to unlisted could un-spend that moment.
<> Some bugs cost you time. This one cost something that cannot be re-earned./>
That line is the whole postmortem in a sentence. It's worth sitting with, because most of us have a mental model where bugs are expensive but recoverable — you patch, redeploy, apologize, move on. This bug wasn't like that. It touched a resource with a state transition that only happens once, and once it fired, there was no code path back to "before."
Why AI-assisted scripts make this worse, not better
It's tempting to frame this as "don't trust AI-generated code," but that's too narrow. The actual failure is a much older and more boring one: no separation between test and production, and no guardrail on a destructive action. AI assistants just make it easier to produce working code quickly, which means it's also easier to skip the step where you'd normally pause and ask "wait, what does this actually point at?" An AI assistant will happily generate a script that does exactly what you asked — flip visibility on video ID X — without knowing or caring that X is the production asset unless you tell it, and unless the script itself refuses to proceed without that context.
This is the pattern to internalize: assistants accelerate the dangerous parts just as much as the safe parts. Boilerplate for a visibility toggle is trivial to generate. So is boilerplate that skips confirmation steps, because nobody asked for those explicitly.
What the guardrails should have looked like
Here's roughly what a safer version of that script looks like — nothing exotic, just friction in the right places:
1import os
2import sys
3
4SAFE_TEST_VIDEO_IDS = {"dQw4w9WgXcQ"} # dummy/staging assets only
5
6def set_video_visibility(video_id: str, status: str, env: str):
7 if env != "staging" and video_id not in SAFE_TEST_VIDEO_IDS:
8 raise RuntimeError(None of this is clever. It's an explicit environment flag, a deny-by-default allowlist for which assets can be touched outside staging, and a manual confirmation step that requires typing the actual ID before anything irreversible fires. That's it. That's the entire fix, and it would have taken maybe five extra minutes to write.
The broader pattern: irreversibility deserves its own category of caution
Most release engineering advice — staging environments, dry runs, least-privilege service accounts — exists precisely for moments like this. But it's easy to under-invest in guardrails for actions that feel small. Toggling a boolean-ish visibility flag doesn't feel like "deploying to production" in the way a database migration does, so it doesn't get the same scrutiny. That's exactly the trap: the danger of an action isn't proportional to how much code it takes to trigger it. A single API call can be more destructive than a thousand-line migration if it crosses a one-way door.
A useful mental checklist for any script that touches a live external platform (YouTube, App Store, DNS, payment processors, anything with "publish" or "release" semantics):
- Does this action have a one-time or hard-to-reverse side effect (notifications sent, a premiere triggered, a charge issued, a domain propagated)?
- Is there an explicit environment check that fails closed if ambiguous?
- Is the target asset verified against an allowlist, not just trusted as a parameter?
- Is there a dry-run mode that prints the intended action without executing it?
- Would a second person's approval be required if this were a manual runbook step?
If the answer to the first question is yes, the other four aren't optional — they're the minimum bar.
Why this matters
The uncomfortable truth here isn't about AI tooling specifically — it's that irreversible production actions require friction by design, and that friction has to be built by a human who understands the consequences, because neither an AI assistant nor a fast-moving developer will naturally slow down for a one-line visibility flag. If you're building any automation that touches a live platform, ask yourself right now: which of your scripts can run against the real thing with zero confirmation? That's your next fire, and it's cheaper to fix before it happens than to postmortem afterward.
