Guide · Already building with AI
Check that your work was really backed up, whatever the tool said
Before you believe "saved" or "backed up", open the file from somewhere else. In my research project, the log said a folder of data files was backed up for a week, and none of them were. The habit for anyone, and the git details for people who use it.
When an app, a shared drive or an AI tells you a file is saved or backed up, open it from somewhere else before you believe it: from another device, from the shared link, or from the file's version history. A sync app can show a green tick while a file sits in a folder it was never told to sync. If an AI agent says "I saved the report to the team folder", go to the team folder and open the report. People who run backups use the same habit: you only know a backup works once you have restored something from it.
For teams: name who confirms that important work reached the shared copy (the person who made it should not be the only one), do it the same day the work is marked done, and record the confirmation where the team tracks the work, such as the ticket or the project log. An AI agent can do the confirming only if it uses a check that someone else can repeat, like a script, and the result goes in the same record.
Here is the case that taught me this. My research project is mathematics, done with Claude, an AI agent that writes code, runs computations and keeps a log of what it did. The project's files are backed up with git, which keeps a saved copy of each version; recording a version in git is called a commit. On August 28 a new folder was started for one paper's data. Over the next week Claude committed its work many times. Each time the commands finished without an error, and Claude wrote in the log that the data was committed. The folder's text documents really were in git, so it looked complete.
None of the folder's 96 data files were. They sat safely on the computer's disk, but git had no copy of any of them, including data that every check in that paper relied on. It came to light on September 4, when Claude tried to add one new data file by naming it directly, and git refused and said the file was set to be skipped. Claude then found all 96 files missing from git and committed them. For a week the log had said there were backup copies, and there were none.
Claude then scanned the whole project for the same problem. It sorted the 1,916 files git was skipping:
| Files | What they were | What happened |
|---|---|---|
| 571 | Code, results, figures and other work that should have been kept | Committed that day |
| 1,143 | Temporary files, downloads, large files and other things meant to be skipped | Left skipped on purpose |
| 172 | Files Claude was unsure about | Left skipped and reported to me |
| 18 | A folder another agent was still working in | Left alone until that agent finished |
| 12 | Files covered by a separate access rule | Left alone |
If you do not use git, you can stop here. The rest of this lesson is the mechanics, for people who do.
Git reads a settings file, .gitignore, that says which files to skip. Mine works as an allow list. It starts with "*" (skip everything) and "!*/" (but look inside every folder). Then come about a dozen lines that let kinds of files back in, such as "!*.md" (keep text documents), "!*.py" (keep Python code) and "!*.csv" (keep CSV tables).
Git applies the lines from top to bottom, and when two lines match the same file, the later line wins. The new folder's data files were JSON files, and no line let JSON back in, so "*" applied to them. Its text documents matched "!*.md" and were kept. The fix was one more line: an exclamation mark, the folder's name and /**, which lets everything in that folder back in.
Claude staged files with git add -A, which stages every new, changed or deleted file that is not ignored, and then committed. git add -A did what it was configured to do: it exits without an error and prints nothing about the files it skipped, which is why a week went by.
The same file caused a different problem on September 3. Claude sorted it alphabetically to remove a duplicate line. In plain byte order "!" comes before "*", so the sort moved the "*" line below every "!" line, and "skip everything" became the last word on every file and folder. From then on git ignored every new file. About twenty-five minutes later a separate Claude session noticed its four new files were not being tracked, traced the cause to the sort, and the earlier version of the file was restored. Some sort programs order punctuation differently, so the same sort can give different results on different machines. The order of lines is what the file means; never sort it.
Checks that catch this:
- git check-ignore -v followed by a path prints the exact line of .gitignore, with its line number, that is causing git to skip it. It would have explained both problems in seconds.
- git ls-files --error-unmatch followed by a path fails if git is not tracking the file. Tracked means git knows about it, which is not yet the same as committed.
- git ls-tree -r --name-only HEAD lists what is actually in the last commit; search its output for the files you expect.
- git status --ignored=matching -uall lists every ignored file one by one (plain --ignored folds a fully ignored folder into one line), so you can read the list for anything that should not be on it.
- A fresh clone from the remote, into another folder, is the git version of opening the file from somewhere else. It proves the commit and the push. A clone of your local copy proves only the commit.
Asking an agent to run these checks still relies on its report. Where you can, run them mechanically: a post-commit hook or a continuous-integration job that lists the expected files in HEAD and fails loudly if one is missing.