Testing Antigravity: Building a Data-Intensive POC at 300km/h

Introduction Last week, I spent a few hours on a Frecciarossa train from Rome to Calabria....

Introduction

Last week, I spent a few hours on a Frecciarossa train from Rome to Calabria. Usually, this is time spent catching up on emails, but I decided to use the journey to stress-test Antigravity for code development.

As a Google GDE and Data Engineer, I’m always looking for ways to streamline the "zero-to-one" phase of a project. My objective was specific: Build a functional, data-intensive Proof of Concept (POC) that I could eventually use in a GDE workshop or technical presentation.

The Smoke Test

Before trusting an AI framework with my GCP environment, I started by running through some of the more complex Antigravity examples. I wanted to see if the agent could handle intricate logic and performance-sensitive code without "hallucinating" or breaking under pressure. Once it proved it could handle high-level orchestration and optimization in these isolated tests, I knew it was ready for a real-world Data Engineering pipeline.

The Objective

The project I set out to build is an intensive data application called "Dog Finder". The goal was to create a system that could handle real-time sightings of lost dogs, process them through a reliable pipeline, and land them in a data warehouse for analysis.

The final architecture consists of:

• Frontend/Backend: A Flask application deployed on Google Cloud Run.
• Ingestion: A Pub/Sub topic with a strict schema to ensure data quality at the entry point.
• Storage/Analytics: A BigQuery dataset with a table partitioned by sighting_date for cost-effective querying.
• Automation: Fully idempotent shell scripts for resource provisioning and cleanup.

The Workflow: From Coder to Conductor

Working with Antigravity felt less like traditional coding and more like leading a team of mid-level developers. I was the Architect, and the AI was the execution arm.

The Proactive "Wins"

One of the most interesting aspects of the experience was the AI’s "propropositive" nature. Sometimes it suggested paths I hadn't explicitly asked for, but that added immediate value. For instance, while we were building the documentation, it suggested generating a Mermaid architecture graph directly in the README. It was a "nice-to-have" that I ended up keeping because it made the repo much more professional for a workshop setting.

The "Experience" Corrections

However, "AI-driven" doesn't mean "autopilot." I frequently had to use my experience to correct the course. In the initial infrastructure scripts, the AI took some "happy path" shortcuts that wouldn't fly in a real environment. I had to explicitly step in to enforce Data Engineering standards:

• Idempotency: I guided the agent to ensure setup_resources.sh wouldn't crash if a bucket or topic already existed.
• Schema Integrity: I enforced snake_case and double precision for coordinates to prevent downstream data issues in BigQuery.
• Refactoring: I instructed the AI to reorganize the project—moving scripts to /scripts and schemas to /schemas. Once the instruction was clear, the AI executed the refactor across the entire project flawlessly.

From POC to "Almost Prod-Ready"

The most impressive part of this experience was the velocity. What I initially planned as a simple POC evolved so quickly that I spent some time at home after my trip hardening it into an almost production-ready state.

Funny Fact: I was doing all of this while traveling through the tunnels of the Italian countryside. I was constantly losing my 5G connection as the train sped along. If I managed to build and deploy a full GCP data pipeline while dealing with intermittent connectivity, imagine what you can achieve with a stable fiber connection.

The Verdict

If you are an experienced developer, Antigravity is a superpower. It allows you to focus 100% of your energy on solution design and architectural tuning. You can move fast because you already know what "good" looks like and can spot the shortcuts the AI might try to take.

For junior developers, my advice is to go easy. It allows you to arrive at a working result very quickly, but "working" isn't always "ideal." Use it to learn, but always question the architectural choices it makes for you.

You can check out the full project and the result of this high-speed experiment here:

{% embed https://github.com/patricio-navarro/dog_finder_app %}