Building a Verification Loop With Antigravity 2.10.0's Embedded Terminal

Every time an agent finished writing changes, I switched to a separate terminal window. Run the tests, trace the failing line, switch back. Some days the switching wore me down more than the work itself.

Version 2.10.0, released on August 24, lets you open a terminal directly from the sidebar with Ctrl / Cmd + `. The same release moved Git into the Review pane, so you can inspect the working tree diff, stage files, and commit without leaving the app.

It looks like a small change. For me it turned into a reason to rebuild the habit underneath it — the rule that I always run at least one command myself before accepting an agent's work. Once the cost of switching dropped, a different problem surfaced: without deciding in advance what to run, the checking becomes scattered.

When the friction disappears, the quality of your checking gets exposed

Back when leaving for an external terminal was annoying, that annoyance quietly limited how often I checked. It acted as a filter.

Remove the friction and you start running things at random. A slightly different command each time, a slightly different scope, and afterwards you cannot quite say what you verified. Working as an indie developer, nobody points that out for you.

So the first thing worth doing with the embedded terminal is fixing the set of commands you run.

Pin it down to three commands

These are the three I use. They are chosen so their purposes do not overlap.

The order matters. Reading a diff while the code does not even typecheck wastes the reading. Running tests without reading the diff misses the category of mistake that passes tests happily — an implementation that works but is not what you asked for.

The third one is measurement, not review. You ask for a small fix, and the agent touched 40 files. Seeing that number once, before staging, is enough to decide whether to accept the change or split it. If the diff has grown past what a single commit should carry, Splitting a Giant Antigravity Diff Into Meaningful Commits covers how I break it apart.

Scope the checks to the files that changed

Of those three, the first two are what actually cost time. Running them across the whole repository throws away the benefit you just gained.

I compared the two approaches on my articles repository — 1,031 MDX files — using a small script that validates required frontmatter keys.

A factor of 251. The absolute numbers will differ in your project — a type-checked TypeScript repository is far slower than a text validator — but the shape of the gap holds: the cost of a full-tree check scales with the repository, while the cost of checking a diff scales with the diff.

Waiting 6.8 seconds once is fine. Waiting 6.8 seconds several dozen times a day, every time you want to sanity-check an agent's output, is exactly the kind of cost that makes you skip the check.

Here is the script I settled on. It lives at the repository root so I can invoke it straight from the sidebar terminal.

#!/usr/bin/env bash
# verify-changed.sh — verify only the files that changed
set -euo pipefail
 
# Uncommitted additions, copies, and modifications.
# The -z flag plus mapfile -d '' keeps paths with spaces intact.
mapfile -d '' -t CHANGED < <(git diff --name-only --diff-filter=ACM -z HEAD)
 
if [ "${#CHANGED[@]}" -eq 0 ]; then
  echo "No changes. Skipping verification."
  exit 0
fi
 
echo "${#CHANGED[@]} file(s) to verify"
 
# Route files to the right checker by extension.
TS_FILES=()
for f in "${CHANGED[@]}"; do
  case "$f" in
    *.ts|*.tsx) TS_FILES+=("$f") ;;
  esac
done
 
if [ "${#TS_FILES[@]}" -gt 0 ]; then
  # Passing files to tsc directly makes it ignore tsconfig.json.
  # So we typecheck the project and filter the output instead.
  npx tsc --noEmit --pretty false 2>&1 \
    | grep -F -f <(printf '%s\n' "${TS_FILES[@]}") \
    || echo "No type errors in the changed files"
fi
 
exit 0

The tsc part needed care. Hand it file arguments and it stops reading tsconfig.json, which means a project with strict enabled silently gets checked under looser rules. Filtering the output instead keeps the configuration in force.

That was not something the documentation made obvious. My first version passed the files directly, and I spent a while pleased that no type errors were showing up.

Two assumptions worth checking first

A sidebar terminal does not necessarily start in the same environment as your usual one. Two things trip people up early.

PATH inheritance. An application launched from the GUI may never run the config files your login shell reads. It shows up as a command that works everywhere else returning command not found here. The same root cause affects agent-run commands, so the diagnosis in When the Antigravity Agent Says 'command not found' for node or python: Causes and Fixes applies directly.

Working directory. With a multi-root workspace open, it is not obvious which root the terminal starts in. A verification script written with relative paths will happily inspect the wrong repository. I now print git rev-parse --show-toplevel at the top of mine. It costs one line and removes an entire category of confusing results.

If non-ASCII output comes back garbled, that is a separate encoding setting rather than a path problem — Fixing Japanese Mojibake (Garbled Text) in Antigravity's Integrated Terminal covers that case.

Give the Review pane and the terminal separate jobs

Since 2.10.0 also brought Git into the sidebar, both tools now sit within reach, and it gets easy to blur what belongs where. My split looks like this.

The dividing line is whether a human is required. Matching intent can only be read. Whether something is broken is better answered by a machine. Drawing that line once cuts down the time spent staring at a diff wondering whether it runs.

If typing the same verification commands starts to grate, move them into task definitions. Combined with the setup in Polishing Your Antigravity Workflow with tasks.json and launch.json, launching them from the embedded terminal becomes a single keystroke.

One thing to do next

Drop a file equivalent to verify-changed.sh into whichever repository you are working in right now. It can be nearly empty. Having an obvious entry point for "check only what changed" sitting at the repository root is itself what stops you from skipping the check.

How to decide the scope you hand to an agent in the first place is something I work through in a membership article, counting an actual working tree as I go. If the question one level up from workflow interests you, that is where it lives.