Non tutto il software richiede lo stesso livello di controllo. Il livello di verifica deve essere proporzionato alle conseguenze di un errore.

"I bug sono parte del gioco" era vero ma diceva troppo poco. Oggi le cose che possono andare storte in un software non sono solo i bug: ci sono errori nei dati, regressioni, output sbagliati di un modello, automazioni che partono quando non dovrebbero, permessi troppo larghi e azioni compiute da un agente per conto di qualcuno.

Quello che cambia non è se possano succedere, ma cosa succede quando succedono. Un prototipo interno che sbaglia fa perdere mezz'ora. Una funzione che autorizza un pagamento che sbaglia è un altro discorso.

Per questo il livello di verifica non è uno solo. A rischio basso stanno i prototipi, gli strumenti interni non critici e gli esperimenti: lì conviene andare veloci e correggere dopo. A rischio medio sta il software operativo, dove un errore si sente ma si può rimediare. Ad alto rischio stanno pagamenti, dati sensibili, autorizzazioni e processi da cui dipende il lavoro di molte persone: lì il rigore vale il tempo che costa.

Un caso a parte è quando il software può agire da solo. Quando un agente compie azioni, non basta verificare che il risultato sia giusto: bisogna decidere prima cosa gli è permesso fare, cosa deve farsi confermare, cosa lascia scritto di quello che ha fatto e cosa si può annullare.

Niente di tutto questo è un dettaglio tecnico da delegare. È una decisione condivisa: quanto controllo serve, quanto costa e cosa siamo disposti ad accettare. Deciderlo insieme e consapevolmente è diverso dallo scoprirlo dopo.