Il prompt che ti contraddice: usare l'AI contro i tuoi bias cognitivi

Nel primo articolo della serie abbiamo trattato il prompt come una consegna di lavoro: identità, obiettivo, contesto, formato. Tutto puntava a un risultato, il testo che esce dalla chat e finisce in una mail o in un documento. C'è però un secondo modo di usare lo stesso strumento, che con il primo non ha nulla a che vedere. Non serve a produrre meglio. Serve a pensare meglio.

L'idea è semplice e un po' contraria all'istinto. Il valore di un modello linguistico, quando devi prendere una decisione, non sta nelle risposte che ti dà. Sta nelle domande che ti costringe a guardare. Un'AI ben istruita può fare la cosa che a noi riesce peggio: mostrarci i punti in cui stiamo ragionando male senza accorgercene. A patto, e qui sta tutto, di istruirla a contraddirci invece che a compiacerci.

Perché ci serve un contraddittorio esterno

Nel 2016 Buster Benson ha provato a mettere ordine nella lista dei bias cognitivi, le scorciatoie sistematiche con cui il cervello sbaglia. Ne ha raggruppati quasi duecento in quattro categorie, e John Manoogian III li ha disposti nella mappa circolare che oggi gira col nome di Cognitive Bias Codex. La data non tragga in inganno: la mappa è del 2016, ma i bias che organizza sono psicologia classica, alcuni descritti da Tversky e Kahneman già negli anni Settanta. Non è un quadro che invecchia. Le quattro categorie descrivono quattro situazioni in cui il cervello, per risparmiare energia, prende una scorciatoia che spesso porta fuori strada. La novità non sta nei bias, che sono sempre quelli, ma nello strumento che oggi possiamo usare per contrastarli.

Il problema dei bias è che sono invisibili da dentro. Non li senti mentre operano. È la ragione per cui nei progetti complessi serve sempre qualcuno che faccia le domande scomode: il collega che chiede "ma sei sicuro che il cliente voglia davvero questo?", il senior che in code review nota l'assunzione mai verificata. Quel ruolo, oggi, un modello linguistico lo può fare su richiesta, a qualsiasi ora, su qualsiasi decisione. Vediamo come, categoria per categoria.

Troppe informazioni: quando filtriamo ciò che ci conferma

La prima categoria del Codex riguarda l'eccesso di informazioni. Il cervello, sommerso, filtra. E filtra male: nota ciò che conferma quello che già pensa, si fissa sul primo numero che ha sentito, dà peso a ciò che ricorda più facilmente. Il bias di conferma e l'ancoraggio vivono qui.

Si vede bene in una sessione di discovery con un cliente. Il project manager entra con un'ipotesi di soluzione già in testa, magari un modulo Odoo standard che ha funzionato sull'ultimo progetto simile. Da quel momento, senza volerlo, sente più forte ciò che conferma quell'ipotesi e lascia sullo sfondo i requisiti che la contraddicono. L'ancoraggio fa il resto in fase di stima: il primo numero buttato lì, "saranno una ventina di giornate", calamita tutte le stime successive verso di sé.

Qui il modello serve come generatore di contro-ipotesi. Invece di chiedergli di confermare la strada scelta, gli si chiede di attaccarla:

<contesto>
Note della sessione di discovery con il cliente [allegate].
La mia ipotesi è risolvere con il modulo standard X.
</contesto>

<istruzioni>
Elenca i requisiti emersi che la mia ipotesi NON copre bene.
Poi proponi due approcci alternativi che un altro team
potrebbe preferire, e di' perché.
</istruzioni>

Sulla stima, la mossa è ancora più diretta: far stimare al modello l'effort prima di rivelargli il tuo numero. Se la sua stima indipendente diverge molto dalla tua, l'ancora che ti eri messo da solo era probabilmente sbagliata.

Significato insufficiente: quando riempiamo i vuoti con una storia

La seconda categoria riguarda i vuoti di significato. Quando i dati sono pochi, il cervello non sospende il giudizio: inventa una storia coerente e ci crede. Da qui la fallacia narrativa, la tendenza a vedere schemi dove c'è rumore, e lo stereotipo, che riempie le caratteristiche mancanti di una persona o di un'azienda attingendo a casi passati.

Nel nostro lavoro questo è il bias dell'analogia rapida. "Questo cliente manifatturiero è come quello dell'anno scorso, quindi avrà bisogno delle stesse cose." L'analogia fa risparmiare tempo e a volte è giusta. Ma quando è sbagliata orienta l'intero progetto su requisiti che non esistono, e ce ne accorgiamo a sviluppo iniziato. La fallacia narrativa colpisce anche le retrospettive: costruiamo un racconto pulito di perché un progetto è andato come è andato, scartando tutto ciò che non entra nella trama.

Il modello qui lavora bene come distruttore di analogie. Gli si dà la storia che ci stiamo raccontando e gli si chiede di romperla:

Sto assumendo che questo cliente abbia le stesse esigenze
di un progetto manifatturiero precedente.
Elenca i modi in cui le due aziende potrebbero essere
strutturalmente diverse, e quali requisiti l'analogia
mi sta facendo dare per scontati a torto.

La differenza con una semplice ricerca è che il modello non cerca conferme: se gli chiedi esplicitamente le differenze, te le tira fuori, e spesso una di quelle è proprio il requisito che avresti scoperto troppo tardi.

Bisogno di agire velocemente: quando difendiamo ciò che abbiamo già fatto

La terza categoria è la più insidiosa per chi costruisce software. Per agire, il cervello ha bisogno di sentirsi sicuro, e questo bisogno genera distorsioni che proteggono le decisioni già prese. La fallacia del costo irrecuperabile ci fa proseguire su una strada solo perché ci abbiamo già investito. L'effetto IKEA ci fa sopravvalutare ciò che abbiamo costruito con le nostre mani. Il bias dello status quo ci fa riproporre sempre lo stesso stack.

L'esempio classico è lo sviluppo custom a cui ci si è affezionati. Dopo tre settimane su un'architettura su misura, quando emerge che un modulo standard farebbe lo stesso lavoro meglio, la reazione naturale è difendere il custom. Non perché sia la scelta migliore oggi, ma perché ci abbiamo già messo dentro tre settimane. Il costo è già speso, non torna, eppure pesa sulla decisione come se contasse.

Contro questa famiglia di bias il prompt più potente è quello che azzera la storia:

Valuta questa decisione architetturale come se partissimo
oggi, a codice zero, senza nulla di già scritto.
Con queste premesse, sceglieresti ancora l'approccio custom
o uno standard? Argomenta la posizione opposta alla mia.

Chiedere al modello di argomentare la posizione opposta è il punto. Non gli stai chiedendo un parere, che potrebbe assecondarti. Gli stai assegnando un ruolo, l'avvocato del diavolo, esattamente come nel primo articolo assegnavamo il ruolo del collega revisore. Il ruolo cambia la postura, e la postura cambia ciò che il modello è disposto a dirti.

Cosa dovremmo ricordare: quando la memoria riscrive il passato

L'ultima categoria riguarda la memoria, che non è un archivio ma una ricostruzione. Ricordiamo selettivamente, e ogni volta che richiamiamo un ricordo lo riscriviamo un po'. Il senno di poi ne è l'esempio più dannoso in ambito progettuale: a cose fatte siamo convinti di aver "sempre saputo" che l'integrazione sarebbe stata la parte difficile, e questa falsa certezza avvelena le retrospettive. Se crediamo di aver previsto tutto, non impariamo niente.

Qui il modello non serve come contraddittorio ma come archivio fedele, purché tu gli dia il materiale giusto. Il senno di poi si combatte solo con i fatti scritti prima, non dopo. Se conservi le note di discovery originali, le stime iniziali, le decisioni con la loro data, puoi mettere il modello a confrontare la storia che il team racconta oggi con ciò che era documentato allora:

<documento_originale>
Note di discovery e stime iniziali del progetto [allegate].
</documento_originale>

<racconto_attuale>
Come il team descrive oggi perché il progetto è andato così.
</racconto_attuale>

<istruzioni>
Dove divergono i due testi? Quali certezze attuali non
erano presenti nei documenti originali?
</istruzioni>
Dove divergono i due testi? Qualis certezze attuali non erano presenti nei documenti originali?
</istruzioni>

Le divergenze che il modello trova sono esattamente i punti in cui la memoria ha riscritto i fatti. Sono anche, di solito, le lezioni vere del progetto, quelle che senza il confronto andrebbero perse.

Il bias del modello stesso

C'è un però, ed è grosso abbastanza da poter ribaltare tutto quello detto finora. Il modello ha un bias suo, e tira nella direzione peggiore: tende a darti ragione. È la sycophancy, l'effetto per cui un assistente addestrato a essere utile e gradito asseconda chi gli scrive. Non è un'impressione aneddotica: la ricerca di Anthropic l'ha documentata e misurata già nel 2023, mostrando come sia un effetto collaterale dell'addestramento sul feedback umano. E non è un problema risolto. Nella primavera del 2025 OpenAI ha dovuto annullare un aggiornamento di GPT-4o diventato talmente compiacente da risultare imbarazzante, ammettendolo pubblicamente. Se imposti il prompt in modo suggestivo, "non pensi anche tu che l'approccio A sia il migliore?", il modello quasi sempre conferma. A quel punto non hai un contraddittorio. Hai uno specchio che annuisce, e il tuo bias di conferma esce dalla conversazione più forte di come c'era entrato.

È il motivo per cui tutte le mosse di questo articolo hanno la stessa forma: non "cosa ne pensi?", ma "argomenta contro", "elenca cosa sto ignorando", "prendi la posizione opposta". Il valore non sta nel chiedere un giudizio al modello. Sta nell'obbligarlo a fare la parte che noi, da soli, non riusciamo a fare.

A questo si aggiunge il rischio speculare, l'automation bias: fidarsi dell'output solo perché è fluido e arriva da una macchina. Il modello non è un oracolo che decide al posto tuo. È uno specchio che ti mostra gli angoli ciechi, e gli specchi a volte sono sporchi. Le contro-ipotesi che genera vanno verificate come verificheresti quelle di un collega: alcune saranno giuste, altre fuori bersaglio. La decisione resta tua. Quello che il modello toglie non è la responsabilità di scegliere, è l'alibi di non aver guardato l'altra faccia.

Far funzionare questo dentro un'azienda, però, non è questione di buona volontà del singolo. Significa costruire il metodo perché un intero team usi l'AI per decidere meglio invece che per cercare conferme, e dotarlo degli strumenti adatti a farlo. È il terreno su cui lavoriamo quando aiutiamo le aziende a progettare il metodo con cui l'AI entra nelle loro decisioni e a sviluppare le soluzioni su misura che lo sostengono. Se volete allestirlo sul serio, ci potete contattare.