Getting Ready for the Gemini CLI and Code Assist Personal Shutdown: A June 18 Migration Inventory

The Code Assist Dependency Hiding in CI and GitHub

The riskiest spots are workflows that call Code Assist inside GitHub Actions, because they will quietly start failing on June 18. Using a "doc sync" workflow from my own repo, here is the replacement logic.

Before, it leaned on the Code Assist extension.

# before: depends on Code Assist (expected to fail after 6/18)
name: doc-sync
on:
  push:
    paths: ["src/**"]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate docs with Code Assist
        run: |
          gemini code generate-docs \
            --input src/ \
            --output docs/

That gemini code family of subcommands is exactly what the personal shutdown targets. Moving to direct API calls (next section) is the most robust option, but any step where you want interactive completion can go to Antigravity instead. The deciding question is "does a human review results as it runs, or does it complete unattended?" CI is unattended by nature, so I tilted it toward direct API calls.

Move Interactive Scripts to the Antigravity CLI

The steps I used interactively — drafting code reviews, talking through a refactor — move to the Antigravity CLI, which is where Google is pointing Gemini CLI users.

Install and first sign-in look roughly like this (always confirm the exact command surface against the official release notes at migration time; here I am showing the shape of the replacement).

# 1) Install the Antigravity CLI
npm install -g @google/antigravity-cli
 
# 2) Sign in with your Google account (a browser opens)
antigravity auth login
 
# 3) Smoke test: hand it one file to summarize
antigravity run --model gemini-3.5-flash \
  --prompt "Explain this file's responsibility in three lines" \
  --file src/lib/content.ts

One practical tip: do not switch the command name in one shot. I dropped a temporary shell alias so my muscle memory (typing gemini) stayed intact while the engine underneath changed.

# Temporary migration alias in ~/.zshrc
# Fingers type gemini; the real call is antigravity
alias gemini='antigravity run --model gemini-3.5-flash --prompt'

I lived with that for a few days, and once it felt natural I removed the alias and used the real name. Trying to rebuild even your finger memory in one go just raises the friction; taking it in stages is, in my experience, the faster path overall.

Park Unattended Work on Direct API Calls

This is the heart of the migration. Unattended work like CI is most shutdown-resistant when it calls the Gemini API directly, with no CLI in between. However the CLI's delivery model changes, anything that calls the API with a key is unaffected.

Here is the same "doc sync" workflow rewritten as a direct google-genai SDK call.

# scripts/gen_docs.py — call the API directly, no CLI
import os, pathlib
from google import genai
 
client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
 
SRC = pathlib.Path("src")
OUT = pathlib.Path("docs")
OUT.mkdir(exist_ok=True)
 
for path in SRC.rglob("*.ts"):
    code = path.read_text(encoding="utf-8")
    resp = client.models.generate_content(
        model="gemini-3.5-flash",
        contents=(
            "Document the public API of the following TypeScript in concise Markdown. "
            "Prioritize how to use it over implementation details.\n\n"
            f"```ts\n{code}\n```"
        ),
    )
    doc_path = OUT / (path.stem + ".md")
    doc_path.write_text(resp.text, encoding="utf-8")
    print(f"wrote {doc_path}")

The workflow loses the CLI install and just adds Python and the SDK.

# after: direct API call (independent of CLI delivery model)
name: doc-sync
on:
  push:
    paths: ["src/**"]
jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Generate docs via Gemini API
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        run: |
          pip install google-genai
          python scripts/gen_docs.py

The diff between before and after is small, but the meaning differs a lot. Before depended on a personal tool staying available. After depends only on an API key being valid. The latter keeps far more inside your own control.

Unattended jobs are also the slowest to notice when they break. So I added a tiny failure notice here: a few lines that turn the job red and ping Slack if the response is empty or an exception is thrown. It is unglamorous, but for an externally imposed deadline like June 18, those few lines earn their keep.

Verify Nothing Broke After the Migration

Once you rewrite, verify now — do not wait for the deadline. Walking into the cutoff on "it should work" is the worst place to be.

I narrowed verification to three checks.

1. Run CI once with an empty commit — does the workflow go green?
2. Eyeball the output — is it empty strings or a canned error message?
3. Check API rate limits — moving from CLI to direct calls changes how call volume shows up

The third is easy to miss. My doc sync targeted every *.ts file, so a single push made dozens of API calls. gemini-3.5-flash is fast and cheap, but that volume brushes against the free-tier per-minute request limit. I scoped it to changed files only, holding it to around a dozen calls per run. When I timed it, each file took roughly the same a few seconds before and after; with the CLI overhead gone, batching several files was actually a touch faster.

The Checklist Through June 18

Finally, here is the order of remaining work. This is the sequence I worked through myself.

1. Grep every repo for CLI / Code Assist dependencies, tagging each highest / medium / low
2. Delete the "low (unused)" ones and stop thinking about them
3. Rewrite "highest (CI)" to direct API calls — keep the CLI out of unattended work
4. Move "medium (local, interactive)" to Antigravity CLI, preserving muscle memory with a migration alias
5. Run the rewritten CI on an empty commit and confirm both the green status and the output content
6. Re-estimate API rate limits and per-run call counts
7. Add a failure notice (a few lines that turn the job red on empty responses or exceptions)

Externally imposed deadlines arrive regardless of your own schedule. That is exactly why it matters to pull control of the response back to your side. As a next step, just run the grep on one local repo. If the dependency turns out to be small, that is reassurance; if it is large, you will be glad you moved early.

Thank you for reading. I hope it helps with the planning of any fellow indie developer who is also racing a deadline.