Google Antigravity dopo Jules: esportare il lavoro e migrare

Chiusura di Google Jules: le date da tenere presenti

Google Jules, l'agente di Google che programma in background, passa in modalità di sola lettura dopo l'11 novembre, prima della dismissione definitiva. L'avviso di chiusura di Jules pubblicato da Google è datato 29 ottobre 2026.

L'avviso non specifica un'ora di interruzione, un fuso orario, una scadenza separata per le API o per le licenze, date relative a fatturazione e rimborsi, né tempi di conservazione dei dati dopo la chiusura. Sono aspetti ancora senza risposta: la tabella non permette di ricavarne altre scadenze.

Per uno sviluppatore che ha una correzione in sospeso, la decisione immediata è se completarla in Jules oppure trasferire la patch e i requisiti ancora da soddisfare in una nuova attività. Per il responsabile di un team di sviluppo, invece, occorre individuare le dipendenze che non emergono da una normale revisione del codice: prompt ricorrenti, passaggi di configurazione, permessi sui repository e credenziali.

Se Jules svolge attività per voi, intervenite subito. I team che hanno già integrato tutte le modifiche completate e non hanno bisogno dei dati conservati in Jules hanno meno materiale da trasferire. Chi sta valutando gli agenti senza avere lavoro già avviato in Jules può saltare l'esportazione e passare direttamente alla scelta dell'ambiente di esecuzione descritta più avanti. Prendersi tempo per scegliere un fornitore a lungo termine è ragionevole; rimandare il salvataggio del proprio lavoro non lo è.

Salvare ciò che non è nel repository Git

Il codice, i branch e le pull request già presenti in GitHub restano dove sono. L'esportazione di Google comprende ciò che è conservato in Jules: impostazioni, variabili d'ambiente, pianificazioni, collegamenti ai repository, memorie, script di configurazione e, per le sessioni, prompt, piani, log e patch. Il riferimento sono le istruzioni ufficiali per l'esportazione.

Una pull request, o PR, è una proposta di modifica al codice. Può conservare la patch senza conservare il motivo per cui l'agente l'ha scelta. Uno script di configurazione potrebbe contenere il comando di installazione del pacchetto mancante che ha permesso ai test di passare; una memoria potrebbe spiegare perché è stato scartato un refactoring apparentemente allettante. Esaminate questo materiale prima di trasformarlo in istruzioni per un altro agente.

Usate l'esportazione come archivio, poi preparate un passaggio di consegne più essenziale per ciascuna attività incompleta. Indicate repository e branch, la modifica desiderata, quanto è già stato fatto, i criteri di accettazione ancora da soddisfare e il comando che dimostra la riuscita del lavoro. Collegate i documenti di supporto invece di incollare un'intera conversazione in un nuovo prompt.

Per esempio, a un'attività di aggiornamento delle dipendenze non basta l'istruzione «completa l'aggiornamento». Conservate le informazioni sul problema di compatibilità ancora aperto, sui file modificati e sul test che riproduce l'errore. Il nuovo agente avrà così un incarico ben delimitato e chi esamina il risultato potrà respingerlo se è incompleto.

Esportare con la procedura pubblicata da Google

La procedura di Google usa Jules Tools e il prompt di esportazione fornito nell'avviso. Installate lo strumento ed effettuate l'accesso:

npm install -g @google/jules
jules login

Dalla vostra directory home, avviate un agente di programmazione da riga di comando e incollate il prompt completo riportato nell'avviso. Per i dati dei repository, collegate prima GitHub. L'output viene salvato in ~/jules-export: mantenetelo privato, perché env-variables.json contiene i valori delle credenziali. I dati di ogni sessione comprendono summary.md, i log delle attività e i diff.

Un messaggio di completamento non garantisce che l'archivio sia completo. Dall'esame dello script di esportazione pubblicato da Google emerge che il conteggio delle sessioni considera quelle elencate, anche quando non è possibile recuperarne i dettagli. Gli errori vengono segnalati separatamente. Lo script recupera inoltre i comandi di configurazione dagli output delle sessioni: controllate quindi che cosa è stato effettivamente salvato prima di dichiarare che un repository può essere trasferito. Questa osservazione deriva dalla lettura dello script pubblicato; per questo articolo non è stata eseguita alcuna esportazione.

La distinzione conta per chi deve approvare la migrazione. «Il comando è terminato» dimostra meno di «la patch, la configurazione e il contesto necessari sono presenti». Se manca un dato importante, recuperatelo finché avete ancora accesso a Jules, invece di chiedere al prossimo agente di ricostruirlo.

Che cosa succede alla cronologia e alle API di Jules?

Conservate la cronologia in locale ed eliminate la dipendenza da Jules nelle vostre automazioni. L'avviso di chiusura non promette né l'importazione automatica della cronologia in un altro agente né la disponibilità delle API dopo la dismissione.

La documentazione pubblica delle API di Jules descrive le sessioni e le relative attività, tra cui l'avvio del lavoro, l'approvazione dei piani e l'invio di messaggi. Si tratta di dipendenze operative: un bot per le issue che crea una sessione ha bisogno di un sostituto anche se nessuno del team apre il sito di Jules.

Censite gli script, i file di workflow e le integrazioni che chiamano Jules. Annotate quali dati ricevono, quale segnale attendono per considerare il lavoro riuscito e dove salvano i risultati. Una migrazione che cambia soltanto il prompt può comunque fallire, perché la vecchia integrazione si aspetta un identificativo di sessione Jules o ne interroga periodicamente le attività per verificarne il completamento.

Il fatto che una guida introduttiva alle API sia ancora online non prolunga la vita del servizio. In assenza di scadenze specifiche per gli endpoint, pianificate sulla base delle date del servizio e trasferite la creazione delle attività prima del passaggio in sola lettura. È una raccomandazione operativa, non un'ulteriore scadenza per le API annunciata da Google.

Per la cronologia, distinguete tra conservare il lavoro e poterlo riprendere. Un piano salvato aiuta un altro agente a capire l'incarico, ma non ricrea l'ambiente in cui operava quello precedente. Completate il lavoro oppure lasciatelo in uno stato ben documentato, così che un altro sviluppatore possa riprodurre il passaggio successivo senza aprire Jules.

Google Antigravity: cosa arriverà da Jules e cosa offre già?

Google Antigravity, la piattaforma di Google per lo sviluppo con agenti, è il prodotto in cui l'azienda dichiara di voler far confluire quanto appreso con Jules. Nell'annuncio ufficiale di Jules, Google afferma di essere al lavoro per unire l'esecuzione autonoma remota in background all'ambiente di sviluppo di Antigravity. Non indica una data per la disponibilità di questa integrazione.

Il prodotto attuale consente già di svolgere utili attività in background. L'Antigravity App gestisce agenti in parallelo, raggruppa il lavoro in Projects ed esegue attività pianificate. La documentazione di Google su Remote Control descrive l'accesso dal browser a sessioni in esecuzione sui propri portatili, computer desktop o server.

La differenza sta in chi mette a disposizione il computer. Remote Control dà accesso a una macchina già esistente. Da solo, non dimostra che Google abbia predisposto un servizio ospitato sui propri sistemi in sostituzione di Jules. Un team che vuole eseguire manutenzione durante la notte deve sapere quale macchina resta accesa, chi ne mantiene le dipendenze e cosa succede se diventa indisponibile.

Come migrare: aprite il repository in Antigravity, ricostruite la configurazione e le istruzioni necessarie, poi eseguite una piccola attività con un test chiaro. Se prevedete di usare l'accesso remoto, verificate la macchina di destinazione e la sua disponibilità. Aggiungete la pianificazione ricorrente dopo che il flusso ha superato la revisione.

Scegliete Antigravity se volete usare il suo ambiente di sviluppo e potete gestire la macchina che esegue il lavoro. Se il requisito è «lo sviluppatore chiude il portatile e nessuno deve occuparsi di un'altra macchina», valutate subito una soluzione ospitata dal fornitore, senza far dipendere il passaggio da una funzionalità priva di una data di rilascio.

Consultate la guida ai prezzi di Antigravity per decidere su accesso e quote di utilizzo, e il confronto Google Antigravity vs Cursor per la questione distinta di quale ambiente di sviluppo quotidiano si adatti meglio al vostro lavoro.

Trasferire le attività in background in un ambiente che sapete gestire

Scegliete l'ambiente di esecuzione prima dello stile con cui l'agente scrive. Il runtime è l'insieme del computer e dell'ambiente software che eseguono l'attività. Per questa migrazione, il confronto utile riguarda chi lo gestisce: voi, il fornitore che lo ospita oppure la vostra automazione tramite GitHub Actions.

Le opzioni seguenti si basano sulla documentazione attuale dei fornitori. Sono punti di partenza per la migrazione: non implicano funzionalità identiche né un formato di importazione condiviso con Jules.

OpenAI Codex Cloud: attività nel cloud e configurazione riutilizzabile

OpenAI Codex Cloud è un agente di programmazione ospitato nel cloud che può continuare a lavorare mentre il computer è in sospensione. Ogni attività ha il proprio spazio di lavoro e permette di esaminare modifiche e risultati dei test prima di creare un commit o aprire una PR. La guida ufficiale a Codex Cloud descrive la procedura di configurazione attuale.

Come migrare: in ChatGPT, scegliete Work in > Cloud, poi create o selezionate un ambiente. Collegate i repository GitHub, lasciate che Codex prepari il progetto, esaminate i controlli sulla configurazione e pubblicate l'ambiente. Avviate un'attività ben delimitata usando il materiale di passaggio da Jules già ripulito, quindi verificate le modifiche e i risultati dei test.

Il limite da affrontare è l'accesso alle risorse dall'ambiente. Un test che passa in locale dice poco su un'attività cloud che non riesce a raggiungere il registro dei pacchetti o un servizio necessario. Nelle impostazioni dell'ambiente, fornite le destinazioni di rete e le credenziali richieste, poi eseguite lì lo stesso test.

Scegliete Codex se il requisito principale è una coda di attività ospitata dal fornitore, con una configurazione del progetto riutilizzabile. Per la prima prova preferite un'attività di cui potete valutare rapidamente la correttezza a una riscrittura senza confini precisi. Il confronto tra Codex e Claude Code affronta più in generale la scelta del flusso di lavoro, al di là della chiusura di Jules.

Claude Code: sessioni cloud o automazione del repository

Claude Code di Anthropic offre sessioni cloud che continuano dopo la chiusura del portatile, oltre a un'integrazione separata con GitHub Actions per i workflow del repository. La strada giusta dipende da ciò che dovete sostituire: l'assegnazione interattiva di un'attività oppure un trigger automatico.

Per le sessioni cloud: collegate il repository, configurate l'ambiente cloud, l'accesso alla rete e le variabili, quindi avviate un'attività con un perimetro definito. Da un terminale Claude Code con autenticazione già effettuata, claude --cloud avvia il lavoro nel cloud. Nel normale flusso che prevede la clonazione da GitHub, eseguite prima il push del branch, così che la sessione riceva i commit desiderati. Consultate la guida alle sessioni cloud di Claude.

Il limite riguarda la capacità condivisa e l'accesso: le sessioni cloud consumano la quota di utilizzo di Claude dell'account e i permessi dell'organizzazione possono limitarle. Una configurazione personale funzionante per uno sviluppatore non dimostra che l'account aziendale possa gestire lo stesso carico di lavoro.

Per GitHub Actions: un amministratore del repository può eseguire /install-github-app in Claude Code, seguire la configurazione dell'autenticazione ed esaminare la PR generata per il workflow. Iniziate con una richiesta esplicita tramite @claude, poi aggiungete l'attività ricorrente o attivata da eventi che dovete sostituire. Anthropic documenta i requisiti relativi ad app, credenziali e workflow nella sua guida a GitHub Actions.

Qui il punto critico è la responsabilità del workflow. Qualcuno deve mantenere trigger, credenziali e permessi, e saper distinguere un errore di configurazione da un'attività di programmazione non riuscita. Scegliete Actions quando l'evento nel repository è il punto di partenza naturale. La nostra guida a Claude Code con GitHub Actions illustra questo modello operativo.

L'agente di programmazione di GitHub Copilot: gestire il passaggio in GitHub

L'agente di programmazione di GitHub Copilot implementa e testa modifiche in background all'interno del flusso di lavoro di GitHub. La documentazione attuale distingue tra sandbox cloud e ambienti GitHub Actions: controllate quindi quale ambiente è selezionato per l'attività. Il riferimento è Copilot su GitHub.

Come migrare: verificate l'accesso previsto dal piano e le regole dell'organizzazione, selezionate repository e branch, quindi assegnate a Copilot un'attività con criteri di accettazione e la richiesta di una PR. Esaminate le modifiche proposte e i risultati dei test prima del merge. Riutilizzate la stessa descrizione dell'issue presente nell'inventario di Jules, così da poter verificare se il sostituto ha soddisfatto la richiesta.

Il limite dipende dall'ambiente di esecuzione: le sessioni GitHub Actions modificano un solo repository, mentre quelle in sandbox cloud possono coinvolgerne più di uno. Entrambe lavorano su un solo branch e aprono una sola PR per attività. Se la migrazione richiede modifiche coordinate su più branch, suddividetela in interventi che possano essere esaminati separatamente.

Scegliete Copilot se la coda delle revisioni e l'assegnazione delle attività sono già gestite in GitHub. Il passaggio di consegne resta così vicino all'issue e alla PR, ma occorre comunque ricostruire l'ambiente e le istruzioni prima conservati in Jules.

Le aspettative da ridimensionare: esportare non significa migrare automaticamente

La scorciatoia fuorviante è leggere «Jules confluisce in Antigravity» come un piano di trasferimento degli account. Le dichiarazioni di Google descrivono una direzione di sviluppo del prodotto e un'esportazione dei dati. Non promettono che sessioni attive, pianificazioni o memorie compariranno in un sostituto già pronto all'uso.

Un'altra scorciatoia è considerare l'accesso dal browser una prova che l'esecuzione avvenga nel cloud. Un browser può controllare una macchina gestita da voi oppure una ospitata dal fornitore. Le interfacce possono sembrare simili, ma la responsabilità di mantenere il lavoro in esecuzione è diversa.

Adottate un criterio di accettazione concreto: il sostituto deve riprodurre la configurazione necessaria, completare un'attività ben delimitata, rendere visibili i propri controlli e consegnare una modifica verificabile. Non sceglietelo soltanto perché riconosce lo stesso repository o propone un piano plausibile. Il piano è un indizio utile della comprensione dell'incarico; è il flusso di lavoro completato con successo a dimostrare che la migrazione funziona.

Per il responsabile del team, questo restringe la decisione. Non serve risolvere ogni futura preferenza sugli strumenti di programmazione prima della chiusura. Serve un percorso verificato per le attività che altrimenti si fermerebbero, con un responsabile capace di diagnosticarne gli errori.

La checklist per questa settimana

Date la priorità a far funzionare il primo sostituto, poi estendete il metodo al resto delle attività in sospeso.

• Fare l'inventario: elencate repository Jules, sessioni incomplete, attività ricorrenti e sistemi che chiamano le API. Assegnate un responsabile e una destinazione a ogni attività da proseguire.
• Conservare: eseguite la procedura di esportazione di Google, controllate gli errori e i file importanti, quindi custodite l'archivio originale in uno spazio privato.
• Completare o lasciare un punto di ripresa: esaminate le patch in sospeso e lasciate ogni attività da proseguire con un branch, un requisito e un test comprensibili.
• Ricostruire: configurate dipendenze, istruzioni, accesso alla rete e credenziali nell'ambiente di esecuzione scelto. Non inserite valori segreti nelle normali note delle attività.
• Verificare: portate una piccola attività attraverso configurazione, implementazione, test e revisione umana. Controllate anche cosa succede in caso di errore, oltre alla PR riuscita.
• Effettuare il passaggio: spostate i trigger ricorrenti solo quando il sostituto funziona. Disattivate gli invii duplicati e revocate gli accessi obsoleti quando non servono più.

L'azione da mettere in agenda per lunedì è scegliere un repository attivo, esportarne il contesto da Jules e completare una piccola attività con il sostituto, fino alla revisione. Otterrete così un modello di migrazione utilizzabile, da ripetere prima che il servizio smetta di accettare lavoro.

Iscrivetevi alla newsletter per ricevere guide pratiche sui cambiamenti negli strumenti per sviluppatori.