El agente que se revisa a sí mismo: qué hace de verdad /boost en Antigravity

Hay una idea que se repite en cada demo de agente: el agente dice que ha terminado y tú le crees. El vídeo que analizamos hoy vale precisamente por lo contrario: un agente al que le piden construir un juego, una revisión independiente encuentra dos fallos que el «todo funciona» escondía, y el asunto acaba con siete tests en verde y 600 laberintos jugados. La lección no es la herramienta. Es cómo se le encarga el trabajo.

Primero, una distinción que casi todo el mundo mezcla

En el vídeo de AICodeKing conviven dos cosas distintas y conviene separarlas desde el principio:

Gemini 3.8 Flash es el modelo. Llegó a Google Antigravity a principios de septiembre de 2026 y permite ajustar el esfuerzo de razonamiento: bajo para lo que necesita latencia, medio por defecto (el recomendado para código y agentes) y alto para razonamiento profundo y matemáticas.
Boost es el flujo de trabajo. Se pide escribiendo /boost al principio del mensaje, con el modelo que tengas seleccionado debajo de la caja de texto.

Qué hace y por qué tiene tres fases

Según la documentación de Google, /boost monta un pipeline de razonamiento multiagente con tres fases:

Un orquestador inspecciona el contexto del proyecto, decide la estrategia y trocea el problema en subtareas que se puedan verificar por separado.
Subagentes especializados trabajan en ámbitos aislados: unos de implementación (escriben código, refactorizan, generan tests) y otros de investigación (depuran la causa raíz, trazan grafos de llamadas, analizan dependencias sin tocar ficheros). Cada worker ejecuta el build y las suites de tests en local antes de reportar.
La verificación agrega los resultados, pasa comprobaciones de regresión y, si falla una aserción, devuelve el diagnóstico al bucle para que se corrija.

Tres detalles de control que importan más de lo que parece: los subagentes heredan permisos acotados (las reglas de ficheros y de comandos del proyecto, nunca más derechos de los necesarios), cualquier comando protegido sube a la interfaz para que lo apruebes, y cada subagente corre en un contexto aislado, de forma que sus logs y sus diffs de borrador no ensucian la conversación principal.

Y un requisito que el titular del vídeo se salta: /boost es de plan de pago, tanto en Antigravity 2.0 como en la CLI.

El encargo y lo que apareció

El experimento es un juego: un laberinto con generación procedural, tablero editable, una llave que abre la salida y un solucionador animado. Simple de describir y difícil de terminar bien, que es exactamente lo que lo hace un buen test. El autor pidió el juego y los tests de las partes que podían romperse.

Lo que se ve funcionando: tablero isométrico, tres tamaños, una semilla para reproducir un laberinto concreto (con la semilla 42 y dificultad fácil, la ruta se resuelve en 40 movimientos), un botón que dibuja el camino guía teniendo en cuenta la llave, y un editor de muros en el que taponar el corredor de entrada cambia el estado a sin salida y reabrirlo lo devuelve a resoluble.

Hasta aquí, la demo bonita. Lo interesante es lo que salió en la revisión independiente:

Generar un laberinto nuevo podía tumbar las suscripciones a eventos que mantienen la interfaz actualizada.
Un fallo de validación de movimiento permitía, llamando al motor directamente, saltar coordenadas grandes a través de un muro.

Ninguno de los dos se veía jugando. Ambos se devolvieron al agente, que arregló el motor y añadió tests de regresión para los dos casos. La suite final: siete tests en verde, incluido un lote de 100 laberintos generados, comprobaciones de colisión, el requisito de la llave, rejillas editadas bloqueadas y el estado de reinicio del solucionador. Una revisión aparte jugó y resolvió 600 laberintos en los tres tamaños.

Es decir: el valor no estuvo en que el agente escribiera un juego. Estuvo en que hubo algo que comprobó el trabajo y encontró lo que el «ya está terminado» tapaba.

La parte que te llevas a tu propio proyecto

El propio autor lo dice sin adornos: lo útil es darle al agente un resultado concreto y una definición clara de qué significa que funcione. En su caso, eso fue enumerar los casos de fallo antes de empezar: movimiento bloqueado, llave ausente, caminos inalcanzables y reiniciar mientras el solucionador está corriendo.

La traducción a otros encargos es directa:

Una interfaz de reservas: describe qué debe pasar cuando un hueco deja de estar disponible a mitad de la reserva.
Un importador de datos: incluye un fichero vacío y una fila rota entre los casos de prueba.
Cualquier pantalla con formulario: doble envío, campos vacíos, volver atrás después de enviar.

Y una regla que no caduca: inspecciona el resultado tú mismo. En el vídeo, el autor cambia la semilla, cambia la dificultad, prueba una colisión contra un muro, completa un laberinto y comprueba la reproducción y los controles del camino. No se apoya en que el agente diga que todo funciona.

La letra pequeña, que el titular no cuenta

Conviene leer esta parte antes de hacerse ilusiones:

El título promete «totalmente gratis» y «mejora a Astra». En el propio vídeo se corrige: /boost exige plan de pago, y su autor afirma que no puede sostener que Boost gane a Flash normal en todas las tareas — eso pediría comparaciones repetidas con los mismos prompts y las mismas condiciones.
No hay multiplicador de coste medido. El autor lo dice explícitamente: no lo ha medido y su demo no sirve para establecerlo.
En la prueba, Boost no apareció en el autocompletado, así que el resultado no se puede atribuir en exclusiva al pipeline de Boost.
Es una demo, no un benchmark independiente.

Y el dato de coste que sí conviene interiorizar: Gemini 3.8 Flash cuesta $0,75 por millón de tokens de entrada y $3,75 por millón de salida, pero el modelo gasta más tokens a propósito en tareas difíciles — da pasos de razonamiento más pequeños, llama herramientas de forma iterativa y verifica sobre la marcha. Como resume el autor: un precio bajo por token no te dice el coste total de terminar un proyecto. Dentro de Antigravity, además, lo que manda es tu plan, tu cuota restante y tus ajustes de crédito.

Practícalo en Codeia

Este vídeo es, en el fondo, una clase de ingeniería de contexto: qué le pides al agente, con qué criterio decides que ha terminado y quién verifica. En los cursos de Codeia trabajamos con agentes reales y con esa misma pregunta encima de la mesa, y en la comunidad puedes contar cómo te va cuando le pides a un agente que se revise a sí mismo.