Hablar de Antigravity es hablar de un cambio de paradigma: en vez de un IDE “pasivo” con un asistente puntual, tenemos una plataforma agent-first que entiende el proyecto, propone rutas de trabajo y ejecuta tareas. Tras varios días usándolo, me acostumbré al flujo con una facilidad que me sorprendió; la curva de aprendizaje es corta si ya vienes de entornos como VS Code o Windsurf, pero la mentalidad cambia: aquí orquestas agentes, no solo líneas de código.
A nivel conceptual, piensa en Antigravity como un espacio donde conviven Editor + Terminal + Navegación/Contexto y un panel de tareas/planes. En mi caso, lo que más me enganchó fue el Assistant Mode y la gestión de Tasks: creas una misión (p. ej., “encuentra dónde se rompe este hook de WordPress”), el sistema descompone, justifica y deja rastro de lo que hace. Esa trazabilidad da mucha confianza cuando tocas repos reales.
¿Para quién es? Para quien ya usa copilotos pero siente que se quedan cortos en multi-paso, depuración guiada y contexto de proyecto. Si estás en PHP/WordPress, Node o Python, el esquema mental te encaja de inmediato.
Antigravity en 5 minutos: concepto, vistas (Editor/Manager) y agentes
Qué lo hace distinto a un IDE clásico (editor, terminal, navegador “agents-aware”)
En un IDE clásico, tú conduces y el copiloto comenta. En Antigravity, delegas subtareas: el agente inspecciona archivos, corre scripts, revisa logs y propone cambios con explicaciones. El Editor sigue siendo tu centro, pero está “aware” de lo que hacen los agentes; la Terminal se usa sin salir del flujo; y la “navegación” del repositorio/conocimiento pasa por el prisma del agente (no solo por tu memoria).
En mis pruebas, noté que el agente justifica por qué sugiere un diff y qué alternativa descartó. Ese “mostrar el pensamiento” (hasta donde el producto lo permite) agiliza decisiones: si veo que su hipótesis no aplica a mi plugin, corto rápido sin perder tiempo.
Artifacts, tasks y trazabilidad: ver para creer
Cada Task deja evidencia: comandos ejecutados, archivos tocados y motivos. Cuando depuré mi plugin de WordPress, ver esa “bitácora” me permitió revertir un intento fallido en segundos, y quedarme con el cambio bueno. Además, si pides una refactorización, puedes exigir criterios de aceptación (tests que deben pasar, estilo de código, no romper hooks). Ese enfoque auditable es, para mí, la ventaja competitiva: no es magia negra, es proceso visible.
Primeros pasos y flujo real: del onboarding a la depuración de un plugin de WordPress
Preparar el entorno (Windows/macOS/Linux) y crear la primera misión
La experiencia de onboarding fue directa: abrir el proyecto, indicarle el objetivo y dejar que indexe. Recomiendo preparar un brief de contexto en el README: qué hace el plugin, dónde están los tests y qué rutas no debe tocar. Yo añadí una lista de “áreas sensibles” (hooks críticos, filtros, dependencias) y notas de cómo correr el entorno local. Con eso, la primera misión (“localiza por qué este shortcode lanza un notice en PHP 8.x”) salió fluida.
Cómo usé Assistant Mode y Tasks para encontrar y corregir un bug
Mi flujo real fue así:
- Declaré la misión: “hay un notice en
do_shortcodecuando el atributo X no llega”. - El agente inspeccionó los archivos del plugin y apuntó a una función con tipado laxo.
- Propuso un plan: reproducir en local, añadir guard clauses y ajustar el
sanitize_text_field. - Ejecutó pruebas (las mínimas necesarias) y me dejó un diff razonado.
- Validé manualmente en el sitio de staging.
El resultado fue mejor de lo esperado: en un par de iteraciones quedó limpio y, de paso, el agente señaló una consulta innecesaria a la base de datos que yo no había considerado. Aquí noté el valor de Gemini 3 para problemas acotados: desmenuza con precisión. Aun así, para sesiones largas de programación sigo prefiriendo Claude Sonnet; siento que su estilo me rinde mejor al estructurar refactors amplios. Tener elección de modelo dentro del mismo flujo fue clave para mí.
Modelos soportados y elección práctica: Gemini 3 vs Claude Sonnet (y otros)
Ventana de contexto, uso de herramientas y “cuando uno rinde mejor que otro”
Sin entrar en benchmarks formales, así se sintió en mi día a día:
- Gemini 3: muy sólido en tareas específicas y cuando el agente debe usar herramientas (leer archivos, ejecutar comandos, razonar sobre logs). Lo elegí para localizar el notice del shortcode y para micro-fixes guiados por pruebas.
- Claude Sonnet: lo percibo fuerte en planificación y estilo de código cuando pides “reestructura este módulo en tres capas, con contratos claros y tests de borde”. Para refactors o documentación más extensa, me fluyó mejor.
Consejo práctico: define el criterio de éxito por Task (p. ej., “todos los tests verdes + no warnings en el log”), y cambia de modelo si ves que el agente divaga. La plataforma lo permite y se nota.
Antigravity vs VS Code vs Windsurf: interfaz, filosofía y compatibilidad
¿Está “basado en” otro IDE o es una capa agent-first? Lo que debes saber
La duda es frecuente (yo también la tuve): “¿Antigravity está construido sobre VS Code o Windsurf?”. La sensación al usarlo es que se inspira en patrones conocidos (paneles, barra lateral, terminal integrada), pero la filosofía es distinta: todo gira en torno a misiones y agentes. Más que “un VS Code con plugin”, se comporta como un entorno diseñado para orquestar trabajo autónomo.
¿Qué implica en la práctica?
- Contexto compartido: el agente “sabe” qué estás editando y por qué, y sus propuestas llegan con plan y justificación.
- Auditoría: cada paso deja rastro (tareas, artifacts, diffs).
- Flujo dirigido: creas misiones, no solo archivos.
Si hoy dependes de VS Code por sus extensiones, mi consejo es doble:
- Convive: sigue usando VS Code para tareas ultra-manuales y Antigravity cuando requieras cadenas de pasos (reproducir bug → instrumentar → testear → proponer fix).
- Evalúa Windsurf si te interesa otro enfoque “IA-centrado”. En mi caso, Antigravity me resultó más natural por cómo visibiliza planes/tareas dentro del editor, pero la elección es de flujo mental más que de “feature checklist”.
Límites, disponibilidad y roadmap: lo que ya puedes hacer hoy
Gratis (preview), rate limits y dónde descargarlo
A día de hoy, la experiencia más útil es tratar Antigravity como un laboratorio de trabajo con agentes: perfecto para prototipos, depuración guiada y refactors acotados. Si te encuentras con límites de uso (rate limits) o alguna fricción de acceso, planifica sesiones focalizadas (una misión bien definida por bloque de trabajo) y documenta qué logró el agente en cada iteración. Esa disciplina te ahorra tiempo y evita repetir pasos.
Dónde empezar:
- Prepara README/contexto del repo.
- Define métricas sencillas (ej.: “warnings=0”, “latencia < X ms”).
- Abre la primera misión pequeña (un bug/hotfix), luego escala a una refactorización.
Buenas prácticas y errores comunes con Antigravity
Cómo escribir tareas claras y auditar a los agentes
- Especifica el objetivo y los límites: “arregla A sin tocar B/C”.
- Adjunta señales de validación: tests a correr, comandos, dataset de prueba.
- Pide justificación: solicita el porqué del cambio (te ayuda a aceptar/rechazar rápido).
- Reutiliza artifacts: conviértelos en documentación viva del proyecto.
Seguridad, permisos y trabajo con repos reales
- Trabaja en ramas aisladas y con staging.
- Revisa comandos antes de ejecutarlos si el agente los propone.
- Mantén copias de configuración (wp-config, .env) fuera del alcance del agente cuando no sean necesarias para la tarea.
En mi caso, al depurar el plugin, mantener la misión acotada y pedir criterios de aceptación evitó que el agente tocara plantillas fuera de alcance. Ese control fino marca la diferencia entre “IA útil” y “IA que te desordena el repo”.
FAQs rápidas sobre Antigravity
¿Es un IDE o una plataforma de agentes?
Una plataforma de desarrollo agent-first con editor/terminal integrados.
¿Necesito usar un modelo específico?
No necesariamente. Yo trabajé con Gemini 3 para tareas quirúrgicas y sigo prefiriendo Claude Sonnet para sesiones de programación más largas.
¿Se integra con proyectos WordPress/PHP?
Sí. Lo usé para depurar un plugin y el flujo de misiones + artifacts me ayudó a aislar el bug y justificar los cambios.
¿Está basado en VS Code o Windsurf?
La experiencia sugiere que no es solo un “tema” de otro IDE: el núcleo es la orquestación de agentes. Si vienes de VS Code/Windsurf, te adaptarás, pero el foco mental cambia.
¿Cómo empiezo sin perderme?
Crea un README de contexto, abre una misión pequeña y exige criterios de aceptación claros (tests, linters, logs limpios).
Conclusión
Antigravity no compite solo por “tener un buen asistente”, sino por convertir la programación en un diálogo con agentes que planifican, ejecutan y rinden cuentas. En mi experiencia, resolví un bug de WordPress más rápido de lo esperado, con diffs explicados y sin romper zonas sensibles. La posibilidad de alternar entre Gemini 3 y Claude Sonnet según la tarea me dio una flexibilidad real. Si buscas pasar de “copiloto” a orquestación de trabajo, vale la pena adoptarlo como tu entorno de misiones.