By the end of this post you will know the difference between version control, cloud backup and build memory, what each one records, what each one leaves out, and why a project can have all three without any of them being redundant.
The three questions
Every project that is worth keeping raises three separate questions.
If my files are lost or damaged, can I get them back?
If a change breaks something, can I see what changed and go back to before it?
If I come back in a month, or hand this to someone else, can anyone tell why it works the way it does?
Backup answers the first. Version control answers the second. Build memory answers the third. Each does its own job well and the others' jobs badly.
Cloud backup
A cloud backup is a copy of your files kept on someone else's computer. Services like OneDrive, Google Drive, Dropbox and dedicated backup tools do this. Some copy continuously as files change. Some run on a schedule.
What it records: the current contents of your files, and often a limited history of earlier versions of each file, kept for a set period.
What it is good at: recovering from disk failure, theft, accidental deletion, or a machine that will not boot. If your laptop dies, your project exists elsewhere.
What it leaves out: backup has no idea which version worked. It keeps whatever was on disk at each moment, including the broken versions. If you overwrote a working file with a broken one and the backup ran, both are there, and nothing marks which is which. And a backup records nothing about why. It holds the files, not the reasons.
Version control (Git)
Version control is a system that records the state of your project's files at chosen moments. Git is the most widely used one. GitHub Desktop and similar programs put a window on top of it so it can be used without typing commands, though many people still meet it through a terminal, the text-based command window that programmers use.
The key idea is the commit. A commit is a snapshot of every file in the project at one moment, together with a short message you write to describe it. You can compare any two commits and return the whole project to any one of them.
What it records: exactly which lines of which files changed between any two commits, and the message written at the time.
What it is good at: answering "what changed?" precisely, and going back. If a commit broke the game, the difference between that commit and the one before is a complete, exact record of the change. Git is also the standard way for several people to work on the same code without overwriting each other. For any project that will be shared or will grow, it is the right tool and worth learning.
What it leaves out: Git records what changed, not why it worked. The commit message is whatever the person wrote, and if the AI wrote the code, the person often does not know what to write. Git also does not record what the AI said. If the AI claimed to change one file and changed three, Git shows three files changed. It does not show the claim, so the mismatch is invisible unless you were keeping the claim somewhere else.
Git also has to be operated. Someone must make the commits at the right moments with useful messages, and for a non-coder the concepts (commits, branches, merges, remotes) are a real learning cost.
Build memory
Build memory is a per-project record kept alongside the game. It is written for the moment a person confirms the build works, and it records what a snapshot cannot: why this build works, what the owner decided, what the AI claimed to have changed against what actually changed in the files, and a verified copy of the working version that can be checked against the original.
What it records: reasons, decisions, claims, and the difference between claims and reality, attached to a specific confirmed-working state.
What it is good at: answering "why does this work, and what did the AI really do?" When a new session starts cold, the reasons can be shown to the model, because they were written down when they were known.
What it leaves out: build memory is not a backup. It keeps a recovery copy of confirmed builds, not a continuous copy of everything, and it lives on the same machine unless you back it up. It is not a substitute for version control on a shared or growing project. It does not record every intermediate change, only the ones a person marked as working.
Why they do not replace each other
A backup will save your project from a dead disk. It will not tell you which of the forty versions in its history was the one that worked.
Git will tell you exactly what changed between any two commits. It will not tell you why the earlier one worked, or that the AI said it changed one thing and changed three.
Build memory will tell you why a build worked and whether the AI's account matches the files. It will not save you from a dead disk, and it does not track every keystroke between confirmed builds.
What to do in practice
If you have nothing, start with a backup. It is the cheapest protection and the widest.
If your project is growing or you work with anyone else, learn Git, through a graphical program if the terminal puts you off.
Whatever else you use, keep a written record of why each working build works, made at the moment you confirm it, before you ask for the next change. That can be a text file. The point is that it exists somewhere outside the AI, because the AI will not remember, and the files alone do not say.
More guides
This is one of a series of plain-language guides to building with AI coding tools. See all guides.
Ask Aquila