June 18 is six days away. That is the day Gemini CLI and the Gemini Code Assist IDE extensions stop serving requests, handing things over to their Go-based successor, the Antigravity CLI (agy).
I had every intention of migrating early. But as any indie developer knows, whatever still works tends to slide to the bottom of the list, and I only sat down to do it this week. The migration itself went fine. What stayed with me was less the work and more what I found myself thinking about while doing it — so I want to write that down while it is fresh.
I started by counting the places where I type "gemini"
Before opening any documentation for the new CLI, I started with grep. In my experience, the slowest part of a migration like this is never learning the new tool. It is remembering all the places where you depend on the old one.
# How often does it appear in my shell history?
history | grep -c "gemini "
# Find call sites across scripts and config files
grep -rn "gemini " ~/bin ~/.zshrc ~/.config 2>/dev/null
# Anything hiding in scheduled jobs?
crontab -l 2>/dev/null | grep geminiI found 18 call sites. Seven were in the shell scripts that support the article pipelines for the four tech sites I run (Dolice Labs). Three were in pre-build checks for my wallpaper apps. Four were shell aliases. And four were experimental scripts I had completely forgotten existed.
Those last four were the real harvest. Without an external deadline, I would have discovered them on whatever random day they stopped working.
I underestimated the words "a separate Go implementation"
The Antigravity CLI is not a renamed Gemini CLI; it is a re-implementation written in Go. Concepts like Agent Skills, Hooks, Subagents, and Extensions carry over — but a concept carrying over and your local configuration working unchanged are two different things.
There have been plenty of reports of existing setups temporarily breaking during the 2.0 transition, and my environment was no exception in small ways: the non-interactive output format had changed slightly, and I had to fix two places where scripts parsed the results. I covered installation and the slash-command mapping in Antigravity CLI (agy) First Look: Migrating from Gemini CLI and Reading the Slash Commands, so here I will only note the part that mattered operationally:
# 1. Back up your existing configuration with a date stamp
cp -r ~/.gemini ~/gemini-config-backup-$(date +%Y%m%d)
# 2. Install agy and verify it runs before touching anything else
agy --version
# 3. Run old and new side by side for a few days, switching scripts one at a timeStep 3 is the one I would defend in a code review. With a deadline approaching, a global search-and-replace is tempting, but blindly swapping command names ignores differences in flags and output formats. Switching one script at a time, verifying each as I went, turned out to be faster in the end.
My real mistake: hardcoding the command name everywhere
While fixing those 18 call sites, one question kept circling: did there really need to be 18 of them?
The answer is no. They existed because I had written the command name directly into every script. A thin wrapper would have reduced the fix to a single file:
#!/usr/bin/env bash
# ~/bin/ai-cli — a thin wrapper that pins the AI CLI implementation in one place
# Every script calls ai-cli; when the implementation changes, only this file changes
exec agy "$@"It is the same idea as moving database credentials into environment variables. I do that without thinking. But I had never extended the habit to CLI tools, because I treated them like air — something that is simply there, the way the editor or the language runtime is there.
Since finishing the migration, every time I write a script that shells out to an external CLI, I pause and ask whether that command name will still exist in a year.
A shutdown deadline is also a chance to re-choose your dependencies
If you build software independently for long enough, you attend a lot of tool retirements. Honestly, each one is a little tiring. But this round changed how I receive them.
A shutdown date forcibly visualizes how much dependency has quietly accumulated in your environment. In day-to-day development, dependencies only ever increase; the audit never happens unless you schedule it yourself. "It stops in six days" converted that audit from someday into today.
Having chosen to work in a field that moves this fast, I now believe the foundation for trying new tools without fear is designing your environment around the assumption that every tool has a lifespan — gathering each dependency into one place, ready to be swapped out.
If you have not migrated yet, start before installing anything: grep your shell history and your scripts, and count your call sites. In my case, those ten minutes of inventory determined the shape of the entire migration.