I rischi della programmazione a scatola nera con l'IA

Nel QA e nel testing è comune parlare di test a scatola nera o test a scatola bianca. I test a scatola nera si eseguono quando non si conosce il funzionamento interno del sistema e si testa la sua funzionalità. I test a scatola bianca si eseguono quando si conosce il funzionamento o la struttura interna del sistema e si configurano i test per verificare i diversi casi possibili previsti dal codice.

Con gli strumenti di intelligenza artificiale sta emergendo quella che potremmo definire programmazione a scatola nera. L'utente specifica all'IA ciò che desidera a livello funzionale da un'applicazione e l'IA lo genera.
L'utente non sa come funzioni internamente la sua applicazione, non gli interessa o non è in grado di comprendere le implicazioni di come sia stata implementata la soluzione.
Questo sarebbe un tipico caso d'uso di strumenti come Lovable e alcuni altri che stanno iniziando a nascere, ma potrebbe essere considerata "scatola nera" anche l'accettazione di codice generato dall'IA senza alcuna revisione e comprensione.

In contrapposizione alla programmazione a scatola nera esiste anche la programmazione a scatola bianca con l'IA. In questo caso c'è un responsabile tecnico che decide l'architettura, come implementare la soluzione e si avvale dell'IA per implementarla più velocemente. In base al contesto e alla capacità di comprensione, le parti delegate all'IA sono più o meno grandi.
Lo sviluppatore del prodotto cambia il suo ruolo: invece di scrivere linee di codice, progetta/dirige, orchestra e revisiona, essendo completamente responsabile del "come". Per questo motivo la mia raccomandazione è che i frammenti richiesti all'IA siano piccoli e concisi, in modo da poter essere rivisti, compresi e gestiti nella successiva manutenzione (la mia raccomandazione è nulla più grande di una pull request che siamo in grado di rivedere e comprendere). Sebbene la conoscenza completa sia inafferrabile e vi siano varie sfumature di bianco, la programmazione a scatola bianca consiste nel comprendere la soluzione nel modo più completo possibile; non si tratta di dividere una grande scatola nera in una moltitudine di scatole nere più piccole.

Anche se ovviamente ho la mia preferenza, non è che una modalità sia buona o cattiva di per sé, semplicemente bisogna comprenderle, vederne i pro e i contro e, soprattutto, capirne i rischi.

Nel caso della programmazione a scatola nera, i rischi che a mio avviso andrebbero valutati sono:

Rischio 1: La mancanza di responsabilità. Come già accennato in un articolo precedente, l'IA non può tradursi in una diluizione della responsabilità. Se il software generato non funziona correttamente, presenta problemi di prestazioni, sicurezza, stabilità o effetti collaterali imprevisti, il responsabile deve essere chiaro. Non comprendere né il come né il perché di tali problemi rende più complicata l'assunzione della responsabilità.
Rischio 2: Il mancato controllo della qualità. Non sapere come sia stato generato il software ci impedisce di sapere se sia stato generato un prodotto di qualità o meno. Questo non è una novità, la maggior parte degli stakeholder vuole semplicemente che il software funzioni, a prescindere dal fatto che sia stato generato con criteri di qualità. Ma chi lavora con l'architettura del software e la conosce sa che se manca la qualità, se c'è un debito tecnico, alla fine si paga: difficoltà di manutenzione, errori, lentezza, complicazioni e, in ultima istanza, la necessità di rifare da capo tutto il software.
Rischio 3: Mancanza di conoscenza dell'architettura del software: Non conoscere l'architettura del software implica non conoscerne i punti di forza e le debolezze, ignorare quale parte sarà necessario rafforzare o persino verso dove possa o debba evolversi. Significa ignorare quali siano le sue dipendenze e le sue potenziali vulnerabilità.
Rischio 4: Prestazioni: Le prestazioni di un'applicazione sono intimamente legate alla sua architettura. Possiamo parlare di problemi di scalabilità o "semplicemente" di un uso inefficiente delle risorse, ma senza capire come sia fatta un'applicazione è impossibile non solo intervenire, ma persino proporre delle ottimizzazioni.
Rischio 5: Conoscenza implicita: Quando definiamo e implementiamo esiste un contesto e una conoscenza implicita di ciascuno degli attori che apporta valore. Ad esempio, un architetto o uno sviluppatore software apporterà conoscenze sull'architettura, i pattern di progettazione, la sicurezza dei dati e anche aspetti funzionali basati su esperienze e implementazioni precedenti. Essendo implicita, gran parte di questa conoscenza non viene trasferita né viene richiesto all'IA di applicarla, ottenendo così una soluzione di qualità inferiore rispetto a quella che si avrebbe se fossero intervenuti più attori con diverse competenze nella sua generazione.
Rischio 6: Evoluzione vs rivoluzione (refactor vs replatform): Dobbiamo tenere presente che il sviluppo del software è un processo iterativo. Non si fa un'applicazione e basta. Deve essere evoluta, corretta, migliorata, ecc. Non conoscendo il "come" sia stata fatta, non è possibile specificare l'evoluzione di determinati aspetti, bensì si aggiungono nuove specifiche di alto livello, con un rischio molto grande che l'IA rifaccia l'esistente per soddisfare le nuove specifiche, smettendo di soddisfare le precedenti, tornando a commettere errori e, in generale, facendo emergere tutti i problemi che derivano dal rifare il software anziché sottoporlo a refactoring.
Rischio 7: Perdita di opportunità per mancanza di conoscenza: Esistono casi in cui la conoscenza di come sia fatto qualcosa e delle capacità tecnologiche genera opportunità di business, nuove opzioni funzionali, ecc. È il cosiddetto sviluppo di prodotto "bottom-up". Ignorando questa conoscenza e questi attori che sanno come il software sia strutturato, si perde questa capacità creativa.

Conoscendo questi rischi, bisogna fare attenzione alle implicazioni della programmazione a scatola nera. Tuttavia, come dicevamo prima, non è che sia una modalità sbagliata a priori: esistono casi in cui questo tipo di programmazione può risultare interessante, poiché comporta un minor consumo di risorse umane (sul consumo di token non mi esprimo in questa sede).

Ad esempio, per proof of concept, progetti pilota o prototipi può essere interessante, poiché si tratta di casi in cui le prestazioni e la stabilità in produzione non sono necessarie quanto la velocità e la capacità di testare i concetti, oltre al fatto di non avere l'obiettivo di generare un software che rimanga nel tempo, migliori ed evolva.

In sintesi, quando programmiamo con l'IA, proprio come se commissionassimo un software a una società di consulenza, dobbiamo interrogarci sulle implicazioni del non conoscere tale codice, sui rischi che comporta e su come intendiamo gestirne la manutenzione. Dobbiamo chiederci se stiamo commissionando il software per trovare la soluzione a un problema o se vogliamo implementarlo in prima persona.