We have traveled a long and intense path since we declared the death of "Vibe Coding" in our first installment. We have seen how to structure the governance of a repository, how to force the AI to follow rigorous flows with Spec Kit, and even how to apply reverse engineering in gigantic legacy systems without dying trying.
But we have yet to solve the last major obstacle, the one that separates a personal or toy project from an enterprise-grade flow: secure execution and extreme automation.
It's useless to have an impeccable design specification in Markdown if we then let the agent run commands blindly on our development machine, or if the process of validating that the visual interface actually works still depends on a human manually clicking around in the browser.
Today we are going to open the engine room of Spec-Driven Development in production. We will see how to connect Spec Kit with Google Antigravity (the IDE designed from scratch for agents), how to isolate AI execution using local Sandboxing, and how to use MCP (Model Context Protocol) servers like Playwright MCP and Cloud Run MCP so that agents can test the UI visually and deploy to the cloud with a simple conversational prompt.
1. Context Hierarchy in Google Antigravity
To understand why Antigravity behaves so differently from traditional editors like VS Code or adapted cursors, you have to understand how it manages information.
In normal editors, context is "flat": you throw files at the AI and pray it remembers them all. In Antigravity, the information passed to the model is organized hierarchically into three strict levels of visibility and behavior. This prevents tokens from skyrocketing and keeps the agent focused on what truly matters at any given moment:
┌────────────────────────────────────────────────────────────────────────┐
│ Context Structure in Antigravity │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. RULES (.agents/rules/) │
│ - Persistent and always-active environmental context. │
│ - Example: project-context.md (DB schemas, current stack). │
│ │
│ 2. SKILLS (.agents/skills/) │
│ - Specialized abilities loaded only on demand. │
│ - Example: mcp-toolbox-postgres, caveman. │
│ │
│ 3. WORKFLOWS (.agents/workflows/) │
│ - Interactive slash commands (/) triggered manually. │
│ - Example: speckit.specify.md, speckit.plan.md. │
│ │
└────────────────────────────────────────────────────────────────────────┘- Rules (Environmental Context): They live in the
.agents/rules/folder and are injected into every open conversation if activated. The perfect example is ourproject-context.mdfile. This document is not a feature specification, but a map of the current codebase (technologies in use, file structure, database tables). The agent always reads it to know what playing field it's on. - Skills (On-Demand Knowledge): They are saved in
.agents/skills/and Antigravity only loads them if the current task semantically matches the skill's description. For example, a skill to interact with the PostgreSQL database via MCP Toolbox will only enter the agent's context if the prompt mentions changes to tables or data queries. This saves thousands of unnecessary context tokens in the day-to-day. - Workflows (Manual Triggers): They live in
.agents/workflows/and map directly as slash commands (/) in the editor's chat. This is where Spec Kit templates are injected (/speckit.specify,/speckit.plan,/speckit.tasks,/speckit.implement).
For Antigravity to recognize a Skill or a Workflow, the Markdown file must compulsorily start with a YAML metadata header (frontmatter) defining its name and activation purpose:
---
name: repo-research
description: Analyzes the repository structure and updates the project context file. Use this when requested to investigate, understand, or audit the codebase.
---If you omit this header, or make a YAML error, Antigravity will silently ignore the file, and the agent won't know that ability is available.
2. Local Sandboxing: The Closed Self-Correction Loop
One of the biggest dangers of AI-assisted programming is the "demolition effect": you ask the agent to fix a database bug, and five seconds later, you realize it deleted your migrations folder or installed three incompatible libraries that break your local machine's global build.
To solve this at the root, Antigravity introduces a fundamental concept of agent engineering: Agentic Sandboxing.
The Agent Harness (Agent = Model + Harness)
The golden rule of agentic governance says that a production agent is not just a smart language model; it is the indissoluble pairing of a model and a harness. The model provides logic and reasoning, but the harness provides the operating system, safety boundaries, tools, and the controlled execution environment.
In Antigravity, when the agent executes an implementation task (for example, by triggering the /speckit.implement command), physical code execution does not happen directly on your host machine. The editor automatically spins up a disposable isolated Linux container (Sandbox) and maps your workspace inside it.
┌────────────────────────────────────────────────────────────────────────┐
│ The Self-Correction Loop in the Sandbox │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Agent writes the code │
│ │ │
│ ▼ │
│ 2. Executed in the Sandbox │
│ (npm run test, tsc --noEmit, etc.) │
│ │ │
│ ┌───────────────────┴───────────────────┐ │
│ ▼ ▼ │
│ [Tests Pass?] [Tests Fail?] │
│ │ │ │
│ ▼ ▼ │
│ Converged Code Agent reads stderr │
│ Ready for Human PR and rewrites code │
│ ▲ │
│ └────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘This isolated environment enables a high-performance closed self-correction loop:
- The agent reads the task list from
tasks.md. - It writes the corresponding test, and then generates the implementation in the app's code.
- The Antigravity harness runs the validation command (e.g.,
npm run testorpytest) inside the isolated sandbox. - If the command fails, the agent reads the standard error output (
stderr) directly into its context, analyzes the failure trace, corrects the code, and autonomously runs the tests again. - The loop repeats without human intervention until tests pass at 100% and comply with the repository's Constitution.
You, as a developer, do not have to deal with broken commands in your local console or clean up orphaned variables in your filesystem. You only review the final consolidated result, and if the agent gets stuck or enters an infinite loop of failures, the editor allows you to intervene via the GUI to redirect the design or halt the task.
3. The Model Context Protocol (MCP) in Action
The great breakthrough of the latest agentic development tools is the MCP (Model Context Protocol) standard. Think of MCP as a unified API that allows any AI agent to communicate with external tools, services, and infrastructures securely using perfectly standardized input and output schemas.
Antigravity squeezes the MCP protocol through two spectacular integrations that take the SDD flow to another dimension of technical maturity:
Playwright MCP: Visual Testing in a Real Browser
One of the traditional weak points of AI programming is user interface (frontend) development. The agent can write impeccable HTML/CSS code that passes all linters, but visually looks totally misaligned or breaks the user experience.
By connecting the Playwright MCP server to the Antigravity execution harness, the agent acquires the ability to interact with a real Chromium browser integrated into the IDE:
- After implementing a feature, the agent launches the local server in the sandbox and asks Playwright to open the app.
- The agent can fill out forms, click buttons, navigate routes, and capture screenshots or interactive browser recordings.
- Using multimodal vision capabilities, the agent itself analyzes the image of the real interface, compares the visual rendering with the spec requirements, detects layout misalignments or overlapping elements, and auto-corrects the CSS or JS code until the visual test passes successfully.
Conductor Plugin: Orchestration and Cloud Deployment
The Conductor plugin is the evolution of Google's conversational development CLI tools, and it integrates natively into Antigravity via its terminal interface (agy).
Installing the add-on into your environment takes a single command:
agy plugins install https://github.com/gemini-cli-extensions/conductorOnce integrated, Conductor acts as the master orchestrator that removes the rigidity of having to write strict console commands one by one. It allows you to guide the entire Spec Kit pipeline in a conversational and fluid way. For example, instead of running manual commands, you can chat organically with the agent in the Antigravity terminal:
"Hey, analyze the restaurant reservation requirements we just discussed in the side chat, update the specs/reservation/spec.md file, and implement the changes locally."
Conductor will handle the project state under the hood: it will read the Constitution, update task checklists automatically, validate the code in the sandbox, and keep your logical documents synchronized.
But where Conductor truly shines is when connecting to the Cloud Run MCP server. It brings software deployment to a fully conversational and secure plane:
# Direct deployment via natural language using Cloud Run MCP
agy: Deploy this static gallery to Cloud Run under the "photogallery" service, using nginx and configuring port 80.The agent will interpret the request, use the MCP server to authenticate with your Google Cloud account transparently, prepare the production container, launch the deployment on the infrastructure, and return the public production URL ready for prime time in seconds.
4. Closing the Loop in Continuous Integration (CI/CD)
Spec-Driven Development does not end when the agent completes tasks on your local machine and opens a Pull Request. In professional environments with multiple developers interacting on the same product, the true validator of system consistency is the Continuous Integration (CI) pipeline.
To avoid the dreaded Contract Drift (when two developers introduce changes in parallel branches that compile individually but break mutual integrations upon merging), the standard production flow automates the Spec Kit validator in your CI/CD pipeline build:
# Configuration example for a GitHub Actions Workflow (.github/workflows/sdd-gate.yml)
name: SDD Governance Gate
on:
pull_request:
branches: [ main ]
jobs:
validate-spec:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4
- name: Install uv and Specify CLI
run: |
curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install specify-cli
- name: Run Constitutional Consistency Analysis
run: |
specify init --here --non-interactive --force --integration generic
# Runs the Spec Kit convergence analyzer
specify analyzeWhat does specify analyze do in CI/CD?
The Spec Kit analyzer performs a cross-audit of static and logical consistency without needing to interact with the developer:
- Constitution against the Plan: It checks that all guidelines from the Constitution (like using BigInt for currencies) remain implemented and mapped in the current technical plan.
- Plan against the Code: It scans the directory tree and generated files to ensure the development agent has implemented exactly what was agreed upon in the design contract, without adding forbidden dependencies or improvising out-of-scope features (scope creep).
- API Contracts: If there are changes to endpoints or database schemas, it crosses the contracts of the active branch with the state of
main. If it detects backward compatibility breakage or semantic inconsistency, it fails the CI build immediately, blocking the Pull Request merge before broken code can hurt production.
Conclusion: The End of the Governance Journey
We have completed our six-stop journey through the exciting ecosystem of Spec-Driven Development.
We have moved from the everyday frustration of "Vibe Coding" (where programming with AI felt like chasing a moving target in constant architectural drift) to designing a steel governance chassis capable of taming agentic speed in real, large-scale projects.
In the end, the great lesson SDD leaves us is not technological, but one of mindset: the value of a software engineer in the era of artificial intelligence is no longer measured by the speed at which they type syntax, but by the precision with which they define logical contracts, protect system consistency, and audit architectural boundaries.
Source code has become the exhaust, the ephemeral byproduct of an intelligent compilation engine that we can delete and regenerate in seconds. What truly matters, what you version in Git, what you inherit in your team, and what defines the future of your platform are your specifications, your logical plans, and your Constitution.
AI is ready to do the dirty work in the terminal and code editor. The question now is: Are you ready to start acting like a true Contract Engineer next Monday morning?
See you in the trenches of governed agentic development!
📚 Spec-Driven Development (SDD) Series
- Spec-Driven Development (SDD): AI Agent Governance and the End of 'Vibe Coding'
- The Governance Chassis: Constitution vs. AGENTS.md (And how not to drown in sync debt)
- The SDD Pipeline in Practice: From EARS Syntax to Atomic Tasks
- The Requirements Interview and the 'SpecOps' Loop: How to Use AI Sparring and Rewrite Code Painlessly
- The Challenge of Existing Code (Brownfield) and Managing Multiple Specs with Jira/Git
- Google Antigravity and MCP: Sandboxing, Self-Correction and the Cloud