AI coding assistant migration after Gemini Code Assist

According to Google's official schedule, new consumer installations stopped on June 18, 2026, and the app shut down on July 17, 2026. For engineering leaders, the right AI coding assistant migration response is not a rushed vendor swap. It is to identify every workflow that depended on the tool, preserve review evidence, and test a replacement and rollback path before delivery stalls. The enterprise version of Gemini Code Assist on GitHub was not affected.

Google published the retirement schedule without giving a reason. That makes the operating lesson unusually clean: do not build delivery continuity around assumptions about a vendor's motives or a free tier's permanence. At Van Data Team, we start by mapping identities, integrations, review gates, artifacts, and failure paths. If this risk is already visible in your repositories, scope a production AI agent workflow around an owned control model, migration runbook, and review process.

The scope is not a universal shutdown: separately, consumer requests from the Gemini Code Assist IDE extensions and Gemini CLI stopped on June 18, 2026 for the Individuals, Google AI Pro, and Google AI Ultra tiers. Login with Google also became unavailable for those services. Google directs affected consumer IDE and CLI users to the Antigravity family of products and provides a Gemini CLI to Antigravity CLI migration guide. Standard and Enterprise subscription access remains unchanged.

Key Takeaways

The durable response is to own the workflow, its evidence, and its exit path rather than assume a product tier will remain available.

• The consumer Gemini Code Assist app on GitHub is gone, but the enterprise GitHub app was not affected.
• The consumer IDE and Gemini CLI change was separate; Antigravity is Google's path for affected consumer usage, while Standard and Enterprise access remains unchanged.
• Licensing, identity, code retention terms, exportability, and fallback behavior are architecture inputs, not procurement footnotes.
• A controlled migration needs acceptance criteria, a representative pilot, dual-running where possible, an explicit cutover, and an exercised rollback or manual fallback.
• Vendor-neutral governance should keep AI-authored code reviewable even after the assistant is removed.

What Google changed and what the silence means

Google retired specific consumer surfaces while leaving named organizational subscriptions unchanged, so engineering leaders must read the change by product surface and entitlement.

The scope matters. Antigravity is Google's stated migration direction for affected consumer IDE and CLI usage, not the announced replacement for the retired consumer GitHub code-review app. The Google Cloud enterprise setup guide documents the enterprise GitHub app that remains available.

Google's consumer GitHub deprecation notice is explicit:

"Starting July 17, 2026, the consumer version is shut down, and all code review activities performed by the app end."

The event is settled. The motive is unstated. Google did not attribute the retirement to security, compliance, data leakage, guardrails, or product strategy, so engineering plans should not either.

Decision rule: if a tool can disappear without an owned fallback and its absence would interrupt coding, review, or release work, treat it as a production dependency. A contract does not guarantee permanence, but it can establish organizational ownership, applicable terms, support paths, and offboarding duties. A free consumer tier does not provide that operating model by itself.

Consider a hypothetical pull-request workflow owned by Priya, an engineering manager. Expected review comments vanish because the app was installed through a former developer's personal identity. The merge queue still runs, so no infrastructure alarm fires. The failure is silent: a review signal disappeared, nobody owns the fallback, and the team discovers the dependency during active delivery.

Inventory and evaluate the dependency before choosing a tool

A dependency register plus a durability review turns casual AI-tool use into an owned engineering decision.

Build the register around what breaks

Start with one question: What breaks tomorrow if this tool stops responding? Ask it for IDE suggestions, CLI tasks, pull-request reviews, generated tests, release notes, and any automation that calls the assistant.

Unknown answers are risks, not administrative trivia. If ownership is scattered across chats and personal settings, use a structured method for moving from an ops brief to an executable scope. The useful output is a register with owners, acceptance criteria, failure impact, and a testable migration path.

Evaluate durability with evidence

Model quality matters, but it is only one part of durability. Engineering leaders also need evidence for continuity, data handling, portability, and failure recovery.

Do not assume a paid tier supplies a specific protection. Read the actual agreement and product terms. Deeper integration can reduce daily setup while increasing exit work; portable configuration and independent evidence add operating effort but protect continuity.

Choose a response that fits the dependency

There is no universal winner and no rule that every affected user must move to Enterprise.

A team already using an unaffected subscription does not need an emergency migration merely because the consumer tier changed. It should verify entitlement, document the fallback, and preserve portable rules. That is controlled continuity, not complacency.

Run an AI coding assistant migration as a controlled change

The following illustration summarizes change the tool, preserve the workflow:

An AI coding assistant migration should behave like any production change: define acceptance, test representative work, control cutover, and preserve recovery.

Define acceptance before selecting a replacement

Write the acceptance criteria against the workflow, not against the old vendor's feature names. Cover:

• IDE, CLI, pull-request, and automation behaviors the team relies on
• Organization-controlled authentication and least-privilege repository access
• Allowed code classifications, data handling, deletion, and retention requirements
• Required review comments, logs, configurations, approvals, and export formats
• Workload-specific cost, latency, token budget, output quality, and human review burden
• Observability, timeout behavior, retry policy, escalation, manual fallback, and rollback

This prevents the loudest feature from deciding the migration. A candidate passes only when the full operating workflow remains supportable.

Pilot and dual-run the workflow

Use representative repositories and tasks, including ordinary changes, restricted code, malformed inputs, tool outages, and review escalation. Evaluate what the assistant misses, where it conflicts with existing checks, how developers respond, and whether the evidence remains available outside the product.

Where old access still exists, dual-run it with the candidate through a normal delivery cycle. Where it has ended, compare the candidate with preserved review examples and the manual baseline. Do not score tools by comment volume. Measure whether output catches relevant issues, avoids distracting reviewers, and leaves an auditable decision path.

In a hypothetical pilot, Elias runs the candidate beside the existing review process on an active release branch. The tools produce different comments, which exposes a policy gap: the team had never defined which checks must remain independent. They move those checks into repository-controlled automation before cutover. When the candidate later times out, the manual gate keeps the release moving.

Cut over with rollback already exercised

A cutover runbook should include:

• Named owner, communication path, support route, and change window
• Versioned configuration, permissions, policy rules, and installation steps
• Manual fallback and the conditions that activate it
• Rollback trigger, target state, and evidence that recovery works
• Removal of obsolete permissions, personal logins, secrets, and integrations
• Post-cutover monitoring for missing comments, review delay, cost drift, and developer workarounds

Do not remove the old path until the replacement, manual fallback, and rollback instructions have been exercised, where access permits. If the retired path cannot be restored, rollback may mean returning to manual review or activating another approved tool. Recovery is a workflow state, not necessarily a return to the same vendor.

Build governance that outlives the vendor

Vendor-neutral governance keeps AI-assisted software engineering reviewable even when a product, account type, or commercial tier changes.

The policy should define:

• Who approves AI development tools and who monitors product or contract changes
• Which identities and subscription types are allowed
• Which code classifications and repository context may leave the organization
• How AI-authored changes receive human review and independent automated checks
• Where prompts, policies, review evidence, and approval decisions are retained
• How failures escalate and when the workflow returns to manual operation
• How tools are offboarded, permissions are revoked, and migrations are assigned

The assistant can suggest a change, but the repository and review policy should own the evidence. Keep durable comments in the code-hosting workflow, version reusable rules with the code, and record approvals outside a vendor-only dashboard. Static analysis, tests, branch controls, and human accountability should not disappear with the assistant.

For teams with embedded developer tooling dependencies, the staged pattern used in data platform modernization applies here too: stabilize the workflow, isolate the dependency, migrate behind controlled gates, and keep rollback available.

A Van Data Team migration-readiness review produces a dependency register, risk-ranked failure map, identity and data-flow decision log, acceptance criteria, pilot plan, cutover and rollback runbook, and vendor-neutral governance matrix. The sensible first move is an inventory and scoped delivery plan, not an automatic platform replacement.

The takeaway: own the workflow, not the tier

A free tier is not a contract, and a contract is not an exit plan. The Gemini Code Assist sunset shows why both distinctions matter: the consumer GitHub app ended, the enterprise app remained, and the consumer IDE and CLI path changed separately. Google did not publish a reason, so the durable response is operational, not speculative.

Start by inventorying every assistant, entitlement, login, repository integration, data flow, stored artifact, fallback, and owner. Then test the manual path and migration runbook before another vendor notice turns a convenience into an incident.

The goal of AI coding assistant migration is not to predict which vendor will change next. It is to make sure coding, review, and release work continue when one does. Van Data Team can turn the inventory into a scoped implementation plan with review gates, evidence retention, cutover ownership, and rollback that the engineering team can run after handoff.