Gli assistenti di programmazione basati sull’intelligenza artificiale, come GitHub Copilot, Cursor, Claude Code o Gemini Code Assist, sono ormai nel lavoro quotidiano di molti team. Secondo lo Stack Overflow Developer Survey 2025 l’84% degli sviluppatori li usa o pensa di usarli; lo stesso sondaggio registra però che il 46% non si fida dell’accuratezza delle risposte, contro un 33% che si fida.
Per un’azienda la domanda quindi non è se usarli, ma come usarli senza abbassare la qualità del software che consegna. Nei nostri progetti partiamo da un principio semplice: l’AI propone, una persona decide. Il codice che va in produzione passa dagli stessi controlli, chiunque o qualunque cosa lo abbia scritto.
Vediamo dove questi strumenti aiutano, dove fanno danni e quali regole tengono alta la qualità.
Dove l’AI aiuta davvero
Gli assistenti danno il meglio sui compiti in cui il risultato è facile da verificare:
- Codice ripetitivo: il cosiddetto boilerplate, cioè le parti di struttura sempre uguali (classi di dati, mappature, configurazioni, chiamate alle API).
- Test: proporre casi di prova, compresi i casi limite che spesso si dimenticano. I test generati vanno letti: un test che conferma un comportamento sbagliato è peggio di nessun test.
- Refactoring: riorganizzare il codice senza cambiarne il comportamento, per esempio estrarre funzioni o aggiornare l’uso di una libreria, a piccoli passi.
- Documentazione: commenti, README, descrizioni delle pull request, note di rilascio.
- Codice legacy: farsi spiegare cosa fa una funzione scritta anni fa, senza documentazione, da chi non è più in azienda. È uno degli usi più utili e meno rischiosi, perché non modifica nulla.
Dove fa danni
Il rischio principale è il codice plausibile ma sbagliato: compila, sembra ragionevole e nasconde un errore di logica, un controllo mancante o una funzione di libreria che non esiste. Nel sondaggio di Stack Overflow il problema citato più spesso, dal 66% dei rispondenti, sono proprio le soluzioni dell’AI “quasi giuste, ma non del tutto”.
- Sicurezza: per il GenAI Code Security Report 2025 di Veracode oltre 100 modelli linguistici hanno svolto 80 compiti di programmazione; nel 45% dei casi il codice prodotto conteneva una vulnerabilità dell’elenco OWASP Top 10.
- Licenze: un suggerimento può riprodurre parti di progetti open source con licenze che impongono obblighi. Alcuni strumenti hanno un filtro per i suggerimenti che coincidono con codice pubblico: va attivato.
- Dati riservati: incollare in un prompt una chiave di accesso, dati personali o il codice di un cliente significa inviarli a un servizio esterno, con regole di conservazione e di uso che dipendono dal contratto.
- Produttività presunta: in uno studio controllato di METR (luglio 2025) 16 sviluppatori open source esperti, al lavoro su progetti che conoscevano bene, hanno impiegato il 19% di tempo in più con l’AI, pur convinti di essere andati più veloci. Il campione è piccolo e gli strumenti erano quelli di inizio 2025, ma il messaggio resta: la produttività va misurata, non data per scontata.
Le regole che tengono alta la qualità
Revisione umana su tutto
Ogni modifica entra con una pull request, cioè una richiesta di integrazione che un collega rivede prima del merge. Chi la apre deve saper spiegare ogni riga, comprese quelle proposte dall’assistente. Chi la rivede controlla la logica e i casi limite, non solo lo stile.
Test automatici e integrazione continua
La CI (continuous integration, integrazione continua) è la procedura automatica che a ogni modifica compila il progetto ed esegue i test: se qualcosa si rompe, il merge si ferma. Il codice senza test non entra, che sia scritto a mano o generato. Nel front end Angular che abbiamo sviluppato per SIMOGE, per esempio, i test unitari sono scritti con Jasmine e Karma.
Analisi statica e sicurezza
I linter controllano stile ed errori comuni; strumenti di analisi statica come Semgrep e SonarQube cercano schemi vulnerabili e codice duplicato; uno scanner delle dipendenze segnala le librerie con vulnerabilità note. Quest’ultimo conta molto con l’AI, che può suggerire pacchetti obsoleti o perfino inesistenti. Tutti questi controlli girano a ogni modifica e bloccano il rilascio sugli errori gravi.
Strumenti approvati, dati fuori dai prompt
- Solo strumenti approvati dall’azienda, con un contratto che chiarisca dove finiscono i dati e se possono servire ad addestrare i modelli.
- Impostazioni centrali: filtro sul codice pubblico attivo, file sensibili esclusi dal contesto dell’assistente, account aziendali e non personali.
- Nessun segreto nei prompt: password e chiavi stanno in un gestore dei segreti o nelle variabili d’ambiente, mai nel codice, e uno scanner controlla ogni commit.
- Nessun dato personale: valgono le regole del GDPR anche quando si chiede a un modello di aiutare con un bug.
- Codice del cliente: si usa con l’AI solo se il contratto lo consente e con gli strumenti concordati.
La responsabilità resta di chi sviluppa
Il codice consegnato porta la firma di uno sviluppatore, non di un modello. Per questo l’AI non sostituisce la competenza: chi non sa valutare una soluzione non dovrebbe accettarla. Per chi è all’inizio, l’assistente può essere un ottimo insegnante, se lo si usa per chiedere spiegazioni e non solo risposte.
In pratica servono formazione sull’uso degli strumenti, regole scritte e condivise e le stesse soglie di qualità per tutto il codice. Così l’AI accelera il lavoro ripetitivo e lascia più tempo a quello che richiede giudizio: architettura, sicurezza, confronto con chi userà il software.
Se state introducendo gli assistenti AI nel vostro team, o cercate un team che li usi già con queste regole, parliamone. Trovate cosa facciamo nella pagina dei nostri servizi.
