Manager View es la parte de Google Antigravity que casi nadie usa bien la primera vez: en vez de chatear con un agente a la vez como en el Editor View, te deja lanzar varios agentes de Gemini en paralelo sobre tareas distintas del mismo proyecto y supervisarlos desde un solo tablero. El problema no es activarlo — es saber cuándo de verdad conviene paralelizar y cuándo solo estás generando conflictos de código que vas a tener que resolver tú igual.
Qué es exactamente Manager View
En el Editor View trabajas con un agente como si fuera un copiloto dentro de tu IDE: le pides algo, revisa el código, hace el cambio. Manager View cambia la unidad de trabajo: ya no le das tareas a un agente, le das tareas a varios agentes a la vez, cada uno con su propio contexto y su propia rama de trabajo, y tu rol pasa de "programar junto al agente" a "revisar y aprobar lo que cada agente entregó".
Es el mismo cambio de mentalidad que pasar de programar solo a liderar un equipo pequeño: ya no escribes cada línea, decides qué se hace, en qué orden, y revisas el resultado antes de integrarlo.
Cuándo sí conviene paralelizar
- ▸Tareas independientes de verdad — un agente arma el frontend de una pantalla, otro escribe tests de una función que no toca esa pantalla
- ▸Trabajo repetitivo en paralelo — documentar cinco endpoints distintos, cada uno con su propio agente, en vez de hacerlo uno por uno
- ▸Exploración de alternativas — dos agentes probando dos enfoques distintos para el mismo problema, para comparar resultados antes de decidir cuál integrar
En nuestro curso armamos el CineSwipe (el proyecto capstone) justo así: la sesión 4 enseña Manager View con tareas que de verdad son independientes entre sí, no como ejercicio forzado para "usar la función nueva".
Cuándo NO conviene (y te va a costar tiempo igual)
Si dos agentes tocan el mismo archivo o dependen del resultado uno del otro, paralelizar no te ahorra tiempo: te lo quita. Terminas con dos versiones del mismo componente que hay que fusionar a mano, exactamente el mismo problema de merge conflicts que tienen dos programadores humanos trabajando sobre el mismo módulo sin coordinarse. La regla simple: si tendrías que avisarle a un compañero humano "oye, no toques ese archivo que yo ya estoy en eso", no se lo des a dos agentes en paralelo tampoco.
Más agentes en paralelo no es más velocidad automática. Es más velocidad solo cuando las tareas de verdad no dependen entre sí — si no, es más trabajo de revisión después.
Cómo lo vemos en el curso
El curso de Antigravity For Developers son 8 sesiones (22 horas) que van de menos a más: primero el setup con Gemini y tu primer agente, Editor View para vibe coding, Artifacts para versionar lo que el agente genera, y recién en la sesión 4 entra Manager View con orquestación en paralelo. Las sesiones 6 y 7 son el capstone completo (CineSwipe) integrando APIs REST y MCP, y la sesión 8 cierra con DevOps, seguridad y despliegue — porque un agente que genera código sin control de versiones ni revisión de seguridad es un riesgo, no una ventaja. Cuesta 149 USD.
Ese orden no es casualidad: si te dan Manager View en la primera clase sin haber entendido cómo revisa y versiona el trabajo un solo agente, vas a aprobar cambios de varios agentes a la vez sin realmente poder auditar qué hizo cada uno — y ahí es donde entran bugs silenciosos que nadie detecta hasta producción.
El siguiente nivel: arquitectura de agentes, no solo herramienta
Antigravity te da la orquestación dentro del IDE, pero diseñar sistemas donde varios agentes especializados colaboran en producción — con memoria compartida, manejo de errores entre agentes y costos controlados — es una disciplina más amplia que trasciende una sola herramienta. Si ese es tu objetivo de fondo, la ruta de AI Agentic Engineer cubre esa arquitectura a fondo, con LangGraph y CrewAI además de las herramientas tipo Antigravity.
Si tu interés es más amplio que una herramienta puntual y quieres el panorama completo de cómo integrar IA en el desarrollo de software día a día, la ruta de AI Engineer es el punto de partida antes de especializarte en agentes.
Un detalle que ahorra horas de revisión
Antes de lanzar varios agentes en paralelo sobre un proyecto real, divide el trabajo por capas en vez de por pantallas: un agente para la capa de datos, otro para la lógica de negocio, otro para la interfaz. Dividir por pantalla suena intuitivo pero casi siempre dos pantallas distintas terminan tocando el mismo servicio o el mismo modelo de datos, y ahí aparece el conflicto que querías evitar. Dividir por capa reduce las zonas de choque porque cada agente se queda dentro de su propio límite técnico.
Y revisa cada entrega de un agente como revisarías un pull request de un compañero nuevo en el equipo: con el mismo nivel de atención, ni más confianza porque "lo hizo la IA" ni más desconfianza porque "es un agente". El código que importa es el que termina en producción, no quién lo escribió primero.
