Come usare Claude Code il primo giorno: cosa affidargli e quali permessi non dargli

Quasi nessuno abbandona Claude Code perché non funziona. Lo abbandona perché il primo giorno gli ha dato il compito sbagliato, «rifammi questa app», «sistema tutto il backend», ha visto uscire un risultato mediocre in venti minuti, e ha concluso che l’hype era hype. Poi c’è il gruppo opposto: quelli che al terzo prompt hanno premuto invio su una scorciatoia per non vedere più le richieste di permesso, e due ore dopo si sono trovati file cancellati che nessuno aveva chiesto di cancellare.

Prima ancora del primo compito, vale la pena chiedersi quando conviene un agente AI: l’analisi McKinsey mette in fila costi e trade-off dei workflow agentici, ed è il modo migliore per non partire con il compito sbagliato. Ed è lo stesso motivo per cui i guardrail sugli agenti AI vanno mantenuti nel tempo, non solo configurati il primo giorno.

Questa guida sta esattamente lì: dopo la decisione di provarlo e prima dell’abbandono. Non è una traduzione della documentazione, quella esiste già ed è ottima. È l’ordine dei passaggi che funziona il primo giorno, il compito giusto da dare per primo, e soprattutto la parte che quasi nessuno in italiano tratta davvero: come usare Claude Code senza dargli più potere di quanto serva. I comandi riportati qui sono verificati sulla documentazione ufficiale a settembre 2026: le versioni cambiano in fretta, e un comando copiato da un tutorial di un anno fa è il primo motivo per cui l’installazione fallisce.

La stessa logica di controllo, portata al livello enterprise, è quella su cui Anthropic ha costruito Claude Mythos 5 per la sicurezza delle aziende: si usa dal cloud dell’azienda invece di essere scaricato, per non spostare fuori i confini di accesso.

In questo articolo scoprirai:

• Cosa serve avere pronto prima di lanciare il primo comando
• Installazione di Claude Code: i comandi in ordine, su Mac, Linux e Windows
• Il primo compito da dargli: perché «rifammi l’app» è l’errore che fa abbandonare
• Far pianificare Claude Code prima di fargli scrivere codice
• Quello che non gli affiderei il primo giorno
• Permessi di Claude Code: cosa lasciargli toccare e dove mettere il confine
• Percorsi protetti e difese attive: cosa Claude Code non tocca mai
• Come togliere le richieste di permesso senza spegnere la sicurezza: il sandbox di Bash
• Gli inciampi delle prime ore, e come si scavalcano

Cosa serve avere pronto prima di lanciare il primo comando

Claude Code non è un plugin dell’editor e non è un autocompletamento più intelligente — se stai ancora scegliendo fra le due strade, il confronto voce per voce sta in Claude Code contro Cursor. Il manuale di freeCodeCamp lo inquadra bene: «non è un autocomplete più furbo, è un agente: un sistema che legge il tuo codice, ragiona su cosa va fatto, scrive e modifica file, esegue comandi». Questo cambia i prerequisiti. Non ti serve un editor configurato: ti serve un progetto vero, un terminale e un modo per tornare indietro.

La lista minima, prima di installare qualsiasi cosa:

1. Un terminale aperto, su macOS il Terminale, su Windows PowerShell o WSL, su Linux quello che usi già.
2. Un account attivo: un abbonamento Claude Pro, Max, Team o Enterprise, oppure un account Claude Console con credito prepagato. Senza uno dei due, l’installazione riesce ma la prima sessione si ferma al login. Se non sai quale delle due strade conviene al tuo uso, il confronto sta nella nostra guida ai costi delle API di Claude rispetto all’abbonamento, e la spesa reale di un mese di lavoro l’abbiamo messa in fila in quanto costa Claude Code davvero.
3. Un progetto con git inizializzato. Questo è il punto che salta la maggior parte dei tutorial ed è quello che conta di più: git è il tuo tasto annulla. Un agente che modifica dieci file in una cartella non versionata è un agente le cui modifiche non sai come togliere.
4. Quaranta minuti senza riunioni. Il primo giorno non si fa in cinque minuti fra due call, perché la parte lenta non è l’installazione: è capire che cosa ha senso delegargli.

Dove gira Claude Code, oltre al terminale

Vale la pena sapere anche dove altro vive lo strumento, perché il terminale non è l’unica strada: la documentazione ufficiale elenca versione web, app desktop, estensione VS Code, JetBrains, Slack e integrazione in CI/CD con GitHub Actions e GitLab. Se il terminale ti spaventa, la CLI resta comunque il posto dove si capisce meglio cosa sta succedendo, ed è il motivo per cui questa guida parte da lì. Se invece ti manca il quadro generale su cosa sia il modello sotto, la nostra guida completa a Claude AI copre il contesto, e quella sugli agenti AI e su come funzionano davvero spiega perché un agente si comporta diversamente da un chatbot.

Installazione di Claude Code: i comandi in ordine, su Mac, Linux e Windows

L’installazione nativa è oggi il metodo raccomandato da Anthropic e ha un vantaggio pratico non piccolo: si aggiorna da sola in background. Ecco i passaggi, uno alla volta.

Passo 1, installa. Su macOS, Linux e WSL:

curl -fsSL https://claude.ai/install.sh | bash

Su Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Su Windows CMD, che è la console sbagliata per il comando qui sopra, esiste una riga dedicata:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

In alternativa, con Homebrew su Mac (brew install --cask claude-code) o con WinGet su Windows (winget install Anthropic.ClaudeCode). Su Debian, Fedora, RHEL e Alpine si installa anche con apt, dnf o apk. Attenzione a due differenze che si pagano più avanti. La prima: le installazioni via Homebrew e WinGet non si aggiornano da sole, servono brew upgrade claude-code o winget upgrade Anthropic.ClaudeCode a mano. La seconda riguarda solo Homebrew, che offre due cask diversi: claude-code segue il canale stabile, tipicamente indietro di circa una settimana e senza le versioni con regressioni gravi, mentre claude-code@latest riceve ogni nuova versione appena esce. Il primo giorno il canale stabile è la scelta giusta.

Passo 2, verifica. Un solo comando:

claude --version

Deve stampare un numero di versione seguito da (Claude Code). Se stampa altro, non andare avanti: risolvi qui.

Passo 3, entra nel progetto e avvia. Questo è il passaggio che decide i permessi di tutta la sessione, e lo vedremo fra poco:

cd /percorso/del/tuo/progetto
claude

Passo 4, accedi. Al primo avvio si apre il browser. Se non si apre, premi c per copiare l’URL di login e incollalo a mano. Per cambiare account più avanti, /login dentro la sessione.

Claude Code su Windows: PowerShell, CMD o WSL

Su Windows nativo la documentazione consiglia di avere installato Git for Windows — non lo richiede più — perché senza di quello Claude Code ripiega su PowerShell come shell e alcuni comandi si comportano diversamente. Se sbagli console te ne accorgi subito dai messaggi: The token '&&' is not a valid statement separator significa che sei in PowerShell mentre stai usando il comando per CMD; 'irm' is not recognized è l’errore opposto. Il prompt te lo dice: PS C:\ è PowerShell, C:\ senza PS è CMD. Chi lavora già in WSL non ha bisogno di Git for Windows — e ha in più un vantaggio che conta, perché il sandbox di cui parleremo più avanti su Windows nativo non gira affatto.

Il primo compito da dargli: perché «rifammi l’app» è l’errore che fa abbandonare

Qui si gioca tutto. Il primo compito che quasi tutti danno è il più grande che gli viene in mente, perché è quello che si vuole verificare: «riesce a costruirmi una cosa intera?». È il modo più veloce per ottenere un risultato deludente e smettere.

Il primo compito giusto non è scrivere codice. È farsi spiegare il progetto. Dentro la sessione, prova letteralmente:

what does this project do?

e poi dov'è il punto di ingresso?, spiegami la struttura delle cartelle. Serve a due cose insieme: vedi come l’agente naviga il codice senza che tu gli passi i file a mano, e, soprattutto, capisci quanto ha capito. Se sbaglia a descrivere il tuo progetto, sai già che non può modificarlo bene.

Dalla spiegazione alla prima modifica scritta da Claude Code

Passo successivo: una modifica piccola e verificabile. Non «aggiungi l’autenticazione»: «aggiungi la validazione dell’input al form di registrazione». Una cosa che puoi guardare e dire sì o no in trenta secondi. Il manuale di freeCodeCamp raccomanda per gli esordienti progetti web proprio per questo: «scrivi file, apri il browser e vedi il risultato, il ciclo di feedback è veloce e inequivocabile».

C’è un dato che vale la pena tenere presente proprio il primo giorno. Uno studio randomizzato di METR su 16 sviluppatori esperti e 246 issue reali ha misurato che, con gli strumenti AI, quegli sviluppatori hanno impiegato il 19% di tempo in più, mentre erano convinti di essere andati il 20% più veloci. Non è un verdetto contro gli agenti (gli autori sono espliciti nel dire che non dimostra che l’AI non aiuti la maggior parte degli sviluppatori), ma è la migliore ragione esistente per misurare invece di fidarsi della sensazione nelle prime settimane.

Far pianificare Claude Code prima di fargli scrivere codice

Sul primo compito vale un’ultima regola: fallo pianificare prima di farlo scrivere. Basta chiudere la richiesta con «non scrivere ancora codice» per ottenere un piano da approvare, ed è una delle raccomandazioni esplicite delle best practice pubblicate da Anthropic. C’è anche una scorciatoia dedicata: /plan davanti a un singolo prompt lo fa ragionare senza toccare i file, e quando il piano è pronto scegli tu se approvarlo, se rivedere ogni modifica una per una o se continuare a pianificare. Vale anche il modo in cui formuli la richiesta, le regole della nostra guida al prompt engineering valgono qui più che altrove, perché un agente amplifica sia la qualità sia i buchi delle tue istruzioni.

Quello che non gli affiderei il primo giorno

Scegliere il compito è più difficile che eseguire il comando, e il fallimento del primo giorno nasce quasi sempre da qui. Il manuale di freeCodeCamp elenca quattro categorie da non dare in pasto a un agente che lavora in autonomia, e sono esattamente le quattro che un principiante sceglie per prime: compiti ambigui o sotto-specificati, decisioni architetturali che richiedono giudizio, lavori in cui un malinteso si propaga a cascata, e qualunque cosa tocchi sistemi in produzione senza una revisione umana in mezzo.

I quattro lavori da tenere fuori dal primo giorno con Claude Code

Tradotto in pratica, il primo giorno terrei fuori:

• Le migrazioni di database e tutto ciò che tocca la produzione. Nel luglio 2025 l’agente di Replit ha cancellato un database di produzione durante un blocco esplicito delle modifiche: 2.402 record fra dirigenti e aziende, con l’agente che poi ha ammesso di aver «violato istruzioni esplicite». La lezione non è che il modello si è comportato male: è che il blocco esisteva solo nelle istruzioni, e niente nel percorso di esecuzione lo faceva rispettare.
• Il repository aziendale con i segreti dentro. Il primo giorno si sceglie un progetto di cui non ti importa niente, o una copia.
• Le scelte che avresti fatto diversamente. Se non sai dire perché una soluzione è giusta, non saprai riconoscere quando quella proposta è sbagliata, e con un agente questo è il fallimento più costoso, perché il codice sbagliato funziona abbastanza da entrare in main.
• Il refactoring di file che non hai mai letto. Vale anche al contrario: l’autore di Builder.io racconta di un componente React da 18.000 righe che «nessun agente AI è mai riuscito ad aggiornare tranne Claude Code». Ma lui quel file lo conosceva.

Permessi di Claude Code: cosa lasciargli toccare e dove mettere il confine

È la parte che decide come finisce il tuo primo giorno, ed è quella che quasi nessuna guida tratta.

In quale modalità di permesso parte la tua sessione

Prima di configurare qualcosa, conviene sapere in che modalità sei partito, e qui c’è la sorpresa più grande. La documentazione sulle modalità di permesso, nella tabella «In quale modalità si avvia una sessione», è esplicita: su piano Pro, Max o Team, da terminale o con l’estensione VS Code, la modalità di partenza è auto, cioè «Tutto, con controlli di sicurezza in background». Non sola lettura: l’agente agisce, e a rivedere le sue azioni è un secondo modello, il classificatore.

Parte invece in modalità Manual chi sta su Enterprise o su una API key della Console, chi passa da Amazon Bedrock, Google Cloud Agent Platform o Microsoft Foundry, chi usa claude -p e l’Agent SDK, chi ha un’organizzazione che ha spento auto mode con disableAutoMode, e chiunque nella primissima sessione dopo un’installazione o un aggiornamento. Nota terminologica che conta quando cerchi aiuto: quella modalità oggi si chiama Manual nella CLI, in claude --help, nelle estensioni e nell’app desktop, mentre il suo valore di configurazione resta default. Dalla versione 2.1.200 la CLI accetta anche l’alias, quindi claude --permission-mode manual e claude --permission-mode default fanno la stessa cosa. Le sei modalità sono default (Manual, sola lettura), acceptEdits, plan, auto, dontAsk — che esegue solo gli strumenti pre-approvati ed è pensata per CI e script — e bypassPermissions, che è quella da usare soltanto dentro un container.

I confini che Claude Code ha già di suo

C’è poi il confine più importante e meno conosciuto: in modalità Manual, Claude Code può scrivere soltanto nella cartella da cui l’hai avviato e nelle sue sottocartelle, e sempre in Manual chiede anche prima di leggere percorsi fuori da quel perimetro con gli strumenti Read, Grep e Glob. È il motivo per cui il cd del passo 3 non è una formalità: quella riga definisce il raggio d’azione dell’agente per tutta la sessione. Avviarlo dalla home significa dargli la home. Ma non leggerlo come una garanzia assoluta, perché è una garanzia della modalità Manual: in auto mode le stesse azioni passano dal classificatore invece che da te, e in bypassPermissions non c’è nessun confine da rispettare.

Percorsi protetti e difese attive: cosa Claude Code non tocca mai

Esiste un secondo confine che vale quasi ovunque, e in italiano non lo racconta nessuno: la lista dei percorsi protetti. Le scritture lì dentro non sono mai auto-approvate in nessuna modalità tranne bypassPermissions, e nemmeno una regola permissions.allow le pre-approva, perché il controllo scatta prima che Claude Code valuti le regole del file di impostazioni. Nell’elenco ci sono le directory .git, .claude, .vscode, .idea, .devcontainer, .husky, e file come .bashrc, .zshrc, .gitconfig, .npmrc, .pre-commit-config.yaml e .mcp.json. Tradotto: l’agente non ti riscrive la configurazione della shell, gli hook di commit o la propria configurazione senza che tu dica sì una volta.

Altre protezioni attive senza fare nulla, elencate nella pagina sulla sicurezza: i comandi che scaricano dal web come curl e wget non sono mai auto-approvati; le richieste di rete richiedono conferma; il web fetch gira in una finestra di contesto separata proprio per non far entrare istruzioni ostili nella conversazione; alla prima esecuzione in un repository sconosciuto viene chiesta una verifica di fiducia, che però è disattivata quando lanci in modalità non interattiva con il flag -p. Vale la pena ricordarselo, perché è la modalità che si usa negli script. Piccolo dettaglio che fa perdere tempo a molti: se avvii Claude Code direttamente dalla home, l’accettazione della fiducia non viene scritta su disco e la richiesta ricompare a ogni avvio. Non c’è un’impostazione per farla ricordare, si avvia da una sottocartella di progetto.

Il tasto che cambia modalità di permesso, e cosa approva davvero

Impara il tasto delle modalità. Shift+Tab cicla fra le modalità di permesso. La modalità piano fa proporre senza scrivere; acceptEdits approva automaticamente le modifiche ai file, e qui c’è il dettaglio che nessuno ti dice: in quella modalità sono auto-approvati anche alcuni comandi di filesystem, mkdir, touch, mv, cp, sed, rmdir e rm. L’auto-approvazione vale solo per i percorsi dentro la working directory o le cartelle elencate in additionalDirectories, ma dentro quel perimetro sì, anche rm. Se hai attivato acceptEdits perché eri stanco di confermare, hai anche detto sì alle cancellazioni. Quello che ti salva dal caso estremo è un interruttore separato, i percorsi critici: una cancellazione che punta a / o alla home, come rm -rf / o rm -rf ~, non viene mai approvata da una regola di allow né da un hook, in nessuna modalità, nemmeno quando è nascosta dentro una sostituzione di comando. Sulle modalità più recenti, incluso il controllo automatico che valuta le azioni al posto tuo, abbiamo un pezzo dedicato a la modalità Auto e i permessi degli agenti.

Togliere le richieste di permesso senza spegnere la sicurezza: il sandbox di Bash

Non usare la scorciatoia che ti verrà consigliata. Girando fra i tutorial troverai il flag che salta tutte le richieste di permesso, l’autore di Builder.io lo raccomanda apertamente per non «tornare cinque minuti dopo e trovarlo fermo a chiedere: posso modificare questo file?». È una posizione difendibile per chi ha anni di pratica e un ambiente isolato. Il primo giorno no. E soprattutto: su Pro o Max quel flusso continuo di conferme oggi non c’è, quindi il problema del primo giorno non è saltare i permessi, è sapere in quale modalità sei partito. Te lo dicono /status e la barra di stato, ⏵⏵ auto mode on oppure ⏸ manual mode on. Se poi vuoi solo togliere di mezzo le conferme sui comandi che usi sempre, la strada è metterli in lista con /permissions — oppure, meglio ancora, quella che segue.

Questa è la parte più cambiata rispetto ai tutorial in circolazione, ed è la ragione per cui oggi «salto tutti i permessi» non è più l’unica alternativa al confermare ogni comando. Claude Code ha un sandbox integrato per lo strumento Bash che sposta il controllo di livello: invece di approvare comando per comando, dichiari una volta quali file e quali domini di rete i comandi possono toccare, e a farlo rispettare non è il modello ma il sistema operativo, per ogni comando e per ogni processo figlio.

La differenza è tutta lì, ed è la stessa lezione del disastro Replit citato più sopra: un blocco che vive solo nelle istruzioni è un blocco che un modello può violare, un blocco imposto dal kernel no. È lo stesso principio che avevamo messo in fila parlando di come si configura un agente AI in modo sicuro.

Come si accende il sandbox, e cosa serve avere installato

Il sandbox gira su macOS, Linux e WSL2. Su Windows nativo non è supportato: se vuoi usarlo lì, devi far girare Claude Code dentro una distribuzione WSL2. Su macOS non c’è niente da installare, perché usa il framework Seatbelt già presente nel sistema. Su Linux e WSL2 servono due pacchetti, bubblewrap per l’isolamento del filesystem e socat per instradare il traffico di rete:

sudo apt-get install bubblewrap socat

Poi, dentro la sessione, un comando solo:

/sandbox

Il pannello che si apre ha tre schede — Mode, dove scegli fra «auto-allow» (i comandi sandboxati girano senza chiedere) e «regular permissions» (le conferme restano anche dentro il sandbox); Overrides, che decide se un comando che fallisce sotto sandbox può ripiegare sull’esecuzione non isolata; e Config, che mostra le impostazioni risolte. Se ne vedi comparire una quarta, Dependencies, vuol dire che manca un pacchetto: installalo, riavvia Claude Code e rilancia /sandbox, perché il controllo delle dipendenze avviene solo all’avvio.

La modalità che scegli nel pannello viene salvata nelle impostazioni locali del progetto, in .claude/settings.local.json. Per accenderlo su tutti i progetti, metti sandbox.enabled a true in ~/.claude/settings.json.

Cosa vede e cosa non vede un comando dentro il sandbox

Di default un comando sandboxato può scrivere nella working directory, nella cartella temporanea della sessione e nelle directory che hai aggiunto con --add-dir, /add-dir o permissions.additionalDirectories. Sulla rete la prima connessione verso un dominio nuovo chiede conferma, o passa dal classificatore se sei in auto mode.

Due dettagli che conviene conoscere prima di fidarsi. Il primo: i comandi che non possono girare sandboxati ricadono sul flusso normale dei permessi, e li riconosci perché la richiesta si intitola «Bash command (unsandboxed)» invece di «Bash command» — quella parola fra parentesi è l’informazione più utile della schermata. Il secondo, ed è una degradazione silenziosa: se il sandbox non riesce a partire perché mancano le dipendenze o la piattaforma non è supportata, di default Claude Code mostra un avviso ed esegue i comandi senza isolamento. Se il sandbox per te è un requisito e non un comfort, imposta sandbox.failIfUnavailable a true e trasformalo in un errore vero.

Sandbox e auto mode sono indipendenti e si combinano: il primo decide cosa un comando può raggiungere una volta partito, il secondo se ti viene chiesto prima di partire. La combinazione più sensata per il primo giorno su Mac o Linux è modalità Manual più sandbox in auto-allow: nessun classificatore di mezzo, poche conferme, e un confine che non dipende dal buon comportamento del modello.

Claude Code e la trifecta letale: il rischio che nasce dagli strumenti esterni

La terza cosa da sapere il primo giorno non è un’impostazione, è una combinazione. Simon Willison la chiama «trifecta letale»: accesso a dati privati, esposizione a contenuti non fidati e possibilità di comunicare verso l’esterno. Presi singolarmente sono innocui; insieme sono una fuga di dati che si attiva da sola, perché il modello «non segue soltanto le nostre istruzioni».

Un agente che legge il tuo repository, apre una pagina web e può fare una chiamata di rete ha tutti e tre gli ingredienti, ed è la configurazione più comune, non un caso limite. È anche il motivo per cui vale la pena essere selettivi con gli strumenti esterni che gli colleghi: se stai valutando di aggiungerne, parti da il Model Context Protocol con cui si collegano gli strumenti, perché ogni server che aggiungi allarga la superficie di attacco senza che nessuna richiesta di permesso te lo segnali in modo evidente. È anche l’ingrediente su cui il sandbox del paragrafo precedente morde di più: l’isolamento di rete toglie il terzo lato del triangolo, e lo toglie a livello di sistema.

Gli inciampi delle prime ore, e come si scavalcano

Sono sempre gli stessi quattro o cinque, e la pagina ufficiale di troubleshooting li mappa uno per uno. Prima ancora di cercare lì, però, c’è un comando che nelle guide più vecchie non c’è e che oggi è il primo da provare: /doctor (alias /checkup) esegue un controllo completo dell’installazione, dice cosa non va e in molti casi lo sistema da solo.

command not found: claude subito dopo l’installazione. Non è fallita l’installazione: è il PATH che non include ancora la cartella dell’eseguibile. Chiudi e riapri il terminale prima di provare qualsiasi altra cosa, nella maggior parte dei casi basta.

syntax error near unexpected token '<', oppure un 403. Vuol dire che il comando di installazione ha ricevuto una pagina HTML invece di uno script: quasi sempre è un proxy aziendale o un filtro di rete in mezzo. Non insistere a rilanciare, cambia metodo di installazione.

Login e credenziali: gli inciampi meno ovvi di Claude Code

Il login non torna indietro dal browser. Succede sistematicamente in WSL2, nelle sessioni SSH e nei container, perché il browser non riesce a raggiungere il server locale di callback. La soluzione è già prevista: il browser mostra un codice, tu lo incolli nel terminale al prompt che lo chiede.

Hai un abbonamento ma ti conta l’API. Se in ambiente è impostata la variabile ANTHROPIC_API_KEY, Claude Code salta il login e ti chiede di approvare la chiave, che una volta approvata ha la precedenza sull’abbonamento: ti ritrovi a consumare credito prepagato senza capire perché. unset ANTHROPIC_API_KEY e poi /status per verificare quale credenziale è attiva. Se invece i limiti sembrano più stretti del previsto, il comando che risponde davvero è /usage, che scompone il consumo per skill, subagent, plugin e server MCP; sul contesto più ampio abbiamo scritto a proposito dei limiti di utilizzo di Claude.

Quando le risposte peggiorano dopo un’ora: gestire la finestra di contesto

Non è il modello che si stanca: è la finestra di contesto che si riempie di roba vecchia. Due abitudini risolvono quasi tutto: /clear ogni volta che cambi argomento («non ti serve tutta quella cronologia che si mangia i token», scrive Builder.io) e l’apertura di una sessione nuova quando il contesto è al 40-50%. E ricorda che per fermarlo si preme Esc, non Ctrl+C: Ctrl+C ti fa perdere la sessione.

Un’ultima nota di realismo: il repository pubblico di Claude Code ha migliaia di issue aperte, in gran parte su funzioni avanzate. È uno strumento che si muove molto in fretta — abbastanza da avere un digest settimanale delle novità, che è il posto giusto dove controllare se una guida che stai seguendo (compresa questa) è rimasta indietro. Se qualcosa si comporta in modo strano, prima di dare la colpa a te stesso vale la pena cercare in quei due posti.

Dal «l’ho fatto girare sul portatile» al passaggio in azienda

Il primo giorno finisce bene quando hai fatto una modifica piccola, l’hai capita, e sai esattamente cosa l’agente poteva e non poteva toccare. Il passo successivo, quello che quasi sempre arriva una settimana dopo, è: se funziona per me, come lo do a un team?

La differenza fra i due mondi non è la licenza: è che in azienda i permessi non possono essere una scelta individuale. La documentazione su identità e accessi prevede impostazioni gestite centralmente per imporre standard organizzativi, configurazioni di permesso condivise via controllo di versione, container di sviluppo per isolare l’esecuzione e metriche OpenTelemetry per monitorare l’uso. A queste si aggiunge la leva che il primo giorno non serve e in azienda sì: il sandbox si può imporre via managed settings, così nessuno degli sviluppatori può lavorare senza isolamento. Sono le cinque leve che servono per non ritrovarsi con dieci sviluppatori e dieci politiche di sicurezza diverse. E se la domanda che arriva dall’alto è «quanto ci stiamo guadagnando», il punto di partenza è lo stesso di ogni adozione di AI generativa: quando l’AI generativa non genera ROI, il problema quasi mai è la tecnologia.

Da usare Claude Code a costruire agenti sui processi dell’azienda

C’è poi il salto successivo, che è di natura diversa: smettere di usare un agente e cominciare a costruirne uno sui processi dell’azienda, l’assistenza, la revisione del codice, l’elaborazione di documenti. Lì non si parla più di CLI ma di Agent SDK, e la domanda diventa quanto di quel lavoro si può fare in casa: ne abbiamo discusso in Claude Agent SDK per PMI: quando serve un partner. Nel frattempo, se vuoi consolidare le basi in modo strutturato, Anthropic pubblica un corso ufficiale gratuito pensato proprio per chi non ha mai usato un agente di programmazione.

Una raccomandazione finale, che è la sintesi di tutto il pezzo: il primo giorno non serve a scoprire quanto è potente lo strumento. Serve a scoprire dove va messo il confine. La potenza si vede da sola nelle settimane successive; il confine, se non lo decidi tu il primo giorno, non lo decide più nessuno.

Fonti:

• Claude Code, Quickstart (documentazione ufficiale Anthropic)
• Claude Code, Security (documentazione ufficiale Anthropic)
• Claude Code, Choose a permission mode (documentazione ufficiale Anthropic)
• Claude Code, Configure the sandboxed Bash tool (documentazione ufficiale Anthropic)
• Claude Code, Identity and Access Management (impostazioni gestite in azienda)
• Claude Code, Troubleshoot installation and login
• Claude Code, What’s new (digest settimanale delle novità)
• Anthropic Engineering, Claude Code best practices
• Anthropic, Claude Agent SDK: overview
• Builder.io, How I use Claude Code (+ my best tips)
• freeCodeCamp, The Claude Code Handbook
• Simon Willison, The lethal trifecta for AI agents
• METR, Measuring the impact of early-2025 AI on experienced open-source developer productivity
• Tom’s Hardware, AI coding platform deletes entire company database during code freeze
• Anthropic, Claude Code 101 (corso ufficiale gratuito)
• anthropics/claude-code, Issue tracker pubblico