Google Antigravity IDE first impressions & survival guide - AI Development Discussion

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.

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:

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.
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.
Separate workspaces

Use a dedicated sandbox folder (e.g. antigravity-playground) while you learn it. Add real repos later.
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.
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.

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

Security: the big red flag

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

Key problems:

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
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.

Simple experiments to try

If you want a structured test drive:

Toy app session
- New folder
- Small game or playground app
- Force yourself to approve plans and diffs like PRs.
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”.
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.
References

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.