Hasta ahora, la asistencia por IA en la programación operaba bajo un esquema síncrono: el desarrollador escribía y el modelo predecía la siguiente línea. Antigravity rompe este flujo introduciendo la delegación asíncrona. El usuario asume el rol de orquestador (lo que Google denomina Manager View), lanzando subagentes independientes que trabajan en segundo plano estructurando código, ejecutando tests y corrigiendo errores en entornos virtuales remotos.
aplicación de escritorio frente a CLI
Para sustituir el entorno clásico, Google despliega la plataforma bajo dos enfoques con requisitos de hardware radicalmente distintos:
La aplicación de escritorio: Es el entorno visual principal. Ofrece una interfaz gráfica para monitorizar ramas de código y agentes en paralelo, pero al estar empaquetada con módulos nativos orientados al rendimiento -que exigen conjuntos de instrucciones de CPU recientes como AVX/AVX2-, probablemente no será viable en ordenadores antiguos o con hardware heredado.
La CLI nativa en Go: La alternativa eficiente. Al no ejecutar inferencia localmente, evita por completo las dependencias de hardware que afectan a la app de escritorio. Es un binario estático que opera desde la terminal, consume apenas unos megabytes de RAM y permite orquestar agentes en la nube desde cualquier máquina.
Arquitectura cloud-native e I/O local
Al tratarse de un cliente ligero, el consumo de recursos en la máquina local es secundario. Toda la carga de inferencia de los modelos Gemini 3.1 Pro y 3.5 Flash se delega a la infraestructura en la nube de Google.
Para gestionar el árbol de archivos local sin corromper el código mientras los agentes trabajan de forma autónoma, la CLI ofrece dos metodologías de sincronización:
Demonio local (daemon): Un proceso en segundo plano que mantiene un socket abierto para inyectar en disco los cambios confirmados por el agente remoto en tiempo real.
Sincronización a demanda (pull): Para entornos aislados o con políticas restrictivas, la conexión local se corta. El agente finaliza su tarea en los servidores de Google y los archivos solo aterrizan en el disco cuando el desarrollador ejecuta un comando de sincronización manual.
El coste real del bucle cerrado: consumo de tokens
La demostración técnica de la keynote desveló el principal interrogante del sistema: la eficiencia económica.
La autonomía de Antigravity implica que los agentes entran en bucles cerrados de planificar → escribir → testear → fallar → refactorizar. Al no requerir confirmación humana entre iteraciones, el consumo de la ventana de contexto se dispara, con riesgo de agotar los límites de uso en tareas mal planificadas o ejecutadas. Aunque el sandbox remoto no se factura durante la actual fase preview para los usuarios con suscripciones Pro, el modelo expone un riesgo real: un único prompt inicial puede desencadenar una cascada de agentes cuyo coste escala sin intervención humana.
Riesgo de concurrencia: el talón de Aquiles del trabajo asíncrono
El modelo asíncrono exige un control de versiones riguroso con Git. Si se solapan tareas manuales o se ejecutan de forma simultánea otros asistentes en el mismo repositorio (como Claude Code o Codex) mientras un subagente de Antigravity opera en segundo plano, la sobrescritura cruzada de archivos destruirá la lógica del proyecto.
Síncrono vs. asíncrono: la diferencia que importa
La distinción fundamental entre Claude Code y Antigravity no es la ausencia de diálogo, sino cuándo y cómo se produce ese diálogo.
Claude Code es un asistente síncrono y bloqueante. Planifica, pide permiso antes de cada acción, ejecuta y vuelve a consultar. Si el desarrollador no responde, el proceso se congela. El humano es el cuello de botella del flujo, pero también su control permanente.
Antigravity invierte ese modelo. El desarrollador propone un objetivo amplio y el agente intenta resolverlo de principio a fin en su propio sandbox: crea subagentes, compila, lee errores y se autocorrige sin intervención constante. Sin embargo, esto no significa que opere a ciegas.
Para evitar bucles ineficientes de consumo de tokens, el sistema incorpora tres mecanismos de intervención estructurada. Los puntos de control detienen al agente antes de fusionar cambios destructivos o masivos, generando un estado de revisión - en la CLI visible como
BLOCKED_WAITING_APPROVAL - donde el desarrollador aprueba o rectifica. Las peticiones de clarificación se activan cuando el agente encuentra una ambigüedad que no puede resolver por su cuenta (credenciales, endpoints caídos, decisiones de arquitectura): pausa, notifica y abre un diálogo directo para resolver la duda puntual antes de retomar el trabajo asíncrono. La intervención forzada permite redirigir al agente en cualquier momento mediante comandos de steering, aunque esté ejecutando tareas en segundo plano.La diferencia real, por tanto, no es autonomía absoluta frente a supervisión constante. Claude Code acompaña al desarrollador en cada paso; Antigravity lo trata como a un jefe de proyecto: trabaja por su cuenta y solo convoca cuando tiene algo que aprobar o cuando se topa con un muro que no puede saltar solo.
En conclusión, Antigravity 2.0 es una plataforma que libera los recursos del hardware local, pero impone un cambio en la metodología de trabajo. El programador deja de ser un escritor de código (asistido) para transformarse en un auditor de procesos: la habilidad requerida no es ya dominar la sintaxis, sino definir con precisión los límites de actuación de la herramienta.
