A maggio 2025 l’ho capito meglio, nel senso pi\u00f9 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<\/a>, e il titolo era gi\u00e0 una risposta: il problema non era il modello, ero io che non stavo verificando abbastanza.<\/p>\n\n\n\n\n\n\n\n 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<\/a> \u2014 dove ho scoperto che si pu\u00f2 usare l’AI per scrivere codice in modo sostenibile se imposti bene i vincoli prima di iniziare. Gli agenti disfunzionali<\/a> \u2014 dove ho scoperto che cinque agenti AI che lavorano insieme senza adversarial verification producono output plausibili ma sbagliati, e che la qualit\u00e0 emersa introducendo dinamiche di sfida sistematica era incomparabile. \u00c8 il paradosso del cervello aumentato<\/a>: 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.<\/p>\n\n\n\n Il thread comune non era intenzionale. L’ho visto guardando indietro, non costruendolo in avanti. Ogni post \u00e8 nato da una domanda pratica specifica, non da un disegno editoriale. Solo mettendoli in fila adesso emerge la traiettoria: il problema non \u00e8 lo strumento, \u00e8 la relazione che costruisci con esso. E quella relazione richiede un metodo. Che non avevo, e che stavo cercando senza saperlo.<\/p>\n\n\n\n Dall’ultima parte di questo percorso \u00e8 nata anche adversarial-verify<\/a>, 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 \u00e8 la storia del prodotto. Quello che voglio raccontare qui \u00e8 la storia del processo che ha portato al prodotto successivo, pi\u00f9 interessante e ancora in fase di sviluppo.<\/p>\n\n\n\n Adversarial-verify funziona bene su ci\u00f2 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 \u00e8 backward-compatible o non lo \u00e8. Il test copre il branch oppure no. Puoi decomporre, verificare, concludere con certezza.<\/p>\n\n\n\n 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 \u00e8 vero, se \u00e8 difendibile, se regge alle assunzioni che comporta.<\/p>\n\n\n\n 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 \u00e8 “corretta” o “sbagliata” in senso assoluto: \u00e8 pi\u00f9 o meno robusta in base a determinate assunzioni. Un OKR non \u00e8 PASS o FAIL come un test unitario: \u00e8 ben costruito o mal costruito in relazione a un contesto organizzativo che cambia. Una decisione di business non ha un verdetto, ha probabilit\u00e0 di esito condizionate a variabili che non controlli.<\/p>\n\n\n\n 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 \u00e8 andata molto pi\u00f9 lontano di quanto mi aspettassi.<\/p>\n\n\n\n Quello che segue \u00e8 il resoconto di una conversazione reale, con i passaggi che ho ritenuto pi\u00f9 significativi. Non \u00e8 una trascrizione integrale, n\u00e9 un riassunto; \u00e8 una selezione deliberata. La logica della selezione \u00e8 questa: ogni blocco ha portato qualcosa di nuovo nel ragionamento, e voglio che rimangano tutti perch\u00e9 rappresentano il percorso, non la destinazione.<\/p>\n\n\n\n Il punto di partenza era tecnico: se adversarial-verify lavora su orologi, uno strumento per le nuvole dovrebbe funzionare diversamente. Ma in che modo?<\/p>\n\n\n\n Nella discussione \u00e8 emersa una distinzione che trovo utile esplicitare, poich\u00e9 di solito rimane implicita. Ci sono tre modi di ragionare sulla verifica:<\/p>\n\n\n\n Il ragionamento deduttivo<\/strong> parte dalla ground truth e conduce al verdetto: “La spec dice X, il codice fa Y, quindi Y viola la spec.” \u00c8 il ragionamento naturale di adversarial-verify.<\/p>\n\n\n\n Il ragionamento induttivo<\/strong> parte dai campioni e costruisce il pattern: “Ho trovato tre funzioni con questo bug. Probabilmente ce ne sono altre.” \u00c8 gi\u00e0 meno certo, ma ha ancora un ancoraggio empirico.<\/p>\n\n\n\n Il ragionamento abduttivo<\/a><\/strong> osserva un fenomeno e costruisce la migliore spiegazione possibile, dati gli indizi: “Questo codice ha un try\/catch vuoto. La spiegazione pi\u00f9 probabile \u00e8 che qualcuno sapesse di un errore e non volesse gestirlo.” Non c’\u00e8 certezza. C’\u00e8 inferenza verso la spiegazione pi\u00f9 coerente con ci\u00f2 che vedi. E nella code review, l’abduzione \u00e8 gi\u00e0 presente ma non riconosciuta \u2014 emerge ogni volta che un reviewer dice “questo non mi convince” senza riuscire a spiegare esattamente perch\u00e9.<\/p>\n\n\n\n Per i problemi di tipo nuvola, il ragionamento abduttivo non \u00e8 un’eccezione: \u00e8 la modalit\u00e0 principale. Osservi pattern, costruisci narrazioni, scegli quella pi\u00f9 robusta. Un tool che aiuta a pensare su nuvole deve essere progettato intorno all’abduzione, non solo intorno alla deduzione.<\/p>\n\n\n\n Robert Bjork e Elizabeth Bjork hanno lavorato per decenni su un concetto che chiamano “desirable difficulties”<\/a>: 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\u00f9 difficili di quanto debbano essere, intenzionalmente, perch\u00e9 la difficolt\u00e0 favorisce l’apprendimento profondo, mentre la facilit\u00e0 produce l’illusione di apprendimento.<\/p>\n\n\n\n Il contesto originario \u00e8 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\u00f9 difficili, non pi\u00f9 facili. Deve creare attrito cognitivo, non eliminarlo.<\/p>\n\n\n\n Questo era gi\u00e0 nel workflow anti-offloading del blog \u2014 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\u2019adversarial thinking come concetto, il principio si radicalizza: lo strumento non deve mai darti la risposta. Deve renderti pi\u00f9 difficile non trovarla da solo.<\/p>\n\n\n\n Gary Klein ha sviluppato nel 1998 una tecnica che chiama pre-mortem<\/a>: immagina che il progetto sia gi\u00e0 fallito, poi chiedi “cos’\u00e8 andato storto?” Questo rovesciamento prospettico \u2014 ragionare dal futuro catastrofico al presente \u2014 aumenta del 30% la capacit\u00e0 di identificare le ragioni del fallimento rispetto al processo standard di risk assessment. Non perch\u00e9 rivela informazioni nuove, ma perch\u00e9 sblocca un tipo di pensiero che la valutazione prospettica inibisce: \u00e8 pi\u00f9 facile immaginare il fallimento specifico di qualcosa che \u00e8 gi\u00e0 avvenuto.<\/p>\n\n\n\n Il pre-mortem \u00e8 una delle nove tecniche di cognitive forcing che sono entrate nell’adversarial thinking. Le chiamo cognitive forcing perch\u00e9 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\u00f9 forte dell’argomento opposto), l’unfalsifiability check (questa affermazione pu\u00f2 essere falsata? Se no, non \u00e8 utile).<\/p>\n\n\n\n La variet\u00e0 \u00e8 deliberata: lo strumento seleziona almeno tre tecniche per sessione e non ripete mai la stessa combinazione. Questo \u00e8 un altro modo di introdurre desirable difficulties \u2014 non sai quale angolo di attacco arriver\u00e0, quindi non puoi pre-razionalizzare le risposte.<\/p>\n\n\n\n Daniel Kahneman, Olivier Sibony e Cass Sunstein, in “Noise: A Flaw in Human Judgment<\/a><\/em>” (2021), distinguono tra bias ed errore casuale. Il bias \u00e8 sistematico: tende sempre nella stessa direzione, \u00e8 identificabile, \u00e8 correggibile se lo riconosci. Il rumore \u00e8 dovuto alla variabilit\u00e0 casuale: la stessa persona, di fronte allo stesso problema in momenti diversi, produce giudizi diversi. \u00c8 meno visibile del bias, spesso pi\u00f9 costoso e quasi mai discusso.<\/p>\n\n\n\n Quando prendi decisioni strategiche, valuti OKR, stimi rischi di mercato, il tuo giudizio varia in funzione di quanto hai dormito, di cosa \u00e8 successo in riunione prima, di quante volte hai gi\u00e0 visto quel tipo di problema. La coerenza del tuo pensiero \u00e8 un’illusione pi\u00f9 fragile di quanto sembri. Uno strumento per problemi di nuvola deve aiutarti a riconoscere il rumore nel tuo ragionamento, non solo il bias. Questo \u00e8 il senso della tecnica “noise vs signal” \u2014 non \u00e8 una metafora, \u00e8 letteralmente la distinzione di Kahneman applicata ai propri processi cognitivi.<\/p>\n\n\n\n Ed ecco dove la cosa si complica.<\/p>\n\n\n\n Nella discussione, il punto \u00e8 emerso in modo diretto: “Una skill adversarial-thinking rischia di essere esattamente ci\u00f2 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<\/em>.”<\/p>\n\n\n\n Questo non \u00e8 un problema tecnico risolvibile con una feature. \u00c8 una tensione strutturale. Michael Gerlich, nel suo studio del 2025 su 669 partecipanti, pubblicato su Societies (MDPI)<\/a>, 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\u00f2, \u00e8 la variabile moderatrice: la self-trust. Chi si fida di s\u00e9 stesso mantiene un pensiero critico anche nell’uso dell’AI. Chi si fida dell’AI lo riduce.<\/p>\n\n\n\n Il locus of control \u00e8 il discriminante. Non quanto usi lo strumento, ma dove tieni l’autorit\u00e0 epistemica \u2014 se ce la tieni tu o la deleghi allo strumento.<\/p>\n\n\n\n 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\u00e0 verificano la coerenza interna del ragionamento. Se chi usa lo strumento ha davvero pensato, le risposte sono coerenti. Se ha delegato, emergono contraddizioni.<\/p>\n\n\n\n Esempio concreto: nella Fase 0, l’utente scrive: “Il nostro vantaggio \u00e8 il network effect<\/em>“. Tre domande dopo, lo strumento chiede: “Quali dei tuoi clienti attuali hanno portato altri clienti? Quanti?<\/em>” Se l’utente ha pensato, risponde con dati; se no, ammette onestamente di non averlo fatto. Se ha delegato, la risposta \u00e8 generica o vaga, oppure contraddice la Fase 0.<\/p>\n\n\n\n La risposta onesta che \u00e8 emersa nella discussione \u00e8 stata: riduce il rischio, non risolve la tensione. Funziona come controllo di consistenza, non come garanzia. Un utente sofisticato pu\u00f2 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 \u00e8 tecnico, \u00e8 comportamentale. E i problemi comportamentali non si risolvono con architetture software \u2014 si gestiscono, si presidiano, si riducono.<\/p>\n\n\n\n Quanto si riducono con l’adversarial thinking? Non lo so. La skill \u00e8 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 \u00e8 evidenza, e sarebbe disonesto presentarla come tale.<\/p>\n\n\n\n Nella discussione \u00e8 emersa anche una mappa di chi stava lavorando su questa tensione prima che diventasse un problema pratico di prompt engineering.<\/p>\n\n\n\n Luckin e Holmes (UCL, 2016)<\/a> in “Intelligence Unleashed<\/em>” argomentano a favore di un’AI che potenzia la scoperta senza sostituirla \u2014 pi\u00f9 strumento che oracolo. John Sweller, con la cognitive load theory sviluppata nel 1988, aveva gi\u00e0 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)<\/a> distingue tra tecnologie “mind tools” \u2014 che amplificano il pensiero \u2014 e “mind prosthetics” \u2014 che lo sostituiscono. La distinzione non \u00e8 nello strumento, ma nell’uso.<\/p>\n\n\n\n Nessuno di loro parlava di LLM, ovviamente. Stavano parlando di tecnologia in generale. Ma il frame \u00e8 identico: il problema non \u00e8 usare lo strumento, ma ci\u00f2 che fa il tuo cervello mentre lo usi. E quella distinzione \u2014 amplificatore vs sostituto \u2014 \u00e8 quella che ho cercato di costruire dentro il workflow del blog con la Fase 0 e la Fase 4, ed \u00e8 quella che \u00e8 entrata come principio fondante di adversarial-thinking.<\/p>\n\n\n\n A un certo punto della discussione ho detto una cosa che riporto cos\u00ec com’era, senza abbellirla: “lo accetto perch\u00e9 il mondo \u00e8 pieno di tensioni non risolvibili a cui si pu\u00f2 rispondere solo dicendo ‘stacce’ e con l’emoji ‘shrug’. Almeno questo, in base alla mia competenza.<\/em>“<\/p>\n\n\n\n Non \u00e8 resa. \u00c8 onest\u00e0 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 \u00e8 la pratica iterativa di gestirla nel lavoro quotidiano e l’onest\u00e0 di dire dove arrivo e dove mi fermo.<\/p>\n\n\n\n Adversarial-thinking \u00e8 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 \u2014 strategia, business, OKR, ragionamento complesso. La trovate su GitHub<\/a> con licenza MIT.<\/p>\n\n\n\n La filosofia che ci ho messo dentro \u00e8 semplice e la riporto dal README, perch\u00e9 \u00e8 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 \u2014 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<\/em>.”<\/p>\n\n\n\n \u00c8 la companion skill di adversarial-verify. Se adversarial-verify copre i problemi orologio \u2014 codice, architettura, dati, documentazione, test \u2014, 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\u00e9 i problemi che affrontano sono per natura distinti.<\/p>\n\n\n\n Non so dove sta andando questo percorso. Questo \u00e8 il quarto articolo di una serie che non avevo pianificato come tale \u2014 ogni post \u00e8 nato dalla fine del precedente, non da un piano editoriale.<\/p>\n\n\n\n Quello che so \u00e8 che ogni iterazione ha portato qualcosa che non avevo prima: un termine pi\u00f9 preciso, una distinzione pi\u00f9 netta, un artefatto pi\u00f9 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.<\/p>\n\n\n\n Quello che non so \u00e8 se ci\u00f2 che sto costruendo \u00e8 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 \u00e8 importante.<\/p>\n\n\n\n Quel che so \u00e8 che continuare a fare questo \u2014 identificare le tensioni, nominarle con precisione, costruire artefatti che le gestiscano, e poi scriverne onestamente \u2014 \u00e8 la cosa pi\u00f9 utile che riesco a fare in questo momento. Non perch\u00e9 abbia le risposte, ma perch\u00e9 il processo di cercarle mi rende un consulente migliore, uno sviluppatore pi\u00f9 attento e, forse, un pensatore un po’ meno facilmente gabbabile dagli LLM.<\/p>\n\n\n\n Il viaggio continua. Se avete domande scomode da porre, il posto giusto \u00e8 nei commenti o su LinkedIn<\/a>. Se volete usare adversarial-thinking e dirmi cosa non funziona, il posto giusto \u00e8 GitHub<\/a>.<\/p>\n\n\n\n Questo articolo \u00e8 il quarto di una serie. Il primo: Il paradosso del cervello aumentato<\/a>. Il secondo: Agenti disfunzionali, software funzionante<\/a>. Il terzo: Adversarial verification come metodo<\/a>.<\/em><\/p>\n\n\n\n Riferimenti: Bjork & Bjork, “Making things hard on yourself, but in a good way”, UCLA, 2011<\/a> \u00b7 Klein, “The Pre-Mortem Technique”, 1998<\/a> \u00b7 Kahneman, Sibony, Sunstein, “Noise: A Flaw in Human Judgment”, 2021<\/a> \u00b7 Gerlich, “AI Tools in Society”, Societies MDPI, 15(1), 2025<\/a> \u00b7 Popper, “Of Clouds and Clocks”, Washington University, 1966<\/a> \u00b7 Luckin & Holmes, “Intelligence Unleashed”, UCL\/Pearson, 2016<\/a> \u00b7 Sweller, Cognitive Load Theory, 1988<\/a> \u00b7 Dede, Harvard Graduate School of Education<\/a> \u00b7 fullo\/claude-adversarial-thinking, GitHub, MIT License<\/a><\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Stavo valutando di fare un fork di adversarial-verify per usarla nella consulenza \u2014 strategia, OKR, decisioni di business \u2014 quando mi sono accorto che il problema non era tecnico. Era concettuale: il codice ha verdetti, la strategia no. Da quella domanda \u00e8 nata una conversazione che ha prodotto adversarial-thinking, una skill per problemi nuvola invece che problemi orologio. Ma guardando indietro a due anni di post, ho visto emergere un filo rosso che non avevo pianificato. Questo articolo racconta quel filo, quella conversazione e perch\u00e9 il prodotto finale \u00e8 meno interessante del processo che lo ha generato.<\/p>\n","protected":false},"author":1,"featured_media":4613,"comment_status":"closed","ping_status":"open","sticky":false,"template":"templates\/template-cover.php","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[2313,16,4,5],"tags":[2439,2413,2430,2436,2421,2412,2444,2443],"class_list":["post-4612","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-design","category-lifehack","category-pensieri","category-tecnologia","tag-agentskills","tag-ai","tag-claude","tag-claude-code","tag-filosofia","tag-llm","tag-popper","tag-skills"],"yoast_head":"\n![\"\"](\"https:\/\/i0.wp.com\/www.fullo.net\/blog\/wp-content\/uploads\/2026\/04\/Gemini_Generated_Image_32cdvn32cdvn32cd.png?resize=580%2C317&ssl=1\")
<\/a><\/figure>\n\n\n\nIl salto: da orologio a nuvola<\/h2>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/www.fullo.net\/blog\/wp-content\/uploads\/2026\/04\/Gemini_Generated_Image_kawqcwkawqcwkawq.png?resize=580%2C317&ssl=1\")
<\/a><\/figure>\n\n\n\nLa discussione: i termini tecnici che contano<\/h2>\n\n\n\n
Il ragionamento abduttivo che nessuno nomina<\/h3>\n\n\n\n
Le desirable difficulties<\/em> di Bjork<\/h3>\n\n\n\n
Il cognitive forcing e il pre-mortem di Klein<\/h3>\n\n\n\n
Il rumore come nemico invisibile<\/h3>\n\n\n\n
Il paradosso centrale: uno strumento che aiuta a pensare<\/h3>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/www.fullo.net\/blog\/wp-content\/uploads\/2026\/04\/Gemini_Generated_Image_neishvneishvneis.png?resize=580%2C317&ssl=1\")
<\/a><\/figure>\n\n\n\nLo zero trust sull’utente<\/h3>\n\n\n\n
Il perch\u00e9 filosofico di chi ci ha gi\u00e0 pensato<\/h3>\n\n\n\n
Lo shrug e l’onest\u00e0 epistemica<\/h3>\n\n\n\n
La skill come prodotto derivato<\/h2>\n\n\n\n
Il viaggio in mare aperto<\/h2>\n\n\n\n