Google Jules cierra: cómo exportar tu trabajo y migrar

Cierre de Google Jules: las fechas que afectan a tu trabajo

Google Jules, el agente de programación de Google que trabaja en segundo plano, pasará a modo de solo lectura después del 11 de noviembre, antes de su cierre definitivo. El aviso de cierre de Jules de Google está fechado el 29 de octubre de 2026.

El aviso no concreta la hora de corte, la zona horaria, un plazo específico para la API, una fecha límite para las licencias, fechas de facturación o reembolso ni un calendario de conservación de datos tras el cierre. Son preguntas sin respuesta; no se pueden deducir esas fechas a partir de la tabla.

Si tienes una corrección a medias, lo urgente es decidir si la terminas en Jules o llevas el parche y los requisitos pendientes a una nueva tarea. Si diriges un equipo de ingeniería, toca localizar las dependencias que suelen quedar fuera de una revisión de código: prompts recurrentes, pasos de preparación del entorno, permisos de los repositorios y credenciales.

Si Jules ejecuta tareas para ti, actúa ya. Los equipos que ya han integrado todos sus cambios y no necesitan conservar registros de Jules tienen menos trabajo que trasladar. Quienes estén evaluando agentes y no tengan tareas previas en Jules pueden saltarse la exportación y pasar directamente a elegir dónde ejecutarán el trabajo, como se explica más adelante. Es razonable tomarse tiempo para elegir un proveedor a largo plazo; guardar el trabajo no debería esperar.

Guarda el trabajo que no está en tu repositorio Git

El código, las ramas y las pull requests que ya están en GitHub seguirán allí. La exportación de Google abarca lo que guarda Jules: ajustes, variables de entorno, programaciones de tareas, conexiones con repositorios, memorias, scripts de preparación y, de cada sesión, prompts, planes, registros y parches. Consulta las instrucciones oficiales de exportación.

Una pull request, o PR, es una propuesta de cambio en el código. Puede conservar el parche sin explicar por qué el agente eligió esa solución. Un script de preparación podría contener la instalación del paquete que faltaba para que pasaran las pruebas; una memoria podría explicar por qué se descartó una refactorización que parecía prometedora. Revisa ese material antes de convertirlo en instrucciones para otro agente.

Conserva la exportación como archivo y prepara después un paquete de información más pequeño para cada tarea pendiente. Incluye el repositorio y la rama, el cambio que buscas, lo que ya está hecho, los criterios de aceptación que faltan por cumplir y el comando que permite comprobar el resultado. Enlaza los registros de apoyo en lugar de pegar una conversación entera en un nuevo prompt.

Por ejemplo, para actualizar una dependencia no basta con pedir «termina la actualización». Deja constancia del problema de compatibilidad que sigue pendiente, los archivos modificados y la prueba que reproduce el fallo. Así, el siguiente agente recibe una tarea bien delimitada y quien la revisa tiene un criterio para rechazar un resultado incompleto.

Exporta con el procedimiento publicado por Google

El procedimiento de Google utiliza Jules Tools y el prompt de exportación que proporciona la empresa. Instala la herramienta e inicia sesión:

npm install -g @google/jules
jules login

Desde tu directorio de usuario, abre un agente de programación de línea de comandos y pega la versión completa del prompt del aviso. Conecta primero GitHub para incluir los datos de los repositorios. Los archivos se guardan en ~/jules-export; mantenlos privados porque env-variables.json contiene los valores de las credenciales. Los registros de cada sesión incluyen summary.md, registros de actividad y diferencias de código.

Que aparezca un mensaje de finalización no demuestra que la exportación esté completa. Al revisar el exportador publicado por Google se observa que su contador de sesiones cuenta las sesiones enumeradas, incluso cuando falla la descarga de los detalles de alguna de ellas. Los errores se notifican por separado. Además, recupera los comandos de preparación a partir de las salidas de las sesiones, así que conviene revisar qué se ha guardado realmente antes de dar por hecho que un repositorio se puede trasladar. Esta observación procede de la lectura del script publicado; no se ejecutó ninguna exportación para este artículo.

La diferencia importa a quien deba aprobar la migración. «El comando terminó» demuestra menos que «tenemos el parche, la configuración y el contexto necesarios para la tarea». Si falta un registro importante, recupéralo mientras aún tengas acceso, en vez de encargar al siguiente agente que reconstruya lo que falta.

¿Qué pasará con el historial y la API de Jules?

Guarda el historial en local y elimina la dependencia de Jules en tus automatizaciones. El aviso de cierre no promete una importación automática del historial a otro agente ni la continuidad de la API tras el cierre.

La documentación pública de la API de Jules describe las sesiones y sus actividades, como crear tareas, aprobar planes y enviar mensajes. Son dependencias para ejecutar el trabajo: un bot que crea sesiones a partir de incidencias necesita una alternativa aunque nadie del equipo abra la web de Jules.

Haz un inventario de los scripts, archivos de flujos de trabajo e integraciones que llaman a Jules. Anota qué reciben como entrada, qué señal esperan para dar el trabajo por terminado y dónde guardan los resultados. Cambiar solo el prompt no basta si la integración sigue esperando un identificador de sesión de Jules o consultando sus actividades para detectar cuándo termina una tarea.

Que la guía de inicio rápido de la API siga publicada no significa que se haya ampliado la vida del servicio. Mientras no exista un calendario específico para sus endpoints, usa el calendario del servicio para planificar la migración y traslada la creación de tareas antes del paso a solo lectura. Esta es una recomendación operativa, no una nueva fecha para la API anunciada por Google.

En cuanto al historial, conservarlo no equivale a poder reanudar una sesión. Un plan guardado ayuda a otro agente a entender la tarea, pero no recrea el entorno en el que trabajaba el anterior. Termina el trabajo o déjalo en un punto de control documentado para que otro desarrollador pueda reproducir el siguiente paso sin abrir Jules.

¿Qué llegará a Antigravity y qué ofrece ya?

Google afirma que está trasladando lo aprendido con Jules a Antigravity, su plataforma de desarrollo con agentes. El anuncio oficial de Jules indica que Google trabaja para combinar la ejecución autónoma remota en segundo plano con el entorno de desarrollo de Antigravity. No da una fecha para la llegada de esa combinación.

El producto disponible ya permite realizar trabajo útil en segundo plano. La Antigravity App gestiona agentes en paralelo, agrupa el trabajo en Projects y ejecuta tareas programadas. La documentación de Remote Control de Google describe el acceso desde el navegador a sesiones que se ejecutan en tus portátiles, equipos de escritorio o servidores.

La diferencia está en quién pone la máquina. Remote Control permite acceder a un equipo que ya existe. Por sí solo, no demuestra que Google haya habilitado una alternativa a Jules alojada en su infraestructura. Un equipo que quiera ejecutar mantenimiento durante la noche debe saber qué máquina seguirá encendida, quién mantendrá sus dependencias y qué ocurrirá si deja de estar disponible.

Cómo migrar: abre el repositorio en Antigravity, reconstruye la configuración y las instrucciones necesarias y ejecuta una tarea pequeña con una prueba clara. Si vas a depender del acceso remoto, comprueba la máquina de destino y su disponibilidad. Añade la programación recurrente cuando ese flujo de trabajo haya pasado la revisión.

Elige Antigravity si quieres su entorno de desarrollo y puedes hacerte cargo de la máquina que ejecuta las tareas. Si necesitas que el desarrollador pueda cerrar el portátil sin que nadie tenga que mantener otra máquina, evalúa ya una opción alojada por el proveedor, en lugar de hacer depender la transición de una función sin fecha.

Consulta los precios de Antigravity para decidir sobre acceso y cuotas, y la comparativa Google Antigravity vs Cursor para resolver otra cuestión: qué entorno encaja mejor con tu trabajo diario de desarrollo.

Traslada las tareas en segundo plano a un entorno que puedas gestionar

Elige el entorno de ejecución antes de fijarte en cómo redacta el agente. Ese entorno es el conjunto de máquina y software que ejecuta la tarea. Para esta migración, lo que interesa comparar es si lo administras tú, si lo aloja el proveedor o si tus automatizaciones lo utilizan a través de GitHub Actions.

Las siguientes opciones se basan en la documentación actual de los proveedores. Son puntos de partida para migrar; no implican que las herramientas tengan las mismas funciones ni que compartan un formato de importación con Jules.

Tareas en OpenAI Codex Cloud: ejecución alojada y configuración reutilizable

OpenAI Codex Cloud es un agente de programación alojado por el proveedor que puede seguir trabajando mientras tu equipo está en suspensión. Cada tarea dispone de su propio espacio de trabajo, y puedes revisar los cambios y los resultados de las pruebas antes de hacer un commit o abrir una PR. La guía oficial de Codex Cloud describe el proceso de configuración actual.

Cómo migrar: en ChatGPT, selecciona Work in > Cloud y crea o elige un entorno. Conecta los repositorios de GitHub, deja que Codex prepare el proyecto, revisa sus comprobaciones de configuración y publica el entorno. Inicia una tarea bien delimitada con el material de Jules que hayas revisado y depurado; después, examina los cambios y los resultados de las pruebas.

El obstáculo está en los recursos a los que puede acceder el entorno. Que una prueba pase en local dice poco si la tarea en la nube no puede acceder al registro de paquetes o a un servicio necesario. Añade los destinos de red y las credenciales necesarios en los ajustes del entorno, y comprueba allí la misma prueba.

Elige Codex si tu principal necesidad es una cola de tareas alojada por el proveedor con una configuración de proyecto reutilizable. Para el primer ensayo, escoge una tarea cuyo resultado puedas evaluar rápidamente, en lugar de una reescritura sin límites claros. La comparativa entre Codex y Claude Code analiza la elección del flujo de trabajo más allá de este cierre.

Claude Code: sesiones en la nube o automatización del repositorio

Claude Code, de Anthropic, ofrece sesiones en la nube que siguen ejecutándose cuando cierras el portátil, además de una integración independiente con GitHub Actions para automatizar flujos de trabajo del repositorio. La vía adecuada depende de si necesitas sustituir la asignación interactiva de una tarea o un mecanismo que la inicia automáticamente.

Para sesiones en la nube: conecta el repositorio, configura la preparación del entorno en la nube, el acceso a la red y las variables, e inicia una tarea de alcance definido. Desde una terminal de Claude Code con la sesión iniciada, claude --cloud pone en marcha el trabajo en la nube. Si utilizas el procedimiento habitual de clonación desde GitHub, sube primero la rama para que la sesión reciba los commits correctos. Consulta la guía de sesiones en la nube de Claude.

Aquí los límites son la capacidad compartida y el acceso: las sesiones en la nube consumen la cuota de uso de Claude de la cuenta, y los permisos de la organización pueden restringirlas. Que a un ingeniero le funcione su configuración personal no demuestra que la cuenta de la empresa pueda ejecutar la misma carga de trabajo.

Para GitHub Actions: un administrador del repositorio puede ejecutar /install-github-app en Claude Code, seguir la configuración de autenticación y revisar la PR generada con el flujo de trabajo. Empieza con una petición explícita a @claude y añade después la tarea recurrente o activada por eventos que quieres sustituir. Anthropic detalla los requisitos de la aplicación, las credenciales y el flujo de trabajo en su guía de GitHub Actions.

El obstáculo en este caso es quién se hace responsable del flujo de trabajo. Alguien debe mantener los disparadores, las credenciales y los permisos, y distinguir un fallo de configuración de un fallo en la tarea de programación. Elige Actions cuando un evento del repositorio sea el punto de partida natural. Nuestra guía de Claude Code con GitHub Actions explica ese modelo de funcionamiento.

Agente de programación de GitHub Copilot: gestiona la tarea desde GitHub

El agente de programación de GitHub Copilot implementa cambios y ejecuta pruebas en segundo plano dentro del flujo de trabajo de GitHub. Su documentación actual distingue entre entornos aislados en la nube y entornos de GitHub Actions, así que comprueba cuál se ha seleccionado para la tarea. Consulta Copilot en GitHub.

Cómo migrar: confirma que el plan y las políticas de la organización permiten el acceso, selecciona el repositorio y la rama, y asigna a Copilot una tarea con criterios de aceptación y una petición de PR. Antes de integrar el cambio, revisa lo que propone y las pruebas que aporta. Conserva la descripción de la incidencia del inventario de Jules para poder comprobar si la alternativa ha cumplido lo solicitado.

Los límites dependen del entorno de ejecución: las sesiones de GitHub Actions modifican un solo repositorio, mientras que las sesiones en entornos aislados en la nube pueden abarcar varios. Ambas trabajan en una sola rama y abren una sola PR por tarea. Si la migración exige cambios coordinados entre ramas, divídela en trabajos que puedan revisarse por separado.

Elige Copilot si ya gestionas la cola de revisiones y la asignación de responsables en GitHub. Así, el traspaso del trabajo queda junto a la incidencia y la PR, aunque sigue siendo necesario reconstruir el entorno y las instrucciones que antes guardaba Jules.

La promesa exagerada: exportar no es migrar automáticamente

El atajo engañoso consiste en interpretar «Jules se traslada a Antigravity» como un plan de transferencia de cuentas. Los anuncios de Google hablan de la dirección del producto y de una exportación de datos. No prometen que tus sesiones activas, tareas programadas o memorias aparezcan listas para funcionar en una herramienta sustituta.

Otro atajo es tomar el acceso desde el navegador como prueba de que la ejecución ocurre en la nube. Un navegador puede controlar tanto una máquina que administras tú como otra alojada por un proveedor. Las interfaces pueden parecerse aunque la responsabilidad de mantener el trabajo en marcha sea distinta.

Aplica un criterio de aceptación práctico: la alternativa debe reproducir la configuración necesaria, completar una tarea bien delimitada, mostrar sus comprobaciones y entregar un cambio que se pueda revisar. No la elijas solo porque reconoce el mismo repositorio o propone un plan creíble. Un plan aporta indicios de que ha entendido la tarea; un flujo de trabajo que funciona demuestra que la migración funciona.

Para quien dirige un equipo de ingeniería, esto acota la decisión. No hace falta resolver todas las preferencias futuras sobre herramientas de programación antes del cierre. Hace falta una vía comprobada para las tareas que, de otro modo, dejarían de ejecutarse, con una persona responsable que sepa diagnosticar los fallos.

Lista de tareas para esta semana

La prioridad es conseguir que funcione una primera alternativa y extenderla después al resto del trabajo pendiente.

• Inventario: enumera los repositorios de Jules, las sesiones sin terminar, las tareas recurrentes y los sistemas que llaman a su API. Asigna un responsable y un destino a cada trabajo que deba continuar.
• Conservación: ejecuta el procedimiento de exportación de Google, revisa los errores y los archivos importantes, y guarda la exportación original en privado.
• Finalización o punto de control: revisa los parches pendientes y deja cada tarea que vaya a continuar con una rama, un requisito y una prueba que se entiendan.
• Reconstrucción: configura las dependencias, las instrucciones, el acceso a la red y las credenciales del entorno elegido. No incluyas valores secretos en las notas habituales de las tareas.
• Validación: lleva una tarea pequeña por todas las etapas: preparación, implementación, pruebas y revisión humana. Comprueba también qué ocurre cuando algo falla, además de revisar la PR que sale bien.
• Transición: traslada los disparadores recurrentes solo cuando la alternativa funcione. Evita los envíos duplicados y retira los accesos obsoletos cuando ya no sean necesarios.

El lunes, empieza por elegir un repositorio activo, exportar su contexto de Jules y completar una tarea pequeña con la alternativa, incluida su revisión. Así tendrás un procedimiento de migración que podrás repetir antes de que el servicio deje de aceptar trabajo.

Suscríbete al boletín para recibir guías prácticas sobre los cambios en las herramientas de desarrollo.