Cuando una herramienta promete trabajar durante horas, la primera pregunta es qué tendrá que entregar al terminar. Un repositorio, un informe y una demostración pueden parecer resultados completos y seguir dejando dudas importantes. Antes de ceder más autonomía, necesitas una forma de aceptar o rechazar el trabajo.
Google presenta Antigravity como una plataforma de desarrollo con agentes. Aquí analizamos su propuesta a partir de documentación oficial consultada el 7 de septiembre de 2026. No hemos realizado una prueba propia de Antigravity ni medido cuánto tiempo ahorra en un proyecto de LetBrand.
Una tarea pequeña antes de una migración grande
Para conocer el entorno, elige una copia de un proyecto sencillo. Un primer encargo podría ser añadir un filtro a una tabla ya existente, conservando la ordenación y el estado vacío. El objetivo es ver el ciclo de trabajo: qué pregunta, qué cambia, qué ejecuta y qué entrega para revisión.
Define también lo que no forma parte del encargo. Si solo quieres el filtro, no hace falta rediseñar toda la página. Un resultado más amplio puede ser peor si obliga a revisar cambios que nadie necesitaba.
Abre los archivos y reproduce el comportamiento. Guarda el estado inicial y el diff final. Esta prueba no exige un gran benchmark: exige que tú puedas reconocer cuándo está terminada.
Qué añade Teamwork
La documentación de Teamwork describe un trabajo coordinado entre agentes para problemas extensos. Primero se concreta el objetivo y sus criterios de aceptación; después se organiza la ejecución y la verificación.
La distinción práctica es el tamaño del problema. Una tarea acotada puede resolverse con un ciclo corto de edición y comprobación. Una migración con varios componentes necesita además coordinar dependencias: quién cambia una interfaz, quién adapta sus consumidores y cómo se comprueba el conjunto.
Antes de usar un equipo de agentes, escribe esas dependencias. Si no puedes explicar qué piezas pueden avanzar por separado, aumentar el número de agentes puede añadir trabajo de integración. Esta es una recomendación de método, no una medición del rendimiento de Teamwork.
Leer los anuncios con sus límites
En su actualización del 27 de agosto, muestra aplicaciones de Teamwork en investigación e ingeniería. Son ejemplos comunicados por el proveedor; no prueban que cualquier proyecto vaya a obtener resultados parecidos.
Para evaluar un caso publicado, pregunta qué se comprobó, contra qué referencia y con qué condiciones. Que un sistema termine una demostración concreta no responde por sí solo a cuánto costará mantener tu aplicación ni a cuánto tendrás que revisar tú.
La disponibilidad también cambia. La documentación consultada y el anuncio reciente sitúan Teamwork en planes de pago, mientras que materiales anteriores lo limitaban a Ultra. Comprueba el acceso real de tu cuenta antes de organizar trabajo dependiente de esa función. No fijamos aquí una cuota universal ni una tarifa de tu región.
Qué revisar durante el primer encargo
Conserva una lista corta de comprobaciones: la función satisface el encargo; los cambios ajenos están explicados; puedes ejecutar las pruebas; los datos de ejemplo no contienen información privada; y sabes recuperar el estado anterior.
Pide que el resultado distinga entre pruebas ejecutadas, comprobaciones pendientes y decisiones que tomó por su cuenta. «Todo correcto» no es suficiente si no puedes localizar la evidencia que lo sostiene.
En una interfaz, comprueba también el resultado en el navegador. En una refactorización, compara el comportamiento anterior y posterior. En un informe, abre las fuentes importantes. La herramienta puede ayudar a producir evidencia, pero el tipo de evidencia depende de lo que estés encargando.
Cuándo merece una evaluación más larga
Seguiría probándolo si el primer encargo deja cambios comprensibles y fáciles de verificar. Ampliaría el alcance poco a poco, conservando los mismos criterios. Si el principal problema es que falta información sobre el proyecto, prepararía esa información antes de atribuir el fallo al modelo.
Si estás valorando otros entornos de programación, aplica también los criterios de nuestra comparación de Claude Code y Codex.
Coordinar agentes no implica que se estén mejorando a sí mismos. Explicamos esa diferencia en qué es la automejora recursiva.
Nuestra guía de skills para agentes ayuda a separar instrucciones reutilizables de herramientas. Si quieres definir una prueba limitada para tu equipo, puedes explicarnos qué proyecto tienes.
