Lines of unfamiliar text scroll past faster than you can follow, and next to them a button asks whether you want to allow the command. Many people stop right there the first time they use Antigravity.
As an indie developer, I once spent an evening asking an agent to tidy the store descriptions for one of my wallpaper apps, and I kept pressing "allow" without really knowing what I was approving. Nothing went wrong. But what I felt the next morning wasn't relief. It was the uneasy sense that I might simply have been lucky.
Here is what I'd like to say first: you don't have to understand everything before you approve. If you narrow your attention to three places, you can avoid nearly every irreversible mistake without being able to read a single command.
Reading everything is what makes it frightening
Most of what an agent runs is ordinary work: opening a file, listing a folder, installing a package. On screen, though, harmless lines and risky lines look exactly alike, so "I can't read all of it" quietly turns into "all of it might be dangerous."
The fix is to change the question. Instead of widening what you understand, narrow what you check.
- Before you ask, make sure you can get back to where you started
- Before you approve, look only at the first word of the command
- After the agent finishes, look at what changed
These map to before, during, and after. If one of them slips, the other two will still catch a good share of the trouble.
Checkpoint 1: make a way back before you ask
First, what this step solves. If you can always return to the state you had before asking, then nothing that happens along the way can be fatal. Git is the tool for this, and the move is small: give the current state of your working folder a name and keep it.
# In your working folder: save the state before you ask the agent
git status --short
git add -A
git commit -m "State before asking the agent"git status --short tells you whether any files are mid-change. If nothing prints, the folder is clean. The last two lines save that moment.
Why bother? A saved moment is a marker you can return to any number of times. If the agent heads somewhere you didn't expect, the marker gets you back to "before." If a folder isn't under Git, copying the whole folder first does the same job.
Checkpoint 2: before you approve, read only the verb
Approval dialogs show long commands. Don't read the whole thing. Look at the first word and at where the command is pointed. The table below is the cheat sheet I wrote for myself and then tidied up.
| First word | What it means | What to check |
|---|---|---|
| ls / cat / git status | Look only | Generally fine to approve as is |
| npm install / pip install | Add a part | Does the package name match what you asked for? |
| rm / rm -rf | Delete | Is the target inside your working folder only? |
| git push --force / git reset --hard | Overwrite or rewind history | If no reason was given, pause first |
| curl, wget, sudo | Fetch from outside, or run with elevated rights | Decline if an address or permission appears that you never asked for |
You only read the left column. If a delete-type word shows up, check once that the target doesn't reach outside your working folder. If you're still unsure, don't approve; ask in the chat, "What will that command do?" Agents are good at explaining their own actions.
If the same dialog keeps coming back and slowing you down, I wrote up the causes and fixes separately: Antigravity approval dialog keeps appearing and "always allow" doesn't stick.
Checkpoint 3: after it finishes, look at the diff
Even if you felt uneasy during the run, looking at what changed afterward catches most problems. Again, you aren't reading text. You're looking at file names and the size of the change.
# See what changed since the saved moment, as a list
git diff --stat HEAD
# Look inside a single file you're curious about
git diff HEAD -- path/to/file--stat lists each changed file with a rough count of lines added and removed. If files appear that have nothing to do with your request, that's where you stop. If only the files you expected have changed, you can reasonably relax.
Why start with the list? Checking whether the scope drifted is far quicker than reading line by line, and if the scope is right, you can open individual files only when you need to.
If the scope did drift, go back to the marker from checkpoint 1.
# Discard every change and return to the saved moment (check the diff first)
git restore .This restores files that were changed after you saved. Files the agent newly created will remain, so delete them by hand if you don't need them. If there's a change you want to keep, move that file somewhere else first.
The line I've drawn
At the start I tried to read the full command every time I approved. It didn't go well. Each unreadable line stopped me, and the work itself stalled.
These days my rule is this: if I can get back, and I know where to look, I can move forward without understanding everything. You don't have to wait for your understanding to catch up. With a routine to check against, you can widen what you hand to the agent a little at a time.
The same routine works when I ask for changes to my own sites: make a way back, read the verb, look at the diff. The tools change, but the frame stays put.
Tomorrow, before you start, try typing git commit once. That alone makes working with an agent noticeably easier.