Google Jules: Un Fantasma Tecnico nel Cuore di Mountain View

Voto: 3/10

Mi è capitato spesso, negli ultimi mesi, di avere la sensazione di muovermi in una stanza buia cercando un interruttore che so per certo esistere, ma che nessuno sembra voler ammettere di aver installato. Quel "clic" che cerco si chiama Google Jules. È un nome che suona familiare, quasi amichevole, ma se provate a parlarne in un forum di sviluppatori o durante un caffè tra colleghi, riceverete nella migliore delle ipotesi uno sguardo interrogativo e nella peggiore una correzione convinta: "Ah, intendi Gemini Code Assist, giusto?". No, non intendo Gemini Code Assist. Intendo Jules, il sistema di sviluppo che nessuno, o quasi, conosce.

L'esistenza di Jules è un paradosso vivente. Da un lato, è il manifesto di quella che Google definisce "sviluppo agentico", un sistema capace di agire autonomamente mentre noi facciamo altro. Dall'altro, è avvolto da una sorta di timidezza comunicativa che lo rende quasi invisibile rispetto ai roboanti annunci di Cursor, Claude Code o lo stesso ecosistema Vertex AI. In questo lungo viaggio nel ventre della balena di Google Labs, voglio portarvi con me per esplorare cosa sia davvero questo sistema, perché mi ha fatto perdere il sonno su progetti complessi come quelli basati su Godot, e perché, nonostante una potenza di calcolo teoricamente illimitata, finisce per meritarsi un voto che non supera il 3.

Il Mistero dell'Invisibilità: Perché Jules è il Segreto Meglio Custodito di Google?

Iniziamo dalla domanda più ovvia: perché non lo conosce nessuno? Se analizziamo la strategia di Google, notiamo una frammentazione che confonderebbe anche il più esperto dei product manager. Mentre il mondo intero parla di Gemini, Jules è rimasto confinato nel perimetro dei Labs per mesi, uscendo in una beta pubblica nel maggio 2025 che sembrava più un soft launch per pochi intimi che un guanto di sfida lanciato a Microsoft e GitHub. La beta pubblica è oggi acqua passata: Jules è uscito dal beta nel settembre 2025, è integrato nei piani Google AI Pro e Ultra, e conta già oltre 140.000 contributi pubblici al codice da parte degli utenti.

La verità è che Jules non è un prodotto finito, ma un esperimento di architettura asincrona. Mentre strumenti come Cursor o Copilot vivono dentro il nostro editor, respirano con noi riga dopo riga, Jules vive nel cloud, in una dimensione separata dove noi gli affidiamo un compito e lui si ritira in una sorta di isolamento monastico per risolverlo. Questa natura asincrona lo rende alieno al flusso di lavoro tradizionale. Non è un co-pilota; è un appaltatore esterno a cui diamo le chiavi di casa e che ci richiama dopo due ore dicendo di aver finito.

Un altro motivo della sua scarsa popolarità è la sovrapposizione interna con progetti come Google Antigravity. Annunciato verso la fine del 2024, Antigravity si presenta come un IDE completo, un fork di VS Code che cerca di fare quello che fa Cursor, ma sotto l'egida di Mountain View. Jules, in questo scenario, sembra il fratello maggiore un po' burbero e specializzato che viene mandato a fare i lavori sporchi — refactoring massivi, aggiornamento di dipendenze, scrittura di test — mentre Antigravity si prende le luci della ribalta come "nuovo modo di programmare".

L'Illusione del "Gratis": Qual è il Vero Prezzo di Jules?

Se andate su jules.google, la prima sensazione è quella di essere davanti a un regalo inaspettato. Il sistema offre un tier gratuito di accesso per iniziare a conoscere lo strumento, ma le limitazioni sono evidenti fin da subito. Non siamo più nell'epoca dei 15 task al giorno della prima beta: i piani attuali sono strutturati attorno agli abbonamenti Google AI.

Perché Google offre Jules (anche parzialmente) gratuitamente? La risposta risiede nei dati e nel perfezionamento dei modelli. Sebbene Google dichiari esplicitamente che Jules non si addestra sui contenuti dei repository privati, ogni interazione, ogni piano approvato e ogni correzione suggerita dall'utente serve a raffinare la capacità di ragionamento dei modelli Gemini. In sostanza, noi siamo i beta-tester di un'intelligenza agentica che, una volta matura, diventerà il cuore pulsante di offerte enterprise molto costose.

Il piano Google AI Pro (€19,99/mese) offre limiti 5x superiori rispetto al tier gratuito, con accesso a Gemini 3.1 Pro, ed è descritto come «ideale per il coding quotidiano». Il piano Google AI Ultra (circa €150/mese) arriva invece a limiti 20x superiori, «per workflow multi-agente intensivi su larga scala», con accesso alle stesse superfici (CLI, API, web) che condividono una visione unificata del progetto.

L'Architettura Sotto il Cofano: La Macchina Virtuale Temporanea

Arriviamo alla parte che più mi ha affascinato e, al contempo, frustrato. Jules non legge semplicemente il nostro codice; Jules se ne appropria temporaneamente. Quando assegniamo un compito, il sistema avvia una macchina virtuale (VM) dedicata nel cloud di Google. Questa VM è un ambiente isolato, una sorta di sandbox sicura basata su Ubuntu Linux.

Ecco cosa succede tecnicamente: Jules clona il nostro repository GitHub all'interno di questa VM, analizza la struttura del progetto e cerca di capire come farlo girare. È un approccio radicalmente diverso dal "copia-incolla" di snippet a cui ci hanno abituato le chat AI tradizionali. Qui c'è un file system reale, un terminale reale e una connessione internet che permette a Jules di scaricare documentazione aggiornata o dipendenze mancanti.

L'ambiente OS costruito è un Ubuntu standard, equipaggiato con una suite di strumenti preinstallati che coprono i linguaggi più popolari:

• Node.js 22+: ideale per il mondo web moderno.

• Python: con supporto a pacchetti come poetry e uv.

• Go, Java, Rust: toolchain complete per lo sviluppo backend e di sistema.

• Docker: per gestire container all'interno della stessa VM.

Tuttavia, l'ambiente è rigorosamente headless. Non c'è un server grafico, non c'è X11, non c'è supporto per OpenGL o Vulkan nativo che sia facilmente accessibile all'agente. Ed è qui che iniziano i problemi quando usciamo dal seminato del web o del backend puro.

Vale la pena citare una novità importante introdotta nel 2025 e maturata nel 2026: Jules ora espone una Jules API stabile e una Jules Tools CLI (npm install -g @google/jules) che permettono di integrare l'agente direttamente nel terminale, nella pipeline CI/CD e in sistemi personalizzati. Il CLI supporta task paralleli, funziona su Windows e WSL, e include un diff viewer per controllare le modifiche prima di applicarle.

Il Caso Godot e "The Safe Place": Quando Jules Alza Bandiera Bianca

Ho provato a mettere Jules alla prova con progetti più complessi, come quelli basati sull'engine Godot, nello specifico il progetto The Safe Place. Qui la sensazione che Jules "conosca ma non possa fare" diventa frustrante. L'intelligenza di Gemini 3.1 Pro è in grado di analizzare gli script GDScript, comprendere la logica dei nodi e suggerire refactoring impeccabili sulla carta. Ma quando si tratta di validare quelle modifiche, Jules si scontra con il muro della sua stessa architettura.

Godot, per sua natura, richiede un ambiente che supporti il rendering grafico, anche solo per avviare il project manager o eseguire test che coinvolgono la scena. Nella VM di Jules, Godot spesso non riesce nemmeno ad avviarsi perché non trova una GPU o i driver Vulkan corretti. Jules si ritrova così a essere un chirurgo che ha studiato perfettamente l'anatomia del paziente ma che è costretto a operare in una stanza completamente buia, senza poter vedere se il taglio che sta facendo è corretto.

Il risultato è un loop infinito di errori. Jules propone una modifica, prova a eseguirla, il processo fallisce perché l'ambiente non è adatto, e lui riprova cambiando qualche riga di codice, non rendendosi conto che il problema non è il codice, ma la "scatola" in cui è rinchiuso. Questa compartimentazione, se da un lato garantisce una sicurezza estrema (i nostri file locali non vengono toccati), dall'altro limita Jules a essere un eccellente sviluppatore web ma un pessimo sviluppatore di applicazioni grafiche o complesse.

Un Workflow "Scomodo": Il Calvario dei Commit e dei Branch

Un altro aspetto che mi ha lasciato perplesso è l'estrema rigidità del flusso di lavoro. Jules non è un sistema interattivo nel senso moderno del termine. Se voglio vedere i risultati del suo lavoro, non posso semplicemente fare un preview in tempo reale. Devo seguire un rituale quasi burocratico.

Jules lavora in isolamento. Una volta completato il compito, genera un piano che noi dobbiamo approvare. Poi esegue. Alla fine, per mostrarci cosa ha fatto, apre una Pull Request su un ramo specifico della repository GitHub. Solo a quel punto posso scaricare il ramo, fare il pull nel mio ambiente locale e visionare le modifiche.

È un processo incredibilmente lento. In un mondo dove Cursor ci permette di accettare o rifiutare modifiche con un tasto Tab in millisecondi, il workflow di Jules sembra un ritorno all'era della programmazione via schede perforate, dove si consegnava il pacco di schede all'operatore e si tornava il giorno dopo per il risultato.

Una novità del febbraio 2026 ha mitigato parzialmente il problema: Jules ora include un CI Fixer che, quando una GitHub Action fallisce su una PR creata da lui, rileva l'errore, lavora autonomamente a una correzione e invia un nuovo commit — tutto senza intervento manuale. Prima di questa feature, un CI rotto richiedeva di copiare i log a mano e rispiegarli a Jules da capo. Un miglioramento reale, ma che non risolve il problema strutturale del ciclo di feedback troppo lento.

Inoltre, Jules sembra soffrire ancora di una cronica mancanza di memoria contestuale tra una sessione e l'altra. Mi è capitato spesso che mi chiedesse di verificare modifiche che lui stesso aveva appena fatto, dimenticandosi che io, dall'esterno, non ho visibilità sulla sua VM finché lui non decide di "pubblicare" il suo lavoro su GitHub. È come lavorare con un collaboratore molto intelligente ma che vive in una stanza insonorizzata e può comunicare con noi solo tramite lettere raccomandate.

Il Critic: L'Auto-revisione che Arriva Tardi

Da agosto 2025, Jules ha introdotto una funzionalità interessante: il critic agent. In pratica, una volta generata una patch, un secondo agente la esamina criticamente prima che venga sottoposta all'utente. Il critic non corregge il codice: lo segnala e lo rimanda a Jules per migliorarlo. Può intercettare situazioni come algoritmi corretti ma inefficienti, funzioni con signature modificate senza gestire tutti i parametri, o patch che passano i test ma introducono errori logici sottili.

È una buona idea, e nella pratica funziona meglio di quanto mi aspettassi. Il problema è che rimane un processo a singolo passaggio (one-shot): il critic esamina l'output finale tutto in una volta, non è un agente multi-step che ragiona durante l'esecuzione. Per i task complessi, dove l'errore si annida nelle decisioni architetturali prese a metà percorso, questo approccio arriva sistematicamente troppo tardi.

Qual è il Vero Scopo di Jules? IDE o Analista di Codice?

Dopo averlo usato a fondo, mi sono chiesto: ma Google cosa vuole farne di Jules? La risposta, a mio avviso, è che Jules non è, e non sarà mai, un IDE. Il suo scopo non è scrivere codice insieme a noi, ma scrivere codice al posto nostro per quei compiti che noi detestiamo.

Jules è un Analista Esecutivo. Il suo punto di forza non è la velocità, ma la profondità dell'analisi. Grazie alla finestra di contesto di Gemini, Jules è in grado di leggere l'intera architettura di un progetto, capire come un cambiamento in una libreria di basso livello influenzi un componente della UI e proporre una soluzione coerente che attraversa dieci file diversi.

I suoi casi d'uso ideali sono compiti di manutenzione pura:

• Aggiornamenti di versione: "Passa l'intero progetto da Node 18 a Node 22 e correggi tutte le API deprecate."

• Scrittura di test: "Aggiungi unit test per tutte le funzioni nel modulo utility."

• Documentazione: "Leggi il codice e aggiorna il file README con istruzioni chiare per i nuovi arrivati."

• Scheduled Tasks: Jules può ora operare su task programmati, funzionando come un agente di manutenzione notturno che controlla aggiornamenti e segnala problemi in automatico.

In questo senso, Jules non è un concorrente di Cursor, ma un'alternativa agentica a strumenti di refactoring massivo. È un sistema progettato per girare di notte o mentre siamo in riunione, consegnandoci al mattino una Pull Request pulita e testata — almeno nelle sue intenzioni.

Valutazione: Perché un "3"?

Il mio voto di 3 non è una condanna, ma una constatazione di immaturità. Jules è un gigante dai piedi d'argilla. La potenza di calcolo di Google Cloud e l'intelligenza di Gemini 3.1 Pro sono motori formidabili, ma la carrozzeria — intesa come esperienza utente e flessibilità dell'ambiente di lavoro — è ancora rudimentale.

Per l'utente che accede oggi a Jules, tutto resta un po' difficile da capire. L'interfaccia è migliorata rispetto all'esordio, ma il feedback della VM rimane limitato e la dipendenza totale da GitHub rende il sistema rigido per chiunque usi altri sistemi di versionamento o preferisca flussi di lavoro più agili. La CLI e l'API sono passi avanti concreti, ma richiedono una configurazione che scoraggia chi cerca uno strumento plug-and-play.

Inoltre, la discrepanza tra le capacità di analisi (altissime) e le capacità di esecuzione in ambienti non standard (basse) crea una "valle dei sogni infranti" per chiunque cerchi di usarlo al di fuori del sentiero tracciato dalle applicazioni web JavaScript o Python. Il caso Godot non è un'eccezione: è la regola per qualsiasi progetto che richieda un ambiente di esecuzione con stato visivo o componenti hardware non standard.

Il Futuro: "Jitro" e l'Era dell'Integrazione Totale

Siamo nel 2026, e il panorama sta cambiando velocemente. Google sta già integrando Jules con il Model Context Protocol (MCP), permettendogli di parlare con strumenti esterni come Slack, Jira o Linear. Questo potrebbe essere il vero punto di svolta: un Jules che non solo scrive codice, ma che legge i bug report su Jira, decide autonomamente quali correggere, avvia una VM, scrive la soluzione e apre la PR, notificando il team su Slack.

Ma l'evoluzione più interessante è quella che si intravede all'orizzonte. Google starebbe sviluppando internamente la prossima generazione di Jules sotto il nome in codice "Jitro": non più un agente che risponde a prompt, ma un sistema orientato agli obiettivi, in cui il developer non dice a Jules cosa fare ma verso quale metrica tendere. KPI-driven development, in pratica, dove l'agente identifica autonomamente cosa cambiare nel codebase per migliorare performance, copertura dei test o accessibilità. Un annuncio ufficiale potrebbe arrivare al Google I/O 2026 di maggio.

Finché Jules rimarrà questo fantasma asincrono chiuso in una VM Ubuntu senza occhi per vedere la grafica e senza una connessione fluida con l'editor dello sviluppatore, resterà uno strumento di nicchia. Un esperimento affascinante che molti proveranno una volta per poi tornare ai propri rassicuranti — e più veloci — co-piloti locali.

In conclusione, Jules è la promessa di un futuro dove non dovremo più scrivere codice noioso, ma è una promessa che oggi richiede troppa pazienza e troppi compromessi. È un sistema che merita di essere tenuto d'occhio, ma che per ora, nel mio blog e nel mio workflow, resta un collaboratore part-time a cui affido solo le pulizie di casa, mai la progettazione del giardino.

Note Tecniche: Capacità di Jules (aggiornato maggio 2026)

Per chi volesse approfondire le specifiche tecniche della piattaforma, ecco una sintesi delle capacità e dei limiti riscontrati durante i test estensivi.

Dal 9 marzo 2026, Gemini 3.1 Pro è il modello di default per gli utenti del piano Pro, sostituendo Gemini 3 Pro come baseline per la risoluzione di problemi complessi. L'evoluzione verso Gemini 3.1 migliora sensibilmente la qualità dei piani di esecuzione, ma la sfida principale resta l'abbattimento della latenza operativa tra l'agente cloud e l'ambiente di sviluppo locale dello sviluppatore. Finché questa barriera non sarà superata, Jules rimarrà un potente analista relegato in una torre d'avorio digitale.