The “one change, read the diff, commit” loop: Git for non-engineers

The scariest moment for a new builder isn’t a blank screen. It’s when the app worked an hour ago, the agent has made a pile of changes since, and now nothing loads and you don’t know what changed.

Git exists to make that moment boring. It saves snapshots of your project so you can see exactly what changed and go back to any earlier version. You don’t need to master it. You need one loop and a handful of commands.

The loop

1. Ask for one change. One. “Add a delete button to each row in the projects list” is one change. “Add delete, editing, and sorting” is three.
2. Read the diff. Look at exactly what the agent changed before you accept it.
3. Run it. Open the app and try the thing you asked for. Then try something nearby to make sure it still works.
4. Commit. Save a snapshot with a short message describing the change.

Repeat that all day. It feels slow for the first week and turns out to be fast, because you almost never lose more than one change’s worth of work.

How to read a diff without knowing how to code

A diff shows lines removed (usually red, marked with a minus) and lines added (usually green, marked with a plus). You won’t understand every line, and that’s fine. You’re checking for things anyone can spot:

• Which files changed. If you asked for a button and the agent edited your database setup, ask why.
• How much changed. A small request should produce a small diff. Hundreds of lines for one button is a warning sign.
• Code you didn’t expect to lose. Agents sometimes delete things while “cleaning up.” Large red blocks deserve a question.
• Secrets. Anything that looks like a key or password showing up in a file that’s about to be committed.

When something looks off, ask the agent directly: “Explain each file you changed and why.” Agents are good at explaining their own work, and the explanation often exposes the mistake.

The commands you need

You can do all of this from your editor’s source control panel, but it helps to know what’s happening underneath. Run these from your project folder:

git status                # what has changed since the last commit
git diff                  # show the line-by-line changes
git add -A                # stage every change for the next commit
git commit -m "Add delete button to projects list"
git log --oneline         # list recent commits
git restore .             # throw away uncommitted changes to tracked files
git push                  # send your commits to GitHub

The most underrated line there is git restore. If the agent made a mess and you haven’t committed, it puts every file Git was already tracking back to your last commit. Brand-new files the agent created stay put, so check git status afterward and delete anything you don’t want. Knowing you can always get back is what makes it safe to experiment.

If you already committed the bad change, ask your agent to help you revert that specific commit. Reverting adds a new commit that undoes the old one, so your history stays intact and nothing is lost.

Writing commit messages

A commit message is a note to your future self. Keep it short and describe the change in plain language. “Add delete button to projects list” is good. “Updates” or “fix stuff” will be useless the day you need to find when something broke.

A handy trick: once you’ve reviewed the diff, ask the agent to draft the commit message. Then read it and trim anything that overstates what changed.

Push to GitHub often

Commits live on your computer until you push them. Pushing sends them to GitHub, which gives you an off-site backup and, later, is how Vercel knows there’s a new version to deploy. Push at the end of every work session at minimum.

This loop is the backbone of the Build With Agents module in the sprint, but you can start using it today on any project you have open.