Hemos recorrido un camino largo e intenso desde que declaramos la muerte del "Vibe Coding" en nuestra primera entrega. Hemos visto cómo estructurar la gobernanza de un repositorio, cómo obligar a la IA a seguir flujos rigurosos con Spec Kit, e incluso cómo aplicar la ingeniería inversa en sistemas legacy gigantescos sin morir en el intento.
Pero nos queda por resolver el último gran obstáculo, el que separa un proyecto personal o de juguete de un flujo de nivel empresarial: la ejecución segura y la automatización extrema.
De nada sirve tener una especificación de diseño impecable en Markdown si luego dejamos que el agente ejecute comandos a ciegas en nuestra máquina de desarrollo, o si el proceso de validar que la interfaz visual de verdad funciona sigue dependiendo de que un humano haga clics de forma manual en el navegador.
Hoy vamos a abrir la sala de máquinas del Spec-Driven Development en producción. Veremos cómo conectar Spec Kit con Google Antigravity (el IDE diseñado desde cero para agentes), cómo aislar la ejecución de la IA mediante Sandboxing local, y cómo usar servidores MCP (Model Context Protocol) como Playwright MCP y Cloud Run MCP para que los agentes prueben la UI visualmente y desplieguen a la nube con un simple prompt conversacional.
1. La Jerarquía de Contexto en Google Antigravity
Para entender por qué Antigravity se comporta de forma tan diferente a editores tradicionales como VS Code o cursores adaptados, hay que entender cómo gestiona la información.
En editores normales, el contexto es "plano": le tiras archivos a la IA y rezas para que se acuerde de todos. En Antigravity, la información que se le pasa al modelo se organiza de forma jerárquica en tres niveles estrictos de visibilidad y comportamiento. Esto evita que los tokens se disparen y mantiene al agente enfocado en lo que de verdad importa en cada momento:
┌────────────────────────────────────────────────────────────────────────┐
│ Estructura de Contexto en Antigravity │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. RULES (.agents/rules/) │
│ - Contexto ambiental persistente y siempre activo. │
│ - Ejemplo: project-context.md (esquemas de BD, stack actual). │
│ │
│ 2. SKILLS (.agents/skills/) │
│ - Habilidades especializadas que se cargan solo bajo demanda. │
│ - Ejemplo: mcp-toolbox-postgres, caveman. │
│ │
│ 3. WORKFLOWS (.agents/workflows/) │
│ - Comandos interactivos de barra diagonal (/) disparados a mano. │
│ - Ejemplo: speckit.specify.md, speckit.plan.md. │
│ │
└────────────────────────────────────────────────────────────────────────┘- Rules (El contexto ambiental): Viven en la carpeta
.agents/rules/y se inyectan en cada conversación abierta si están activadas. El ejemplo perfecto es nuestro archivoproject-context.md. Este documento no es una especificación de feature, sino un mapa de la base de código actual (tecnologías en uso, estructura de archivos, tablas de la base de datos). El agente lo lee siempre para saber en qué terreno está jugando. - Skills (El conocimiento bajo demanda): Se guardan en
.agents/skills/y Antigravity solo los carga si la tarea actual coincide semánticamente con la descripción del skill. Por ejemplo, un skill para interactuar con la base de datos PostgreSQL mediante MCP Toolbox solo entrará en el contexto del agente si el prompt menciona cambios en las tablas o consultas de datos. Esto ahorra miles de tokens de contexto innecesarios en el día a día. - Workflows (Los disparadores manuales): Viven en
.agents/workflows/y se mapean directamente como comandos de barra diagonal (/) en el chat del editor. Aquí es donde se inyectan las plantillas de Spec Kit (/speckit.specify,/speckit.plan,/speckit.tasks,/speckit.implement).
Para que Antigravity reconozca un Skill o un Workflow, el archivo Markdown debe empezar obligatoriamente con una cabecera de metadatos en formato YAML (frontmatter) que defina su nombre y su propósito de activación:
---
name: repo-research
description: Analiza la estructura del repositorio y updatea el archivo de contexto del proyecto. Úsalo cuando se solicite investigar, entender o auditar el código base.
---Si omites esta cabecera, o si cometes un error en el YAML, Antigravity ignorará el archivo silenciosamente y el agente no sabrá que tiene esa habilidad disponible.
2. Sandboxing Local: El Bucle de Autocorrección Cerrado
Uno de los mayores peligros de la programación asistida por IA es el "efecto demolición": le pides al agente que te arregle un bug de base de datos y, a los cinco segundos, te das cuenta de que te ha borrado la carpeta de migraciones o ha instalado tres librerías incompatibles que rompen la compilación global de tu máquina local.
Para solucionar esto de raíz, Antigravity introduce un concepto fundamental de ingeniería de agentes: el Sandboxing agéntico.
El Arnés de Agentes (Agent = Model + Harness)
La regla de oro de la gobernanza agéntica dice que un agente de producción no es solo un modelo de lenguaje inteligente; es el binomio indisoluble de un modelo y un arnés (harness). El modelo aporta la lógica y el razonamiento, pero el arnés aporta el sistema operativo, los límites de seguridad, las herramientas y el entorno de ejecución controlado.
En Antigravity, cuando el agente ejecuta una tarea de implementación (por ejemplo, al disparar el comando /speckit.implement), la ejecución física del código no ocurre de forma directa sobre tu máquina host. El editor levanta de forma automática un contenedor Linux aislado (Sandbox) desechable y mapea ahí dentro tu espacio de trabajo.
┌────────────────────────────────────────────────────────────────────────┐
│ El Bucle de Autocorrección en el Sandbox │
├────────────────────────────────────────────────────────────────────────┤
│ │
│ 1. Agente escribe el código │
│ │ │
│ ▼ │
│ 2. Se ejecuta en el Sandbox │
│ (npm run test, tsc --noEmit, etc.) │
│ │ │
│ ┌───────────────────┴───────────────────┐ │
│ ▼ ▼ │
│ [¿Pruebas Pasan?] [¿Pruebas Fallan?] │
│ │ │ │
│ ▼ ▼ │
│ Código Convergido Agente lee stderr │
│ Listo para PR Humana y reescribe código │
│ ▲ │
│ └────────┘ │
│ │
└────────────────────────────────────────────────────────────────────────┘Este entorno aislado permite habilitar un bucle de autocorrección cerrado de alto rendimiento:
- El agente lee la lista de tareas de
tasks.md. - Escribe el test correspondiente y, a continuación, genera la implementación en el código de la app.
- El arnés de Antigravity ejecuta el comando de validación (por ejemplo,
npm run testopytest) dentro del sandbox aislado. - Si el comando falla, el agente lee la salida de error estándar (
stderr) directamente en su contexto, analiza la traza del fallo, corrige el código y vuelve a ejecutar las pruebas de manera autónoma. - El bucle se repite sin intervención humana hasta que las pruebas pasan al 100% y cumplen la Constitución del repositorio.
Tú, como desarrollador, no tienes que lidiar con los comandos rotos en tu consola local ni limpiar variables huérfanas en tu sistema de archivos. Solo contemplas el resultado final consolidado y, si el agente se queda encallado o entra en un bucle infinito de fallos, el editor te permite intervenir mediante la interfaz gráfica para reconducir el diseño o detener la tarea.
3. El Protocolo de Contexto de Modelos (MCP) en Acción
El gran avance de las últimas herramientas de desarrollo agénticas es el estándar MCP (Model Context Protocol). Piensa en MCP como una API unificada que permite a cualquier agente de IA comunicarse con herramientas, servicios e infraestructuras externas de forma segura utilizando esquemas de entrada y salida perfectamente estandarizados.
Antigravity exprime el protocolo MCP mediante dos integraciones espectaculares que llevan el flujo SDD a otra dimensión de madurez técnica:
Playwright MCP: Testing Visual en Navegador Real
Uno de los puntos débiles tradicionales de la programación con IA es el desarrollo de interfaces de usuario (frontend). El agente puede escribir código HTML/CSS impecable que pasa todos los linters, pero que visualmente se ve totalmente descuadrado o rompe la experiencia de usuario.
Al conectar el servidor Playwright MCP al arnés de ejecución de Antigravity, el agente adquiere la habilidad de interactuar con un navegador Chromium real integrado en el IDE:
- Tras implementar una funcionalidad, el agente lanza el servidor local en el sandbox y le pide a Playwright que abra la app.
- El agente puede rellenar formularios, hacer clics en botones, navegar por rutas y capturar capturas de pantalla o grabaciones interactivas del navegador.
- Utilizando capacidades de visión multimodal, el propio agente analiza la imagen de la interfaz real, compara el renderizado visual con los requisitos de la spec, detecta descuadres de diseño o elementos solapados, y auto-corrige el código CSS o JS hasta que el test visual pasa con éxito.
Conductor Plugin: Orquestación y Despliegue en la Nube
El plugin Conductor es la evolución de las herramientas CLI de desarrollo conversacional de Google, y se integra de forma nativa en Antigravity a través de su interfaz de terminal (agy).
La instalación del complemento dentro de tu entorno se realiza con un único comando:
agy plugins install https://github.com/gemini-cli-extensions/conductorUna vez integrado, Conductor actúa como el orquestador maestro que elimina la rigidez de tener que escribir comandos de consola estrictos uno a uno. Permite guiar todo el pipeline de Spec Kit de manera conversacional y fluida. Por ejemplo, en lugar de ejecutar comandos manuales, puedes charlar de forma orgánica con el agente en la terminal de Antigravity:
"Oye, analiza los requisitos de la reserva del restaurante que acabamos de comentar en el chat lateral, pon al día el archivo specs/reserva/spec.md e implementa los cambios en local."
Conductor se encargará de gestionar el estado del proyecto por debajo: leerá la Constitución, actualizará los checklists de tareas de forma automática, validará el código en el sandbox y mantendrá sincronizados tus documentos lógicos.
Pero donde Conductor brilla de verdad es al conectarse con el servidor Cloud Run MCP. Permite llevar el despliegue del software a un plano totalmente conversacional y seguro:
# Despliegue directo mediante lenguaje natural usando Cloud Run MCP
agy: Deploy esta galería estática a Cloud Run bajo el servicio "photogallery", usando nginx y configurando el puerto 80.El agente interpretará la petición, usará el servidor MCP para autenticarse con tu cuenta de Google Cloud de forma transparente, preparará el contenedor de producción, lanzará el despliegue en la infraestructura y te devolverá la URL pública de producción lista para producción en segundos.
4. El Cierre del Bucle en Integración Continua (CI/CD)
El Spec-Driven Development no termina cuando el agente completa las tareas en tu máquina local y abre una Pull Request. En entornos profesionales con múltiples desarrolladores interactuando sobre el mismo producto, el verdadero validador de la consistencia del sistema es el pipeline de Integración Continua (CI).
Para evitar el temido Contract Drift (cuando dos desarrolladores introducen cambios en ramas paralelas que individualmente compilan, pero que rompen las integraciones mutuas al fusionarse), el flujo estándar de producción automatiza el validador de Spec Kit en el build de tu pipeline de CI/CD:
# Ejemplo de configuración para un Workflow de GitHub Actions (.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
# Ejecuta el analizador de convergencia de Spec Kit
specify analyze¿Qué hace specify analyze en la CI/CD?
El analizador de Spec Kit realiza una auditación cruzada de consistencia estática y lógica sin necesidad de interactuar con el desarrollador:
- Constitución contra el Plan: Comprueba que todas las directrices de la Constitución (como usar BigInt para monedas) sigan estando implementadas y mapeadas en el plan técnico actual.
- Plan contra el Código: Escanea el árbol de directorios y los archivos generados para asegurar que el agente de desarrollo ha implementado exactamente lo que se acordó en el contrato de diseño, sin añadir dependencias prohibidas ni improvisar funcionalidades fuera del alcance (scope creep).
- Contratos de API: Si hay cambios en los endpoints o en los esquemas de bases de datos, cruza los contratos de la rama activa con el estado de
main. Si detecta una rotura de compatibilidad hacia atrás o una inconsistencia semántica, falla el build de la CI de inmediato, bloqueando el merge de la Pull Request antes de que el código roto pueda llegar a herir a producción.
Conclusión: El Fin del Viaje de la Gobernanza
Hemos completado nuestro viaje de seis paradas por el emocionante ecosistema del Spec-Driven Development.
Hemos pasado de la frustración cotidiana del "Vibe Coding" (donde programar con IA se sentía como perseguir un blanco móvil en constante deriva arquitectónica) a diseñar un chasis de gobernanza de acero capaz de domar la velocidad agéntica en proyectos reales de gran escala.
Al final, la gran lección que nos deja el SDD no es tecnológica, sino de mentalidad: el valor de un ingeniero de software en la era de la inteligencia artificial ya no se mide por la velocidad con la que teclea sintaxis, sino por la precisión con la que define contratos lógicos, protege la consistencia de su sistema y audita los límites de su arquitectura.
El código fuente ha pasado a ser el escape, el subproducto efímero de un motor de compilación inteligente que podemos borrar y regenerar en segundos. Lo que de verdad importa, lo que versionas en Git, lo que heredas en tu equipo y lo que define el futuro de tu plataforma son tus especificaciones, tus planes lógicos y tu Constitución.
La IA está lista para hacer el trabajo sucio en la terminal y en el editor de código. La pregunta ahora es: ¿estás preparado para empezar a actuar como un verdadero Ingeniero de Contratos el próximo lunes por la mañana?
¡Nos vemos en las trincheras del desarrollo agéntico gobernado!
📚 Serie Spec-Driven Development (SDD)
- Spec-Driven Development (SDD): Gobernanza de Agentes IA y el Fin del 'Vibe Coding'
- El Chasis de la Gobernanza: Constitución vs. AGENTS.md (Y cómo no ahogarte en deuda de sincronización)
- El Pipeline SDD en la Práctica: De la Sintaxis EARS a las Tareas Atómicas
- La Entrevista de Requisitos y el Bucle "SpecOps": Cómo usar la IA de Sparring y rehacer código sin dolor
- El Reto del Código Existente (Brownfield) y la Gestión de Múltiples Specs con Jira/Git
- Google Antigravity y MCP: Sandboxing, Autocorrección y la Nube