Claude Code è uno degli strumenti AI più interessanti per chi lavora con codice, automazioni e infrastruttura.
Ma è anche uno di quelli da maneggiare con più attenzione.
Perché qui non parliamo più di una chat che suggerisce testi o riassume documenti.
Parliamo di un agente che può leggere file, modificare codice, usare il terminale, eseguire comandi, lanciare test, lavorare con Git, analizzare log e intervenire su repository reali.
Per uno sviluppatore esperto è una leva enorme.
Per chi gestisce siti, automazioni, script, plugin o applicazioni può diventare un acceleratore molto concreto.
Per un’attività senza regole può diventare un rischio.
Il problema non è Claude Code in sé.
Il problema è usarlo come se fosse una normale chat.
Non lo è.
Claude Code non è “AI che scrive codice”
Molti lo descrivono così:
“È Claude per programmare.”
È una semplificazione pericolosa.
Claude Code non si limita a suggerire snippet.
Può lavorare dentro un progetto, leggere più file, capire dipendenze, proporre modifiche, eseguire test, mostrare diff, usare comandi e aiutare in attività tecniche complesse.
Questo cambia il modo di lavorare.
Uno sviluppatore può chiedere:
“Analizza questa codebase e spiegami l’architettura.”
Oppure:
“Trova perché questo endpoint restituisce errore 500.”
Oppure:
“Scrivi test per questo modulo, eseguili e correggi gli errori.”
Oppure ancora:
“Controlla le modifiche prima della pull request e segnalami rischi di sicurezza.”
Sono attività vere.
Non brainstorming.
Il rischio: dare potere operativo senza regole
Quando un agente può modificare file ed eseguire comandi, la domanda non è solo:
“Quanto è bravo?”
La domanda è:
“Cosa gli permettiamo di fare?”
Può cancellare file?
Può modificare configurazioni?
Può lanciare deploy?
Può toccare database?
Può leggere file con segreti?
Può cambiare dipendenze?
Può eseguire comandi shell senza approvazione?
In un progetto personale puoi anche sperimentare.
Su un sito cliente, su un e-commerce, su un’applicazione o su automazioni usate ogni giorno, no.
Serve un sistema di permessi, regole, istruzioni e limiti.
Qui entrano in gioco file come CLAUDE.md, configurazioni globali, configurazioni di progetto, skills, subagents, hooks e permission mode.
Sembra tanta roba.
In realtà il principio è semplice: Claude Code deve sapere come lavorare e cosa non deve fare.
CLAUDE.md: il manuale operativo del progetto
Il file CLAUDE.md è una delle prime cose che configurerei in un repository importante.
È il documento che spiega a Claude come comportarsi in quel progetto.
Non deve essere un poema.
Deve contenere informazioni utili.
Per esempio:
quali comandi usare per installare dipendenze,
come avviare il progetto,
come lanciare test,
quali cartelle contengono frontend, backend o componenti condivisi,
quali file non vanno toccati senza approvazione,
quali regole seguire prima di considerare una task completata.
Un esempio pratico:
“Usa pnpm, non npm. Prima di completare una modifica esegui lint e test. Non modificare lo schema del database senza proporre prima una migration. Non toccare la cartella legacy senza chiedere.”
Queste istruzioni riducono errori stupidi.
E soprattutto evitano che ogni sessione parta da zero.
Per chi lavora su progetti tecnici, CLAUDE.md è una forma di memoria operativa condivisa.
Configurazione globale e configurazione di progetto
Claude Code può lavorare con istruzioni personali globali e istruzioni specifiche del progetto.
Questa distinzione è importante.
Le preferenze personali dell’utente vanno nel livello globale.
Le regole del repository vanno nel progetto.
Esempio.
A livello globale posso dire:
“Prima di modificare codice, spiegami il piano.”
Oppure:
“Non eseguire comandi distruttivi senza conferma.”
A livello progetto invece posso dire:
“Questo repository usa Laravel, PHP 8.3, Pest per i test e una pipeline specifica di deploy.”
Mescolare tutto crea confusione.
Le istruzioni personali non dovrebbero stare nel repository.
Le regole del repository non dovrebbero dipendere dalla memoria privata di un singolo sviluppatore.
Questa separazione rende il setup più chiaro, condivisibile e facile da mantenere.
Skills e subagents: quando il progetto cresce
All’inizio basta un buon CLAUDE.md.
Poi, quando il lavoro si ripete, ha senso introdurre Skills e subagents.
Una Skill può descrivere una procedura tecnica ricorrente.
Per esempio:
audit WordPress,
debug webhook,
review sicurezza,
check performance WooCommerce,
deploy checklist,
analisi log server,
verifica automazioni n8n.
Un subagent invece è un agente specializzato con un ruolo preciso.
Per esempio:
un security reviewer che può leggere codice ma non modificarlo,
un QA tester che esegue test e controlli,
un WordPress debugger che sa come ragionare su plugin, log, WP-CLI e hosting,
un reviewer che controlla diff prima della pull request.
Qui il valore non è “fare scena”.
Il valore è dividere i compiti.
Un agente che fa tutto tende a essere troppo generico.
Un agente specializzato, con limiti chiari, produce risultati più controllabili.
Hooks: regole automatiche, non promemoria
Gli hooks servono quando vuoi che certe azioni avvengano sempre.
Per esempio:
dopo una modifica PHP, esegui php -l sul file,
dopo una modifica JavaScript, esegui lint,
prima di completare una task, mostra il diff,
quando viene proposto un comando rischioso, bloccalo,
dopo una modifica importante, invia una notifica.
La differenza tra Skill e Hook è questa.
La Skill dice a Claude come lavorare.
L’Hook impone una regola automatica.
In un ambiente tecnico gli hook sono utili perché tolgono discrezionalità su controlli minimi.
Non devi sperare che Claude si ricordi di lanciare un test.
Glielo fai fare sempre.
Mini-scenario: debug di un webhook che restituisce errore 400
Immagina un sito WordPress con FunnelKit, GTM e un webhook che ogni tanto restituisce errore 400 quando arrivano utenti con parametri UTM.
Un approccio improvvisato sarebbe:
“Claude, perché succede?”
Risposta generica, tante ipotesi, poca utilità.
Con Claude Code configurato bene, il flusso può essere molto più concreto.
Claude legge il repository o i file del plugin custom.
Controlla log e chiamate.
Cerca dove vengono gestiti parametri UTM.
Verifica se ci sono limiti su header, cookie, query string o payload.
Propone una patch.
Esegue test o almeno controlli statici.
Mostra il diff finale.
Ma attenzione: tutto questo deve avvenire in ambiente controllato, non direttamente in produzione senza backup.
Qui la differenza la fa la configurazione: permessi, deny list, istruzioni, branch di lavoro, test e revisione umana.
Claude Code è utile proprio perché può accelerare il debug.
Non perché deve diventare libero di toccare tutto.
Permission mode: partire prudenti
Per utenti nuovi, io partirei sempre con modalità prudenti.
Meglio far pianificare prima.
Meglio chiedere approvazione sulle modifiche.
Meglio evitare comandi distruttivi.
Meglio vietare deploy produzione, reset database, cancellazioni massive, invii email e modifiche su file sensibili senza conferma esplicita.
La tentazione è togliere tutti i limiti per “far lavorare l’agente”.
È una pessima idea.
Soprattutto quando si lavora su siti, server, automazioni di produzione o dati cliente.
Un buon setup di Claude Code deve bilanciare velocità e controllo.
Se controlli tutto manualmente, perdi parte del vantaggio.
Se non controlli niente, aumenti il rischio.
Dove Claude Code porta più ROI
Claude Code porta valore soprattutto dove ci sono attività tecniche ripetitive o diagnostiche.
Per esempio:
capire una codebase ereditata,
scrivere test mancanti,
analizzare log,
fare review di pull request,
preparare refactor piccoli,
controllare sicurezza di modifiche,
creare script interni,
debuggare automazioni,
documentare repository,
generare checklist di deploy,
aiutare sviluppatori junior a orientarsi.
Non lo userei subito per riscrivere un intero sistema.
Non lo userei alla cieca su produzione.
Non lo userei per modifiche architetturali senza revisione tecnica.
Lo userei invece come acceleratore dentro un processo già governato.
Perché serve una figura tecnica che configuri il sistema
Installare Claude Code è la parte facile.
Il lavoro serio è decidere come deve operare.
Quali repository può vedere?
Quali comandi può eseguire?
Quali file non deve toccare?
Quali test deve lanciare?
Come si gestiscono branch e pull request?
Chi approva le modifiche?
Come si evitano segreti nel contesto?
Come si separano clienti e progetti?
Come si documentano le regole?
Queste sono decisioni tecniche e operative, non semplici impostazioni da spuntare.
Per questo Claude Code non dovrebbe essere introdotto come “tool AI per scrivere codice” e basta.
Dovrebbe essere introdotto come parte di una strategia tecnica.
Piccola, concreta, controllata.
Il setup minimo che consiglierei
Per partire in modo serio, configurerei almeno:
un CLAUDE.md per ogni repository importante,
permessi prudenti,
regole su comandi vietati,
branch dedicati per le modifiche AI-assisted,
review umana obbligatoria prima del merge,
skill tecniche per attività ricorrenti,
eventuali hook per test, lint e controlli minimi,
separazione tra configurazione globale dell’utente e configurazione del progetto.
Non serve fare tutto il primo giorno.
Ma serve sapere dove si sta andando.
Il rischio, altrimenti, è usare Claude Code per qualche settimana con entusiasmo e poi abbandonarlo perché “fa cose strane”.
Spesso non fa cose strane.
È semplicemente stato configurato male.
Se vuoi introdurre Claude Code nei tuoi progetti tecnici, nelle automazioni o nel lavoro su siti e applicazioni senza mettere a rischio repository, dati e server, puoi partire da qui:
https://michelerocco.com/supporto-tecnico-strategico-per-pmi/
Vediamo quali progetti ha senso configurare, quali permessi servono, quali attività possono essere accelerate e quali invece devono restare sotto controllo umano.
FAQ
Claude Code può modificare direttamente il codice del mio progetto?
Serve essere sviluppatori per usare Claude Code?
Cos’è il file CLAUDE.md?
Claude Code può essere usato su WordPress e WooCommerce?
Qual è il primo caso d’uso consigliato?
