Google Antigravity IDE first impressions & survival guide

I’ve been reading docs, codelabs, blog posts, security write-ups, forum threads, X, and Reddit about Google Antigravity. Here’s a dev-focused first look plus the main gotchas.

1. What Antigravity actually is

Antigravity is Google’s free, agent-first IDE built on a VS Code fork.

You get:

• A normal Editor (VS Code style) with autocomplete and inline commands
• A Manager view where you run agents that can touch:
  • the editor
  • a terminal
  • an embedded browser
• Agents emit Artifacts: plans, task lists, diffs, screenshots, recordings

You describe tasks (“build a dashboard”, “refactor auth”), agents do multi-step work, and you review artifacts instead of digging through logs.

Short version: AI IDE + async agents + browser automation + artifact review, free public preview on macOS, Windows, and Linux. 2. Install & first-run: choices that matter

Useful entry points:

• Site: https://antigravity.google
• Docs: https://antigravity.google/docs
• Official intro on the Google Developers Blog
• “Getting Started” Codelab

Things worth deciding up front:

1. Development mode

   On first launch you pick:

   • Agent-driven – most autonomy
   • Agent-assisted – agent works but checks in
   • Review-driven – you approve almost everything

   Default to Agent-assisted. You get real work done but still see key checkpoints.

2. Review policy

   Common policies:

   • Always proceed – don’t use this at the start
   • Agent decides – fine once you trust it
   • Request review – safest on day one

   Start with Request review or Agent decides plus a careful eye.

3. Separate workspaces

   Use a dedicated sandbox folder (e.g. antigravity-playground) while you learn it. Add real repos later.

4. Install the browser extension early

   The browser agent needs the Chrome extension to click around, run UI checks, and capture screenshots / video. The codelab walks you through it.

5. Mental model: not “just VS Code”

The high-level model:

• Editor View
  Normal coding: files, inline completions, commands.

• Manager View
  “Mission control”:

  • Start tasks / conversations
  • See an Inbox of jobs (Idle / Running / Blocked)
  • Switch between Planning and Fast
  • Review Artifacts

• Planning vs Fast

  • Planning – more reasoning, task groups, richer artifacts; good for bigger work
  • Fast – fewer steps; good for small edits and quick shell jobs

• Browser Agent

  Sub-agent that drives the embedded browser:

  • clicks, scrolls, forms
  • reads DOM
  • captures screenshots and recordings

Mental shortcut: Editor = hands, Manager = brain + task board, Browser agent = QA intern with a mouse. 4. What people are actually doing with it

From tutorials and early reviews, common real-world uses:

• Spin up small apps

  • Next.js + Tailwind + shadcn dashboards
  • Simple games (e.g. snake in Pygame)

• Multi-file refactors

  • “Refactor auth module”
  • “Generate tests for billing API”
  • “Update the dependency tree”

• UI / landing pages

  • Generate a few variants, pick one, let it build the implementation plan and code.

• Browser-driven testing

  • Run flows in the embedded browser
  • Attach screenshots for failing states

If you want a quick feel:

• Build a simple game (like snake)
• Build a basic dashboard app

These cover Manager View, Artifacts, and the browser agent in one go. 5. Patterns that seem to work

Pulled from codelabs, blog posts, and dev threads.

Prompting

• Treat the agent like a senior contractor, not autocomplete:

  • goal
  • constraints
  • success criteria

• Ask it to plan before touching files:

  “Create an implementation plan artifact first, wait for my review.”

Task breakdown

• Use multiple conversations instead of one giant prompt:
  • “Set up project skeleton”
  • “Implement feature X”
  • “Add tests and browser checks”
• Run several agents in parallel and use the Inbox to hop between them.

Use Artifacts like PRs

• Skim plans, checklists, and walkthroughs as if they were PR descriptions:
  • adjust architecture early
  • only then let it execute
• Stick with Agent decides or Request review until you understand its habits.

Model / mode choices

• Use higher-quality models for complex, multi-step tasks.
• Use cheaper / faster models for small edits.
• If a config keeps failing or hits quotas, switch to a smaller model and narrow the prompt.

6. Rough edges and “this is buggy” reports

This is clearly still a preview. A few recurring complaints:

Code corruption / replace issues

Some users report Antigravity:

• corrupting files while “fixing” them
• looping on bad edits
• messing up large replace operations

Mitigations:

• Commit to git before big runs
• Ask for diffs / patches instead of blind rewrites
• Be strict with plan review; reject weird plans early

Performance

Common issues:

• Heavy RAM and CPU usage
• Sluggish after long sessions
• Battery drain on laptops

Treat it as a sidecar IDE, not your only editor.

Rate limits / quotas

• Free preview, but quotas on the higher-tier models are tight.
• You can hit limits fast if you poke it constantly.

Practical mindset:

• Use fewer, better-defined tasks
• Let runs finish instead of over-steering
• Fall back to cheaper models when you hit limits

7. Security: the big red flag

Security research (including Mindgard and others) points to serious risks.

Key problems:

1. Prompt-based exfiltration

   • Malicious repo content can instruct the agent to read secrets (like .env)
   • It can encode them into URLs or artifacts that get exfiltrated
   • The agent may read files outside your repo and ignore .gitignore

2. Persistent code execution via global config

   • Project-level config can cause writes to ~/.gemini/antigravity
   • That can lead to arbitrary code execution on future launches
   • Workspace access settings may not fully protect against this

Practical rules for now:

• Do not open untrusted repos in Antigravity
• Treat .agent / rules / workflows as code, not comments
• Avoid Always proceed; keep human review in the loop
• Keep secrets out of the workspace tree where possible
• Use separate machines / VMs for sensitive work

If you work with production or regulated data: keep Antigravity in playground / prototype territory until the security story improves. 8. How it compares (Cursor & Claude Code)

High-level comparison:

• Cursor

  • VS Code-like AI IDE
  • Great line-level help and small tasks
  • Low friction as a daily driver

• Claude Code

  • Terminal-first coding agent
  • Strong reasoning and multi-file work
  • You mostly live in the repo + shell

• Antigravity

  • “Max autonomy” agent IDE
  • Strong task-level orchestration across editor + terminal + browser
  • Weak on polish, stability, and security (for now)

Rough analogy:

Cursor = main editor, Claude Code = deep-dive buddy, Antigravity = experimental control room where you let robots work and read their reports. Just don’t point it at your production monolith yet.

9. Simple experiments to try

If you want a structured test drive:

1. Toy app session

   • New folder
   • Small game or playground app
   • Force yourself to approve plans and diffs like PRs.

2. Refactor sprint

   • Clone a non-critical side project
   • Ask it to:
     • introduce a design system
     • extract a shared layout
     • add tests for one subsystem
   • Keep everything behind “implementation plan + diff review”.

3. Browser agent as QA helper

   • Have it build a tiny full-stack app
   • Prompt it to run auth / form flows and attach screenshots for failures
   • Decide if you’d trust that style of report in real work.

4. References

• Google Developers Blog – Build with Google Antigravity, our new agentic development platform
• Google Codelab – Getting Started with Google Antigravity
• Better Stack – An Introduction to the Google Antigravity IDE

11. Questions for other users

If you’ve used Antigravity for more than a weekend:

• What has it actually shipped for you?
• Any prompt patterns / review policies that made it much more reliable?
• Have you found a defensive setup you’d trust on semi-sensitive repos?
• How do you split work between Cursor / Claude Code / Antigravity day to day?

Real stories, workflows, and failure modes are the most useful part IMO.