---
title: "Esiste ancora spazio per il dubbio?"
description: "Quando una risposta ben scritta arriva senza verifiche, il nostro compito diventa decidere che cosa meriti davvero fiducia."
lang: it
canonical: https://potenza.dev/it/blog/il-dubbio/
alternate:
  en: https://potenza.dev/writing/is-there-still-room-for-doubt/index.md
author: "Emilio Potenza"
updated: 2026-08-01
---

> Site index
> Markdown pages are indexed at https://potenza.dev/llms.txt

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.[^pnas-epistemia] 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.[^metr-2026] 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.

[^pnas-epistemia]: Loru, Nudo, Di Marco, Santirocchi, Atzeni, Cinelli, Cestari, Rossi-Arnaud e Quattrociocchi, [*The simulation of judgment in LLMs*](https://arxiv.org/abs/2502.04426), *PNAS* (2025), doi: [10.1073/pnas.2518443122](https://doi.org/10.1073/pnas.2518443122).
[^metr-2026]: Becker, Rush, Cunningham, Rein e Mahamud, [*We are Changing our Developer Productivity Experiment Design*](https://metr.org/blog/2026-02-24-uplift-update/), METR (2026).