Chat, Editor, Terminal: Which of the Three Panes to Watch on Day One

The first time I opened Antigravity, several areas competed for my attention, and my hands simply stopped. Even people used to reading code may feel something similar for the first few minutes.

The pane I stared at longest was the editor, the one with a file open. But once I asked the agent to do some work, I found that the place worth watching was somewhere else. Staring at the editor, nothing was happening.

This is a short note for people who don't write code, about where to look during the first week and what can safely wait.

Sort the three panes by role

The layout shifts a little between versions, so it lasts longer to remember each pane by what it is for rather than where it sits.

The right-hand column is the point. Trying to watch all three equally is tiring. On day one, let chat lead and keep the other two in supporting roles.

Only two things to read: the plan and the diff

After you send a request, the agent will often lay out what it intends to do. Reading that plan is the first habit worth building.

I narrow it to two questions:

1. Are the files it plans to touch within the scope I asked for?
2. Do words like "delete", "overwrite", or "install" appear anywhere?

When the work finishes, a diff shows up in the editor. That is the moment to open it and glance at the red lines (removed) and green lines (added). You don't have to understand the content. You are checking whether the amount of change matches what you asked for.

If you asked for a one-line fix and the whole screen is colored, go back to the chat before approving and ask why so much changed.

The terminal is for reading, not typing

A black screen with scrolling text is intimidating at first. It was for me.

While the agent is working, though, there is almost nothing for you to type there. Think of it as the notebook where the commands the agent ran and their results are written down.

Reading the first word of each line is enough:

npm install        <- bringing in parts
npm run build      <- assembling the finished product
rm -rf dist        <- deleting the old finished product
git push           <- sending something out to the world

If a line makes no sense, ask the agent. A fixed way of asking keeps you from hesitating.

Before (request only)

Fix the typos in README.md.

After (with a promise to check first)

Fix only the typos in README.md.
Before you change anything, list the places you plan to edit.
Before running any terminal command, tell me in one sentence what it does.

The reason is simple: I want the plan and the explanation pulled into the conversation before the agent's hands move. Checking beforehand is far easier than rewinding afterward.

My thumb was moving before I had read anything

Here is one of my own mistakes, written down.

Early on, every time a prompt asked permission to run a command, I approved it without reading. A stalled screen made me uneasy, and I wanted to get ahead. The result was poor. I couldn't explain afterward what had changed, and when I wanted to undo something, I had nothing to go on.

Now I check one thing before approving.

Before I press approve, I can say in one sentence what will change.

If I can't, I don't press it. I go back to the chat and ask for an explanation. This is the rule I keep hardest on the days I'm in a hurry.

The first thirty minutes

Here is the day-one flow, kept short.

1. Pick one folder it is fine to touch, and open it
2. Send one small request (a typo fix, tidying a description)
3. Read the plan that appears in the chat
4. When the diff appears, look at the amount in the editor
5. In the terminal, read only the first word of each command

Typing into the terminal yourself, or editing by hand in the editor, can be added later once you're comfortable.

For now, send one small request and read the plan. That is where I started too.