How my workflow evolved from solo prompting in AI Studio to managing a multi-model AI team, running parallel subagents overnight, and enforcing strict quality gates.

As a Google Cloud GDE, I love exploring how new tools change the way we build software. If you follow my articles on Dev.to (dev.to/patitonav), you might remember when I tested Antigravity on a high-speed train in Italy and built a Proof of Concept (POC) in a couple of hours. At the time, I described the feeling as moving "from Coder to Conductor."

But a POC is not a real product. What happens when you use AI to build, scale, and maintain a production application over several months?

Recently, I built a multi-tenant SaaS application on Google Cloud Run and Firebase. The app itself isn't the point. What matters is that this was my first major project where I used AI across the entire software lifecycle: from prototyping and cloud setup to security audits, testing, and overnight refactoring batches.

Across 180+ commits and 100 Pull Requests, "conducting" a single AI chat stopped scaling. I had to act like an Engineering Manager of an AI team: defining team rules (AGENTS.md), building modular Skills, routing tasks across models (Gemini 3.1 Pro, Flash 3.8, Argon, and Claude Opus/Sonnet), and enforcing quality gates so no agent could approve its own code.

Here is how my workflow evolved across 5 stages.

Stage 1: Solo Coder in the Playground (AI Studio to Antigravity)

To go from zero to one, Google AI Studio is great. You describe what you want, click elements on the screen to fix UI issues, and get a working web prototype in a couple of days.

But I hit a wall as soon as I needed to turn that single-user prototype into a multi-tenant SaaS with isolated customer data, strict database security rules, automated cloud scripts, and separate Sandbox and Production environments. A browser playground is built for fast UI experiments, not for managing infrastructure, test suites, or git workflows.

So I exported the code and moved to Antigravity.

Stage 2: Pair Programmer & Tech Lead (Manual Model Switching & `AGENTS.md`)

At first, I worked 1-on-1 with Antigravity using Gemini 3.1 Pro and Gemini Flash. Very quickly, I noticed a trade-off between cost and quality:

Using a heavy reasoning model for everything wastes your token budget on simple tasks.
Using a lightweight model for everything leads to messy code and missed security edge cases.

To solve this, I switched models manually inside the same chat: using Gemini 3.1 Pro for planning, Flash for coding, and 3.1 Pro for reviewing logic and tests.

I also hit another common problem: AI writes too much code. Ask for a small feature, and it adds extra helpers, unused types, and unnecessary comments. To fix this, I created an AGENTS.md file in the root of my workspace with four core rules:

DRY (Don't Repeat Yourself): Single source of truth for every piece of logic.
KISS (Keep It Simple, Stupid): The simplest solution that works is the right one.
YAGNI (You Aren't Gonna Need It): Don't build features you don't need right now.
CAZZ (Cut All Zombie Zones): Delete dead code, unused imports, and commented-out blocks.

## For AI Agents
You are an amplifier of the engineer's intent, not a generator of volume. 
Resist the urge to scaffold, boilerplate, or "helpfully" add things that were not asked for. 
The best contribution is often the smallest one that solves the real problem. 
Leave the codebase cleaner than you found it. Every piece of code you write is tech debt.

Stage 3: Project Manager (Cleaning Context Bloat & Modular Skills)

As the codebase grew, the agent slowed down and started forgetting our conventions. When I asked Antigravity to inspect the workspace, we found massive context bloat: over 5,400 lines of default skills for mobile and SQL tools we didn't use, a huge old session log cached in a local folder, and outdated markdown files we were using to track tasks.

Too much unused context makes the agent slower, wastes tokens, and causes hallucinations. Here is how I cleaned it up:

Deleted Unused Skills: Removed the irrelevant templates and kept only the skills matching our stack.
Created Modular Custom Skills: In Antigravity, a skill is a markdown file with a short YAML header (name and description). Instead of loading every rule into every chat, the agent only loads a skill when it needs it.
Turned AGENTS.md into a 20-Line Index: Instead of a wall of text, AGENTS.md became a short router telling the agent which skill to read for each task.
Used /compact After Merging PRs: Long sessions fill up with terminal and test logs. Running /compact summarizes the conversation and frees up context.
Moved Tasks to GitHub Issues: Deleted local task files and told the agent to use the gh CLI, making GitHub Issues and Milestones our single source of truth.

Stage 4: Engineering Director (Multi-Model Strategy & Quality Gates)

As new models arrived in Antigravity, I stopped relying on a single agent and started acting like an Engineering Director, assigning each model to the role where it performs best.

1. How My Gemini Stack Evolved (`3.1 Pro` → `Flash 3.8` → `Argon`)

Step 1 (Gemini 3.1 Pro + Flash): Manual model switching inside a single chat.
Step 2 (Flash 3.8): Flash 3.8 brought a big jump in speed and tool-calling accuracy. Instead of switching dropdowns manually, I spawned background Flash 3.8 subagents to work on focused tickets and run tests at a fraction of the token cost.
Step 3 (Gemini 4 Argon): Google's flagship reasoning model in Antigravity became my permanent Coordinator and Tech Lead, holding the full architecture in memory while delegating implementation to Flash 3.8 subagents.

2. How I Integrated Claude (`Opus` & `Sonnet`) with Gemini

Using only one model family creates blind spots. I combined Claude Opus and Claude Sonnet with my Gemini agents in three ways:

Workflow	How Claude + Gemini Work Together	Why It Works
1. Blank-Page Epic Design	Use Claude Opus (Thinking) to brainstorm new epics and edge cases, then hand the plan to Argon + Flash 3.8 to build.	Opus is great at exploring complex user journeys before code exists.
2. Cross-Model Security Audit	Run the exact same audit prompt on Claude Opus and Gemini Argon, then ask Argon to compare and merge both reports.	Opus catches structural code smells; Argon catches cloud and database security details.
3. Sonnet + Flash "Skeptical Validators"	Run a repo review with Claude Sonnet, then have Argon spawn parallel Flash 3.8 subagents to verify each claim against `git log` and compiler output before creating GitHub Issues.	Filters out over-engineered ideas (YAGNI) and duplicate tickets before they clutter the backlog.

3. Subagent Skill Inheritance & Quick Side Queries (`/btw`)

Once I saw that subagents automatically inherit all workspace skills, orchestration became simple. My Argon Coordinator didn't need long prompts; it just spawned a Flash 3.8 worker and told it which skills to follow. And when I had a quick architecture question while subagents ran in the background, the /btw command gave me a fast answer without interrupting the active agent.

4. Never Let an Agent Grade Its Own Homework (`pr-quality-gate`)

When an agent reviews its own code, it rarely catches its own mistakes. So I created a mandatory pr-quality-gate skill. Before any Pull Request is ready to merge, the Coordinator agent runs four steps:

Web Standards Check: Runs a frontend audit skill (modern-web-guidance) to check accessibility, button semantics, and mobile layout.
3 Parallel Evaluator Subagents: Spawns three read-only subagents (Frontend/State, UI/Accessibility, and Backend/Security) to audit the diff against DRY, KISS, YAGNI, and CAZZ.
Parallel Refactoring Subagents: Spawns worker subagents to fix the findings, with a strict rule that no two agents edit the same file at the same time.
Independent Final Reviewer & Sandbox Test: A fresh reviewer subagent inspects the final diff, runs all tests, posts an approval comment on the PR, and deploys to Sandbox.

Stage 5: Operations Manager (Shipping 16 Stacked PRs Overnight)

After our security and architecture audit, we had 16 tech-debt and security tickets in the backlog. Solving them one by one in chat would have taken days.

Instead, I built a parallel-pr-orchestrator skill so Argon could run an overnight batch using four rules:

Zero Merge Conflicts (Parallel Tracks + Stacked PRs): I split the 16 issues into 4 parallel tracks touching completely different files, each running in an isolated git worktree (Workspace: 'share'). Within a track, dependent tickets branched on top of each other as stacked PRs (main ← PR 1 ← PR 2 ← PR 3).
Low Token Usage (Model: 'flash'): Argon coordinated the waves, while all Worker, Evaluator, Refactoring, and Reviewer subagents ran on Flash 3.8.
Hardware & Emulator Limits: To avoid freezing my laptop or causing port conflicts with the local database emulator, I set a limit of 4 parallel workers and allowed only one subagent at a time to run emulator tests.
Safety Guardrails: Subagents were not allowed to merge PRs or run deployment scripts overnight.

At 9:07 PM, I triggered the orchestrator using the /goal command (which keeps Antigravity working until the entire goal is finished) and left it running overnight. When I checked at 7:43 AM, all 16 Pull Requests were open on GitHub with passing tests, independent APPROVED reviews, and zero merge conflicts.

Real-World Gotchas (And How `/learn` Fixed Them)

Even with good skills, agents still make mistakes. My favorite habit in Antigravity is running /learn right after correcting the AI. Instead of fixing an issue only in the current chat, /learn writes a permanent rule into AGENTS.md or your skills so no future agent repeats it:

Broken Local Links in Markdown: Subagents initially pasted IDE links (file:///...) into README.md and docs/, which break on GitHub. One /learn rule enforced using relative paths across all documentation.
Trying to Merge Too Early: An agent tested a new auth provider in Sandbox and wanted to merge to main before it existed in Production. We added a rule never to merge while manual cloud setup is pending, and to automate provider setup in deployment scripts first.
Missing Post-Merge Cleanup: Subagents used to stop right when a PR was merged. Now they automatically post a delivery summary on the closed issue, update related tickets, close finished milestones, and delete merged branches.

The Verdict

Managing a full project lifecycle with AI is very different from building a weekend POC.

For experienced engineers, Antigravity lets you work like an Engineering Manager with a 24/7 team. You focus on architecture, security boundaries, and product decisions, while your agents handle implementation, testing, and refactoring.
For junior developers, go step by step. AI can generate thousands of lines of working code overnight, but "working" is not the same as "maintainable." Read the diffs, question every architectural choice, and never skip tests.

To scale your own AI workflow from prototype to production:

Start in AI Studio, then move to Antigravity when you need real architecture, security rules, and automated cloud scripts.
Keep AGENTS.md short, move detailed workflows into modular skills, and use /compact in long sessions.
Use the right model for the job: Use Argon to coordinate, Claude Opus/Sonnet for planning and cross-model audits, and Flash 3.8 for parallel workers and skeptical validators.
Never let an agent approve its own PR: Run a multi-agent quality gate and test in Sandbox before merging.
Use /learn after every mistake so your agents improve every day.

How are you managing your AI workflows when projects grow beyond a simple POC?
Have you tried combining different models or running parallel subagents? Let me know in the comments!

StackFeed

What I Learned Managing a Full Project with Antigravity