Claude Code non vive solo nel terminale
Quando si parla di Claude Code, la prima immagine che viene in mente è il terminale: una finestra nera, comandi, codice che scorre. Ed è lì che ho iniziato a usarlo anch'io.
Ma da un po' di tempo le cose sono cambiate. Claude Code è disponibile anche come app web su claude.ai/code e come app desktop, oltre che nelle estensioni per editor come VS Code. Non è un dettaglio: cambia proprio il modo in cui puoi usarlo.
In questo articolo spiego cosa ho capito usando la versione cloud, con un esempio concreto che riguarda questo stesso blog.
Cosa cambia col cloud
La differenza principale è una sola, ma conta: quando avvii un agente dal cloud, lui continua a lavorare anche se chiudi il browser o metti via il computer.
Nel terminale locale, se interrompi la sessione, l'agente si ferma. Dal cloud invece il lavoro prosegue in background, sul server. Tu puoi tornare a controllare il risultato quando vuoi.
Questo apre scenari interessanti. Si possono pianificare agenti che partono su una pianificazione precisa, simile a un cron (cioè un timer automatico, come "ogni lunedì mattina alle 8"). Utile per compiti ricorrenti: generare report, controllare dati, aggiornare contenuti.
Un altro aspetto che apprezzo: le skill, cioè le cartelle con istruzioni riutilizzabili per gli agenti, restano disponibili anche dalla versione cloud se stanno nel repository del progetto. Non devi riconfigurare niente. L'agente cloud legge le stesse istruzioni che usi in locale. Questo rende il setup portabile: costruisci il comportamento una volta, funziona ovunque.
I modelli su cui gira sono quelli di Claude, con Opus 4.8 come scelta principale. C'è anche Fable 5 per certi casi. Non ho motivo di smettere di usare il terminale per il lavoro quotidiano, ma avere il cloud come opzione aggiuntiva è comodissimo.
Un esempio concreto: come nasce questo blog
Veniamo al pratico, perché è qui che le cose si fanno interessanti.
Questo articolo che stai leggendo è stato scritto con l'aiuto di una skill dedicata. Ho una cartella nel repository del sito che contiene istruzioni precise su come strutturare gli articoli del blog: frontmatter, tono, lunghezza, regole stilistiche (niente trattini lunghi, frasi brevi, zero inglesismi gratuiti).
Quando voglio un articolo, posso dare un briefing e avviare l'agente. Lui legge le istruzioni dalla skill, segue lo schema, scrive la bozza in italiano e in inglese, rispetta il formato e la crea come file nel repository. La bozza poi arriva a me per revisione. Io leggo, eventualmente correggo, e solo dopo approvo la pubblicazione.
Il punto chiave è "bozza". Non ho tolto la revisione umana dal processo. Ho tolto il tempo che ci voleva per partire da zero.
Questo schema, all'apparenza semplice, ha un vantaggio nascosto: è collegabile a qualsiasi evento esterno. Un flusso di automazione (ho parlato in altri articoli di n8n) potrebbe ascoltare un messaggio su Telegram, estrarne il titolo e il briefing, e avviare l'agente automaticamente. L'articolo arriverebbe in bozza nel repository senza che io abbia aperto il terminale o il browser. Torni, trovi la bozza, la rivedi, e pubblichi.
Non lo faccio ancora in modo completamente automatico, ma il meccanismo è già in piedi. Manca solo il collegamento finale tra il messaggio esterno e l'avvio dell'agente.
Far partire il lavoro da dove sei
Questo è il cambio di mentalità più grande che ho avuto lavorando con gli agenti cloud.
Prima, per far fare qualcosa al computer, dovevo essere davanti al computer. Ovvio, no? Ma con il cloud questo non è più necessariamente vero.
Puoi avviare un agente dalla versione web mentre sei in treno. Puoi pianificarne uno per la notte, così al mattino trovi i risultati. Puoi, in futuro, innescare il lavoro da un messaggio da un'altra app.
Non sto descrivendo fantascienza. Sto descrivendo strumenti che esistono oggi, che sto usando, e che stanno cambiando concretamente come organizzo le giornate di lavoro.
La libertà di location, in questo mestiere, è spesso legata al laptop. Con gli agenti cloud, puoi slegare almeno una parte del lavoro anche da quello.
A cosa fare attenzione
Sarebbe disonesto non dirlo: ci sono rischi concreti, e vale la pena nominarli.
Il primo è il problema dei permessi. Gli agenti hanno bisogno di permessi per agire, leggere file, scrivere nel repository, chiamare servizi esterni. Dare permessi troppo larghi "per comodità" è un errore che si paga. Conviene ragionare su cosa serve davvero, caso per caso.
Il secondo è quello delle azioni irreversibili. Se un agente cancella dei file, invia email o tocca dati reali su un database, non c'è un "annulla". Prima di automatizzare qualcosa del genere, costruisci un passaggio di conferma. L'agente propone, tu approvi, poi si esegue.
Il terzo, e lo ripeto spesso, è la questione delle credenziali. Chiavi API, password, token di accesso: non vanno mai in file di testo nel repository, nemmeno nei file di istruzioni per gli agenti. Vanno nelle variabili di ambiente del servizio cloud che usi, e basta. Un segreto in chiaro nel codice è un rischio che non vale nessuna comodità.
L'ultimo punto è la revisione del risultato. Un agente che lavora da solo produce comunque una bozza, non un prodotto finito. Io lo tratto sempre come un collaboratore che ha fatto un primo giro di lavoro, non come uno che ha consegnato il risultato definitivo. Questa mentalità, finora, mi ha evitato brutte sorprese.
Detto questo: il guadagno in tempo e in focus è reale. Non ho smesso di controllare il lavoro, ho smesso di fare le parti più meccaniche. E quella è una differenza che si sente ogni giorno.
