Correctness, confidence, and context: Framing software assurance in the AI age

Il Grande Enigma del Software: Perché il "Perfetto" non è l'Obiettivo

Immaginate di stare costruendo un enorme castello invisibile fatto di logica e istruzioni. Questo è ciò che gli ingegneri del software fanno ogni giorno. Scrivono codice per far fare cose ai computer, dal ordinare una pizza al far volare gli aerei. Per molto tempo, il sogno è stato quello di costruire questi castelli in modo così perfetto da non poter mai, mai commettere un errore. Gli ingegneri volevano dimostrare matematicamente che ogni singolo mattone era al posto giusto. Ma ecco il problema: il mondo reale è disordinato. È pieno di regole non scritte, abitudini culturali e "buon senso" che non puoi trascrivere in un elenco di istruzioni.

Ora, immaginate che sia arrivato un nuovo tipo di aiutante: l'Intelligenza Artificiale (IA). Questa IA è incredibilmente brava a indovinare cosa viene dopo, come un indovino velocissimo che ha letto quasi ogni libro mai scritto. Ma a differenza dei vecchi ingegneri che volevano dimostrare le cose, questa IA lavora su probabilità. Dice: "Sono sicuro al 90% che questa sia la risposta giusta", invece di "So con certezza che questa è la risposta giusta". Questo crea un grande problema: come possiamo fidarci di un sistema costruito su supposizioni quando abbiamo bisogno che sia sicuro? Questo è l'enigma che Mary Shaw sta affrontando. Lei vuole cambiare il nostro modo di intendere la "correttezza" del software, passando dall'impossibile sogno della perfezione a un approccio più pratico, tipico dell'ingegneria, volto a garantire che le cose siano "abbastanza buone" per il compito che devono svolgere.

---

La Grande Idea del Paper: Dal "Perfetto" al "Abbastanza Buono"

In questa presentazione chiave per gli ingegneri del software, Mary Shaw sostiene che dobbiamo smettere di cercare di dimostrare che il nostro software sia perfetto al 100% e iniziare a concentrarci sul fatto che sia adatto al suo scopo. Suggerisce che il vecchio modo di pensare — cercare di scrivere un insieme perfetto di regole per dimostrare che un programma è corretto — è ormai superato, specialmente ora che stiamo usando l'IA.

Ecco la storia del suo argomento, suddivisa in parti semplici:

1. Il Probleo dell'Ombra: Ciò che l'IA non può Vedere

Immaginate di cercare di descrivere un oggetto complesso, come una tazza di carta pieghevole, a un amico che non ne ha mai visto una. Potete solo mostrargli le ombre che proietta su una parete. Dal davanti, l'ombra sembra un quadrato. Di lato, sembra un triangolo. Dall'alto, sembra un cerchio. Se aveste solo le ombre, potreste ipotizzare che sia un blocco strano, ma perdereste il fatto che è una tazza che può contenere acqua.

Shaw dice che i modelli di IA sono come quell'amico che guarda le ombre. Sono addestrati su "ombre digitali": il testo, il codice e i dati che esistono online. Ma il mondo reale è pieno di conoscenza tacita: cose che sappiamo ma che non scriviamo. Questo include l' "atmosfera" di un luogo di lavoro, le regole non scritte di una cultura o l'intuizione di un meccanico esperto quando sente un rumore strano in un motore. Poiché questa conoscenza non è scritta, l'IA non può vederla. Vede solo l'ombra, non l'oggetto reale. Quando l'IA cerca di costruire software, potrebbe mancare questi dettagli cruciali e invisibili, portando a errori che un esperto umano avrebbe colto immediatamente.

2. Il "Culto del Cargo" della Programmazione

Shaw racconta la storia di persone su delle isole che videro degli aerei atterrare con del cibo durante una guerra. Quando la guerra finì e gli aerei smisero di arrivare, i locali costruirono torri di controllo di bambù e marciarono in formazione, sperando di richiamare gli aerei. Copiarono le ombre dell'attività (le marce, le torri) ma mancarono la causa reale (la logistica e la pianificazione militare).

Avverte che usare l'IA per scrivere codice può talvolta diventare un "culto del cargo". Potremmo chiedere all'IA di scrivere codice che sembri corretto (l'ombra) senza comprendere le ragioni profonde del perché quel codice debba essere in quel modo. Se chiediamo semplicemente una "vibe coding" (scrivere codice basandosi su una sensazione o su un semplice comando) senza comprendere le regole nascoste, potremmo costruire sistemi che sembrano buoni ma che crollano quando si presentano problemi del mondo reale.

3. Le "Credenziali" invece delle "Specifiche"

Tradizionalmente, gli ingegneri cercano di scrivere una "specifica" perfetta — un enorme e rigido libro di regole che dice esattamente cosa deve fare il software. Shaw suggerisce che questo è impossibile perché il mondo cambia e non possiamo prevedere tutto.

Invece, propone di trattare il software come una persona che si candida per un lavoro. Non abbiamo bisogno di tutta la sua storia personale; abbiamo solo bisogno delle sue credenziali.

• Un subacqueo mostra una tessera che dice: "Posso scendere fino a 30 metri".
• Un pilota mostra una licenza che dice: "Posso pilotare questo aereo".
• Un sistema software dovrebbe mostrare una "credenziale" che dice: "Sono sicuro al 90% di poter gestire 1.000 utenti", oppure "Sono stato testato per essere sicuro per questo compito specifico".

Queste credenziali non sono prove perfette; sono dichiarazioni oneste di quanto siamo sicuri, da dove proviene quella sicurezza e quali sono i limiti. È un modo per dire: "Abbiamo controllato questo, ed ecco quanto siamo certi".

4. La Scelta dell'Ingegnere: Il Satisficing

Il paper suggerisce che dovremmo smettere di cercare la perfezione e iniziare a praticare il satisficing. Questa è una parola sofisticata per dire "trovare una soluzione che sia abbastanza buona".

• Se state costruendo un gioco, potreste non aver bisogno della perfezione assoluta. Alcuni bug sono accettabili se il gioco è divertente ed economico da realizzare.
• Se state costruendo un dispositivo medico, avete bisogno di un livello di fiducia molto più alto.

Shaw sostiene che gli ingegneri dovrebbero agire come veri ingegneri: dovrebbero valutare il costo, il rischio e lo scopo, e poi scegliere il mix giusto di strumenti per portare a termine il lavoro. A volte, è più economico risolvere un problema dopo che si è verificato piuttosto che cercare di prevenirlo per sempre. L'obiettivo non è eliminare tutti gli errori (il che è impossibile); l'obiettivo è gestire il rischio in modo che il sistema sia sicuro e utile per il suo compito specifico.

Cosa Significa per il Futuro

Mary Shaw non sta dicendo che l'IA sia cattiva. Sta dicendo che non possiamo trattare l'IA come una bacchetta magica che risolve tutto. Dobbiamo essere più intelligenti su come la usiamo. Dobbiamo accettare che l'IA lavori su supposizioni (statistiche) e che non possa vedere le "ombre" invisibili della cultura e dell'esperienza umana.

Il suo messaggio principale è un appello all'azione per la comunità del software: Smettiamo di fingere di poter dimostrare che tutto è perfetto. Invece, siamo onesti ingegneri. Costruiamo sistemi in cui sappiamo esattamente di cosa siamo sicuri, di cosa non lo siamo e perché. Facendo così, possiamo usare l'IA per aiutarci a costruire un software migliore, senza cadere nella trappola di pensare di aver risolto l'irrisolvibile.

In breve, il paper suggerisce che il futuro del software non riguarda l'essere "corretto" nel senso di un libro di matematica. Riguarda l'essere adatto allo scopo, conoscere i propri limiti e compiere scelte intelligenti e convenienti per mantenere il nostro mondo digitale in sicurezza.