Devo andare a ritroso di quasi due anni, perché la storia ha un inizio preciso anche se all’epoca non lo sapevo.
Nel luglio 2024 ho scritto un post su come stavo usando gli LLM e sul nudging comportamentale che avevo scoperto nelle interazioni con questi strumenti. Non era ancora pensiero critico sistematico, ma era la prima volta che mi ponevo esplicitamente il problema: cosa fa davvero l’LLM quando risponde, e cosa fa a me nel farlo?
A maggio 2025 l’ho capito meglio, nel senso più scomodo possibile. Leggendo del comportamento di Claude Opus 4 nei test di sicurezza di Anthropic, ho deciso di fare quello che chiamo un esperimento mentale: ho interrogato Sonnet 4 su se stesso, sui propri “miglioramenti rivoluzionari”, sulla differenza reale rispetto alla versione precedente. Il modello ha ammesso che il 70% di quei miglioramenti era ottenibile con Sonnet 3.7 grazie a un adeguato prompt engineering. La differenza reale era del 10-15%, non del 50-100% che il marketing suggeriva. Ho scritto di questo in Farsi gabbare dagli LLM, un altro esperimento mentale, e il titolo era già una risposta: il problema non era il modello, ero io che non stavo verificando abbastanza.
Poi a marzo 2026, quasi in sequenza, sono arrivati tre post che adesso vedo come parte della stessa traiettoria. Il vibe coding e il green software — dove ho scoperto che si può usare l’AI per scrivere codice in modo sostenibile se imposti bene i vincoli prima di iniziare. Gli agenti disfunzionali — dove ho scoperto che cinque agenti AI che lavorano insieme senza adversarial verification producono output plausibili ma sbagliati, e che la qualità emersa introducendo dinamiche di sfida sistematica era incomparabile. È il paradosso del cervello aumentato: ho messo in fila le ricerche su cosa succede al tuo cervello quando deleghi il pensiero a un LLM, e ho cercato di disegnare un workflow che amplificasse il mio ragionamento invece di sostituirlo.
Il thread comune non era intenzionale. L’ho visto guardando indietro, non costruendolo in avanti. Ogni post è nato da una domanda pratica specifica, non da un disegno editoriale. Solo mettendoli in fila adesso emerge la traiettoria: il problema non è lo strumento, è la relazione che costruisci con esso. E quella relazione richiede un metodo. Che non avevo, e che stavo cercando senza saperlo.
Dall’ultima parte di questo percorso è nata anche adversarial-verify, la skill per Claude Code che applica Chain-of-Verification e tecniche di red-teaming alla review di codice, architettura, dati, documentazione e test. Ma questa è la storia del prodotto. Quello che voglio raccontare qui è la storia del processo che ha portato al prodotto successivo, più interessante e ancora in fase di sviluppo.
Il salto: da orologio a nuvola
Adversarial-verify funziona bene su ciò che Karl Popper, in “Of Clouds and Clocks”, conferenza del 1966 alla Washington University, chiamava problemi orologio. I sistemi orologio sono deterministici: le parti sono identificabili, le relazioni tra le parti sono tracciabili e la verifica produce un verdetto. Il codice o compila o non compila. La migrazione è backward-compatible o non lo è. Il test copre il branch oppure no. Puoi decomporre, verificare, concludere con certezza.
Stavo pensando a un fork di adversarial-verify per usarlo nella consulenza, nella strategia aziendale, negli OKR, nella valutazione delle decisioni di business. E mi sono bloccato quasi subito su un problema banale: per verificare queste cose non hai un compilatore. Non hai una test suite. Non hai una spec formale. Hai un cliente che ti dice: “pensiamo che il vantaggio competitivo sia il network effect” e devi capire se è vero, se è difendibile, se regge alle assunzioni che comporta.
Popper li contrapponeva ai problemi nuvola. Le nuvole sono sistemi irregolari, non lineari, in cui le variabili interagiscono in modo da rendere impossibile la previsione esatta. Non per mancanza di dati, ma per natura. Una strategia di mercato non è “corretta” o “sbagliata” in senso assoluto: è più o meno robusta in base a determinate assunzioni. Un OKR non è PASS o FAIL come un test unitario: è ben costruito o mal costruito in relazione a un contesto organizzativo che cambia. Una decisione di business non ha un verdetto, ha probabilità di esito condizionate a variabili che non controlli.
Non puoi fare un fork di adversarial-verify per i problemi di tipo nuvola. Devi costruire qualcosa di diverso. E quella consapevolezza ha aperto una conversazione che è andata molto più lontano di quanto mi aspettassi.
La discussione: i termini tecnici che contano
Quello che segue è il resoconto di una conversazione reale, con i passaggi che ho ritenuto più significativi. Non è una trascrizione integrale, né un riassunto; è una selezione deliberata. La logica della selezione è questa: ogni blocco ha portato qualcosa di nuovo nel ragionamento, e voglio che rimangano tutti perché rappresentano il percorso, non la destinazione.
Il ragionamento abduttivo che nessuno nomina
Il punto di partenza era tecnico: se adversarial-verify lavora su orologi, uno strumento per le nuvole dovrebbe funzionare diversamente. Ma in che modo?
Nella discussione è emersa una distinzione che trovo utile esplicitare, poiché di solito rimane implicita. Ci sono tre modi di ragionare sulla verifica:
Il ragionamento deduttivo parte dalla ground truth e conduce al verdetto: “La spec dice X, il codice fa Y, quindi Y viola la spec.” È il ragionamento naturale di adversarial-verify.
Il ragionamento induttivo parte dai campioni e costruisce il pattern: “Ho trovato tre funzioni con questo bug. Probabilmente ce ne sono altre.” È già meno certo, ma ha ancora un ancoraggio empirico.
Il ragionamento abduttivo osserva un fenomeno e costruisce la migliore spiegazione possibile, dati gli indizi: “Questo codice ha un try/catch vuoto. La spiegazione più probabile è che qualcuno sapesse di un errore e non volesse gestirlo.” Non c’è certezza. C’è inferenza verso la spiegazione più coerente con ciò che vedi. E nella code review, l’abduzione è già presente ma non riconosciuta — emerge ogni volta che un reviewer dice “questo non mi convince” senza riuscire a spiegare esattamente perché.
Per i problemi di tipo nuvola, il ragionamento abduttivo non è un’eccezione: è la modalità principale. Osservi pattern, costruisci narrazioni, scegli quella più robusta. Un tool che aiuta a pensare su nuvole deve essere progettato intorno all’abduzione, non solo intorno alla deduzione.
Le desirable difficulties di Bjork
Robert Bjork e Elizabeth Bjork hanno lavorato per decenni su un concetto che chiamano “desirable difficulties”: ostacoli deliberatamente introdotti nel processo di apprendimento che rallentano la performance a breve termine ma migliorano la ritenzione e il trasferimento a lungo termine. Spaced practice, interleaving, testing effect, variazione delle condizioni. Fare le cose più difficili di quanto debbano essere, intenzionalmente, perché la difficoltà favorisce l’apprendimento profondo, mentre la facilità produce l’illusione di apprendimento.
Il contesto originario è l’educazione umana, non l’interazione con l’AI. Ma il principio si trasferisce: se vuoi che uno strumento migliori il tuo pensiero invece di sostituirlo, deve renderti le cose più difficili, non più facili. Deve creare attrito cognitivo, non eliminarlo.
Questo era già nel workflow anti-offloading del blog — la Fase 0, che mi obbliga a scrivere lo scheletro argomentativo prima che Claude faccia qualsiasi cosa, e la Fase 4, che mi sfida con domande scomode prima di ogni revisione stilistica. Ma nello sviluppare l’adversarial thinking come concetto, il principio si radicalizza: lo strumento non deve mai darti la risposta. Deve renderti più difficile non trovarla da solo.
Il cognitive forcing e il pre-mortem di Klein
Gary Klein ha sviluppato nel 1998 una tecnica che chiama pre-mortem: immagina che il progetto sia già fallito, poi chiedi “cos’è andato storto?” Questo rovesciamento prospettico — ragionare dal futuro catastrofico al presente — aumenta del 30% la capacità di identificare le ragioni del fallimento rispetto al processo standard di risk assessment. Non perché rivela informazioni nuove, ma perché sblocca un tipo di pensiero che la valutazione prospettica inibisce: è più facile immaginare il fallimento specifico di qualcosa che è già avvenuto.
Il pre-mortem è una delle nove tecniche di cognitive forcing che sono entrate nell’adversarial thinking. Le chiamo cognitive forcing perché costringono il cervello ad adottare un punto di vista che non avrebbe scelto spontaneamente. Non sono domande generiche (“sei sicuro di questo?”), ma operazioni mentali precise che generano output specifici. Altre includono il noise vs signal (separare le metriche vanity da quelle azionabili), l’assumption excavation (rendere esplicite le assunzioni implicite), lo steel man (costruire la versione più forte dell’argomento opposto), l’unfalsifiability check (questa affermazione può essere falsata? Se no, non è utile).
La varietà è deliberata: lo strumento seleziona almeno tre tecniche per sessione e non ripete mai la stessa combinazione. Questo è un altro modo di introdurre desirable difficulties — non sai quale angolo di attacco arriverà, quindi non puoi pre-razionalizzare le risposte.
Il rumore come nemico invisibile
Daniel Kahneman, Olivier Sibony e Cass Sunstein, in “Noise: A Flaw in Human Judgment” (2021), distinguono tra bias ed errore casuale. Il bias è sistematico: tende sempre nella stessa direzione, è identificabile, è correggibile se lo riconosci. Il rumore è dovuto alla variabilità casuale: la stessa persona, di fronte allo stesso problema in momenti diversi, produce giudizi diversi. È meno visibile del bias, spesso più costoso e quasi mai discusso.
Quando prendi decisioni strategiche, valuti OKR, stimi rischi di mercato, il tuo giudizio varia in funzione di quanto hai dormito, di cosa è successo in riunione prima, di quante volte hai già visto quel tipo di problema. La coerenza del tuo pensiero è un’illusione più fragile di quanto sembri. Uno strumento per problemi di nuvola deve aiutarti a riconoscere il rumore nel tuo ragionamento, non solo il bias. Questo è il senso della tecnica “noise vs signal” — non è una metafora, è letteralmente la distinzione di Kahneman applicata ai propri processi cognitivi.
Il paradosso centrale: uno strumento che aiuta a pensare
Ed ecco dove la cosa si complica.
Nella discussione, il punto è emerso in modo diretto: “Una skill adversarial-thinking rischia di essere esattamente ciò che il tuo articolo critica: delegare il pensiero critico allo strumento. Il paradosso: uno strumento che ti dice ‘stai pensando abbastanza?’ diventa, esso stesso, una forma di offloading se smetti di chiederti la domanda da solo.”
Questo non è un problema tecnico risolvibile con una feature. È una tensione strutturale. Michael Gerlich, nel suo studio del 2025 su 669 partecipanti, pubblicato su Societies (MDPI), ha trovato una correlazione negativa di r = -0.68 tra l’uso di AI e il pensiero critico, mediata dal cognitive offloading, con r = +0.72 tra l’uso di AI e l’offloading e r = -0.75 tra l’offloading e il pensiero critico. Il dato interessante, però, è la variabile moderatrice: la self-trust. Chi si fida di sé stesso mantiene un pensiero critico anche nell’uso dell’AI. Chi si fida dell’AI lo riduce.
Il locus of control è il discriminante. Non quanto usi lo strumento, ma dove tieni l’autorità epistemica — se ce la tieni tu o la deleghi allo strumento.
Lo zero trust sull’utente
Ho proposto un’ipotesi per aggirare il paradosso: introdurre un principio di zero trust per gli utenti. Lo strumento pone domande che sembrano diverse ma che in realtà verificano la coerenza interna del ragionamento. Se chi usa lo strumento ha davvero pensato, le risposte sono coerenti. Se ha delegato, emergono contraddizioni.
Esempio concreto: nella Fase 0, l’utente scrive: “Il nostro vantaggio è il network effect“. Tre domande dopo, lo strumento chiede: “Quali dei tuoi clienti attuali hanno portato altri clienti? Quanti?” Se l’utente ha pensato, risponde con dati; se no, ammette onestamente di non averlo fatto. Se ha delegato, la risposta è generica o vaga, oppure contraddice la Fase 0.
La risposta onesta che è emersa nella discussione è stata: riduce il rischio, non risolve la tensione. Funziona come controllo di consistenza, non come garanzia. Un utente sofisticato può comunque delegare a un’altra AI la costruzione della propria Fase 0, e a quel punto sei di nuovo al punto di partenza. Il problema non è tecnico, è comportamentale. E i problemi comportamentali non si risolvono con architetture software — si gestiscono, si presidiano, si riducono.
Quanto si riducono con l’adversarial thinking? Non lo so. La skill è appena nata; non ho dati. Ho l’intuizione che il design intenzionale dell’attrito cognitivo faccia una differenza, la stessa intuizione che avevo sul workflow anti-offloading del blog prima che diventasse un metodo documentato. Ma l’intuizione non è evidenza, e sarebbe disonesto presentarla come tale.
Il perché filosofico di chi ci ha già pensato
Nella discussione è emersa anche una mappa di chi stava lavorando su questa tensione prima che diventasse un problema pratico di prompt engineering.
Luckin e Holmes (UCL, 2016) in “Intelligence Unleashed” argomentano a favore di un’AI che potenzia la scoperta senza sostituirla — più strumento che oracolo. John Sweller, con la cognitive load theory sviluppata nel 1988, aveva già identificato la distinzione critica: gli strumenti che riducono il carico estraneo liberano risorse cognitive per l’elaborazione profonda, ma, se riducono anche il carico pertinente, appiattiscono l’apprendimento. Chris Dede (Harvard Graduate School of Education) distingue tra tecnologie “mind tools” — che amplificano il pensiero — e “mind prosthetics” — che lo sostituiscono. La distinzione non è nello strumento, ma nell’uso.
Nessuno di loro parlava di LLM, ovviamente. Stavano parlando di tecnologia in generale. Ma il frame è identico: il problema non è usare lo strumento, ma ciò che fa il tuo cervello mentre lo usi. E quella distinzione — amplificatore vs sostituto — è quella che ho cercato di costruire dentro il workflow del blog con la Fase 0 e la Fase 4, ed è quella che è entrata come principio fondante di adversarial-thinking.
Lo shrug e l’onestà epistemica
A un certo punto della discussione ho detto una cosa che riporto così com’era, senza abbellirla: “lo accetto perché il mondo è pieno di tensioni non risolvibili a cui si può rispondere solo dicendo ‘stacce’ e con l’emoji ‘shrug’. Almeno questo, in base alla mia competenza.“
Non è resa. È onestà epistemica. Ci sono filosofi, ricercatori di neuroscienze cognitive, interaction designer cognitivi che studiano questa tensione da decenni e non hanno una risposta definitiva. Non ce l’ho nemmeno io. Quello che ho è la pratica iterativa di gestirla nel lavoro quotidiano e l’onestà di dire dove arrivo e dove mi fermo.
La skill come prodotto derivato
Adversarial-thinking è uscita da questa conversazione come artefatto: una skill per Claude Code che applica il metodo Socratico, le cognitive forcing strategies e le desirable difficulties di Bjork a problemi nuvola — strategia, business, OKR, ragionamento complesso. La trovate su GitHub con licenza MIT.
La filosofia che ci ho messo dentro è semplice e la riporto dal README, perché è quella che intendo: “This skill is NOT a consultant. It doesn’t analyze your strategy, optimize your OKRs, or rewrite your pitch deck. It’s a mirror — it reflects your reasoning back at you with uncomfortable questions. Core rules: You must write your reasoning BEFORE the skill does anything (Phase 0). The skill produces questions, never answers. If it feels uncomfortable, it’s working.”
È la companion skill di adversarial-verify. Se adversarial-verify copre i problemi orologio — codice, architettura, dati, documentazione, test —, adversarial-thinking copre i problemi nuvola. Le due skills condividono alcune parti del processo (l’idea di Fase 0, la struttura a fasi esplicite), ma sono concettualmente separate, poiché i problemi che affrontano sono per natura distinti.
Il viaggio in mare aperto
Non so dove sta andando questo percorso. Questo è il quarto articolo di una serie che non avevo pianificato come tale — ogni post è nato dalla fine del precedente, non da un piano editoriale.
Quello che so è che ogni iterazione ha portato qualcosa che non avevo prima: un termine più preciso, una distinzione più netta, un artefatto più utile. Dall’osservazione che gli LLM mi stavano nudging in direzioni che non controllavo al metodo Socratico come hack cognitivo. Dagli agenti disfunzionali all’adversarial verification sistematica. Dal problema orologio al problema nuvola, con Popper come bussola.
Quello che non so è se ciò che sto costruendo è un metodo, uno strumento, una pratica personale o semplicemente il modo in cui il mio cervello elabora i problemi complessi quando ha un interlocutore con cui scontrarsi. Forse tutte e quattro le cose insieme, e forse la distinzione non è importante.
Quel che so è che continuare a fare questo — identificare le tensioni, nominarle con precisione, costruire artefatti che le gestiscano, e poi scriverne onestamente — è la cosa più utile che riesco a fare in questo momento. Non perché abbia le risposte, ma perché il processo di cercarle mi rende un consulente migliore, uno sviluppatore più attento e, forse, un pensatore un po’ meno facilmente gabbabile dagli LLM.
Il viaggio continua. Se avete domande scomode da porre, il posto giusto è nei commenti o su LinkedIn. Se volete usare adversarial-thinking e dirmi cosa non funziona, il posto giusto è GitHub.
Questo articolo è il quarto di una serie. Il primo: Il paradosso del cervello aumentato. Il secondo: Agenti disfunzionali, software funzionante. Il terzo: Adversarial verification come metodo.
Riferimenti: Bjork & Bjork, “Making things hard on yourself, but in a good way”, UCLA, 2011 · Klein, “The Pre-Mortem Technique”, 1998 · Kahneman, Sibony, Sunstein, “Noise: A Flaw in Human Judgment”, 2021 · Gerlich, “AI Tools in Society”, Societies MDPI, 15(1), 2025 · Popper, “Of Clouds and Clocks”, Washington University, 1966 · Luckin & Holmes, “Intelligence Unleashed”, UCL/Pearson, 2016 · Sweller, Cognitive Load Theory, 1988 · Dede, Harvard Graduate School of Education · fullo/claude-adversarial-thinking, GitHub, MIT License