The first time you let an AI tool edit your project directly, something in you tightens. You typed a sentence and pressed enter, and now files you have never opened are being rewritten in place. In every tool you trusted before, undo sat one keystroke away and covered your last few moves. Here, a piece of software is changing a whole folder at machine speed, and if it makes a mess you are not sure you could even find the mess, let alone reverse it.
That fear is reasonable, and it is also solved. The fix is an old tool that sits under every serious software project and asks nothing from you beyond a mental model you can hold by the end of this page. It is called git, and in the agent era it is what makes handing your files to an AI a calm decision rather than a gamble.
Code is just text files in folders
Before git can make sense, settle what code actually is. A codebase (you will also hear repo or repository) is a folder. The folder holds more folders and files, and the files hold text. When an agent edits your code, it opens text files and changes the text, which is the same physical act as you editing a document, only faster and in more places at once.
Open any public project on GitHub and the structure is familiar: folders, sub-folders, and files with names like index.js or README.md. Some files hold code, some hold configuration, some hold documentation, and every one of them is text you could open right now. You will never need to read most of them. You do need to know that this is the entire structure of the thing your agent works on, because anything made of files can be copied, compared, and restored.
Git is undo for the whole project
You have managed versions by hand before. Most laptops that have ever produced a serious document hold a folder like this somewhere:
Final.docx
Final_v2.docx
Final_FINAL.docx
Final_FINAL_use_this_one.docx
That folder exists because filenames are the only version control a plain folder offers, and git is the engineered answer to the same need.
Put simply, git is undo for an entire project.
Git records every change to every file, by anyone, for the life of the project, and it turns that record into a few moves you will use constantly.
- Save point. Git calls it a commit. It is a snapshot of every file in the project at one moment, stamped with a one-line note saying what changed. Take one whenever the project is in a state you would want back.
- Branch. A branch is a parallel timeline. Branch off, try the risky redesign there, and either fold the result back into the main line or throw the branch away. Your main work is untouched either way.
- Restore. Roll a file, or the whole project, back to any save point. Recovery becomes one deliberate step back to a state that worked, not an afternoon of forensic reconstruction.
You may have noticed that none of this involved commands. Git has a famously prickly command line, and you can have a long building career without typing any of it, because your tool runs the commands for you. You ask for outcomes, like "make a save point before you start," "show me what changed since the last save point," or "put everything back the way it was," and the tool maps each request onto the right git operation. All you have to keep in your head is the picture of a timeline of snapshots you can always step back to.
Why a save point matters more when an agent is editing
When you edit files yourself, you work at human speed and remember roughly what you touched. An agent has no such limit. It can modify files all over the project in the time it takes you to read its plan, and a long session reaches corners of the codebase you have never opened. Reviewing every line as it changes is not realistic, and Review what the AI built covers how to check the work without reading all of it.
The habit to build is simple: make a save point before the agent works. Once that save point exists, the worst case for your files is restoring and retrying with better instructions. We take save points several times an hour when we are actively building, so a mistake, ours or the agent's, only ever costs us the work since the last one.
The industry got a public lesson in July 2025, when an AI coding agent on Replit deleted a startup investor's production database, the live data rather than a test copy. It happened during a code freeze, a window when nothing was supposed to change, and despite explicit instructions not to touch anything. The company's chief executive apologized publicly and shipped new safeguards. The point is not that one vendor failed. The point is that an agent with access and no checkpoints turns one bad minute into a permanent loss, and that safety comes from save points plus hard limits on what the agent can reach.
Git keeps the history, GitHub stores it online
People say git and GitHub interchangeably, and they are different things. Git is the tool that keeps the history, and it runs on your machine, inside the project folder. GitHub is a website where a copy of that history lives online. Other sites play the same role, but GitHub is where most of the world's shared code sits.
The online copy is a backup, so a dead laptop costs you hardware and nothing else, and it is also the meeting point where collaborators and tools pick up your project. When a tool offers to push to GitHub, it is offering to send your local save points up to that online copy, the same local-versus-remote split you met in Where software lives.
Try it now
No setup: Open github.com in your browser and look up a popular project behind a tool you already use. From the project's page, open its commit history and read one screenful of messages, newest first. Each row is a save point with a note, and together they read as the project's diary of what changed, when, and why. Any row could be restored, and the small, specific notes keep the history navigable when something breaks.
With your tools: In Claude Code, inside any project folder, start your next session with one request: "If this folder is not a git repository yet, initialize one. Then make a commit named 'save point'." Now ask for the change you actually wanted. When it finishes, ask "show me what changed since the save point," and if anything looks wrong, "restore everything to the save point." That loop of checkpoint, change, and review is the habit this chapter exists to install. In Codex or Cursor the move is the same: ask the chat for the save point commit first, then read the source control sidebar to see every file the agent touched. If your tools are not set up yet, the Setup Clinic takes you from nothing to that first commit.
Chapter Summary
- Your code is just text files sitting in folders, and an agent editing it is doing the same thing you do in a document, only faster and in more places at once.
- Git is undo for the whole project. It records every change to every file and lets you step back to any earlier state.
- The three moves you will actually use are the save point (a snapshot of every file, called a commit), the branch (a parallel timeline for risky attempts), and restore (roll a file or the whole project back to a save point).
- You never have to type git commands. You ask your tool for the outcome you want, and it runs the right command for you.
- Make a save point before an agent starts. After that, the worst case is restoring and retrying with better instructions, so any mistake only costs you the work since that point.
- Git only protects what lives in the project folder. Your live database, the emails a tool can send, and the money a payment integration can move are not files, so keep an agent behind strict limits on what it can reach.
- Git keeps the history on your machine, and GitHub stores a copy of it online, which turns a dead laptop from a disaster into an inconvenience.
- Save points handle safety on your own machine. The next problem is that a project that runs perfectly for you can still break the moment it runs anywhere else, which is where Environments: why it works on your machine and breaks online picks up.
Sources
- Public reporting on the Replit coding agent incident and the company's response (2025).