Google's I/O announcement that most affects what my IDE looks like next quarter is Antigravity 2.0. The redesigned desktop application, a stable Antigravity CLI, a new SDK for programmatic agent deployment, specialized sub-agents, and a security posture (cross-platform sandboxing, credential masking, hardened Git policies) that takes the production-readiness question more seriously than the first version did.
This is Google's direct answer to Cursor 3's agent-first interface. The two products are now competing on substantially the same axis. The interesting question is no longer whether agent-first IDEs are the right paradigm — both major players have committed to that direction — but which one's trade-offs match the way you actually work.
This is the practitioner read.
What Antigravity 2.0 Actually Is
The pitch from Google: "two powerful surfaces for productivity gains" — the desktop application and the CLI — with a shared agent harness underneath. In practice the lineup looks like this:
- Antigravity 2.0 desktop. The IDE-shaped surface. Multiple agents in parallel, project context, sub-agent orchestration, visual diff review.
- Antigravity CLI. Stable, scriptable, the surface that fits into existing dev workflows and CI.
- Antigravity SDK. Programmatic control. Custom agent deployment on your own infrastructure.
- The harness. Shared across all three. Built on Gemini 3.5 Flash by default, with cross-platform terminal sandboxing, credential masking, and hardened Git policies as built-in primitives, not afterthoughts.
The thing to notice is that Google has split Antigravity into three surfaces deliberately. Cursor 3 is one surface (with the cloud option as an extension). Antigravity is committing to "use the right interface for the job" as a core product decision. CLI for CI and scripting. Desktop for interactive work. SDK for embedding agentic behaviour into your own product.
The CLI and SDK Split Matters More Than It Looks
This is the part that's easy to under-rate. A CLI that shares a harness with the desktop IDE means I can:
- Trigger from CI exactly the same agent that runs on my laptop.
- Write a shell script that orchestrates three agents in parallel, without opening any UI at all.
- Embed agent calls inside existing build pipelines without forcing every contributor onto the desktop app.
The SDK takes this further. "Custom agent deployment on your own infrastructure" means the harness — the sandboxing, credential masking, sub-agent orchestration — becomes infrastructure you can build on, not just use. This is where Antigravity starts looking less like a Cursor competitor and more like Google's answer to the Claude Agent SDK production patterns and to the new Managed Agents API.
The reason this matters for builders: the choice between "IDE" and "platform" isn't binary any more. You can adopt Antigravity at the IDE level for individual developer productivity, the CLI level for team workflow, and the SDK level for product-embedded agents — all sharing the same harness and the same behaviour. That's a different posture than Cursor's "everything routes through the IDE" approach, and it will appeal to teams that want agentic capability without forcing a tool migration on every engineer.
Sub-Agents and the Sandboxing Posture
Two pieces of the new harness deserve specific attention.
Specialized sub-agents
Sub-agents in their own context windows is not new — Claude Code has had this since the level 4 patterns I've written about. What's new in Antigravity 2.0 is that sub-agents are specialized: there's a default cast of them shipped with the harness (test, review, refactor, migration, etc.) rather than every team building their own from scratch. The default cast is a reasonable starting point for most teams and reduces the time-to-first-working-agent meaningfully.
Cross-platform sandboxing, credential masking, hardened Git policies
This is the bit that changes the conversation about agent-first IDEs at companies that care about security review. The first version of Antigravity ran agent operations with relatively loose defaults; teams with audit obligations either avoided it or built wrapper layers. The 2.0 harness ships sandboxing per OS by default, masks credentials at the harness layer (not the application layer), and enforces Git policies (no force pushes, no destructive operations, no skipping hooks) that you would otherwise enforce through pre-commit infrastructure.
These are unglamorous capabilities, and they're exactly the ones that decide whether a tool gets adopted at a regulated organisation. Google is signalling that they want Antigravity to land in enterprise security reviews, not just on individual engineers' laptops.
Antigravity 2.0 vs Cursor 3: Where Each Wins
A direct, honest read on the trade-offs, given both products are now committed to the same paradigm:
| Concern | Antigravity 2.0 wins | Cursor 3 wins |
|---|---|---|
| Three-surface flexibility (IDE / CLI / SDK) | ✓ | |
| Best default sub-agent cast | ✓ | |
| Security posture and sandboxing | ✓ | |
| Parallel agents UX in the IDE | ✓ | |
/best-of-n across models in worktrees | ✓ | |
| Design Mode for UI iteration | ✓ | |
| Marketplace and plugin ecosystem | ✓ (more mature) | |
| Default model integration | Gemini 3.5 Flash | Composer 2.5 + Claude/GPT |
The honest summary: Cursor 3 is still the better interactive coding experience for most individual developers. Antigravity 2.0 is the better choice for teams that want to operate at three surfaces (IDE, CLI, embedded) without owning the integration work. The marketplace gap will close over time; the architectural choice — three surfaces vs one — is structural.
Migration Considerations
The questions I'd be asking before moving a team:
- Are we using the CLI/CI path? If most of your team's value is in CI-mediated agent runs, Antigravity's CLI parity is a real win. Cursor's CLI story is less mature.
- Are we shipping agentic features in our own product? If yes, the SDK matters. Building on Claude Agent SDK, OpenAI Assistants, or Antigravity SDK is now a three-way decision, not a two-way one.
- Is the team already invested in Cursor? Don't migrate just because Antigravity exists. The cost of changing IDEs is real (muscle memory, plugins, configurations); the cost of running both at different layers is much smaller.
- Are you in a regulated industry? The default sandboxing posture is enough on its own to make Antigravity worth a serious evaluation. I'd want it on the comparison table for any healthcare, financial, or government engagement this quarter.
- What's your planning workflow? If you've adopted the HTML-as-plan format I've written about, it carries straight across. Both IDEs read HTML plans just fine.
What's Not Changed
The honest expectation-setting:
- The model still hallucinates. A better IDE doesn't change probabilistic output. Evals and code review remain non-negotiable.
- Prompt and plan discipline still matter. A vague spec produces a vague result in Antigravity the same as anywhere else.
- Multi-provider risk is unchanged. Antigravity defaulting to Gemini 3.5 Flash is convenient but not free — make sure your routing layer can route a meaningful share of traffic to a non-Google model if you ever need to.
The Practitioner's Take
The story I keep coming back to is that the agent-first IDE category is now a real category. A year ago, agent capability in editors was a side-panel novelty. Today, two of the most-used surfaces for software work — Cursor and Antigravity — have rebuilt themselves around agents as the primary unit, not as a feature.
This is the shape of how production code gets written for the next two years, regardless of which IDE wins individual users. The companies running the operating-system mindset framework are already organising around it. The companies treating agents as a feature add to their existing 2023 IDE setup are going to feel the gap widen month by month.
The right move this quarter is not to bet the team on one IDE. It's to make sure your harness — your skills, your plans, your design system files, your CLAUDE.md / GEMINI.md equivalents — is portable across both. The agent-first paradigm is the bet. Which IDE you sit inside next month is a tactical choice that can change again next quarter.