Ho voluto scrivere questo post per mettere in ordine alcune considerazioni sull’uso dell’IA generativa nello sviluppo software e sull’entusiasmo con cui è stata accolta nel nostro settore, dove la possibilità di produrre più velocemente sembra giustificare qualsiasi rinuncia a comprendere ciò che si sta producendo. È un entusiasmo che comprendo quando viene da colleghi che cercano di risparmiarsi una parte del lavoro quotidiano; mi convince molto meno quando serve a rivendicare competenze che si è scelto di delegare o a spacciare per innovazione l’automazione di pratiche che avevano ben poco di innovativo già prima.
Avevamo già affrontato l’argomento presentando la nostra AI policy per lo sviluppo software, nella quale chiediamo a chiunque collabori con noi e/o intenda contribuire ai nostri progetti di leggere e comprendere il codice che scrive, nonché, soprattutto, di assumersene la responsabilità, anche quando ha utilizzato un assistente generativo. In questo articolo intendo invece soffermarmi anche sul contesto in cui questi strumenti vengono adottati: le aziende per cui lavoriamo, il valore che attribuiscono alle nostre competenze e la facilità con cui una maggiore velocità di produzione viene celebrata come innovazione, senza preoccuparsi troppo di cosa si stia producendo e di chi dovrà occuparsene quando smetterà di funzionare.
La prima cosa che mi preme ricordare è che, quando le chiediamo di generare qualcosa al posto nostro, l’IA generativa non è uno strumento che ci aiuta a crearlo con le nostre capacità. È un sistema statistico addestrato sul lavoro di altre persone, spesso senza il loro consenso. Le stiamo delegando un lavoro che potremmo anche non essere in grado di svolgere autonomamente.
Questa distinzione resta valida indipendentemente dalla sua estrema utilità per sviluppare meglio e più velocemente una marea di stronzate spesso inutili, ovvero una parte considerevole dei servizi IT prodotti dalle imprese capitaliste che operano in Italia e nel resto del mondo.Del resto, anche la proprietà intellettuale di queste stronzate ha ben scarso valore, trattandosi in buona sostanza di una continua scopiazzatura di sistemi, soluzioni e idee altrui: una pratica diffusissima ben prima dell’avvento dell’IA generativa.
Non sorprende, quindi, che nei settori in cui gran parte del lavoro consiste nel riciclare ciò che già esiste, incluso il mio, mi preme precisarlo, un tool capace di automatizzare questa pratica per portare più velocemente a casa la pagnotta venga accolto con tanto entusiasmo. Quando il valore del proprio lavoro è affidato a un CEO tanto saccente quanto incapace, che spaccia per innovazione l’ennesima minestra riscaldata, magari su LinkedIn, la genAI rappresenta bene il perfezionamento industriale di una mediocrità già ampiamente consolidata.
Comprendo, e in molti casi condivido, la scelta di molti colleghi di utilizzare questi strumenti per risparmiarsi almeno una parte del pattume che sono costretti a produrre ogni giorno in ufficio, magari in uno smart working malcagato e «concesso» al posto di un aumento: a condizione, però, di avere l’onestà intellettuale di riconoscere quanto poco ci sia di nostro in ciò che abbiamo fatto generare, senza pretendere di spacciare la capacità di impartire prompt per talento creativo, né attribuirci il merito di un lavoro che è stato svolto al posto nostro. Se sappiamo comprendere, verificare e correggere quel lavoro, il nostro contributo ha un valore riconoscibile; se ci siamo limitati a chiedere modifiche finché il risultato ci è sembrato accettabile, dovremmo almeno evitare di rivendicare competenze che non abbiamo.
Tutto ciò premesso, ho comunque enormemente più stima di chi utilizza l’IA come strumento ausiliario di analisi, verifica e supporto tecnico, anziché farsi generare intere porzioni di codice con gli occhi foderati di prosciutto, senza comprenderne davvero il funzionamento.
Gli esempi sono parecchi: supporto al penetration testing e al vulnerability assessment, threat modeling, security auditing, code review, individuazione di bug e potenziali regressioni. Poi c’è la generazione di unit test e integration test, la preparazione di casi per il fuzz testing, l’analisi dei risultati e delle lacune nella copertura dei test. Lo stesso vale per il supporto all’analisi statica e alla verifica delle dipendenze, per la performance analysis e l’individuazione dei colli di bottiglia, per il debugging assistito e l’analisi dei log. Persino la documentazione tecnica può beneficiarne, magari a patto di rileggerla prima di consegnarla e firmarla.
Questi impieghi richiedono comunque gli strumenti adatti: chiedere a un modello di esaminare il codice non equivale a eseguire una scansione, così come un’ipotesi sulle prestazioni va verificata con misure reali. L’IA può aiutarci a predisporre i controlli e a interpretarne i risultati; resta da accertare che siano stati eseguiti correttamente e che le conclusioni abbiano un riscontro.
C’è poi l’intero comparto DevSecOps e della catena CI/CD: dalla configurazione e verifica delle pipeline all’automazione dei controlli, magari a patto di aver prima descritto cosa devono controllare; dalla verifica delle policy al monitoraggio dei deployment, fino al supporto nelle attività di incident analysis e remediation.
Per dare una struttura a queste verifiche si possono usare riferimenti come il Secure Software Development Framework del NIST e l’Application Security Verification Standard di OWASP. La guida OWASP SAMM sullo sviluppo assistito dall’IA affronta anche l’integrazione di questi strumenti nei processi di sviluppo e sicurezza. Sono attività nelle quali il valore che cerchiamo nell’IA consiste nell’aiutarci ad analizzare, verificare e rendere più sicuro ciò che stiamo realizzando. Questo uso non risolve le controversie sul lavoro impiegato per addestrare i modelli, ma ha uno scopo che considero molto più utile della produzione in serie di contenuti da rivendere come propri.
Anche uno sviluppatore inesperto, un appassionato senza particolari competenze e persino il vibe coder, appena sopra al CEO che non capisce un cazzo e ai minchioni che gli mettono like su LinkedIn, possono trarne un beneficio concreto: ottenere un supporto per riconoscere problemi che altrimenti non sarebbero in grado di individuare.
Una vulnerabilità trascurata può avere conseguenze molto più gravi di qualche riga di codice scritta male. Se un assistente segnala che un endpoint permette di leggere i dati di un altro cliente, o che una credenziale è finita nel repository, ci sta indicando un problema sul quale intervenire; occorre poi verificare che la segnalazione sia fondata e capire come correggerlo, eventualmente facendosi aiutare da qualcuno che abbia le competenze necessarie.
Una risposta rassicurante del modello, invece, non garantisce che il software sia sicuro. Anche la documentazione di GitHub Copilot richiede di verificare il codice generato e presenta la code review assistita come un’integrazione della revisione umana. Far scrivere allo stesso modello il codice e i test può inoltre lasciare intatto un errore di interpretazione presente in entrambi.
Colmare almeno in parte queste lacune, a patto di verificare i risultati e non scambiare generatori statistici per garanzie di sicurezza, significa utilizzare queste tecnologie per prevenire disastri, anziché produrre minchiate senza avere la minima idea di cosa si stia facendo.
Riferimenti
- NIST SP 800-218: Secure Software Development Framework. Pratiche per ridurre le vulnerabilità durante il ciclo di vita del software.
- OWASP Application Security Verification Standard: requisiti per progettare e verificare la sicurezza delle applicazioni web.
- OWASP SAMM: AI-Assisted Development. Indicazioni per integrare gli assistenti generativi nei processi di sviluppo e sicurezza.
- GitHub: uso responsabile degli agenti Copilot, con capacità, limiti e indicazioni per la revisione del codice generato.
- U.S. Copyright Office: Copyright and Artificial Intelligence. Rapporti sull’addestramento dei modelli e sulla tutela dei risultati generati, riferiti al quadro statunitense.
