Google Deleted the IDE: A Builder's Honest First Look at Antigravity 2.0

On the morning of May 19, thousands of developers opened Antigravity and found their code editor gone. Not crashed — gone. The terminal, the file tree, the panel where you actually edit code: replaced overnight by a chat box. Google had pushed an automatic update, with no opt-in, and turned a code editor into what it now calls an "agent control tower."

Underneath the rollout disaster, though, is the most interesting bet anyone has made in developer tooling this year. Every other company spent 2025 bolting an agent onto an editor. Google did the opposite. It decided the editor was the legacy part — and deleted it.

That is the whole thesis of Antigravity 2.0, unveiled at I/O on May 19 by Varun Mohan and Logan Kilpatrick: the agent, not the IDE, is the unit of developer tooling now. I have spent a good chunk of this week with the docs, the release notes, and a depressingly large number of angry forum threads, reading all of it against the agents I have actually shipped. Here is the honest version — what shipped, the part that matters for builders, and why the launch broke trust.

What Antigravity 2.0 actually is (in 90 seconds)

Antigravity started life in November 2025 as a fork of VS Code with a Gemini agent stapled to the side: competent, familiar, unremarkable. Version 2.0 is a full rebuild, and it is not one product but five surfaces wrapped around a single agent harness.

The desktop app — a standalone application Google calls a "central home for agent interaction." You do not open files; you dispatch agents, watch them work in parallel, schedule them to run in the background, and review what they produce. It ships with dynamic subagents and hooks into AI Studio, Android, and Firebase.

The Antigravity CLI — a terminal surface for spinning up agents without a GUI. It is written in Go, and Google is openly steering Gemini CLI users to migrate to it.

The Antigravity SDK — programmatic access to the same agent harness that powers Google's own products, which you can host on your own infrastructure.

Managed Agents in the Gemini API — that same harness as a hosted primitive: one API call gives you an agent running in an isolated sandbox. More on this shortly, because it is the real release.

Antigravity in the Gemini Enterprise Agent Platform — the Google Cloud on-ramp, wiring agents directly into your Cloud projects.

Notice the shape. Four of the five surfaces are not an editor. The desktop app got the keynote demo, but the actual product is the harness underneath — and that harness is now an API. That is the part I care about.

The part that actually matters (and it is not the desktop app)

If you only read the I/O coverage, you would think Antigravity 2.0 is a desktop app with a controversial UI. The release that will still matter in a year is Managed Agents in the Gemini API.

Here is the model. A normal Gemini call gives you one response. A Managed Agents call gives you an autonomous loop: the agent plans, runs a tool, looks at the result, and repeats until the task is done — inside an isolated, ephemeral Linux sandbox that Google provisions for you. One call. No orchestration code, no container to babysit, no tool-execution loop to write by hand.

client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Clone the repo, run the tests, and fix what is failing.",
    environment="remote",  # fresh sandbox; reuse "env_abc123" to keep state
)

Out of the box the agent gets three tools: code_execution for running Bash, Python, and Node, google_search, and url_context for reading web pages. Point it at an environment and the filesystem tools switch on too — read, write, edit, and search files that persist across calls. You configure behaviour the way you would brief a teammate: an AGENTS.md for instructions and skills under .agents/skills/, mounted straight into the sandbox. No DAG, no graph library, no glue.

I have built this loop by hand. My GitHub PR-reviewer agent is a LangChain-and-Mastra pipeline that pulls a pull request, reasons over the diff, and posts inline comments — and an embarrassing fraction of that code is not "review a PR," it is plumbing: tool registration, sandbox isolation, retries, passing state between steps. Managed Agents collapses that plumbing into a hosted call. The interesting question stops being "how do I run an agent safely" and becomes "what do I put in AGENTS.md."

That is a real shift, and a familiar one if you have ever written an MCP server — which I have. The whole industry is converging on one primitive: a model in a loop, with tools, in a sandbox. Everyone is now racing to own the hosted version of it. Google's bet is that if the harness is good enough, you will reach for theirs instead of assembling your own.

A few honest caveats the docs rather bury. function_calling, computer_use, and file_search are explicitly not supported by the managed agent today. It is a preview. And "ephemeral" is load-bearing: you opt into persistence by reusing an environment ID, otherwise the sandbox and its files evaporate when the interaction ends.

The model bet: Gemini 3.5 Flash

The harness runs on Gemini 3.5 Flash, and that choice is itself a statement. Google's pitch is "frontier intelligence with incredible speed" — a model it claims outperforms Gemini 3.1 Pro across almost all benchmarks while running four times faster than other frontier models. Independent measurements put it near 289 output tokens per second, roughly four times the throughput of Opus 4.8 or GPT-5.5.

Speed sounds like a vanity metric until you have watched an agent loop. An agent does not make one model call; it makes dozens — plan, act, observe, plan again — and latency compounds. A loop that takes forty seconds a turn with a slow frontier model is a different product at ten seconds a turn. Putting the fast model at the centre of an agent platform, instead of the smartest one, is a deliberate wager that for agentic work throughput beats raw reasoning depth.

It is a wager, not a settled fact. The consistent thread in early hands-on reviews — and it matches my own prior with Gemini — is that on genuinely hard, multi-file reasoning it still trails Claude. More than one reviewer described falling back to Claude for the gnarly logic and using Antigravity for the autonomous, run-it-end-to-end work. Fast-and-frontier-ish wins the loop; it does not yet win the hardest single step.

The launch that broke trust

Now the part Google would like everyone to forget — and it is instructive, not just gossip. By the account of its own users, the 2.0 rollout was a disaster.

The update was automatic and overnight, with no opt-in and no migration path. Developers who had a working VS Code-style setup woke up to find terminals, the file explorer, visual error indicators, and direct code editing gone, replaced with a chat-first "control tower." Visual git management was reduced to manual command line. The old IDE still existed, but you had to go and download it separately — it was not what the update handed you. The response was immediate: revert to 1.23.2, disable auto-updates, and vent. One developer summed up the mood as "non-technical people shipping code straight to production." On Google's own forums, people reported stability bugs that are almost poetic — close an app the agent was testing and it would still register the app as running, then diagnose the closure as a malfunction — alongside aggressive free-tier limits and lockouts after surprisingly short sessions.

Here is why this matters beyond the schadenfreude. The failure was not really technical; it was a thesis collision. Google believes the agent is the primary surface and the editor is legacy. A great many working developers believe the editor is where they live and the agent is a power tool they reach for. Both can be partly right. But you cannot resolve that disagreement by deleting one side of it overnight on people's working machines. "Agent-first" is a fine product philosophy and a terrible way to treat an installed base.

Where it fits — and the bigger thing it signals

So would I build on it? Selectively, and not as my primary editor today.

The Managed Agents API is genuinely worth a prototype if you are building anything that needs a model to run code in a sandbox: CI-style fixups, data wrangling, scripted research, "go do this multi-step thing and report back." Collapsing the harness into a single call is real leverage, and the AGENTS.md-plus-skills configuration is a clean mental model. I would reach for it the way I currently reach for an MCP server — a hosted capability, not a religion. The desktop app I would watch rather than adopt: too new, too rough, and the trust deficit is real.

The competitive read, as of this week: Antigravity is strongest at autonomous, multi-step work where the agent plans, codes, tests, and verifies end-to-end, and at running several agents in parallel. Cursor still owns the tight inner loop — autocomplete, inline edits, the things you do every minute. Claude Code still owns deep multi-file reasoning. And the ground keeps shifting: Cognition just retired Windsurf and relaunched it as Devin Desktop on June 2. Nobody is standing still.

Step back from the tool fight, though, and the signal is bigger than Antigravity. For fifteen years the unit of developer tooling was the editor; everything was a plugin around the place you typed. Google just shipped a platform that treats the agent as the unit and the editor as one optional view of it. They botched the rollout, and the model is not the best at everything. They may still be early to where this is all heading.

The question Antigravity forces is not whether the agent harness is good — it is getting good everywhere. The question is whether we want the job it implies. Antigravity's bet is that the developer of 2027 is less someone who writes code and more someone who manages agents that do. Deleting the editor was Google saying the quiet part out loud. The backlash was thousands of developers answering: not yet, and not like this.

That is the conversation worth having. The tool is just the opening argument.