Quel che non abbiamo ancora capito: specificare il problema è il problema
Previsioni infondate, tagli miopi e hype: il dibattito sull'AI secondo le leggi di Cipolla
Questo post è parte di una serie di interventi che vi propongo per riflettere sulle sfide, sulle opportunità e sulle distorsioni che emergono dal dibattito sull’intelligenza artificiale. Sono convinto che l’AI sia una tecnologia di enorme potenziale, che peraltro usiamo da decenni, anche prima dell’arrivo e del successo dell’ultima generazione di strumenti di GenAI. Ma per evitare errori e semplificazioni, è necessario ragionare e andare al fondo delle questioni che non sono affatto semplici o banali.
L’illuminante classificazione di Carlo Cipolla
Nel 1975, l’economista Carlo Cipolla scrisse un illuminante saggio intitolato Le leggi fondamentali della stupidità umana, un testo che, nella sua semplicità e immediatezza, sottolinea magistralmente molti dei nostri difetti e carenze.
Il punto sostanziale è rappresentato dalle definizioni riportate nella figura che ho qui ripreso da Wikipedia.
Lo stupido è colui che, allo stesso tempo, fa male agli altri e a sé stesso.
Giustamente, Cipolla dice che gli stupidi sono la categoria peggiore perché non creano valore per nessuno, a differenza degli intelligenti, degli sprovveduti e – ebbene sì – anche dei banditi, che almeno qualcosa di utile per se stessi fanno. Gli stupidi no: distruggono valore e non creano nulla per nessuno.
Il dibattito di oggi sull’AI è dominato da questa dinamica. È troppo spesso distruttivo e “stupido” (perdonatemi, uso la terminologia “tecnica” di Cipolla), perché fa male a tutti: a chi propone gli strumenti e le tecnologie dell’AI (offerta) e a chi vuole utilizzarli (domanda). Ovviamente, ci sono anche i banditi che speculano su tutto ciò che sta accadendo, ma, almeno in questo contesto, vorrei lasciarli da parte per un momento.
Alcuni commenti che ci indicano lo stato del dibattito
Ogni giorno si scrivono milioni di parole sul tema dell’AI. È quindi impossibile riassumere correttamente e completamente la dinamica del dibattito. Ma vorrei qui citare (e criticare) alcune notizie o commenti che ritengo particolarmente emblematici.
Circa un anno fa, Dario Amodei, CEO di Anthropic, fece una previsione:
Ora, perché fare queste affermazioni? Fattualmente, non è successo e non serviva essere la Sibilla Cumana per capire che già allora si trattava di un’affermazione priva di fondamento. Eppure non più tardi di qualche giorno fa, l’ex CEO di Google, Eric Schmidt, si è lanciato in previsioni altrettanto azzardate, riportando quel che uno sviluppatore gli ha detto senza farsi una domanda, senza farsi venire un dubbio:
A sua volta, l’autore del tweet con nonchalance scrive una frase che chi si occupa di informatica e ingegneria del software sa essere uno dei problemi più critici – se non il più critico:
A programmer writes a spec and an evaluation function, runs it at 7pm, and wakes up to what was invented overnight.
The advantage now belongs to whoever can specify the problem precisely.
The rest will be automated.
Questa frase suona come una rivelazione. Ma è esattamente il problema su cui l'informatica lavora — senza averlo risolto — da oltre mezzo secolo.
Come se nessuno ci avesse mai pensato prima!
Saremmo tutti andati a dormire più sereni, no?
Per esempio, è da cinquant’anni che ci si pone il problema di capire come scrivere “spec and evaluation function”. Ho chiesto aiuto a Perplexity Pro giusto per fare qualche esempio tratto dalla storia dell’informatica:
I principali informatici che hanno sviluppato e formalizzato il concetto di precondizioni e postcondizioni appartengono alla tradizione della verifica formale dei programmi e della logica della programmazione.
Robert W. Floyd
Floyd fu il primo a introdurre sistematicamente il concetto di asserzioni sui programmi nel suo articolo fondamentale “Assigning Meanings to Programs” (1967). Propose di annotare i flowchart con predicati logici in punti chiave del flusso di esecuzione, gettando le basi per tutta la teoria successiva della correttezza dei programmi.
C.A.R. Hoare
Tony Hoare è il nome più celebre in questo campo: nel 1969 pubblicò “An Axiomatic Basis for Computer Programming”, in cui definì le famose triple di Hoare:
{P} C {Q}
dove P è la precondizione, C il comando e Q la postcondizione. Questa notazione è ancora oggi lo standard per ragionare formalmente sulla correttezza dei programmi.
Bertrand Meyer
Meyer portò le precondizioni e postcondizioni nel mondo dell’ingegneria del software pratica, introducendo il concetto di Design by Contract nel linguaggio Eiffel (anni ‘80). Nel suo modello, le precondizioni sono obblighi del chiamante, le postcondizioni sono garanzie del fornitore, e gli invarianti di classe completano il contratto. Questo approccio ha influenzato linguaggi moderni come Java (con JML), Python e molti altri.
Dijkstra e Gries svilupparono e sistematizzarono ulteriormente queste idee.
Molte di queste idee sono state sviluppate prima ancora che io iniziassi il mio percorso di studi al Politecnico (1977)! Nel mio piccolissimo, appena laureato, ho scritto, insieme a Carlo Ghezzi e Dino Mandrioli, un articolo su “Executable Data Flow Diagrams” (1988). L’idea era di scrivere specifiche che potessero essere comprese per generare codice. Giusto per dire che, per decenni, in tanti si è studiato il problema, che è strutturalmente complesso perché è difficile capire quali siano i requisiti.
Quando si dice che gli agenti AI hanno scritto un compilatore, si prende come esempio proprio uno di quei sistemi in cui i requisiti sono (quasi) completamente formali per definizione: la sintassi e la semantica del linguaggio di ingresso e del linguaggio di uscita. Non per niente, i compiler-compiler – come YACC e Bison – furono creati già negli anni ‘70. Li usai al Poli quando ancora programmavo a schede in Fortran V e vidi per la prima volta un terminale VT100 collegato ad un PDP-11. Addirittura, la ricerca su questi temi nacque nel 1959. Era ovvio che questo potesse essere automatizzato: lo si faceva da decenni. Ed è anche ovvio che si tratta di un caso ideale per sperimentare la collaborazione: le specifiche sono pressoché prive di incertezze.
Il vero punto è capire i requisiti di un utente che deve sviluppare software per i processi della propria azienda. Perché sono stati creati i SaaS? Per mettere a fattor comune i requisiti che, a fatica, si sono consolidati nel tempo, pur senza eliminare il bisogno di customizzazioni e personalizzazioni.
Perché si è introdotto l’approccio Agile? Proprio perché il primo giorno di un qualunque corso di informatica si ricorda che spesso “l’utente non sa cosa vuole”. Tramite l’approccio Agile si itera, cercando di convergere verso una soluzione, mostrandogli semilavorati che l’aiutino a capire.
L’insostenibilità dei tagli e il suicidio di rinunciare ai giovani
Se i problemi fossero davvero risolti, ci aspetteremmo che le aziende di AI ne stiano traendo frutto. Invece, il quadro è molto diverso. OpenAI ha cambiato radicalmente strategia, spostandosi verso l’utenza business – un segnale che il modello consumer non sta generando i ricavi attesi. Più in generale, le aziende che sviluppano l'AI stanno bruciando risorse enormi senza raggiungere la redditività. Siamo in una fase in cui l’offerta investe massicciamente scommettendo su un ritorno futuro che nessuno è ancora in grado di quantificare con certezza.
Ed è proprio in questo contesto di incertezza che alcune aziende – lato domanda – prendono decisioni drastiche e irreversibili: riducono il personale e smettono di assumere giovani, giustificandosi con l’avvento dell’AI. Ma se chi produce questi strumenti non ha ancora trovato un modello economico sostenibile, su quali basi chi li utilizza prende decisioni strutturali sul proprio capitale umano?
In molti casi, si sospetta che si tratti di “AI-washing”: tagli motivati da altre ragioni – ristrutturazioni, calo della domanda, pressione sugli utili – rivestiti di una narrativa AI che li rende più accettabili agli occhi del mercato. In altri casi, ancora più preoccupanti, si tratta di tagli preventivi: si elimina personale non perché l’AI abbia dimostrato di poterlo sostituire, ma perché si presume che lo farà.
I più colpiti sembrerebbero i giovani: non ci sarebbe bisogno di persone junior, perché i senior, aiutati dall’AI, fanno tutto.
È quanto di più immaturo e miope si possa immaginare.
Prima di tutto, perché è una tesi tutta da verificare sul campo. Secondo, perché i senior di domani sono i junior di oggi: esaurita questa generazione di senior, chi subentrerà? Non per niente, IBM ha affermato di aver triplicato le assunzioni di giovani.
Ricercatori come Frank Nagle (MIT) hanno osservato che è un errore strategico tagliare i lavori entry-level. E altri hanno notato che si sta manifestando il paradosso di Jevons: al diminuire del costo di produzione del software, aumenta la domanda di sviluppo e, di conseguenza, la richiesta di software engineer.
Ci stiamo facendo male, tutti, da stupidi
Ricapitoliamo. Abbiamo CEO che fanno previsioni smentite dai fatti entro pochi mesi. Abbiamo commentatori che presentano come rivelazioni problemi su cui l’informatica lavora da mezzo secolo senza averli risolti in modo facilmente applicabile in contesti industriali. Abbiamo aziende che tagliano i professionisti di domani sulla base di promesse tecnologiche non ancora mantenute. E abbiamo un’industria dell’offerta che brucia capitali senza un orizzonte chiaro di sostenibilità.
Nella tassonomia di Cipolla, tutto questo è un comportamento stupido nel senso tecnico del termine: danneggia chi lo subisce e chi lo pratica. Le previsioni infondate erodono la credibilità di chi le fa. I tagli ai junior privano le aziende del proprio futuro. L’hype indiscriminato alimenta aspettative che, quando verranno deluse, genereranno un contraccolpo che danneggerà anche chi lavora seriamente su queste tecnologie.
Il comportamento intelligente – sempre nella tassonomia di Cipolla – è quello che crea valore per sé e per gli altri. Applicato all’AI, significa valutare questi strumenti per ciò che effettivamente sanno fare oggi, non per ciò che qualcuno promette che faranno domani. Significa investire nei giovani, formarli nell’uso di queste tecnologie e riconoscere che la complessità del software non si risolve con un prompt ben scritto. Significa, in una parola, sostituire l’hype con la maturità di analisi. Che è, poi, l’unica strategia che nella storia dell’innovazione tecnologica abbia mai funzionato davvero.
© 2026 Alfonso Fuggetta & Sonia Montegiove. Salvo diversa indicazione, tutti i contenuti di questa pubblicazione sono protetti da copyright e rilasciati con licenza CC BY-NC-ND 4.0: https://creativecommons.org/licenses/by-nc-nd/4.0/deed.it