Google Uses Antigravity CLI to Automate Spanner Migration

Migrating a production database without taking services offline can require extensive application changes. Google's Finance Engineering team faced that challenge while modernizing its legacy data layer and moving to Cloud Spanner.

The migration required the existing datastore and Spanner to receive identical writes while historical data was backfilled and verified. That meant modifying dozens of Data Access Objects, or DAOs, with dual-write logic, schema conversion, error handling, and tests.

Rather than completing those changes manually, the team built an automated refactoring pipeline using Antigravity CLI in headless mode.

Google said the approach helped accelerate migration work while maintaining strict data parity in staging environments as the team prepared for production.

The challenge: Managing a dual-write migration

A straightforward database cutover is not always suitable for high-throughput production services where financial accuracy is important.

For Google's Finance Engineering team, the migration required both the legacy datastore and Cloud Spanner to receive identical writes until historical records had been backfilled and the results verified.

The team organized the migration into three phases.

Historical backfill

Existing historical records were copied to Cloud Spanner while maintaining referential integrity.

Dual-write and dual-read

Each DAO was modified to write mutations to both the primary datastore and Cloud Spanner in parallel during the migration period.

Automated verification and parity checking

The team intercepted RPC traffic and performed end-to-end verification to confirm that writes reached both databases with byte-for-byte equivalence.

This architecture provided a way to keep the existing data layer operating while the new Spanner environment was populated and validated.

However, implementing the same architecture across the application created substantial repetitive work.

Each DAO required a dedicated MutationConverter class to map complex domain models to Spanner schema columns. Developers also needed dual-write branches, rollback or error-reporting logic, and unit tests covering writes to both systems.

Google said performing these high-precision changes manually across more than 30 DAOs would have taken months of engineering time.

The solution: Standardizing mutation conversion

Before automating the refactoring, Google's engineering team standardized the way DAOs would translate application data into Spanner mutations.

The team created a decoupled MutationConverter interface.

Instead of placing Spanner table names and column mappings directly inside DAO business logic, the schema translation was isolated into dedicated converter units.

The standardized interface included operations for creating insert and update mutations.

For example, the pattern used methods such as:

ToInsertMutation(entity)

ToUpdateMutation(entity)

The implementation mapped application-domain fields to the corresponding Spanner schema columns and returned a spanner.Mutation.

This created a deterministic contract between the DAO and the Spanner SDK.

That contract was important to the automation strategy because the AI coding agent was given a clearly defined implementation pattern to reproduce across multiple DAOs.

The team therefore standardized the software architecture before asking the automation pipeline to perform the repetitive refactoring.

Why Google used Antigravity CLI in headless mode

Interactive AI coding assistants can be useful when developers are exploring solutions or working through individual coding tasks.

Google's Finance Engineering team needed something different.

The migration involved systematic changes across dozens of files, making a repeatable automation workflow more suitable for the task.

The team built an orchestration script called migration_ui.py that runs Antigravity CLI in headless mode using -p.

Headless execution allowed Antigravity to operate through shell scripts, continuous integration pipelines, and background automation without requiring engineers to manually interact with a terminal prompt for each task.

Google described three key parts of the workflow.

Version-controlled prompt architectures

The engineering team treated prompts as version-controlled engineering artifacts.

Reusable prompt templates contained specific rules for handling common Spanner migration edge cases, including timestamp serialization, nullability conversions, mutation ambiguity, and FakeTimeSource test injection.

This gave the automated process a consistent set of instructions for each DAO refactoring task.

Batch execution and automated verification

The orchestration script takes a target DAO name and retrieves the existing single-write source code and schema.

That information is provided to headless Antigravity along with the team's structural conventions.

Antigravity then generates:

• The new MutationConverter

• The refactored dual-write DAO

• Corresponding unit tests

The workflow then runs blaze test.

If a linter error or test assertion fails, the resulting error log is passed back to Antigravity for self-correction.

This creates a feedback loop in which generated code is tested, errors are returned to the AI system, and the implementation can be corrected before human review.

Overnight execution

The automated workflow can also run without continuous developer interaction.

Google said engineers could queue 10 DAOs at the end of the day. By the following morning, the pipeline could generate, test, and validate 10 clean changelists ready for human code review.

This example demonstrates how headless AI coding can be integrated into a larger engineering workflow rather than being limited to interactive development sessions.

Results from the migration workflow

Google said combining Cloud Spanner's distributed database capabilities with Antigravity CLI's headless automation produced several benefits for the engineering team.

Reduced migration effort

DAO dual-write migrations that previously required extensive manual coding and testing were completed and reviewed in a fraction of the time.

Google did not provide a specific percentage or exact number of engineering hours saved.

High data fidelity during migration testing

Each generated DAO followed the same tested MutationConverter pattern.

The generated code also underwent automated unit testing against Spanner test doubles.

Google said this helped the team sustain high data fidelity during extensive migration testing.

More focus on higher-value engineering

By reducing repetitive boilerplate refactoring work, engineers could spend more time on areas such as data modeling, architectural resilience, and performance optimization.

These results describe Google's Finance Engineering team's experience with the migration. The source does not provide evidence that identical results would apply to every organization or migration environment.

Three lessons for database migration projects

Google's experience also offers three recommendations for engineers considering similar migration workflows.

1. Decouple schema translation first

Before creating migration automation, Google recommends defining a strict interface that isolates the new cloud database SDK requirements from existing business logic.

The MutationConverter pattern provides the example used by the Finance Engineering team.

For AI-assisted development, clearly bounded design patterns can provide a defined target for generated code.

2. Use headless automation for repetitive refactoring

For repetitive changes across multiple files, Google recommends considering scripted, headless workflows instead of relying entirely on interactive AI chat.

In the described workflow, prompt inputs and test verification became repeatable parts of the engineering process.

The source specifically recommends considering this approach when repetitive refactoring extends beyond a small number of files.

3. Let the build system provide a guardrail

Google connected the AI generation process directly to its build and test harness.

The workflow used blaze test, while the source also references go test as another possible build and testing mechanism.

This allows compilation problems and failed assertions to be detected before a developer reviews the generated changes.

Human code review remains part of the process.

What this approach means for cloud engineers

The Google Cloud example shows how an AI coding tool can be incorporated into a structured database migration workflow.

The important element is not simply that Antigravity generates code.

The team's process combines a standardized implementation pattern with version-controlled prompts, source and schema context, automated testing, error feedback, and human code review.

For enterprises, this could mean that repetitive migration work can be organized as a repeatable engineering pipeline rather than handled entirely through manual code changes.

The development also reflects a broader shift toward integrating AI-assisted coding into existing software engineering processes. In this model, AI generation operates alongside established development controls such as testing, build systems, architectural conventions, and human review.

The source describes this approach specifically within Google's Finance Engineering migration to Cloud Spanner. Additional details about broader adoption across Google were not disclosed in the article.

From manual DAO changes to an automated loop

The core challenge in Google's migration was repetition.

Each DAO needed similar categories of changes, but the implementation still had to account for the specific domain model and Spanner schema involved.

The engineering team addressed this by separating schema translation into a standardized MutationConverter pattern.

Once that pattern was established, Antigravity could be given the existing DAO, schema, and engineering conventions and asked to generate the required changes.

The resulting workflow connected code generation directly to automated testing.

A simplified version of the process is:

Define the pattern → provide source and schema context → generate the refactoring → run tests → return errors → correct the implementation → conduct human review.

This approach allowed the team to automate repetitive portions of the migration while retaining engineering validation throughout the process.

AI-assisted migration still depends on engineering structure

Google's example also highlights an important distinction between AI-generated code and AI-driven engineering workflows.

The team did not rely on an open-ended request for the AI system to redesign each DAO.

Instead, it first established a defined interface and specific migration conventions.

The automated process then operated within those boundaries.

For cloud engineering teams, this suggests that the design of the workflow surrounding an AI coding agent can be as important as the code generation itself.

Clear interfaces can define what the generated code should look like. Automated tests can identify implementation problems. Error feedback can support corrections, while human review provides the final engineering assessment.

The broader takeaway

Google's Finance Engineering migration demonstrates one way an AI coding agent can be used for repetitive database refactoring.

The team combined Cloud Spanner with Antigravity CLI's headless automation to handle dual-write changes across more than 30 DAOs.

The workflow was built around a standardized MutationConverter pattern, version-controlled prompts, automated testing, error feedback, and human review.

Google reported that this approach reduced migration effort, supported high data fidelity during migration testing, and allowed engineers to focus more on data modeling, architectural resilience, and performance optimization.

The source does not provide a specific numerical measurement for the overall time savings or migration performance improvement.

The broader lesson is that AI-assisted coding can become more useful for large engineering tasks when it is connected to clearly defined software patterns and automated validation.

In Google's case, the goal was not simply to generate code faster. It was to create a repeatable process for making and validating a large number of related code changes during a production database migration.