AI will make mistakes, and you will give wrong instructions too. This piece teaches you to design a Loop that catches errors when they happen: six steps, each with a clear completion condition, plus an end-to-end demonstration.
- People who have started handing important work to AI (organizing files, batch edits, updating system settings) but feel uneasy, afraid it will wreck a whole pile of things at once
- People who have been burned by AI and afterward couldn't find what it actually changed or where it broke
- People who want to confidently let AI do bigger things but don't know how to set up the safety net
- A mindset flip: from chasing zero errors to being able to afford errors
- The six-step fault-tolerant Loop, each step with a completion condition, and a concrete task walked end to end
- The five standard moves for after something goes wrong
1. First, face one fact: zero errors is unachievable
AI is uncertain. Run the same instruction twice and the results can differ, no matter how strong the model is.
People are the same. I myself slip, give wrong instructions, and forget to consider a scope.
So the goal of "designing a mechanism that never errs," I gave up. At least I can't do it.
I switched to a different goal: if you get it wrong, you can re-check, and you can restore.
This is fault tolerance. Errors are unavoidable, but the damage can be controlled.
2. Three goals, three lines of defense
I set three goals for the fault-tolerance mechanism, ordered by importance, each goal matched to a line of defense:
| Goal | Line of defense | Steps |
|---|---|---|
| 1. Make as few errors as possible | Prevent beforehand | Sort by size, keep an exit, small test first |
| 2. When it errs, know where | Leave a trail during | Do it in batches, keep records, set a stop-loss |
| 3. Knowing where, be able to restore | Recoverable afterward | Backup, verify with a different mind, wrap-up note |
Note what this ordering implies: no matter how well the first line is done, the second and third still have to be built. Because the first line will be breached; that's the premise, you just don't know which time.
3. The six-step fault-tolerant Loop
First, an overview of the six steps:
| Step | In one line | What counts as done |
|---|---|---|
| 1. Sort by size | Only big things enter the loop; small things get done directly | You can say whether it's big or small, and how large the scope is |
| 2. Keep an exit | Back up, and write down how to go back | The backup opens, and the restore steps are written |
| 3. Small test first | Run 1 to 2 samples first | You confirm the result is correct with your own eyes |
| 4. Batch with a trail | Run in batches, agree on a stop-loss | Each batch has a record you can check |
| 5. Verify with a different mind | Execution and verification use different minds | You can state the verification evidence |
| 6. Write a note | Record what was changed and where the backup is | All four things are written |
Below, every step is demonstrated with the same example: you want AI to uniformly rename 300 old files on your computer and add dates. Touching hundreds of files at once is exactly where the fault-tolerant Loop belongs.
What to do: ask yourself one question, how big is this change? Editing one sentence in one file is a small thing; do it directly, no loop needed. Touching dozens or hundreds of files at once, involving renaming, deleting, or moving, or touching important settings, is a big thing; run the full six steps.
What counts as done | you can say "this is small" or "this is big, because the scope is such-and-such."
Example: 300 files to rename, big thing, into the loop.
The most common pitfall | not sorting by size. The result is you lose both ways: small tasks get dragged down by the process, and big tasks run without protection.
What to do: two things. One, copy the entire range that could possibly be touched as a backup. Two, write down "how to go back if it goes wrong," concrete enough that you can restore by following it.
What counts as done | the backup opens by your own hand, and the restore steps are already written in your notes. Missing either one, no starting.
Example: copy the whole folder, named "pre-rename backup 0702." Write one line in your notes: if it goes wrong, copy this entire backup folder back over the top.
The most common pitfall | too small a backup scope. You assume only folder A will be touched so you back up only A, and then the error spreads to B. The backup must cover "the entire range that could actually be touched," not just "the range I intend to change." The gap between those two is exactly where accidents hide.
What to do: pick 1 to 2 files, let AI run through them first, and open them with your own eyes to see the result.
What counts as done | the test result is exactly what you wanted, and you confirmed it with your own eyes, only then may you scale up.
Example: rename 2 first. Open and look: is the new filename format right? Was the file content touched?
The most common pitfall | the plan looks perfect, so you just run it all. This step blocks the most damaging kind of error, "the instruction itself was written wrong." The same error is trivial across 2 files and a disaster across 300; the only difference is whether you tested first.
What to do: execute in batches, don't run it all in one go. After each batch, note which files this batch touched. Before starting, agree on a stop-loss condition with the AI: on what situation it should stop and report, rather than forcing through.
What counts as done | every batch has a record you can check, and the stop-loss condition is clearly stated.
Example: split 300 into 6 batches of 50. Keep a list per batch. Agree on the stop-loss: if you hit a file whose name format is inconsistent with the earlier ones, stop and ask me.
The most common pitfall | running it all in one go. The value of batching only shows up when something goes wrong: you'll know which batch the error is in, and you only restore that batch, no need to redo everything.
What to do: the executing AI saying it's done and all fine cannot count as verification. Switch to another AI, or use a different method yourself, and check again: open a few sampled files to see the actual content, compare the changed files against the backup, and confirm the differences are only the expected ones.
What counts as done | you can state the verification evidence: which files I sampled, what I compared, and the result.
Example: sample 3 files from batches 1, 3, and 6 and open them. Then ask another AI to scan all the filenames and report whether any were missed or are inconsistent in format.
The most common pitfall | treating the executing AI's report as verification. It may really be done, or it may just think it's done. The rule: execution and verification cannot be the same mind.
What to do: record four things: what was changed this time, how it was verified, where the backup is, and when the backup can be deleted.
What counts as done | all four things are written. For backups, my habit is to keep them a week and delete only after confirming everything is fine, and I open a to-do to remind myself to delete the backup, not relying on memory.
Example: the note says "7/02 renamed 300 files, sampled 9 plus a full filename scan passed, backup in such-and-such folder, delete on 7/09 after confirming all is well."
The most common pitfall | disbanding once it's done. When something actually goes wrong, you can't even remember what you touched last week. This note is the map for the next time something breaks.
4. When it goes wrong, follow these five moves
The real value of the fault-tolerant Loop is after something goes wrong. When you notice something's off, do it in order:
| Order | Move | The point |
|---|---|---|
| 1 | Stop | Don't rush to fix |
| 2 | Locate | Check the wrap-up note and batch records to find which batch erred |
| 3 | Restore | Restore that batch from the backup |
| 4 | Fix the approach | Find where the instruction was written wrong, and change it |
| 5 | Back to step 3 | Small-test again; only scale up after it passes |
The fifth move is the easiest to skip: don't fix and then immediately re-run at scale, because your fix itself may also be wrong. A fixed instruction gets the same treatment as a new instruction, always small-tested again.
5. A real case: 170 files corrupted, then recovered
A while back I ran a large knowledge-base cleanup, fully autonomous, with AI handling over a hundred files. In one part, the batch-replace instruction was written wrong, the whole batch ran, and the content of 170 files was scrambled. Worse, that backup only covered the folder I assumed would be touched, while the actual damage spread beyond the backup's scope.
The files were recovered, because the way they were corrupted could be reversed. I wrote up the full account and the three lines of defense separately: AI Errors Aren't the Danger, Having No Backup Is: Lessons From Corrupting 170 Files. This six-step Loop is the complete process I organized from scattered principles after that incident.
6. How to think about cost: different steps, different tiers of AI
The fault-tolerant Loop has many steps, won't it be expensive? My approach is to tier the models. State the premise firmly first: only after the exit is kept, the small test passes, and the stop-loss is agreed, may you hand execution to a cheap model.
| Step type | Which steps | Which model tier |
|---|---|---|
| Requires judgment | Sorting by size, designing the plan and restore steps, interpreting verification results, analysis after an incident | The strongest model |
| Pure execution | Copying backups, running batches, running verification commands | A cheap, fast model |
Handing execution to a cheap model is fine, because the whole loop holds it. And execution and verification are always different minds.
Wrap-up
To put this piece in one line: instead of spending effort making AI not err, spend the effort making sure you can come back after it errs.
If you're pressed for time, condense it into three questions to ask yourself before starting: is the exit kept? Have I tested the small one? Who verifies?
Only with a strong enough safety net do you dare hand bigger things to AI. That fault-tolerance mechanism is exactly what lets you accelerate.
FAQ
Do I have to run all six steps every time I use AI?
Step 1, "sort by size," is answering exactly this question. Everyday small things get done directly; only things that touch a lot, can delete, or can't be changed back enter the full six steps.
I don't have hundreds of files to handle, is this useful to me?
Yes. Just use the three questions from the wrap-up: is the exit kept, have I tested the small one, who verifies. It applies to any situation where you hand something important to AI, such as letting AI edit your resume, organize your photo album, or clean up your inbox.
How long should a backup be kept?
My habit is a week. Delete only after confirming everything is fine, and open a to-do to track deleting the backup, not relying on memory.
How does this relate to Loop Engineering?
The fault-tolerant Loop is one application of Loop Engineering. Loop Engineering is about turning repeated work into a self-running cycle; the fault-tolerant Loop is about how to run the highest-risk kind of that work, large-scale changes, safely.
Want to bring the fault-tolerant Loop into your own workflow?
I host two free online talks every month, sharing practical methods for using AI as a thinking partner and turning your knowledge and experience into prompts, skills, and a knowledge base. If you're interested in AI workflows and Loop Engineering, start from the community.
Two free talks every month.
Join the LINE Community ↗