Google Antigravity First Look: Hands-on with Google's AI Coding Agent

Google Antigravity is an agent-first development environment (a VS Code fork built around Gemini 3 Pro) that lets you hand off entire coding tasks, not just autocomplete, to agents working across your editor, terminal, and a real browser. It is a free public preview, strong on greenfield features and test-driven fixes, weaker on large legacy refactors that need deep repo context.

What Exactly Is Antigravity, and How Is It Different from Copilot or Cursor?

Most AI coding tools live inside one surface: your editor. GitHub Copilot and Cursor both started as inline completion and chat layered onto an editing surface, and even their agent modes still treat the editor as the primary canvas. Antigravity flips that. Google built it as a standalone application, distributed separately from VS Code proper, where the editor is one of three peer surfaces alongside a terminal and a controllable browser instance. The pitch, laid out on the official Antigravity site, is that an agent should be able to write code, run it, and verify the result in a real browser without you shuttling context between four different windows.

In practice this means Antigravity's agent can open a Chrome-based browser session, click through your app's UI, take a screenshot, and use that screenshot as evidence in its own task log. Cursor and Copilot Workspace can call out to headless browser tools if you wire them up, but it is not the default loop. In Antigravity it is the default loop.

Under the hood, planning and code generation run on Gemini 3 Pro by default, with lighter subagent tasks (browser verification, quick lint checks) often assigned to Gemini 3 Flash to keep the loop from being bottlenecked on the slower model for every trivial step. You can see and change model assignment per agent in the manager view, which matters because a Pro-only run on a multi-file task can take noticeably longer than the same task split across a fast subagent for verification and a slower one for planning.

Setting Up a Real Task: A Walkthrough

I pointed Antigravity at a mid-size Next.js app (roughly 40k lines, a mix of TypeScript and a few legacy JS files) and asked it to add a paginated API endpoint plus a matching frontend table with sort controls. The prompt I gave the agent manager looked like this:

1Add a GET /api/orders endpoint with cursor-based pagination
2(limit + cursor query params, default limit 25, max 100).
3Add a frontend OrdersTable component that consumes it, supports
4sorting by date and total, and shows a "load more" control.
5Write integration tests for the endpoint and a Playwright test
6for the load-more flow. Do not touch the auth middleware.

The agent broke this into a task list artifact, which you can inspect and edit before it starts. That editable plan is one of the better design decisions here: I removed a subtask where it proposed adding a new ORM migration (unnecessary for this schema) before it touched a single file, saving a rollback later.

Execution took about eleven minutes end to end, including a full Playwright browser run against a locally spun-up dev server. That is slower than a single Cursor Composer pass on the same scope (closer to three or four minutes in my experience), but the difference is that Antigravity's run included actual browser verification of the load-more interaction, not just a static code diff and a hope that it works.

The Agent Manager: Running Several Agents in Parallel

The feature that most changes daily workflow is the Agent Manager, a separate window that lists every active and past agent run across your projects. You can kick off three or four agents on unrelated tickets (a bug fix, a small refactor, a test-coverage task) and check back in fifteen minutes rather than babysitting one chat thread.

The catch: agents running against the same repo checkout can and do collide. I ran two agents against the same branch, one adding a component and one refactoring a shared utility file, and the second agent's diff conflicted with the first's mid-run. Antigravity surfaced the conflict rather than silently overwriting, but recovering meant manually rebasing the agent's working branch, something the tool does not automate yet. The safe pattern is one agent per worktree or per branch, which means you need git worktree discipline if you want true parallelism:

1git worktree add ../app-agent-1 feature/orders-endpoint
2git worktree add ../app-agent-2 fix/date-parsing-bug

Point each Antigravity agent at a separate worktree and the collision problem disappears.

Artifacts: How Antigravity Shows Its Evidence

Every completed task produces an "artifact": a walkthrough document with the diff summary, test results, and (when a browser subagent ran) screenshots of the before and after UI state. This is genuinely useful for code review. Instead of reviewing a raw diff cold, you get a short narrative plus visual proof that the load-more button actually loads more rows.

It is not a substitute for reading the diff, though. On one task the artifact confidently described a change as "adds null check to prevent crash" when the actual diff had added the check to the wrong branch of an if/else, meaning the crash path was still reachable under a different condition. The artifact's prose was optimistic; the code was wrong. Treat artifacts as a review aid, not a review replacement.

Where It Breaks: Failure Modes Worth Knowing

Three failure patterns showed up repeatedly in a week of daily use:

Repo context limits on large monorepos. On a roughly 250k-line monorepo with multiple packages, the planning agent occasionally referenced a file path that had been moved six months earlier, because its retrieval step pulled a stale index. Smaller, well-scoped repos did not show this problem.

Test-loop thrashing. On one task involving a flaky integration test unrelated to the actual change, the agent spent several minutes retrying and rewriting the test to make it pass rather than recognizing the flake and flagging it. It eventually gave up and reported the failure honestly, but the retry loop burned real time and, if you are on metered API usage instead of the preview, real tokens.

Browser subagent brittleness on dynamic UI. Single-page apps with heavy client-side routing occasionally caused the browser subagent to click a stale element reference after a re-render, producing an "interaction failed" artifact that needed a manual rerun.

None of these are disqualifying, but they mean you should not point Antigravity at your highest-stakes legacy refactor unattended and walk away for the afternoon.

Cost and Latency Realities

As of this preview, Antigravity itself does not charge per token; Google is running it as a free public preview tied to a Google account, distinct from paying for Gemini API usage directly through Google AI Studio or the Gemini API. That changes the calculus versus Cursor, which bills through its own subscription plus usage-based model calls, and versus Copilot, which is a flat per-seat subscription through GitHub. If your team is cost-sensitive right now, free preview access is a real advantage, but it is also temporary by nature of being a preview, and Google has not published what pricing will look like once it exits that phase.

Latency is the tradeoff for the extra verification. A task that touches three files and includes a full browser check regularly runs eight to fifteen minutes end to end in my testing, versus two to five minutes for a comparable Cursor Composer run without browser verification. If you need fast iteration on small, well-understood changes, that gap is annoying. If you need confidence that a UI change actually works before it hits review, the extra minutes buy something Cursor and Copilot do not give you out of the box.

Antigravity vs Cursor vs Copilot: When to Reach for Which

Reach for Antigravity when the task has a verifiable end state you can check visually or through an integration test, when you can afford a few extra minutes per task, and when you want an artifact trail for review. It is a strong fit for feature work with clear acceptance criteria: new endpoints, new UI flows, bug fixes with a reproducible browser-observable symptom.

Reach for Cursor or Copilot's agent mode instead when you need fast, tight iteration inside the editor on changes that do not need browser-level verification, when you are working in a very large monorepo where context retrieval matters more than execution surface, or when your team already has Cursor or Copilot licenses baked into procurement and switching tools has its own cost.

A Workflow That Actually Works

The pattern I settled on after a week: use Antigravity for anything with a UI or API contract you can verify end to end, spin up a dedicated git worktree per agent task so parallel runs cannot collide, read the artifact for context but review the raw diff line by line before merging, and fall back to a tighter, faster tool for small mechanical edits where an eleven-minute browser-verified run is overkill. Treat the free preview pricing as a limited-time advantage rather than a permanent one, and budget review time for the cases where the artifact's narrative is more confident than the code underneath it deserves.