La primera vez que abrí Antigravity hice lo que probablemente hayas hecho tú: lo traté como un Cursor con otro logo. Le pedí algo, miré cómo escribía código, corregí, repetí. Funcionaba. Pero no estaba sacándole nada que no me diera ya cualquier otro editor con IA.
El cambio llegó cuando dejé de pensar en Antigravity como un editor y empecé a pensarlo como lo que Google quiere que sea: una capa de coordinación de agentes. No es un detalle de marketing. Cambia por completo qué tipo de trabajo le delegas y, sobre todo, cuánto criterio tuyo necesitas dejar escrito antes de delegarlo.
Después de varias semanas usándolo en proyectos reales (algunos de Venturest, otros de pruebas), estos son los casos de uso que de verdad mueven la aguja, cómo configurar las rules para que el agente trabaje a tu favor, y el ecosistema de skills y workflows que casi nadie está aprovechando todavía.
Qué es Antigravity (y por qué importa la distinción)
Antigravity es la plataforma de desarrollo agéntico de Google, lanzada en noviembre de 2025 junto a Gemini 3. Técnicamente, el editor es un fork de VS Code, así que el entorno te resultará familiar desde el primer minuto. Pero quedarse en "es un IDE" se pierde lo importante.
La plataforma tiene dos superficies. El Editor View es el IDE de siempre con IA encima: autocompletado, comandos en lenguaje natural, todo lo que ya conoces. El Manager Surface es donde está el salto: una interfaz dedicada para lanzar, orquestar y observar varios agentes trabajando en paralelo, de forma asíncrona, en distintos workspaces.
Esa es la idea de fondo. Pasas de "chatear con la IA en una ventana" a "asignar misiones a un equipo y revisar resultados". Y como cualquier persona que ha gestionado un equipo de ingeniería sabe, eso introduce un problema viejo con cara nueva: si no codificas tus estándares, cada agente improvisa los suyos.
Un apunte sobre modelos: Antigravity es gratis en preview para individuos y te deja elegir modelo, con Gemini 3.1 Pro de base pero también soporte para Gemini 3.5 Flash, Claude Sonnet 4.6 y modelos abiertos. La optionalidad de modelo es más útil de lo que parece: no todos rinden igual según la tarea.
Los casos de uso que de verdad cambian tu flujo
1. Delegar tareas end-to-end, no fragmentos
El error más común es seguir pidiendo trozos: "escríbeme esta función", "arregla este bug". Antigravity está pensado para misiones completas. El agente puede planificar y ejecutar una tarea atravesando editor, terminal y navegador: escribe el código de una feature, levanta la aplicación desde la terminal, abre el navegador para probar que el componente funciona, y lo verifica. Todo sin que estés en cada paso.
Mi regla mental: si la tarea cabe en una frase orientada a objetivo ("implementa el login con email y verifica que el flujo completo funciona"), es candidata a delegación. Si necesitas microgestionar cada decisión, mejor quédate en el Editor View.
2. Agentes en paralelo: el equipo que no se interrumpe
El Manager Surface permite lanzar varios agentes en workspaces distintos a la vez. Aquí es donde dejé de pensar en "una conversación" y empecé a pensar en "tareas concurrentes".
El patrón que más me ha servido: un agente "junior" ocupándose de refactors tediosos o de actualizar dependencias en segundo plano, mientras otro agente trabaja conmigo en la lógica compleja. No paras tu flujo principal para atender lo aburrido. Eso sí (y lo digo por experiencia), el soporte de branching de Git todavía no está maduro. Si pones varios agentes a tocar el mismo repo grande sin disciplina, te la juegas. Workspaces separados y commits frecuentes no son opcionales aquí.
3. Browser-in-the-loop: la verificación real
Esta es probablemente la feature que más diferencia a Antigravity. El agente levanta una instancia real de Chrome (el Browser Subagent) y usa la aplicación mientras la construye: pulsa botones, rellena formularios, hace capturas. Si algo no funciona, lo ve, lo depura y lo arregla sin que tú abras DevTools.
Cierra el bucle entre escribir código y validarlo. Para desarrollo web, esto solo ya justifica probarlo.
4. Artifacts y Walkthroughs: revisar sin leer logs
En lugar de hacer scroll por logs de llamadas a herramientas, los agentes producen Artifacts: entregables legibles como planes de implementación, listas de tareas, capturas y grabaciones de las sesiones de navegador. Y al terminar, generan un Walkthrough: un resumen de qué cambió, qué ficheros se tocaron y por qué se eligieron ciertos patrones, con capturas de la app funcionando.
Suena a detalle estético. No lo es. Es lo que hace que revisar el trabajo de un agente sea factible. Tienes prueba visual de que la feature funciona antes de meterte en la sintaxis. Para quien revisa código de un equipo —humano o agéntico— eso es oro.
Un último consejo de flujo: usa Plan mode para tareas complejas (genera un plan que apruebas antes de actuar) y Fast mode para arreglos rápidos. Aprobar el plan antes de que el agente se lance es la diferencia entre corregir el rumbo en un minuto o limpiar el desastre en tres horas.
Las rules: aquí es donde codificas tu criterio
Los modelos de Antigravity son generalistas potentes, pero no conocen tu proyecto ni los estándares de tu equipo. Las rules son el mecanismo para arreglar eso. Y entender su jerarquía es lo que separa configurarlo bien de pelearte con un agente que no para de tomar decisiones que no quieres.
- System rules: directrices inmutables de Google DeepMind. Definen identidad, protocolos de seguridad y capacidades base. No las tocas.
- Global rules: tus preferencias personales, aplicadas a todos los proyectos. Viven en tu directorio home, en
~/.gemini/GEMINI.md(y~/.gemini/AGENTS.mdpara el estándar cross-tool). Ideales para cosas como "usa siempre TypeScript" o el idioma de las respuestas. - Workspace rules: los estándares del proyecto actual. Viven dentro del repo, en
GEMINI.md,AGENTS.mdo en la carpeta.agent/rules/. Aquí pones lo del equipo: "usamos Next.js App Router", convenciones de commits, estructura de carpetas.
Lo interesante de la última oleada es AGENTS.md, un estándar cross-tool que comparten Antigravity, Claude, Cursor y otros. La ventaja es real: escribes tus reglas una vez y las reutilizas entre herramientas, en lugar de mantener un fichero distinto por cada vendor. Si estás invirtiendo tiempo en esto, apuesta por AGENTS.md antes que por el formato propietario.
Configurarlas es sencillo: en el Agent Manager, los tres puntos (•••) arriba a la derecha → Customizations → pestaña Rules → + Global o + Workspace. Y se escriben en lenguaje natural, sin sintaxis rara. Un ejemplo real de regla de estilo:
# Python Style Rule
Usa siempre estándares PEP 8.
Al refactorizar, asume que formateamos con `black`.
Mantén las dependencias a librerías open-source y gratuitas.Skills y workflows: el resto del ecosistema
Las rules no son lo único. Hay dos piezas más, y la confusión entre ellas es habitual. La distinción que mejor me funciona:
Una rule es una restricción base: cómo se comporta el agente y cómo se adapta a tu stack y tu estilo.
Un skill es un paquete de conocimiento reutilizable que le enseña al agente cómo resolver una tarea concreta. Es una carpeta con un fichero SKILL.md (y opcionalmente scripts/, examples/, resources/). La gracia está en la progressive disclosure: el skill duerme hasta que el agente, leyendo solo su descripción, decide que es relevante para lo que le has pedido. Así no saturas el contexto con instrucciones que no vienen al caso.
El campo más importante de un skill es la descripción: escríbela en tercera persona y con palabras clave claras, porque es literalmente lo que el agente usa para decidir cuándo activarlo. Algo como: "Genera tests unitarios para código Python siguiendo convenciones de pytest."
Los skills tienen scope global (actualmente en ~/.gemini/config/skills/) o de workspace (<proyecto>/.agents/skills/). Y siguen el estándar abierto Agent Skills, que también comparten otras herramientas: escribes el skill una vez y lo usas entre harnesses, sin reescribir la misma capacidad por cada proveedor.
Un workflow es el orquestador. Se invoca como un slash command (/deploy, /startcycle) y guía al agente por un plan de varios pasos bien estructurado. Es lo que te permite automatizar tareas repetitivas sin perder precisión —encadenar, por ejemplo, "revisa el código → genera tests → audita → despliega" en un solo comando.
Rule, skill, workflow. Restricción, conocimiento, orquestación. Cuando combinas las tres, dejas de tener un programador genérico y pasas a tener un especialista que sigue tus reglas, sabe hacer tus tareas y ejecuta tus procesos.
Buenas prácticas (algunas aprendidas a base de tropiezos)
Lo que me habría gustado que alguien me dijera antes:
- Prompts enfocados y orientados a objetivo. Una misión clara por tarea. No mezcles cosas no relacionadas en el mismo prompt: confundes al agente y empeoras el plan.
- Una carpeta o workspace por tarea. Aísla contextos. Es la mejor defensa contra que un agente pise el trabajo de otro.
- Revisa el plan antes de aprobar. En tareas grandes, Plan mode no es burocracia: es tu punto de control.
- Commits incrementales desde el minuto cero. Haz un commit inicial antes del primer prompt y deja que el agente comitee por etapas. Si alucina una estructura de ficheros o rompe una dependencia, revertir es cuestión de segundos. Esto, con el branching aún inmaduro, es innegociable.
- Cuidado con el prompt injection. Es un riesgo real de los IDEs agénticos: un atacante puede esconder instrucciones en un README o en comentarios para que el agente filtre datos. Revisa los comentarios autogenerados buscando URLs salientes sospechosas y desactiva el renderizado de imágenes en Markdown en los paneles de preview si no lo necesitas.
- Mantén los skills atómicos y bien nombrados. Es tentador hacer un mega-skill que lo haga todo. No lo hagas. Los skills proliferan rápido y, si se solapan, el modelo elige mal. Scoped y específico le gana siempre a un blob que lo hace todo.
El cambio de fondo
Hace unos meses escribí que no necesitas tu propia IA, necesitas usarla bien. Antigravity es el caso de estudio perfecto de esa idea.
La herramienta es gratis y potente. Pero su valor no está en que escriba código más rápido (eso ya lo hacían otras). Está en que te obliga a hacer explícito lo que normalmente vive solo en tu cabeza: tus estándares, tu forma de hacer las cosas, tus procesos. Las rules, los skills y los workflows no son features de configuración. Son el ejercicio de codificar tu criterio para que un equipo de agentes lo siga sin ti delante.
Y ahí está lo incómodo y lo interesante a la vez: la ventaja competitiva del que programa con agentes ya no es lo rápido que teclea. Es lo bien que sabe delegar. Que es, por cierto, exactamente la misma habilidad que separa a un buen tech lead de un buen senior developer.
¿Tú ya has dejado tu criterio por escrito, o sigues corrigiendo al agente uno por uno cada vez?
