← Volver al blog

Antigravity: qué es, cómo funciona y por qué cambia la forma de programar


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í:


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:


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?


Si hoy dependes de VS Code por sus extensiones, mi consejo es doble:



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:



Buenas prácticas y errores comunes con Antigravity

Cómo escribir tareas claras y auditar a los agentes


Seguridad, permisos y trabajo con repos reales


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.

Cuéntame sobre tu proyecto