Sicurezza e qualità¶
Il capitolo 4 ha proposto un framework per decidere se un progetto è adatto al vibe coding, valutando otto dimensioni di rischio prima di iniziare. Questo capitolo si occupa di ciò che viene dopo: come proteggere un progetto una volta che si è deciso di costruirlo.
Il punto di partenza è una constatazione pratica: non tutti i progetti richiedono le stesse attenzioni. Un convertitore di PDF che gira sulla propria macchina e un'applicazione che gestisce pagamenti online hanno profili di rischio radicalmente diversi, e trattarli allo stesso modo produce due effetti ugualmente dannosi. Chi costruisce un piccolo tool personale si spaventa inutilmente di fronte a checklist pensate per applicazioni complesse. Chi costruisce qualcosa di più ambizioso si convince di aver fatto abbastanza dopo qualche controllo superficiale. La prima cosa da fare, prima ancora di parlare di rischi e contromisure, è capire a che livello si colloca il proprio progetto.
Quattro livelli di attenzione¶
La scala che segue aiuta a collocare ciascun progetto nel livello di attenzione appropriato. Ogni gradino aggiunge responsabilità rispetto al precedente, e l'ultimo rappresenta un confine netto: oltre quel punto, le competenze insegnabili in questo manuale non bastano più.
Lo uso solo io, senza dati sensibili¶
È il caso più semplice e probabilmente il più frequente per chi inizia. Un'applicazione che gira sulla propria macchina, non gestisce credenziali né dati personali di altri, e non è destinata alla condivisione. Il convertitore PDF→markdown del capitolo 5 è un esempio perfetto: riceve un file, lo trasforma, restituisce il risultato. Se qualcosa non funziona, l'unica persona coinvolta è chi lo ha costruito.
A questo livello i controlli di sicurezza sono sostanzialmente assenti. Se l'applicazione funziona come previsto, funziona. L'unica accortezza riguarda chi usa GitHub come backup personale, tenendo il repository privato. Anche in quel caso è buona pratica controllare che il codice non contenga chiavi API o token di accesso a servizi esterni. Un repository privato può diventare pubblico per un clic sbagliato, un account può essere compromesso, e le credenziali che sembravano al sicuro diventano esposte. È un controllo che richiede pochi minuti prima del primo caricamento, e il capitolo spiega come farlo nella sezione sui controlli concreti.
Lo condivido gratuitamente¶
Il progetto viene pubblicato su GitHub o condiviso con altre persone, ma resta gratuito e non gestisce dati sensibili. La Agent Discussion Arena del capitolo 6 rientra in questa categoria: chiunque può scaricarla e usarla, ma non raccoglie informazioni personali né richiede credenziali.
Il passaggio dalla macchina personale alla condivisione pubblica cambia il quadro in modo sottile ma significativo. Altre persone useranno l'applicazione fidandosi del fatto che faccia quello che dichiara di fare, e niente di più. Questo comporta alcune responsabilità minime: una documentazione che spieghi cosa fa il progetto e come usarlo, una licenza che chiarisca i termini di utilizzo, e una revisione di sicurezza di base prima della pubblicazione. Quest'ultimo punto merita attenzione perché è facile da trascurare: quando si sviluppa per se stessi, un piccolo difetto è un inconveniente; quando altre persone usano il proprio codice, lo stesso difetto diventa un problema di cui si è responsabili.
Lo vendo o ci costruisco un servizio¶
Il progetto diventa un prodotto commerciale o la base di un servizio a pagamento. Non gestisce ancora dati sensibili, ma il fatto che qualcuno paghi per usarlo cambia la natura delle responsabilità.
È il punto in cui molti vibe coder non si fermano a riflettere, presi dall'entusiasmo di avere qualcosa che funziona e che potrebbe generare un ritorno economico. Ma vendere un prodotto software o offrire un servizio basato su codice porta con sé obblighi che il codice condiviso gratuitamente non ha. Le responsabilità che entrano in gioco includono gli obblighi fiscali legati all'attività commerciale, la necessità di termini di servizio che definiscano cosa il prodotto fa e cosa no, l'aspettativa di affidabilità da parte di chi paga (un'applicazione gratuita che si blocca è un inconveniente, un servizio a pagamento che si blocca è un inadempimento), la responsabilità verso il cliente in caso di malfunzionamenti, e la conformità alle normative applicabili, che variano in base al settore e al tipo di servizio.
Questo manuale non è il luogo per approfondire ciascuno di questi aspetti, ma è il luogo per dire che esistono. Chi arriva a questo livello ha costruito qualcosa di valore, e il passo successivo non è solo tecnico, è imprenditoriale. Informarsi su questi obblighi prima di iniziare a vendere non è prudenza eccessiva, è il minimo necessario.
Gestisce dati sensibili¶
Il progetto tratta credenziali, dati personali di terzi, informazioni di pagamento, dati sanitari, o qualsiasi altra informazione la cui esposizione causerebbe un danno concreto a qualcuno. A questo livello non conta se l'applicazione la usa una sola persona o un milione: la presenza di dati sensibili cambia radicalmente il profilo di rischio.
Un esempio chiarisce perché. Un'applicazione personale che si collega al proprio conto bancario per aggregare le spese mensili è usata da una sola persona, non è condivisa, non è in vendita. Ma contiene le credenziali di accesso al conto. Se il codice ha una vulnerabilità che espone quelle credenziali, le conseguenze sono le stesse che avrebbe una falla in un'applicazione pubblica: il danno economico è reale, e il fatto che il progetto sia "solo personale" non lo attenua.
Qui il messaggio è netto: far rivedere il codice a un professionista esperto di quel tipo di applicazione. Non "è consigliabile", non "sarebbe meglio": è necessario. Questo manuale può insegnare a riconoscere i rischi e a prendere alcune precauzioni di base, ma non può sostituire la competenza di chi sa leggere il codice con l'occhio allenato a individuare le vulnerabilità specifiche del dominio. Un'applicazione che gestisce dati bancari richiede un esperto di sicurezza finanziaria. Un'applicazione che tratta dati sanitari richiede un esperto di conformità sanitaria. La competenza di sicurezza non è generica, è specifica al settore.
Questo non significa rinunciare al vibe coding per questi progetti. Significa che il vibe coding produce il prototipo e la struttura, ma prima di usare l'applicazione con dati reali il codice passa attraverso una revisione professionale. È lo stesso principio dello spettro della delega introdotto nel capitolo 1: delegare la costruzione non significa delegare la responsabilità.
Cosa può andare storto¶
I dati della ricerca offrono un quadro di riferimento utile. Il 2025 GenAI Code Security Report di Veracode ha testato oltre cento modelli linguistici su ottanta compiti di programmazione in quattro linguaggi diversi, riscontrando che il 45% del codice generato conteneva vulnerabilità classificate nella OWASP Top 10, la lista delle dieci categorie di rischio più critiche per le applicazioni web. Il dato non è migliorato nelle rilevazioni successive fino a inizio 2026, nonostante i progressi dei modelli in altri ambiti. Separatamente, il State of Secrets Sprawl 2026 di GitGuardian, analizzando milioni di commit pubblici su GitHub nel 2025, ha mostrato che il codice scritto con l'assistenza di strumenti AI espone credenziali con una frequenza doppia rispetto al codice scritto senza assistenza AI.
Questi numeri riguardano sviluppatori professionisti che usano strumenti AI nel loro lavoro quotidiano. Per chi non programma e delega interamente la scrittura del codice, il rischio non è minore, è semplicemente meno visibile. Uno sviluppatore che riceve codice insicuro ha almeno la possibilità di riconoscerlo. Chi non sa leggere il codice si fida del fatto che funzioni, e "funziona" non significa "è sicuro".
I problemi più frequenti rientrano in tre categorie che vale la pena conoscere, non per saperli risolvere tecnicamente, ma per sapere che esistono e poterli nominare quando si chiede una revisione.
Credenziali nel codice¶
È il problema più comune e il più facile da prevenire, eppure continua a essere la causa di incidenti seri. Quando si costruisce un'applicazione che si collega a un servizio esterno, quel collegamento richiede quasi sempre una chiave di accesso, che può essere una chiave API, un token, o una combinazione di nome utente e password. Queste credenziali funzionano esattamente come le chiavi di casa: chi le possiede entra.
Il rischio nasce da come queste credenziali finiscono nel codice. Quando si chiede a Claude di costruire un'applicazione che si collega a un servizio, il codice generato spesso include la credenziale direttamente nel testo del programma, come se fosse un dato qualsiasi. Finché il codice resta sulla propria macchina il problema non si pone. Ma nel momento in cui viene caricato su un repository, anche privato, quelle credenziali esistono in un luogo diverso dal proprio computer, e il livello di rischio cambia.
L'analisi di GitGuardian ha documentato oltre 28 milioni di credenziali inserite direttamente nel codice pubblico su GitHub nel solo 2025, con un aumento del 34% rispetto all'anno precedente. Il dato più preoccupante riguarda la persistenza dell'esposizione: quasi il 70% delle credenziali identificate come valide nel 2022 risultava ancora attivo a distanza di tre anni. Chi espone una chiave API e non se ne accorge lascia una porta aperta per anni.
Una precauzione pratica per chi inizia è scegliere servizi che offrano chiavi API di test o sandbox, distinte da quelle di produzione, e che non abbiano la ricarica automatica abilitata. In questo modo, anche se la chiave finisce accidentalmente nel codice, il danno potenziale è limitato. È un'abitudine semplice da adottare fin dal primo progetto, e che diventa naturale con il tempo.
Dati esposti dove non dovrebbero essere¶
Questo problema è più sottile del precedente e più difficile da individuare per chi non programma. Riguarda la differenza tra ciò che succede "dietro le quinte" di un'applicazione, la parte che l'utente non vede, e ciò che arriva al browser o all'interfaccia visibile.
Un esempio concreto aiuta a capire. Si immagini di costruire una piccola applicazione web per raccogliere le iscrizioni a un evento. I partecipanti compilano un modulo con nome, email e numero di telefono. L'organizzatore ha una pagina riservata dove vede l'elenco delle iscrizioni. Se il codice è scritto senza attenzione, potrebbe rendere accessibili tutti i dati delle iscrizioni a chiunque conosca l'indirizzo della pagina, anche senza autenticazione. Oppure potrebbe inviare al browser informazioni in eccesso rispetto a quelle visualizzate, dati che l'interfaccia non mostra ma che sono presenti nella pagina e accessibili a chiunque sappia dove guardare.
Il codice generato dalle AI tende a questo tipo di errore perché ottimizza per il risultato visibile. Se l'interfaccia mostra le informazioni giuste, il compito sembra completato. La distinzione tra "mostra correttamente" e "protegge adeguatamente" richiede un'attenzione che il modello non ha se non gliela si chiede esplicitamente.
Input non controllati¶
Ogni applicazione che riceve informazioni dall'esterno, che si tratti di un campo di testo dove l'utente scrive il proprio nome o di un modulo di ricerca, deve decidere cosa fare con quelle informazioni. Il problema nasce quando l'applicazione accetta qualsiasi cosa le venga inviata senza verificarla.
L'analogia più intuitiva è una cassetta delle lettere che accetta qualsiasi oggetto, non solo le lettere. Se qualcuno inserisce qualcosa di diverso da una lettera, l'effetto dipende da cosa c'è dall'altra parte. Nella migliore delle ipotesi non succede nulla, nella peggiore il meccanismo si inceppa o si danneggia. Nel caso delle applicazioni, "inserire qualcosa di diverso" significa inviare al programma istruzioni mascherate da dati normali, che il programma esegue senza distinguerle dai dati legittimi.
Due delle vulnerabilità più frequenti nel codice generato da AI rientrano in questa categoria. Veracode ha rilevato che l'86% dei campioni di codice testati non proteggeva adeguatamente contro uno di questi attacchi, e l'88% era vulnerabile all'altro. Sono percentuali che riguardano il codice generato da oltre cento modelli linguistici diversi, non un singolo strumento.
Anche qui, l'obiettivo non è diventare esperti di queste vulnerabilità. È sapere che il codice che accetta dati dall'esterno senza controllarli è codice a rischio, e che quando si chiede una revisione di sicurezza questo è uno dei punti da verificare.
I controlli che si possono fare¶
La sezione precedente ha descritto i problemi. Questa si occupa delle contromisure alla portata di chi non programma, graduate sui livelli di attenzione definiti all'inizio del capitolo. Nessuna di queste azioni sostituisce una revisione professionale per i progetti che la richiedono, ma ciascuna riduce il rischio in modo concreto e misurabile.
La revisione di sicurezza con Claude¶
Il modo più diretto per verificare la sicurezza di un progetto è chiedere a Claude di analizzarlo, ma con un accorgimento importante: farlo in una sessione separata da quella in cui si è costruito il progetto. Nella sessione di costruzione, Claude ha il contesto di tutte le scelte fatte durante lo sviluppo e tende a confermarne la validità piuttosto che metterle in discussione. Una sessione nuova parte senza quel contesto e guarda il codice con maggiore distacco critico, come farebbe un revisore diverso dallo sviluppatore.
Ancora meglio è spostare la revisione in Cowork o in Code, dove è possibile utilizzare plugin dedicati alla revisione del codice e all'analisi di sicurezza. In questi ambienti Claude accede direttamente ai file del progetto e può condurre una revisione sistematica, invece di lavorare su frammenti di codice copiati nella conversazione. Il plugin Code Review, costruito e verificato da Anthropic, offre una revisione con agenti specializzati e un filtro basato su livelli di confidenza che aiuta a distinguere i problemi reali dai falsi allarmi. In Code è disponibile anche il comando /security-review, integrato senza bisogno di installare nulla, che analizza il progetto cercando le vulnerabilità più comuni: SQL injection, XSS, problemi di autenticazione, gestione insicura dei dati e vulnerabilità nelle dipendenze.
Oltre ai plugin di Anthropic, la pagina claude.com/plugins ospita plugin di terze parti che non sono verificati da Anthropic ma estendono le capacità di revisione. Semgrep individua vulnerabilità in tempo reale e guida Claude a scrivere codice sicuro fin dall'inizio. CodeRabbit esegue revisioni del codice con oltre quaranta analizzatori, inclusi controlli di sicurezza. Aikido Security offre scansioni per credenziali esposte e vulnerabilità nell'infrastruttura. Il catalogo si evolve rapidamente, e vale la pena cercarne di nuovi al momento in cui si legge.
La richiesta di revisione, che si usi un plugin o una semplice conversazione, va formulata in modo esplicito. Ad esempio: "Analizza questo progetto per vulnerabilità di sicurezza. Controlla in particolare se ci sono credenziali nel codice, dati esposti al client che dovrebbero restare sul server, e input non validati". Specificare cosa cercare è importante perché, come ha mostrato uno studio di Backslash Security, i modelli linguistici generano codice significativamente più sicuro quando ricevono indicazioni esplicite sulla sicurezza. Lo stesso principio vale per la revisione: una richiesta generica produce una revisione generica, una richiesta specifica produce risposte più utili.
Il risultato va letto con un'avvertenza importante. Anche in una sessione separata, anche con l'aiuto dei plugin, è sempre Claude che rivede codice generato da Claude. È una verifica utile, non una garanzia. Claude può individuare errori evidenti, segnalare pattern rischiosi e suggerire miglioramenti concreti. Ma condivide con l'istanza che ha scritto il codice gli stessi schemi ricorrenti e gli stessi punti ciechi. Per i progetti di livello due e tre della scala, questa revisione interna è un primo passo, non l'ultimo.
Le regole nel CLAUDE.md¶
I capitoli 4 e 7 hanno spiegato cosa è il file CLAUDE.md e come usarlo per guidare il comportamento di Claude durante la costruzione di un progetto. In questo contesto, il CLAUDE.md diventa uno strumento di sicurezza preventiva, perché permette di stabilire regole che Claude applica fin dall'inizio, senza doverle ripetere a ogni richiesta.
Alcune regole di sicurezza efficaci da inserire nel CLAUDE.md di un progetto:
- Non inserire mai credenziali, chiavi API o token direttamente nel codice. Usare sempre variabili d'ambiente.
- Validare tutti gli input ricevuti dall'esterno prima di utilizzarli.
- Non inviare al client dati che non sono strettamente necessari per la visualizzazione.
- Richiedere conferma esplicita prima di qualsiasi operazione che cancella o modifica dati in modo irreversibile.
- Se il progetto usa Git, creare un file .gitignore che escluda i file contenenti credenziali (file .env, file di configurazione locale) dal repository.
Non servono competenze di programmazione per scrivere queste regole. Sono indicazioni in linguaggio naturale che Claude interpreta e applica durante la generazione del codice. La differenza tra un progetto con queste regole e uno senza è la stessa che c'è tra un artigiano che lavora con una lista di controlli e uno che si affida alla memoria.
I permessi come protezione¶
Il capitolo 3 ha descritto i livelli di permesso disponibili in Cowork e in Code. In quel contesto la discussione riguardava la comodità operativa, il modo in cui ciascun livello bilancia autonomia di Claude e controllo dell'utente. Ma quei livelli di permesso sono anche una misura di sicurezza, probabilmente la più immediata a disposizione di chi fa vibe coding.
Il principio è quello del privilegio minimo: dare a Claude solo i permessi necessari per il compito in corso, e niente di più. Se Claude sta scrivendo un file di documentazione, non ha bisogno di poter cancellare cartelle. Se sta modificando l'interfaccia di un'applicazione, non ha bisogno di accedere ai file di configurazione del server. In Cowork, la finestra di autorizzazione chiede conferma prima di ogni azione sul filesystem. In Code, il menu a tendina offre quattro livelli di autonomia, dalla richiesta di autorizzazione per ogni operazione fino all'esecuzione libera senza conferme.
La scelta del livello giusto dipende dalla fase di lavoro e dal livello di rischio del progetto. Per i progetti dei livelli zero e uno della scala, un approccio più permissivo accelera il lavoro senza rischi significativi. Per i livelli due e tre, mantenere i permessi restrittivi e autorizzare esplicitamente ogni operazione è una protezione concreta contro errori accidentali, sia di Claude sia propri.
La qualità di ciò che non si vede¶
Le sezioni precedenti si sono concentrate sulla sicurezza, ovvero su ciò che può causare danni immediati e concreti. Questa sezione affronta un problema diverso, meno urgente ma altrettanto importante sul lungo periodo: la qualità interna del codice. Un'applicazione può funzionare perfettamente, superare tutti i controlli di sicurezza, e contenere al suo interno una struttura che la rende progressivamente più difficile da modificare, estendere e mantenere.
Il debito tecnico¶
Per capire il concetto, si pensi a una casa costruita in fretta. Le stanze funzionano, il tetto non perde, gli impianti sono a norma. Ma i muri interni sono stati messi dove era più comodo in quel momento, senza pensare a come si sarebbe usata la casa tra cinque anni. Quando si decide di unire due stanze o aggiungere un bagno, si scopre che i tubi passano proprio dove servirebbe abbattere un muro, e che un intervento che doveva essere semplice richiede di rifare mezzo piano.
Il codice generato dalle AI tende ad accumulare questo tipo di problema in modo caratteristico. Quando si chiede una nuova funzionalità, Claude spesso non modifica il codice esistente per integrarla in modo organico: aggiunge nuovo codice accanto a quello vecchio, duplicando logica che già esiste, creando percorsi paralleli che fanno la stessa cosa in modi leggermente diversi. Ogni singola aggiunta funziona, ma l'insieme diventa progressivamente più fragile. Modificare un punto richiede di modificarne altri tre, e ogni intervento rischia di rompere qualcosa che prima funzionava.
Uno studio pubblicato nel 2026 su ArXiv ha analizzato oltre 6.000 repository pubblici su GitHub contenenti codice generato da AI, riscontrando che il debito tecnico non risolto è cresciuto da poche centinaia di problemi a inizio 2025 a oltre 110.000 problemi a febbraio 2026. Il codice generato dalle AI non accumula solo vulnerabilità: accumula complessità strutturale a un ritmo accelerato rispetto al codice scritto manualmente.
Chiedere a Claude di migliorare¶
Il debito tecnico non è inevitabile. È il risultato di un modo di lavorare in cui si chiede sempre "aggiungi questa funzionalità" senza mai chiedere "adesso metti in ordine". Il lettore di questo manuale può contrastarlo con tre richieste concrete, da usare a ogni milestone significativa del progetto, ovvero ogni volta che un gruppo di funzionalità è completo e funzionante.
La prima richiesta è semplificare. "Ci sono parti di questo codice che fanno la stessa cosa in modi diversi? Unificale." Claude individua le duplicazioni e le consolida, riducendo i punti che dovranno essere modificati in futuro.
La seconda è rifattorizzare. "Il codice è cresciuto molto. Riorganizzalo per renderlo più chiaro e manutenibile, senza cambiare il suo comportamento." Rifattorizzare significa ristrutturare l'interno senza modificare l'esterno: l'applicazione continua a fare le stesse cose, ma il codice diventa più ordinato. È l'equivalente di riorganizzare i mobili in una stanza per avere più spazio, senza cambiare le pareti.
Per entrambe queste operazioni vale lo stesso accorgimento della revisione di sicurezza: è meglio farle in una sessione nuova, separata da quella di costruzione. Claude nella sessione dove ha scritto il codice tende a confermare le proprie scelte strutturali piuttosto che metterle in discussione. Una sessione nuova guarda il codice senza quel contesto e ristruttura con più libertà. In Cowork e in Code, il plugin Code Simplifier di Anthropic automatizza parte di questo lavoro, analizzando il codice modificato di recente e proponendo semplificazioni che preservano il comportamento dell'applicazione.
La terza è documentare. "Aggiungi commenti al codice che spieghino cosa fa ogni sezione principale e perché." La documentazione interna non serve a chi usa l'applicazione, serve a chi dovrà modificarla in futuro, che sia Claude in una sessione successiva, un altro strumento, o un professionista chiamato a intervenire. Senza documentazione, ogni modifica futura parte da zero nella comprensione del codice.
Queste tre richieste non richiedono competenze di programmazione. Richiedono solo la consapevolezza che il codice ha bisogno di manutenzione periodica, esattamente come qualsiasi altro prodotto del lavoro.
Quando servono competenze professionali¶
Il vibe coding funziona bene per una fascia di progetti che è più ampia di quanto molti pensino. Ma ha un confine, e riconoscerlo è una competenza in sé.
I segnali che un progetto ha superato la soglia del vibe coding si manifestano in modo graduale. Claude inizia a impiegare più tempo per ogni modifica, perché il codice è diventato complesso da navigare anche per lui. Le modifiche a una parte dell'applicazione rompono regolarmente altre parti che non si stavano toccando. Le sessioni di lavoro si riempiono di tentativi e correzioni, e il rapporto tra tempo investito e risultati ottenuti peggiora visibilmente. Ogni nuova funzionalità richiede workaround, soluzioni provvisorie che si sommano a quelle precedenti.
Quando si presentano questi segnali, il progetto non è fallito. Ha raggiunto un livello di complessità che richiede competenze diverse da quelle che il vibe coding può offrire. Lo spettro della delega introdotto nel capitolo 1 descrive esattamente questa situazione: la capacità di verificare il risultato (il terzo livello dello spettro) non è sufficiente quando il problema è strutturale, interno al codice, e non si manifesta come un difetto visibile ma come una crescente resistenza al cambiamento.
A questo punto le strade possibili sono due. La prima è coinvolgere un professionista che rifattorizzi il codice, mettendo ordine nella struttura accumulata e creando una base solida per la crescita successiva. La seconda, per i progetti dove la complessità è andata troppo oltre, è ricominciare la costruzione con una specifica migliore, informata da tutto ciò che si è imparato nella prima versione. In entrambi i casi, il lavoro fatto non è perso: ha prodotto una comprensione del problema che la versione precedente non aveva, e questa comprensione è il vero valore del progetto.