AI Errors Aren't the Danger, Having No Backup Is: Lessons From Corrupting 170 Files

Recently, while tidying up my own knowledge base, I handed a large task to an AI to run fully autonomously: unify the old tag names across a few hundred files into their formal names. This is a very typical Loop task. I gave the instruction, authorized it to run on its own, and it kept going. It then made a serious mistake and wrecked 170 files. But in the end I lost nothing.

1. How it happened

I handed the rename job to a sub-agent to carry out. It ran for a few minutes and reported: all five groups complete, zero remaining.

If I had simply trusted it, the story would have ended there, and I would never have known something went wrong.

But I didn't trust it directly. I had another checkpoint count everything again, the dumbest way possible. One count and the problem showed up: its "done" was fake. During one replacement step it had written the command wrong, inserting a string in front of every single character in every file, and all the Chinese was broken into garbled text. 170 files, including several of my important documents, were all wrecked.

2. Why there was zero loss in the end

After it went wrong, three lines of defense brought me back.

The first: before starting, I made a complete backup, and I had verified that this backup could actually restore. This is the most basic step, and also the one most easily skipped. Many people feel safe once they've backed up, yet they've never confirmed the backup even opens.

The second: though the corruption was severe, it was regular. It was the same string inserted repeatedly, so I could remove that string in reverse and restore the files. I first experimented on a file that had a clean backup, confirmed that the reversed restoration matched the backup character for character, and only then dared apply it to everything.

The third: I did not let my own judgment be the final word. I asked a different AI from another family to independently verify the restored files again, including a character-by-character comparison against the backup. It flagged a few suspicious spots, and I checked each one, confirming they were all expected renames with no content missing.

Only after those three lines of defense did I dare say zero loss. That statement isn't a feeling; it was verified.

3. The real lesson of Loop Engineering

This made one idea clearer to me: a loop's safety comes from whether you've designed a loop that catches errors and can restore, not from believing the AI won't make mistakes.

A single AI's "I'm done" can never count as acceptance. It will confidently tell you it finished, even right after it botched the job. That is just how it works, with no malice on the AI's part. So what you need to do is put a check inside the loop that "doesn't rely on the AI's own word."

4. Three principles you can take with you

If you're also letting AI do larger things for you automatically, these three points are the ones I find most useful.

1. Before any destructive action, have a restore point you've verified works. A backup isn't done once you've made it; you have to confirm it opens and restores. An unverified backup is no backup.
2. Don't treat the AI's self-report as acceptance; have an independent check that can verify objectively. Ideally a machine-verifiable condition, black and white, rather than asking the AI "are you done yet?"
3. For important judgments, cross-validate, ideally with a different AI. The same AI checking itself tends to share the same blind spots. Bring in another family and what it catches is often different.

Finally

That day, if I had been missing any one of those defenses, this piece would have become a regretful "I broke my knowledge base" story. But because the loop itself was designed for "things going wrong," it was just a close call, and even turned into good teaching material.

Letting AI run on its own is effortless, and dangerous. What truly makes it safe was never the AI; it's how you design the loop so that even when it goes wrong, you walk away whole.