# Claude Code Considered Killing Plan Mode the Day After Google Antigravity Shipped It — What the Split Really Means

Google Antigravity shipped /plan on Sept. 22, 2026. A day later, Claude Code questioned Plan Mode. Here is what the split really means.

Canonical URL: https://aiidelist.com/blog/claude-code-vs-google-antigravity-plan-mode

Language: en

Published: 2026-09-27

Updated: 2026-09-27

## Key Takeaways

- **Yes, the timing was real:** Google Antigravity added an explicit `/plan` workflow on **September 22, 2026**. On **September 23**, Claude Code team member Thariq publicly said the team was considering killing Plan Mode and using `Shift+Tab` to control effort levels instead.
- **But this is not a simple story of Google being behind Anthropic.** Google had already shipped Plan Mode in Gemini CLI on **March 11, 2026**, months before the Antigravity update.
- **Anthropic was questioning the fixed UI mode, not the idea of planning itself.** The argument was that increasingly capable models may no longer need a special mode just to force them to think before acting.
- **User feedback changed the direction within roughly a day.** The follow-up direction was to preserve Plan Mode as a built-in mod while allowing custom modes and `Shift+Tab` overrides.
- **The deeper disagreement is about product design:** should planning be a model-behavior switch, a human approval boundary, or a customizable workflow primitive?
- The likely future is not "Plan Mode versus no Plan Mode." It is a separation of **reasoning effort**, **execution permissions**, and **review checkpoints**.

## What Happened in Less Than 48 Hours?

The contrast looked almost absurd.

On **September 22, 2026**, Google Antigravity 2.17.0 introduced `/plan`. The workflow lets the agent draft a plan that the developer can inspect and edit before implementation begins. Google also exposed a **Plan Review Policy**, allowing users to control when plans require review.

Then, on **September 23**, Claude Code team member Thariq publicly said Anthropic was considering "killing plan mode" and using `Shift+Tab` for effort levels instead. The stated reasoning was that newer models may no longer need a dedicated mode simply to force more planning before action.

Taken literally, the sequence looked like this:

```text
September 22: Google Antigravity adds /plan
September 23: Claude Code considers removing Plan Mode
September 24: Claude Code proposes keeping it as a customizable built-in mod
```

That is a remarkable product-design collision. One major AI coding platform was making planning more explicit at almost the exact moment another was considering demoting it from a core mode.

But the obvious interpretation — that Google had only just discovered Plan Mode while Anthropic had already outgrown it — is misleading.

## This Is Not a Simple "Google Is Six Months Behind" Story

Google's September Antigravity release was not Google's first Plan Mode.

Gemini CLI introduced Plan Mode on **March 11, 2026**. Its design already included a read-only exploration phase in which the agent could inspect code, investigate dependencies, ask clarifying questions, and propose an implementation strategy without modifying normal project files.

That changes the interpretation completely.

The September event was not:

**Google finally discovers planning while Claude moves beyond it.**

It was closer to:

**Google expands explicit planning into another coding-agent interface while Claude Code questions whether planning should remain a hard-coded top-level mode.**

That is a product architecture disagreement, not evidence of a clean generation-level capability gap.

## Why Claude Code Could Believe Plan Mode Is Becoming Redundant

The strongest argument against a dedicated Plan Mode is that modern coding models can increasingly perform planning internally.

Newer agent systems can inspect a repository, reason through dependencies, choose tools, and adapt their approach while working. If the model can already decide when deeper reasoning is necessary, forcing users to switch into a separate planning state can become unnecessary friction.

The traditional interaction often looks like this:

```text
User chooses Plan Mode
→ model inspects repository
→ model writes plan
→ user reviews plan
→ model exits planning
→ model implements
```

A more autonomous model can potentially collapse that into:

```text
User gives goal
→ model decides how much reasoning is needed
→ model investigates
→ model forms a plan
→ model executes
→ model verifies
```

For small and medium tasks, this can be faster and less ceremonial.

A developer fixing a localized type error, updating a dependency, renaming an API field, or adding a straightforward unit test usually does not need a formal architecture document before every edit. A mandatory planning state can become overhead.

That is the strongest case for shifting from a **mode switch** toward an **effort control**.

## The Problem: Plan Mode Was Never Only About Helping the Model Think

This is where the debate becomes more interesting.

A coding agent's Plan Mode can perform at least three separate jobs:

- **Reasoning control** — encouraging deeper analysis before implementation.
- **Execution control** — preventing the agent from modifying files or running risky actions too early.
- **Human review** — giving the developer a stable artifact that can be inspected, edited, or rejected before implementation begins.

Only the first job becomes less necessary when models get smarter.

The other two can become **more important** as agents become more autonomous.

This is the central weakness in treating Plan Mode purely as a model capability crutch.

A stronger agent can make larger changes, touch more files, run more tools, and operate for longer without intervention. That makes a clear pre-execution review boundary valuable even if the model's internal reasoning is excellent.

In other words:

**The better the agent becomes at acting, the more useful it may be to give humans an explicit place to stop it before action.**

## Google Antigravity Treats Planning as a Human-Control Interface

Google's Antigravity implementation makes this distinction clear.

The `/plan` workflow does not merely tell the model to think harder. It creates an artifact the user can read and edit before code is written and exposes a review policy controlling how often that review happens.

That makes Plan Mode closer to a permission and collaboration layer than a prompt-engineering trick.

The product philosophy is straightforward:

**Planning should be visible when the human wants visibility.**

The model may already be capable of internal reasoning, but visible planning creates a contract between the developer and the agent.

## Claude Code's Reversal Is the Most Important Part of the Story

The initial proposal to remove Plan Mode generated substantial pushback.

The follow-up direction was not to eliminate planning entirely, but to preserve Plan Mode as a **built-in mod** while allowing custom modes and `Shift+Tab` behavior.

That changes the story significantly.

Instead of Claude Code deciding that every developer needs exactly the same fixed Plan Mode, a mod-based architecture could let teams create specialized modes such as:

- **Architecture mode** for repository-wide design work.
- **Debug mode** that investigates without editing until a root cause is identified.
- **Security review mode** that forbids writes and focuses on threat analysis.
- **Migration mode** that inventories dependencies and breaking changes first.
- **Fast-fix mode** that minimizes planning and moves directly to implementation.
- **Review-only mode** that can inspect diffs and tests but cannot modify files.

That direction is arguably more ambitious than simply keeping or deleting Plan Mode.

The primitive becomes **custom execution policy**, not one universal planning button.

## Google and Anthropic Are Actually Converging

At first glance, the companies appear to be moving in opposite directions.

| Question | Google Antigravity | Claude Code direction |
| --- | --- | --- |
| Should planning be explicit? | Yes, through `/plan` | Optional and potentially customizable |
| Should users review plans? | Configurable through Plan Review Policy | Can be encoded into a mode or mod |
| Should reasoning depth be separate? | Planning is exposed as a workflow | Effort is becoming a distinct control |
| Should workflows be customizable? | Review policy provides configurable behavior | Mods may add or replace modes |
| Core product bet | Visible planning and review | Programmable agent harness |

Zoom out, however, and the convergence becomes obvious.

Both approaches are separating capabilities that older coding agents tended to bundle together.

The future interface is likely to expose three independent controls:

```text
Reasoning depth
+
Permission to act
+
Human review checkpoints
```

That is a better abstraction than a single binary switch called Plan Mode.

A developer may want **high reasoning with immediate execution**, **low reasoning with strict approval**, or **high reasoning with no write permission at all**. Those are meaningfully different workflows.

## Plan Mode Is Really a Transaction Boundary for AI Coding

A useful analogy is a database transaction.

Before a destructive operation commits, a system can inspect what is about to happen, validate assumptions, and require approval.

A mature coding agent needs something similar.

For a large task, a good workflow often looks like this:

```text
Investigate
→ state assumptions
→ propose file-level changes
→ identify migrations or risks
→ receive approval
→ execute
→ test
→ summarize the diff
```

The plan is not valuable because the model is incapable of thinking without Markdown bullets.

The plan is valuable because it creates a **checkpoint before state changes**.

That distinction becomes especially important for:

- schema migrations;
- authentication changes;
- infrastructure modifications;
- dependency upgrades across a monorepo;
- large refactors;
- permission and security changes;
- production configuration;
- deletion or renaming operations;
- unfamiliar legacy codebases.

For these tasks, an editable pre-execution plan can reduce the cost of a wrong interpretation.

## When Dedicated Plan Mode Is Still Worth Using

A dedicated planning phase remains useful when the **cost of incorrect execution is much higher than the cost of waiting for review**.

Examples include:

- A task touches many packages or services.
- Requirements are ambiguous.
- The repository contains undocumented conventions.
- Several technically valid architectures exist.
- A change may require database or API migration.
- The user needs to understand the proposed design before approving it.
- The agent has permission to run commands with external side effects.
- The work is being performed in a production-adjacent environment.

In those cases, skipping visible planning can save seconds while creating minutes or hours of cleanup.

## When Plan Mode Becomes Unnecessary Overhead

The opposite is also true.

For tightly scoped tasks, forcing a formal plan can make the tool feel slow and bureaucratic.

Examples include:

- correcting a typo;
- fixing an obvious lint error;
- updating a single test expectation;
- adding a small field to an existing type;
- changing a clearly identified constant;
- applying an already-approved refactor pattern;
- implementing a small isolated UI change.

The ideal agent should not require the developer to decide manually between "think" and "act" every few minutes.

This is where adaptive reasoning and effort controls make sense.

The model should be capable of spending more computation when the task requires it without demanding that the user constantly manage an internal cognitive state.

## The Real Design Question: Who Is Plan Mode For?

The debate exposed a fundamental ambiguity.

If Plan Mode exists primarily **for the model**, stronger models should make it less important.

If Plan Mode exists primarily **for the human**, stronger models may make it more important.

That difference explains why Google and Anthropic can make apparently contradictory choices without either company necessarily being wrong.

Google's Antigravity workflow emphasizes inspectable plans and configurable review.

Anthropic's Claude Code direction emphasizes stronger model autonomy plus a programmable harness in which the user can define the workflow boundary.

These approaches optimize different parts of the same system.

## Why This Matters Beyond Claude Code and Antigravity

AI coding products are moving from autocomplete tools to increasingly autonomous software agents.

That changes what a good interface needs to expose.

The first generation focused on **generation controls**:

- Which model?
- How much context?
- Which files?
- What prompt?

The next generation increasingly needs **governance controls**:

- How much reasoning should the agent use?
- What tools can it call?
- What can it modify?
- When must it ask permission?
- What artifacts must it produce before acting?
- Which steps require human review?

Plan Mode is one early answer to those questions, but it is unlikely to be the final abstraction.

The more capable the model becomes, the less useful it is to micromanage every reasoning step — and the more useful it becomes to define **boundaries around action**.

## What Developers Should Take From the Debate

Developers should avoid treating "Plan Mode on" as a universal best practice.

Instead, choose the workflow based on risk.

**Use visible planning when:**

- the blast radius is large;
- requirements are unclear;
- architectural choices matter;
- external systems are involved;
- rollback is expensive.

**Use direct execution when:**

- the task is local and reversible;
- acceptance criteria are explicit;
- tests provide fast feedback;
- the agent can verify the result safely.

**Use higher reasoning effort when:**

- the task is conceptually difficult;
- failures are caused by hidden interactions;
- the agent needs to understand unfamiliar architecture;
- debugging requires forming and testing multiple hypotheses.

These are three different decisions. A mature coding tool should not force them into a single toggle.

## So, Is There Really a Huge Gap Between Claude and Google?

There is a large **philosophical contrast**, but the evidence does not support calling it a simple capability gap.

Google did not just discover Plan Mode in September. Gemini CLI had already shipped a read-only planning workflow in March.

Likewise, Anthropic did not definitively decide that planning was useless. The Claude Code team publicly explored removing the fixed mode, received strong feedback, and then moved toward preserving planning as a customizable built-in mod.

The more accurate interpretation is:

**Google is productizing planning as an explicit human-review surface, while Anthropic is exploring how to turn planning from a fixed product mode into a configurable part of the agent harness.**

Those are different bets about UX and control, not evidence that one company understands AI coding and the other does not.

## Conclusion

The most interesting part of the Claude Code versus Google Antigravity Plan Mode story is not that one company added a feature while another considered removing it.

It is that **Plan Mode is changing meaning**.

When coding models were weaker, planning was often a way to make the model reason more carefully before touching code.

As models become more capable, internal planning can increasingly happen automatically. But the human-facing value of planning remains: reviewing assumptions, constraining actions, and approving high-impact changes before they happen.

Google's September 22 Antigravity release makes that review surface explicit. Claude Code's September 23–24 discussion points toward something more programmable: effort controls for model reasoning and customizable modes for developer workflow.

The next generation of AI coding tools will probably not be defined by whether they have a button called **Plan Mode**.

They will be defined by whether they let developers independently control **how deeply the agent reasons, what it is allowed to do, and when a human gets the final say**.