The Day Google Told Me to Install VS Code

The auto-update broke around eleven in the morning. Antigravity, the coding tool I had been paying for since the start of the year, decided that the right time to push its 2.0 release was the middle of my workday. The update failed halfway. I spent the next hour reading installer logs, clearing caches, and reinstalling the thing twice.

When it finally launched I opened it expecting my usual workspace. There was no workspace. There was no editor. There was an agent panel, a chat window, and a friendly empty state.

I typed into the chat what I needed. "How do I see my repository?"

The agent's own answer was that I should open the project folder in a code editor "like Visual Studio Code."

I sat there for a second. Google's flagship coding tool, in its first release after a keynote, was telling a paying user to go install a competitor's editor next to it.

Focus That Is Actually Surrender

Antigravity 2.0 dropped at I/O 2026 the same day. Pure agent surface. The editor was split off, no longer the headline, no longer the reason to launch the app. The Gemini CLI was being sunset and folded into the Antigravity CLI. A new SDK. The usual upgrade story, told well.

The frame was focus. The reality was that the team had walked out of the one position the product had that nobody else owned.

There is a kind of product decision that looks like focus and is actually surrender. It is the decision to remove the thing the product is best known for, in the name of making the rest of the product clearer. The slide deck for that decision usually argues that the team wants to "double down on the future". What is really being said is that the team would rather compete on the surface the leader chose than defend the surface they chose first.

The Antigravity editor was a fork of VS Code with an agent living inside it. Cursor has spent two years proving that this exact niche is worth a multi-billion-dollar valuation. Google had the same position. They just gave it back.

What is left is an agent shell sitting in a more crowded fight. Codex on one side, Claude Code on the other. Both objectively stronger right now. Gemini is behind GPT-5.5 on coding benchmarks, the five-hour token window is tight, the model loses the plot on larger refactors. None of that mattered when the editor was the reason to stay. The editor was the part you tolerated the other weaknesses for.

Differentiation Is a Tolerance Budget

This is the part of product strategy that almost nobody writes down honestly.

Differentiation is not a positioning slide. It is the thing that buys you tolerance for everything else you have not solved yet.

Every product ships with a list of unfinished business. Bugs the team has not gotten to, missing integrations, a pricing page that does not quite explain the upgrade, a model six months behind the frontier. The reason users stay through all of that is rarely "the product is uniformly excellent". It is "the one thing this product does, nobody else does as well, and I am willing to live with the rest because of it".

That one thing is the tolerance budget. It pays for everything you have not finished. It pays for the bad onboarding, the slow support, the feature you keep promising for next quarter. As long as the budget is healthy, the user stays. Quietly, sometimes grumpily, but they stay.

The day you remove the differentiator, every weakness moves to the front of the line. Nothing else is paying the bill anymore. The user is now comparing you to the leader on every dimension you used to be allowed to lose.

How Teams End Up Doing This to Themselves

I have watched this happen from inside product orgs more than once, and the mechanism is always the same.

A new strategy lead arrives. Or a new CPO. Or the existing team finally gets the executive room they wanted. They look at the product and notice that one part of it is "messy", "inconsistent with the modern stack", or "not where the industry is going". They are usually right about the cosmetics. They are usually wrong about the consequences.

What they cannot see, because they did not build it, is that the messy part is the part holding the customer base. The cosmetics survey says users complain about it. The cancellation survey shows nobody actually cancels over it. The reviews on G2 mention it as the reason to pick the product. The team building the next version has been told the product needs to "feel like the future", which is rarely a phrase that points at the actual differentiator.

Six months later, the "modernized" version ships. The old part is gone, replaced by something that looks more like whatever the team had been benchmarking against. Adoption flattens. Churn moves up a percentage point. Nobody can quite explain why, because each individual change made sense.

The differentiator left the building, and the tolerance budget left with it.

The Cursor Test

There is a quick way to check whether you are about to make this mistake. I started running it on myself after the Antigravity thing.

• Name the one thing your product does that the obvious competitors cannot, will not, or do badly.
• Name the part of your roadmap that, if shipped, would remove or weaken that one thing.
• Now name the part of the market that picks you specifically because of that one thing.
• Then ask: if I ship the roadmap, where do those users go.

If the answer is "the obvious competitor we are trying to look more like", you are not focusing. You are migrating your users to the leader.

Antigravity had the editor. They removed it. The agent that replaced it is now telling people to install Cursor or VS Code, which is the actual answer. The users will go to whichever of those tools they trust most. A few will stay for the SDK. The rest will read the I/O announcement, try the update, and quietly switch.

What I Took Away From the Update

I do not think Antigravity is dead. Google has the distribution to keep the product alive much longer than the strategic decision deserves. But the moment when it could have been the third real option in a serious fight has probably passed. It is now the worse version of the second.

The lesson is one I keep coming back to in my own product. When you feel the urge to simplify by removing the part of the product that makes users put up with the other parts, stop and ask whose product you are trying to look like. If the honest answer is "the leader", you are not focusing. You are surrendering.

The work of building a defensible product is mostly the work of recognizing your tolerance budget for what it is. Defend the budget, even when it looks unfashionable. Especially then.