Una buona risposta, quando non sappiamo bene da dove provenga, porta con sé un rischio: smettiamo di discuterla. Diventa un fatto assodato prima ancora di essere un fatto.

Succede anche con il codice. Un diff ordinato, nomi sensati, una spiegazione che pare scritta da qualcuno che ha visto il problema da vicino. La review si accorcia. Non perché siamo diventati tutti pigri, anche se qualcuno di noi lo è sempre stato, ma perché la forma è un segnale. Il cervello usa i segnali per decidere dove mettere attenzione. Con l’AI, quella forma arriva in quantità industriale e quasi gratis. La scala del problema cambia.

Qualcuno molto più ferrato di me ha dato un nome a questo effetto collaterale: epistemia, l’illusione di conoscenza che nasce quando la plausibilità di superficie prende il posto della verifica.1 Il nome è un po’ austero, ma la scena la conosciamo tutti. Leggiamo una risposta fluida, riconosciamo il lessico, troviamo una struttura familiare e le mettiamo il timbro «probabilmente sa di cosa parla». Avrà ragione? Sarà vero quello che scrive?

Sarebbe affascinante proseguire con la disputa fra modello intelligente e pappagallo stocastico. La lascio volentieri a chi se ne occupa sul serio: temo che, nelle mie mani, diventerebbe un esercizio di stile. Mi interessa una domanda più terra terra: come si distingue una risposta attraente da una risposta su cui basare una decisione importante? Come si distingue un feature branch destinato a portare una marea di bug in produzione da uno che rilasci e te ne dimentichi?

In un team di sviluppo software, la certezza non è un punto di partenza. È, al massimo, il risultato di una verifica. Per decidere serve sapere come una soluzione potrebbe rompersi: quale invariante deve rispettare, quale test dovrebbe fallire se stiamo sbagliando, quale vincolo stiamo dando per scontato, da dove arriva il dato su cui ci stiamo basando.

La risposta non diventa affidabile perché è stata generata da una persona, da un modello o da un incrocio dei due. Diventa più affidabile quando lascia una traccia verificabile. È una differenza piccola nella frase e enorme nel lavoro quotidiano: sposta la discussione da «mi sembra giusto» a «vediamo se regge».

La plausibilità ha due effetti. Può accorciare la strada dal dubbio verso una falsa certezza; può anche permettere a un dubbio di prendere una forma su cui lavorare. La discriminante è chi usa lo strumento. È quella persona a decidere se il risultato resta un’ipotesi da mettere alla prova oppure diventa una scorciatoia per smettere di pensare.

Anche misurare quanto valgano davvero questi strumenti è diventato più complicato. METR ha provato a ripetere un esperimento sull’impatto dell’AI nello sviluppo e ha incontrato un problema sorprendente: una quota crescente di sviluppatori non voleva lavorare senza AI per costituire il gruppo di confronto.2 Non prova che l’AI faccia sempre risparmiare tempo o produca codice migliore. Dice che lo strumento è entrato nelle abitudini di lavoro e che la sua valutazione richiede metodi più attenti.

Aggiungo una mia osservazione, non una statistica: quando l’azienda non mette lo strumento a disposizione, qualcuno se lo paga da sé e non lo racconta troppo. Trattare l’AI soltanto come una cosa da vietare non riduce il fenomeno; lo sposta fuori dalla luce.

Il compito dell’azienda è quindi più scomodo. Deve governare un codice capace di sembrare corretto anche quando non lo è e persone che hanno già incorporato questi strumenti nel proprio modo di lavorare. La misura non è nascondere l’AI sotto il tavolo. È rendere visibile il passaggio che separa una proposta da una decisione.

Le domande utili restano quasi banali: «Quale test la smentisce?», «quale vincolo stiamo assumendo?», «da dove arriva questo dato?». Non siamo diventati magicamente esperti. Chi prende una decisione deve però sapere che l’onere della prova pesa più di prima, nel software come nel diritto o nell’economia.

Non credo a un futuro in cui l’AI ci sostituirà in ogni aspetto del lavoro. Vedo piuttosto un futuro in cui produrre proposte costerà sempre meno, mentre giudicarle, gestire il rischio e cambiare idea costerà sempre di più. L’uomo resterà il collo di bottiglia. Per ora, e forse è una buona notizia, resta anche necessario.

Footnotes

  1. Loru, Nudo, Di Marco, Santirocchi, Atzeni, Cinelli, Cestari, Rossi-Arnaud e Quattrociocchi, The simulation of judgment in LLMs, PNAS (2025), doi: 10.1073/pnas.2518443122. ↩

  2. Becker, Rush, Cunningham, Rein e Mahamud, We are Changing our Developer Productivity Experiment Design, METR (2026). ↩