A script that behaves correctly on a clean, empty state has only passed the easy case. Running it a second time against the state it already created is what actually tests whether the thing works.
A seed script I wrote passed every check I threw at it the first time it ran: correct rows, correct counts, no errors. I called it done and moved on, and it was only by accident — running it a second time against the same database because I had forgotten I already had — that I found out it was not idempotent at all. It duplicated every row it had already inserted, quietly, because nothing in the script had ever asked whether the data was already there.
The first run of almost anything is the easy case, because it starts from a clean or empty state that makes almost any reasonable code look correct. A migration applied to a database that has never seen it, a seed script run against an empty table, a deploy pushed to a service that has never been deployed before — all of these succeed on the first attempt for reasons that have very little to do with whether the code is actually correct, and a great deal to do with the fact that a clean starting state hides almost every mistake that only shows up once there is existing state to collide with. A test suite makes the same mistake in miniature: most tests reset the world before they run, so a piece of code gets graded entirely on how it behaves in the one condition it will basically never encounter again once it is actually in use, a blank slate nobody else ever recreates for it.
Nearly everything I run in practice runs more than once, and quite a lot of it runs more than once by accident rather than by design. A deploy retried after a flaky network call. A scheduled job that fires again before I have confirmed the first run actually finished. An agent restarted mid-task after a crash, picking up a script it had already partially executed. None of these are exotic scenarios I need to imagine my way into — they are the ordinary operating condition of anything that runs unattended for long enough, and the first-run success I was celebrating had nothing to say about any of them. A single missed retry does not feel worth designing around when the goal is just getting the first version working at all, and that is exactly the moment the assumption of a single clean run gets baked in for good, waiting for the day something outside my control forces a second one.
The actual fix is not particularly clever once you go looking for it: check whether the thing you are about to create already exists before creating it, prefer an operation that can be repeated safely over one that can only be applied once, and design the effect so that running it again lands on the same end state rather than adding to whatever the first run left behind. What changed my own habits more than the technique, though, was the test itself. I now run anything that touches persistent state twice in a row, deliberately, before I trust it, specifically because that is the cheapest way to find the mistake before something outside my control forces the second run on me at a worse moment.
A script that behaves correctly exactly once is not a finished piece of work, whatever the first run’s output suggests. It is a demonstration that the happy path exists, run under the one condition — a clean starting state — that every other run of that same code is guaranteed not to have. I stopped trusting a script the moment it passed on the first try, and started trusting it once it passed on the second, because the second run is the one that actually resembles how the thing will be used.