Google ha añadido un nuevo comando a su entorno de desarrollo Antigravity llamado /boost. Al invocarlo se inicia un flujo de razonamiento multiagente en lugar de un único asistente de programación: un orquestador lee el problema y lo divide en tareas, las reparte entre agentes especializados que trabajan en ámbitos aislados y después somete el resultado a rondas de verificación independientes que realmente ejecutan las pruebas antes de que nada llegue a usted. La noticia no es que la IA escriba código más rápido. Es que las herramientas de programación han empezado a integrar la verificación en la propia herramienta.

Qué anunció Google exactamente

Según la documentación oficial de Antigravity, /boost está diseñado específicamente para la ingeniería de software difícil: errores de concurrencia y condiciones de carrera, optimización algorítmica, regresiones sutiles que aparecen y desaparecen, y refactorizaciones intrincadas que abarcan varios archivos. Son exactamente los problemas en los que fracasa un asistente convencional de un solo turno, porque resolverlos requiere experimentar y dar marcha atrás en lugar de generar directamente.

El comando se ejecuta en tres fases claras:

  • Planificación: un orquestador principal recibe su prompt, examina el contexto del espacio de trabajo, formula una estrategia de ejecución y descompone el reto en subtareas discretas y verificables.
  • Ejecución distribuida: el orquestador reparte esas subtareas entre agentes especializados. Las líneas de trabajo de implementación escriben código y pruebas unitarias. Las líneas de trabajo de investigación realizan depuración de causa raíz y rastrean grafos de llamadas sin modificar ningún archivo. Los agentes de verificación local ejecutan objetivos de compilación y conjuntos de pruebas para validar hipótesis antes de informar.
  • Verificación antes de la entrega: el orquestador agrega los hallazgos y ejecuta controles de regresión contra los conjuntos de pruebas completos y los casos límite. Si una aserción falla, el diagnóstico del error alimenta la siguiente iteración para su corrección automática, y usted solo recibe un resumen de los cambios verificados cuando todo pasa.

Todo ello se ejecuta dentro de worktrees efímeros y aislados, lo que significa que los agentes no experimentan sobre su copia de trabajo del proyecto.

Tres modos, no uno

Google documenta tres modos de ejecución distintos, y la diferencia entre ellos es la parte útil en la práctica:

  • Agente predeterminado: programación interactiva, navegación por el código y refactorización general. Horizonte de tarea de segundos a minutos, un bucle de un solo agente, verificación de una sola pasada. Disponible en todos los planes.
  • /boost: razonamiento profundo y errores persistentes. Horizonte de tarea de segundos a horas, una jerarquía de tres fases, verificación independiente de varias rondas. Disponible en los planes de pago.
  • /teamwork-preview: equipos de agentes que trabajan durante días en grandes migraciones o en la construcción de subsistemas completos, con roles definidos como Explorer, Worker, Critic y Auditor, además de puertas de verificación que intentan romper el código deliberadamente antes de aprobar un hito.

Fíjese en la gradación: cuanto mayor es la tarea, más inversión se destina a la revisión y no a la velocidad. Es una señal a la que merece la pena prestar atención para cualquiera que dirija un proyecto de software.

Por qué esto importa a un empresario, no solo a un desarrollador

Durante los últimos dos años, la conversación sobre la IA en la programación ha sido una conversación sobre velocidad: cuántas líneas se generan por minuto. El problema es que la velocidad no es el cuello de botella en los proyectos reales. Lo es la confianza. ¿Funciona realmente este código en los casos que nadie probó?

Lo que la arquitectura de /boost dice implícitamente es que la industria llegó a la misma conclusión. Un código que llega más rápido no vale nada si cuesta dos semanas de depuración después de la entrega. Por eso la herramienta se construye en torno a tres reglas que se aplican a cualquier equipo técnico, con o sin IA:

  • El autor no califica su propio trabajo: quien verifica es distinto de quien implementó. Ese ha sido el principio de la revisión de código durante décadas. Ahora se impone dentro de la herramienta.
  • La evidencia es ejecución, no afirmación: las pruebas se ejecutan de verdad y se comprueba su salida real, en lugar de aceptar la afirmación de que pasaron.
  • El aislamiento protege el original: la experimentación ocurre en una copia separada, de modo que los intentos fallidos nunca se filtran al proyecto.

Si usted contrata desarrollo de software, esas son precisamente las tres preguntas que debe hacer a su proveedor: quién lo revisa, cuál es la evidencia de que las pruebas pasaron y dónde se produce la experimentación.

Lo que no cambia

Es fácil leer una noticia así como el anuncio de que ya no se necesitan ingenieros. La documentación dice lo contrario con bastante claridad: los agentes heredan las reglas de acceso a archivos y las políticas de permisos de comandos configuradas para su espacio de trabajo, y cualquier comando protegido o edición fuera de los ámbitos de confianza lanza una solicitud de autorización al usuario. Hay un humano responsable al final de la cadena.

Y los permisos son la mitad menor del asunto. Un agente resuelve el problema que usted describió. No puede saber que la propia descripción era errónea. No sabe que su ciclo de facturación cierra el día 25 y no el 30, que este campo nunca debe ser visible para un comercial, ni que cuando su cliente dice "pedido" se refiere a algo distinto de lo que usted entiende. Definir los requisitos, comprender el dominio y asumir la decisión siguen siendo un trabajo enteramente humano.

Cómo lo vemos en Origami

Tratamos las herramientas multiagente como tratamos cualquier herramienta de productividad: aceleran la ejecución, no transfieren la responsabilidad. Un proyecto aquí sigue pasando por especificaciones escritas, revisión humana, un conjunto de pruebas y un entorno de staging antes de producción, tanto si el código lo escribió una persona como si lo generó un agente. Una herramienta que ejecuta sus propias pruebas es una incorporación bienvenida a esa cadena, pero es un eslabón de ella, no su sustituto.

La conclusión práctica para un empresario: espere que los plazos de entrega se acorten específicamente en el trabajo complejo, pero no acepte una entrega sin pruebas, sin documentación y sin un responsable humano. Las herramientas que se revisan a sí mismas elevan el techo de la calidad alcanzable. No eliminan su necesidad de alguien que garantice que lo construido es lo que usted pidió.

Fuentes