Google Jules: l’agent di coding asincrono che lavora mentre fai altro

Google Jules e’ entrato in beta a dicembre 2024 ed e’ diventato generalmente disponibile nel 2025. La proposta e’ semplice da spiegare ma cambia il modo in cui si usa un coding agent: non apri una chat, non tieni aperto l’IDE. Dai un task, chiudi il laptop, torni dopo e trovi una pull request pronta per la review.

Questo e’ il cuore di cio’ che Google chiama “asynchronous coding agent”. Non e’ un assistente che scrive riga per riga mentre digiti. E’ un lavoratore delegato che gira in una VM sul cloud di Google, legge il repo, tenta l’implementazione e poi ti chiama.

Come funziona un task su Jules

Il workflow tipico e’ questo. Colleghi il repository GitHub, apri Jules, assegni il task in due modi: puntando a una issue esistente (“fix issue #123”) oppure scrivendo in linguaggio naturale cosa deve fare (“aggiungi test unitari per il modulo auth”). Jules clona il codice in una VM isolata, ragiona sul piano, scrive il codice, lancia i test se ci sono, e apre una pull request sul branch che decidi tu.

Tu nel frattempo puoi fare altro. Rispondere a email, lavorare su un altro ticket, andare in riunione. Quando la PR e’ pronta ricevi notifica e decidi: merge, commenti di revisione, richiedi modifiche. Jules assorbe il feedback e riapre la PR aggiornata.

Il modello sotto: Gemini 2.5 Pro

Jules gira su Gemini 2.5 Pro, con accesso alle modalita’ di ragionamento esteso tipo Deep Think per i task piu’ complessi. La scelta ha senso: Gemini 2.5 Pro ha una context window enorme, e un agent che deve leggersi mezzo repository per capire dove mettere le mani beneficia parecchio di quel context.

L’integrazione con l’ecosistema Google e’ uno dei motivi per sceglierlo. Chi gia’ usa Google Cloud, Vertex AI o altri pezzi dello stack trova Jules dentro la stessa dashboard, con le stesse credenziali. E chi sta esplorando il mondo degli agenti Gemini puo’ partire dalla Gemini CLI per il lavoro sincrono sul terminale e passare a Jules quando il task diventa asincrono.

Session-based vs task-based

Qui sta la differenza filosofica che conviene capire prima di provarlo. Strumenti tipo Claude Code o Cursor sono session-based: tu sei seduto davanti, c’e’ una conversazione che continua, il contesto cresce, tu dirigi minuto per minuto.

Jules appartiene a un’altra categoria, quella dei “cloud coding agents” dove stanno anche Devin di Cognition e i Background Agents di Cursor. Qui il task e’ piu’ grosso, dura ore invece di minuti, e tu non stai guardando lo schermo mentre succede.

• Session-based: buono per esplorazione, refactoring guidato, debugging in coppia
• Task-based asincrono: buono per fix isolati, coperture test, bump di dipendenze, chores ripetitivi
• Ibrido: tanti team li usano entrambi, uno per tipo di lavoro

Concorrenti da tenere d’occhio

Il panorama e’ affollato. GitHub Copilot Workspace e’ stato lanciato con grande comunicazione ma poi ritirato/rinominato da Microsoft nel 2025. Devin di Cognition e’ forse il piu’ ambizioso ma ha prezzo enterprise e non e’ sempre raggiungibile. Cursor Background Agents offrono un modello simile a Jules ma dentro l’ecosistema Cursor. Anche ChatGPT Agent e Operator di OpenAI si muovono in territorio vicino, anche se con un focus piu’ ampio che include automazione browser.

Jules gioca la carta dell’integrazione Google e del modello Gemini 2.5 con context lungo. E gioca la carta del prezzo: esiste un free tier limitato che permette di provarlo senza spendere, poi i consumi scalano con le quote Google Cloud. Chi gia’ paga GCP per altro lo vede come una estensione naturale.

Dove Jules brilla

Task ben delimitati, descrivibili a parole, con un “done” chiaro. Alcuni esempi dove ha senso provarlo:

• Fix di bug con issue dettagliata e test riproducibile
• Aggiunta di unit test su moduli sottotestati
• Aggiornamento dipendenze con piccoli adattamenti API
• Porting di uno script da una libreria a un’altra
• Refactor mirato di un singolo file o modulo
• Documentazione autogenerata da codice esistente

Dove Jules fa fatica

Il tallone d’Achille e’ la continuita’ di contesto. Un task isolato e’ un conto, un progetto che si sviluppa su settimane e richiede scelte architetturali coerenti e’ un altro. Jules parte ogni volta con il repository e la tua descrizione: non ha memoria lunga di cosa avete concordato tre task prima, non tiene aggiornato un modello mentale del progetto.

Altre debolezze tipiche dei cloud agent: i task lunghi possono sforare la pazienza della VM, i bug visti a occhio nudo in un IDE possono sfuggire a chi legge il diff in PR, la latenza di iterazione e’ alta (scrivi, aspetti, leggi PR, commenti, aspetti di nuovo). Per chi e’ abituato al ciclo rapidissimo di Claude con computer use o di un IDE AI-first, il passaggio puo’ sembrare lento.

Quando provarlo davvero

Vale la pena provare Jules su un repo piccolo e ben testato, con una issue chiara da assegnare. Il free tier basta per capire se il flusso ti si adatta. Dopo due o tre task ti rendi conto se il modello “delego e torno” funziona per come lavori, o se preferisci tenere le mani sul manubrio.

La domanda onesta da farsi non e’ se Jules sia bravo a scrivere codice, perche’ Gemini 2.5 Pro il codice lo scrive bene. E’ se la tua giornata lavorativa ha davvero queste ore cuscinetto da delegare, o se alla fine passi piu’ tempo a specificare il task di quanto ne risparmi a lasciarlo girare.