Jules Google vai acabar: salve seu trabalho e migre

Jules Google: quais datas mudam sua rotina?

O Google Jules, agente de programação do Google que trabalha em segundo plano, entra em modo somente leitura após 11 de novembro, antes do encerramento definitivo. O aviso de encerramento do Jules publicado pelo Google tem data de 29 de outubro de 2026.

O aviso não informa horário de corte, fuso horário, prazo específico para a API ou para licenças, data de cobrança ou reembolso, nem cronograma de retenção de dados após o encerramento. Esses pontos continuam sem resposta; não é possível deduzi-los a partir da tabela.

Para quem tem uma correção em andamento, a decisão imediata é terminar no Jules ou levar o patch e os requisitos pendentes para uma nova tarefa. Para a liderança de engenharia, o desafio é identificar dependências que não aparecem em uma revisão de código comum: prompts recorrentes, etapas de preparação do ambiente, permissões de repositório e credenciais.

Se o Jules executa tarefas para você, aja agora. Equipes cujas alterações concluídas já foram integradas e que não precisam de registros armazenados no Jules têm menos coisas para transferir. Quem está avaliando agentes e não tem trabalho no Jules pode pular a exportação e começar pela escolha do ambiente de execução, mais adiante. Faz sentido esperar para escolher um fornecedor de longo prazo; adiar a preservação do trabalho, não.

Salve o que ficou fora do repositório Git

O código, as branches e os pull requests que já estão no GitHub continuam lá. A exportação do Google abrange configurações, variáveis de ambiente, agendamentos, conexões com repositórios, memórias e scripts de preparação armazenados no Jules, além dos prompts, planos, logs e patches das sessões. Consulte as instruções oficiais de exportação.

Um pull request, ou PR, é uma proposta de alteração no código. Ele pode preservar o patch sem registrar por que o agente escolheu aquela solução. Um script de preparação pode conter a instalação de pacote que faltava para os testes passarem; uma memória pode explicar por que uma refatoração atraente foi descartada. Revise esse material antes de transformá-lo em instruções para outro agente.

Guarde a exportação como arquivo de referência e prepare um conjunto menor de informações para transferir cada tarefa pendente. Inclua o repositório e a branch, a alteração desejada, o que já foi feito, os critérios de aceitação ainda não atendidos e o comando que comprova o sucesso. Use links para os registros de apoio em vez de colar uma conversa inteira em um novo prompt.

Uma tarefa de atualização de dependências, por exemplo, precisa de mais contexto do que “termine a atualização”. Registre qual falha de compatibilidade persiste, quais arquivos mudaram e qual teste reproduz o problema. Assim, o próximo agente recebe uma tarefa bem delimitada, e quem revisa tem como rejeitar um resultado incompleto.

Siga o procedimento de exportação publicado pelo Google

O procedimento do Google usa o Jules Tools e o prompt de exportação fornecido pela empresa. Instale a ferramenta e faça a autenticação:

npm install -g @google/jules
jules login

No seu diretório pessoal, abra um agente de programação na linha de comando e cole o prompt completo disponível no aviso. Conecte o GitHub antes para acessar os dados dos repositórios. A saída é gravada em ~/jules-export; mantenha essa pasta privada, pois env-variables.json contém os valores das credenciais. Os registros de cada sessão incluem summary.md, logs de atividades e diffs.

Uma mensagem de conclusão não comprova que a exportação está completa. A leitura do exportador publicado pelo Google mostra que a contagem de sessões considera as sessões listadas, mesmo quando a busca pelos detalhes de uma delas falha. Os erros são informados separadamente. O exportador também recupera comandos de preparação a partir das saídas das sessões; por isso, confira o que foi de fato gravado antes de declarar que um repositório está pronto para funcionar em outro ambiente. Essa constatação vem da leitura do script publicado; nenhuma exportação foi executada para este artigo.

A diferença importa para quem aprova a migração. “O comando terminou” comprova menos do que “o patch, a configuração e o contexto necessários estão presentes”. Se faltar um registro importante, recupere-o enquanto ainda há acesso, em vez de deixar o próximo agente encarregado de reconstruí-lo.

O que acontece com o histórico e a API do Jules?

Salve o histórico localmente e elimine as dependências do Jules nas suas automações. O aviso de encerramento não promete importação automática do histórico em outro agente nem continuidade da API após o fim do serviço.

A documentação pública da API do Jules descreve as sessões e suas atividades, incluindo criar tarefas, aprovar planos e enviar mensagens. Essas funções são dependências de execução: um bot de issues que cria uma sessão precisa de substituição mesmo que ninguém da equipe abra o site do Jules.

Faça um inventário dos scripts, arquivos de workflow e integrações que chamam o Jules. Registre as entradas que recebem, o sinal de sucesso que aguardam e onde entregam os resultados. Uma migração que só troca o prompt ainda pode falhar porque a integração antiga espera um identificador de sessão do Jules ou consulta as atividades do serviço até detectar a conclusão.

Um guia de início rápido da API continuar publicado não significa que a vida útil do serviço foi prorrogada. Sem um cronograma específico para os endpoints, use as datas do serviço como limite de planejamento e transfira a criação de tarefas antes da entrada em modo somente leitura. Essa é uma recomendação operacional, não uma data adicional para a API anunciada pelo Google.

No caso do histórico, salvar os registros é diferente de poder retomar a execução. Um plano salvo ajuda outro agente a entender a tarefa; não recria o ambiente em que o agente anterior estava trabalhando. Conclua o trabalho ou deixe seu estado registrado de forma que outro desenvolvedor consiga reproduzir o próximo passo sem abrir o Jules.

O que vai para o Antigravity e o que já está disponível?

O Google Antigravity, plataforma de desenvolvimento com agentes do Google, é o destino que a empresa aponta para os aprendizados do Jules. O anúncio oficial do Jules diz que o Google trabalha para combinar a execução remota autônoma em segundo plano com o ambiente de desenvolvimento do Antigravity. Não há data de entrega para essa combinação.

O produto disponível já oferece recursos úteis para trabalhar em segundo plano. O Antigravity App gerencia agentes em paralelo, organiza o trabalho em Projects e executa tarefas agendadas. A documentação do Remote Control descreve o acesso pelo navegador a sessões que rodam nos seus notebooks, desktops ou servidores.

A distinção está em quem fornece o computador. O Remote Control dá acesso a uma máquina que já existe. Por si só, isso não comprova que o Google disponibilizou um substituto do Jules hospedado pela empresa. Uma equipe que quer executar manutenção durante a madrugada precisa saber qual máquina continuará ligada, quem mantém suas dependências e o que acontece se ela ficar indisponível.

Caminho de migração: abra o repositório no Antigravity, reconstrua a configuração e as instruções necessárias e execute uma tarefa pequena, com um teste claro. Se o plano depende de acesso remoto, verifique a máquina de destino e sua disponibilidade. Adicione o agendamento recorrente depois que esse fluxo passar pela revisão.

Escolha o Antigravity se quiser seu ambiente de desenvolvimento e puder operar a máquina que executa as tarefas. Se o requisito for “o desenvolvedor fecha o notebook e ninguém precisa manter outra máquina”, avalie agora uma opção hospedada, sem atrelar a mudança a um recurso ainda sem data.

Consulte os preços do Antigravity para decidir sobre acesso e cotas, e o comparativo Google Antigravity vs Cursor para avaliar qual ambiente de desenvolvimento combina com sua rotina — uma decisão separada da migração.

Alternativas ao Google Jules: escolha o ambiente de execução

Escolha o ambiente de execução antes de escolher o estilo de escrita do agente. Esse ambiente reúne o computador e o software que executam a tarefa. Nesta migração, a comparação que importa é se você opera o ambiente, se o fornecedor o hospeda ou se a sua automação o executa pelo GitHub Actions.

Os caminhos a seguir se baseiam na documentação atual dos fornecedores. São pontos de partida para a migração, sem pressupor recursos idênticos ou um formato de importação compartilhado com o Jules.

OpenAI Codex Cloud: tarefas hospedadas com configuração reutilizável

O OpenAI Codex Cloud é um agente de programação hospedado que pode continuar trabalhando enquanto seu computador está em suspensão. Cada tarefa tem seu próprio espaço de trabalho, e você pode inspecionar as alterações e os resultados dos testes antes de fazer um commit ou abrir um PR. O guia oficial do Codex Cloud descreve o fluxo atual de configuração.

Caminho de migração: no ChatGPT, escolha Work in > Cloud e crie ou selecione um ambiente. Conecte os repositórios do GitHub, deixe o Codex preparar o projeto, confira as verificações de configuração e publique o ambiente. Inicie uma tarefa bem delimitada com o material revisado que veio do Jules e, depois, analise as alterações e os resultados dos testes.

O obstáculo é o acesso aos recursos necessários. Um teste local bem-sucedido diz pouco sobre uma tarefa na nuvem que não consegue acessar seu registro de pacotes ou um serviço obrigatório. Informe os destinos de rede e as credenciais necessários nas configurações do ambiente e verifique o mesmo teste ali.

Escolha o Codex quando o principal requisito for uma fila de tarefas hospedada, com configuração de projeto reutilizável. No primeiro teste, use uma tarefa cujo resultado correto seja fácil de avaliar, em vez de uma reescrita sem escopo definido. O comparativo entre Codex e Claude Code discute a escolha de fluxo de trabalho para além deste encerramento.

Claude Code: sessões na nuvem ou automação no repositório

O Claude Code, da Anthropic, oferece sessões na nuvem que continuam rodando depois que você fecha o notebook, além de uma integração separada com o GitHub Actions para fluxos do repositório. O caminho de migração depende do que será substituído: a delegação interativa de uma tarefa ou um gatilho automatizado.

Para sessões na nuvem: conecte o repositório, configure a preparação, o acesso à rede e as variáveis do ambiente na nuvem e inicie uma tarefa com escopo definido. Em um terminal autenticado do Claude Code, claude --cloud inicia o trabalho na nuvem. No fluxo padrão de clonagem pelo GitHub, faça o push da branch antes para que a sessão receba os commits pretendidos. Consulte o guia de sessões na nuvem do Claude.

O obstáculo está nos limites de uso compartilhados e no acesso: as sessões na nuvem consomem a cota de uso do Claude da conta, e as permissões da organização podem restringi-las. O fato de a configuração pessoal de um engenheiro funcionar não comprova que a conta da empresa pode executar a mesma carga de trabalho.

Para o GitHub Actions: um administrador do repositório pode executar /install-github-app no Claude Code, seguir a configuração de autenticação e revisar o PR de workflow gerado. Comece com uma solicitação explícita a @claude e depois adicione a tarefa recorrente ou acionada por evento que está substituindo. A Anthropic documenta os requisitos de aplicativo, credenciais e workflow no guia do GitHub Actions.

Aqui, o obstáculo é definir quem cuida do workflow. Alguém precisa manter gatilhos, credenciais e permissões, além de distinguir uma falha de configuração de uma falha na tarefa de programação. Escolha o Actions quando um evento no repositório for o ponto de partida natural. Nosso guia do Claude Code com GitHub Actions detalha esse modelo de operação.

Agente de programação do GitHub Copilot: mantenha a delegação no GitHub

O agente de programação do GitHub Copilot implementa alterações e executa testes em segundo plano dentro do fluxo de trabalho do GitHub. A documentação atual distingue sandboxes na nuvem de ambientes do GitHub Actions; por isso, confira qual ambiente foi selecionado para a tarefa. Consulte a página Copilot no GitHub.

Caminho de migração: confirme o acesso pelo plano e a política da organização, selecione o repositório e a branch e passe ao Copilot uma tarefa com critérios de aceitação e um pedido de PR. Inspecione as alterações propostas e as evidências dos testes antes do merge. Reutilize a mesma descrição de issue registrada no inventário do Jules para conseguir avaliar se o substituto cumpriu o pedido.

O obstáculo depende do ambiente de execução: sessões no GitHub Actions alteram um único repositório, enquanto sessões em sandbox na nuvem podem abranger vários repositórios. Ambas trabalham em uma única branch e abrem um único PR por tarefa. Divida uma migração que exija mudanças coordenadas entre branches em partes que possam ser revisadas separadamente.

Escolha o Copilot quando sua fila de revisão e a definição dos responsáveis pelas tarefas já estiverem no GitHub. Isso mantém a transferência de trabalho perto da issue e do PR, mas ainda exige reconstruir o ambiente e as instruções que antes estavam no Jules.

Onde o discurso exagera: exportar não é migrar automaticamente

O atalho enganoso é interpretar “o Jules está indo para o Antigravity” como um plano de transferência de conta. As declarações do Google descrevem a direção do produto e uma exportação de dados. Elas não prometem que suas sessões ativas, seus agendamentos ou suas memórias vão aparecer em um substituto prontos para uso.

Outro atalho é tratar o acesso pelo navegador como prova de execução na nuvem. Um navegador pode controlar tanto uma máquina que você opera quanto uma máquina hospedada por um fornecedor. As interfaces podem parecer semelhantes, mas a responsabilidade por manter o trabalho em execução muda.

Adote um critério prático de aceitação: o substituto precisa reproduzir a configuração necessária, concluir uma tarefa bem delimitada, mostrar suas verificações e entregar uma alteração que possa ser revisada. Não o escolha apenas porque reconhece o mesmo repositório ou produz um plano plausível. Um plano ajuda a demonstrar entendimento; o fluxo funcionando comprova que a migração deu certo.

Para a liderança de engenharia, isso reduz o tamanho da decisão. Não é preciso resolver todas as preferências futuras de ferramentas de programação antes do encerramento. É preciso ter um caminho validado para as tarefas que, de outro modo, parariam, com um responsável capaz de diagnosticar falhas.

Checklist da semana

Priorize colocar o primeiro substituto em funcionamento e depois amplie o processo para o restante do backlog.

• Faça o inventário: liste repositórios do Jules, sessões pendentes, tarefas recorrentes e integrações que chamam a API. Defina um responsável e um destino para cada trabalho que vai continuar.
• Preserve: execute o procedimento de exportação do Google, confira erros e arquivos importantes e guarde o arquivo original em local privado.
• Conclua ou registre o estado atual: revise os patches pendentes e deixe cada tarefa que vai continuar com uma branch, um requisito e um teste compreensíveis.
• Reconstrua: configure dependências, instruções, acesso à rede e credenciais no ambiente de execução escolhido. Não inclua valores secretos nas anotações comuns das tarefas.
• Comprove: execute uma tarefa pequena, passando por preparação do ambiente, implementação, testes e revisão humana. Verifique também o que acontece em caso de falha, além do PR bem-sucedido.
• Faça a transição: transfira os gatilhos recorrentes só depois que o substituto funcionar. Desative envios duplicados e revogue os acessos obsoletos quando deixarem de ser necessários.

A ação para segunda-feira é escolher um repositório ativo, exportar seu contexto do Jules e levar uma tarefa pequena até a revisão em outro agente. Isso cria um modelo de migração que pode ser repetido antes de o serviço parar de aceitar trabalho.

Assine a newsletter para receber guias práticos sobre mudanças nas ferramentas de desenvolvimento.