Guides
Commit Before You Prompt: The One Git Habit for AI Coding
Published:
Before you let an AI write a single line in your project, do one thing: make a git commit. It takes five seconds, and it’s the habit that makes everything else work. You can see what the AI changed, trust it, and undo it when it’s wrong. The reason is simple and worth understanding, because once you get it, you’ll never skip it.
A diff needs a clean starting line
“See what the AI changed” sounds easy, but it depends on something most beginners miss: a diff is always a comparison against a baseline. Git compares your files now against your last commit. So if your last commit was a clean, finished state, then every change the AI makes stands out crisply in your editor’s Source Control panel and in git diff. New lines in green, removed lines in red. You can read its work in isolation.
But if you start from a messy working tree (half-finished edits of your own, debugging tweaks, a function you were in the middle of), then the AI’s changes pile on top of yours, and the diff becomes an unreadable blend of “who changed what.” You lose the one thing that makes AI coding safe: the ability to see exactly what the machine did, separate from what you did.
Committing first draws a clean line in the sand. Everything after it is the AI’s work, clearly labelled.
It also gives you a real undo
The second payoff is safety. AI coding agents are powerful, and occasionally wrong in surprising ways. They rewrite a file you wanted left alone, or “fix” something that wasn’t broken. When that happens and you committed first, recovery is trivial: discard the changes and you’re back to your known-good state, instantly. No detective work, no trying to remember what the original looked like.
This is the calm antidote to the most common AI-coding fear, the one that goes “it changed something I didn’t ask it to touch.” With a commit behind you, that fear evaporates, because you can always get back.
”Commit before prompt” in practice
The rhythm is small and repeatable:
- Commit your current work (even a scrappy “wip” message is fine).
- Prompt the AI to make the change.
- Review the diff: run
/diffin Claude Code, or open the Source Control panel in VS Code and click each modified file. - Keep or undo. If it’s good, commit again. If it’s not, discard and try a different prompt.
Those extra commits aren’t clutter. They’re cheap, and you can always tidy them later. Rewrite a message, or squash several into one before you share your work. Frequent small commits are exactly how experienced developers stay fearless.
Checkpoints are not a substitute
Modern tools like Claude Code add their own checkpoints. Press Esc twice or run /rewind to roll the code and the conversation back a step. These are genuinely useful for a fast undo. But be honest about what they are: a local, temporary undo of the AI’s own edits. They don’t capture changes made by commands you ran in the terminal or by other programs, and they don’t persist the way a commit does. So the layered approach wins: checkpoints for quick “oops, go back one step,” git commits for your permanent, trustworthy save points.
You need almost no git for this
If git intimidates you, here’s the reassuring part. This habit needs only three moves: save a point (commit), see what changed (the diff), and go back (undo). Your editor’s Source Control panel does all three with buttons; you never have to memorise a command. That’s the smallest slice of git that delivers the biggest safety net, and it’s all you need to let an AI work on your code with confidence.
Get set up properly from the start
Our free AI for Coders tool helps you pick the right coding assistant, install it correctly for your operating system, and generate a starter rules file so the AI respects your project’s conventions. Add the “commit before you prompt” habit on top, and you’ll have the two things that make AI coding safe: a tool that fits your work, and a clean diff you can always read and undo.
Keep reading
Frequent questions
Why commit before asking AI to change my code? +
A diff only makes sense against a clean starting point. If you commit first, every line the AI changes shows up clearly as new in git and your editor's Source Control panel, so you can see exactly what it did. If you start from a messy working tree, your half-finished edits and the AI's changes blend together and you can't tell them apart.
Isn't that a lot of extra commits? +
They're cheap and temporary. Make a quick checkpoint commit before a risky prompt, and once you're happy with the result you can keep it, rewrite the message, or squash several commits into one. Frequent small commits are a feature, not clutter. Each one is a point you can safely return to.
Do AI checkpoints replace this habit? +
No. Tools like Claude Code have their own checkpoints (Esc Esc or /rewind) that undo the AI's edits, but those are a quick local undo: they don't track changes made by terminal commands or other programs, and they aren't permanent. A git commit is the reliable save point. Use checkpoints for fast undo and git for real safety.
I don't really know git. Can I still do this? +
Yes. You only need three actions: commit (save a point), look at the diff (see what changed), and undo (go back). Your editor's Source Control panel does all three with buttons, so there's nothing to memorise. It's the smallest amount of git that gives you the biggest safety net.