Se avete la sensazione che il web stia diventando un posto sempre più piccolo, spento, ostile e difficile da navigare, non è una vostra impressione: è una precisa scelta industriale.

Nelle scorse settimane abbiamo assistito all’atto finale di un’espropriazione silenziosa che andava avanti da anni. Google ha presentato la più grande rivoluzione della sua interfaccia degli ultimi venticinque anni, integrando le risposte sintetiche generate dall’intelligenza artificiale direttamente nella pagina dei risultati di ricerca.

Non è un semplice aggiornamento grafico: è la dichiarazione di morte del motore di ricerca per come lo abbiamo conosciuto, studiato, ottimizzato e utilizzato fin dalla fine degli anni novanta.

Il recinto dorato del consumo passivo

Per decenni il patto implicito tra il motore di ricerca e i creatori di contenuti è stato chiaro: voi ci fornite informazioni di valore, noi le indicizziamo e vi inviamo utenti interessati. Questo equilibrio, che ha permesso la nascita del web indipendente, si è rotto definitivamente.

Oggi l’obiettivo del monopolista è trattenere l’utente all’interno della propria piattaforma a ogni costo. Con le risposte sintetiche posizionate stabilmente in cima alla pagina, l’utente non ha più alcun motivo di cliccare sui link esterni per approfondire la fonte: consuma il riassunto preconfezionato dall’algoritmo, si adagia sulla risposta immediata e chiude la scheda.

Questo fenomeno si basa su un’attenta ingegneria del consenso che sfrutta la naturale pigrizia cognitiva dell’essere umano. Cercare sul web è sempre stato un atto attivo che richiedeva fatica: formulare una domanda, valutare l’affidabilità di tre o quattro fonti diverse, confrontare i punti di vista e sintetizzare un’opinione autonoma.

Il nuovo motore di ricerca elimina questa frizione, offrendo una pappa pre-masticata che neutralizza il pensiero critico. Siamo passati dal web dell’esplorazione al web del riassunto probabilistico. I siti web non sono più nodi di una rete decentralizzata, ma semplici fonti di energia da saccheggiare per addestrare e nutrire i modelli statistici di terzi, senza ricevere un solo clic in cambio.

La lezione dell’ex-marketer: l’illusione della terra in affitto

Avendo lavorato per anni nel marketing digitale e avendo progettato architetture web ed e-commerce complessi, conosco bene la narrazione con cui le agenzie hanno venduto l’illusione del posizionamento organico (SEO) come un asset aziendale sicuro.

Per anni interi dipartimenti di marketing hanno speso budget faraonici per inseguire le parole chiave, scalare le posizioni della SERP e compiacere i capricci dell’algoritmo di turno. Oggi quelle stesse aziende si risvegliano in un bagno di sangue perché capiscono, con drammatico ritardo, il vizio di forma strutturale della loro strategia: stavano costruendo grattacieli commerciali su un terreno in affitto.

Un posizionamento in un motore di ricerca proprietario non è una proprietà privata, è una concessione precaria revocabile senza preavviso. Quando il padrone di casa transatlantico decide di cambiare le regole dell’interfaccia o di trattenere per sé gli ospiti che bussano alla sua porta, l’inquilino non ha diritti legali o commerciali a cui appigliarsi.

L’azzeramento del traffico in entrata colpirà duramente tutti i business che hanno barattato l’indipendenza e la proprietà dei propri canali in cambio della comoda illusione della visibilità gratuita su piattaforme altrui.

La contromisura pratica: riappropriarsi dell’infrastruttura

La soluzione a questa catastrofe digitale non è rincorrere l’ennesimo trucco SEO, adattarsi alle linee guida di Google o pregare l’algoritmo di concedervi ancora qualche visita di cortesia. La risposta è la disintermediazione totale. Dobbiamo smettere di essere affittuari e iniziare a possedere l’hardware e la sintassi.

Per resistere all’alluvione sintetica dobbiamo applicare alcune contromisure urgenti:

• ripopolare e sostenere i protocolli decentralizzati e liberi, rilanciando l’utilizzo dei feed RSS per permettere agli utenti di seguire i nostri aggiornamenti in modo cronologico e privo di filtri algoritmici;

• investire sulla proprietà assoluta dei contatti attraverso newsletter, meglio se gestite su server e infrastrutture autonome, stabilendo un canale di comunicazione diretto che nessuna multinazionale può bloccare o tassare;

• puntare sulla complessità logica e sulla profondità dei contenuti, scrivendo testi talmente verticali, tecnici, specifici e ancorati all’esperienza fisica reale da risultare impossibili da sintetizzare per un chatbot probabilistico;

• smettere di ottimizzare i testi per i motori di ricerca e iniziare a farsi cercare direttamente dall’utente per nome e cognome, costringendolo a digitare l’indirizzo direttamente nella barra del browser oppure inserendovi tra i Preferiti.

La rinascita delle nicchie umane

Chi vive di esche, di contenuti generici, di guide di base e di titoli acchiappaclic ha i giorni contati: l’intelligenza artificiale è infinitamente più veloce ed economica nel produrre spazzatura sintetica di basso livello per saturare le risposte veloci del motore di ricerca.

In questo scenario di desertificazione digitale, la vera competenza si difende trasformando la propria presenza in una destinazione stabile e insostituibile. Il web aperto sta morendo, ma le nicchie umane basate sulla fiducia e sulla logica stanno rifiorendo. L’utente consapevole è stanco del rumore di fondo generato dai modelli probabilistici; cerca l’errore umano, cerca l’attrito del ragionamento, cerca il sudore di chi si sporca le mani in laboratorio o in sala macchine.

Tornare a possedere i propri archivi, a pretendere l’attenzione non mediata e a rifiutare la sottomissione alle grandi piattaforme commerciali è l’unico modo per non farsi cacciare dal digitale. Non fatevi intortare dalla comodità delle scatole nere: la sovranità si costruisce un byte alla volta, sul proprio disco rigido.

Sipario.

Negli Stati Uniti è il far west legale e lo Statuto dei lavoratori è carta straccia, ma la sostanza tecnica della questione non cambia di una virgola: per simulare intelligenza, la macchina ha un disperato bisogno di nutrirsi dei dati operativi e fisici di chi lavora per davvero.

Questa è la certificazione ufficiale di un fallimento narrativo monumentale. I modelli linguistici non ragionano, non deducono, non hanno intuizioni e, soprattutto, non progettano. Per simulare competenza, l’algoritmo deve vampirizzare i movimenti fisici umani. Mappare un clic del mouse o la pressione di un tasto, però, non significa in alcun modo mappare il ragionamento architettonico che ha portato a compiere quell’azione specifica.

Pensateci bene: uno specialista in architettura dei sistemi non clicca sul pulsante “Deploy” o non riavvia un servizio su un server per puro caso. Quel singolo, banale clic è solo il terminale fisico di un processo cognitivo vastissimo. Prima di cliccare, lo sviluppatore ha passato ore a leggere i log di sistema, ha analizzato il carico di rete, ha valutato i lock relazionali sul database, ha soppesato il rischio di una race condition e ha verificato le dipendenze del codice. L’intelligenza artificiale, piazzata lì a spiare lo schermo, registra l’azione finale (”il cursore si è mosso alle coordinate X-Y e ha fatto clic”), ignorando totalmente l’abisso cognitivo e la deduzione logica che la precedono.

Stanno costruendo eserciti di bot bravissimi a replicare l’esito finale di una scelta, ma del tutto ciechi di fronte al processo logico che la governa. Il risultato? Avremo macchine eccellenti nel ripetere percorsi felici, ma letteralmente incapaci di risolvere un’emergenza in produzione, di fare debugging su un errore imprevisto o di operare al di fuori di schemi rigidamente predeterminati. È il trionfo del “cargo cult” applicato all’informatica: scimmiottare i gesti dei professionisti sperando che, per magia, ne scaturisca un software funzionante.

Il rifiuto della fatica e la generazione degli utenti passivi

Questo cortocircuito tecnologico si specchia in una dinamica umana altrettanto tossica, un’emergenza silenziosa che osservo quotidianamente in trincea, passando dai percorsi GOL per adulti in riqualificazione fino ai laboratori di programmazione pura degli IeFP: il rifiuto sistematico e quasi fobico del learning by doing.

Nelle aule c’è una pretesa dilagante di avere il piatto pronto e masticato. Ci si blocca, preda del panico totale, davanti a una nuova interfaccia grafica o a una banale riga di codice rosso nel terminale, semplicemente perché non c’è un tutorial passo-passo a indicare la via o una voce suadente che ti dice dove mettere il cursore.

Chi bazzica i computer dagli anni Ottanta, da molto prima che internet diventasse un oracolo onnisciente a portata di smartphone, sa bene che l’unico modo per comprendere davvero un’architettura logica è distruggerla e ricostruirla da zero. Imparavamo a programmare o a usare i software sbattendo la testa contro i manuali (il caro, vecchio e sempre valido RTFM: Read The Fucking Manual), provando configurazioni improbabili, sbagliando, formattando dischi per errore, frustrandoci fino alle lacrime e riprovando il giorno dopo. Non c’era altra via. Non esistevano scorciatoie, non c’erano prompt da incollare e non c’erano forum da consultare.

Oggi dobbiamo dirci una verità impopolare: la frustrazione non è un ostacolo all’apprendimento, ne è il carburante e il motore principale. Quando passi quattro ore a cercare un maledetto errore di sintassi o a capire per quale oscuro motivo una query sul database non restituisce i dati attesi, il tuo cervello è costretto a costruire una mappa mentale indelebile di quell’architettura. Stai cablando neuroni, stai capendo il “perché” delle cose.

Se invece ti limiti a eseguire istruzioni passive dettate da un video su YouTube, o peggio, a incollare blocchi di codice generati da un prompt di un LLM senza saperli leggere, non stai acquisendo alcuna competenza. Non stai diventando un professionista dell’IT, stai agendo esattamente come i bot spia di Meta. Siete diventati meri esecutori statistici, una parodia dell’intelligenza umana, intimamente convinti di saper sviluppare software solo perché il codice, per un miracolo probabilistico, oggi si è compilato senza errori. Siete turisti “fai da te” smarriti all’interno del vostro stesso applicativo.

L’analfabetismo da stack trace

Il sintomo più evidente di questo distacco dalla realtà è quello che chiamo l’analfabetismo da stack trace. I ragazzi oggi lanciano un applicativo, questo va in crash vomitando a schermo un lenzuolo di testo rosso fuoco, e loro smettono immediatamente di ragionare. Invece di fermarsi, respirare e leggere la primissima riga dell’errore per capire il contesto, copiano brutalmente tutto il blocco e lo incollano dentro l’interfaccia dell’IA chiedendo “Aggiustalo!”.

Il motore probabilistico allucina una patch, suggerisce magari di importare una libreria inutile che riscrive mezza architettura, e l’utente esegue ciecamente. Hanno delegato la fase cruciale del lavoro, ovvero il debugging, a un generatore di testo. Ma il debugging è, nella sua essenza più nobile, il metodo scientifico applicato alla macchina: isolare le variabili, formulare un’ipotesi, testarla. Se salti questa fase, sei solo un dattilografo che preme tasti sperando di fare centro.

Il cimitero dei repository e la bomba del “junior gap”

Questa tempesta perfetta di pigrizia cognitiva umana e illusione tecnologica ha ricadute economiche e strutturali catastrofiche sul mercato del lavoro. Stiamo innescando una bomba a orologeria che farà impallidire i disastri del passato (Millennium Bug, te dico levate…), un collasso che chiameremo “debito tecnico strutturale”:

• le aziende IT, affascinate dai pitch commerciali dei vendor, smettono di assumere figure junior, illudendosi che un tool di autocompletamento in abbonamento basti per andare in produzione e abbattere i costi del personale a breve termine;

• l’assenza totale di gavetta impedisce la naturale formazione dei senior di domani, creando un vuoto anagrafico e di competenze incolmabile: vi svelo un segreto, un senior non nasce tale per decreto divino, è semplicemente un junior che è sopravvissuto a centinaia di disastri in sala macchine, affinando la propria capacità di lettura critica sui propri errori;

• se tagliamo l’ingresso alla base del mercato, tra dieci anni a chi affideremo la manutenzione delle architetture critiche, dei sistemi bancari o dei database sanitari;

• i repository aziendali si saturano quotidianamente di codice immantenibile, un mix letale e frankensteiniano di logiche allucinate dall’IA e patch sintattiche innescate da umani che non le hanno comprese. L’IA scrive codice che sembra elegante, ma che nasconde sotto il tappeto colli di bottiglia computazionali, race condition e vulnerabilità silenti che esploderanno brutalmente al primo aggiornamento delle dipendenze di terze parti. E quando il server andrà giù di venerdì notte, chi ha incollato quel codice non avrà la minima idea di dove mettere le mani per ripristinare il servizio.

L’intelligenza, quella vera e organica, non si scarica con un abbonamento mensile, la si allena attraverso l’attrito con la realtà. La competenza digitale si suda sui manuali e sui log di sistema, non si genera tramite chiamate API. Delegare l’apprendimento, l’architettura e la logica a un modello probabilistico significa ipotecare irrimediabilmente il proprio futuro professionale in cambio di un po’ di comodità a buon mercato.

Quando l’hype si sgonfierà, quando gli investitori chiuderanno i rubinetti e le infrastrutture crolleranno sotto l’insostenibile peso del debito tecnico accumulato da questi sedicenti “vibe coders”, il mercato subirà una violenta correzione. In quel momento nessuno cercherà chi sa scrivere il prompt più creativo per ChatGPT. Le aziende cercheranno, pagandoli a peso d’oro, professionisti che possiedono la logica spietata necessaria per leggere il codice a mente fredda, isolare i bug e riparare i danni fisici in sala macchine.

Il tempo delle scorciatoie e delle illusioni magiche è finito. La trincea, quella vera, vi aspetta al varco. Buono studio e buon lavoro.

Il panico da terminale e l’oracolo sintetico

Succede quasi sempre nella tarda mattinata, nei laboratori degli IeFP, quando la stanchezza abbassa le difese immunitarie della logica. Oggi stavo supervisionando un’esercitazione di sviluppo software. L’applicativo in locale va in crash. Il terminale si riempie all’improvviso del classico, inequivocabile testo rosso sangue: uno stack trace chilometrico che vomita a schermo decine di chiamate a funzioni annidate e file di sistema.

Invece di fermarsi, respirare e leggere la primissima riga dell’errore (che indicava banalmente un tentativo di accesso a una variabile non definita nello stato del componente), il ragazzo è andato in vero e proprio panico cognitivo. Ha selezionato tutto il blocco rosso, lo ha copiato e lo ha incollato dentro l’interfaccia dell’ultimo LLM di grido, aggiungendo un solo, disperato comando: “Aggiustalo!”.

Io mi sono goduto la scena…

L’oracolo sintetico, che è programmato per compiacere l’utente e non certo per educarlo, ha allucinato una risposta estremamente complessa, forse più lunga dell’errore stesso. Gli ha suggerito di installare una nuova libreria esterna per la gestione dello stato e di riscrivere mezza architettura. Lui, senza farsi mezza domanda, ha aperto un nuovo terminale, ha lanciato l’installazione e ha incollato la patch generata alla cieca.

Il progetto, ovviamente, è imploso del tutto in meno di un minuto, portandosi dietro le dipendenze originarie e corrompendo irrimediabilmente i file di configurazione locale. Abbiamo dovuto cancellare tutto e ricominciare da capo.

La generazione dei dattilografi ciechi

Questo episodio, apparentemente banale e relegabile a un errore di gioventù, fotografa in modo spietato l’emergenza più grave che sta affrontando il mercato del lavoro IT nel 2026: l’analfabetismo da stack trace.

Stiamo crescendo, e le aziende stanno tuttora coccolando, una generazione di autogeneratori di codice che non ha la minima idea di come si faccia il debugging. Pensano che un errore del compilatore sia una specie di maledizione magica, un rito oscuro da esorcizzare passando la patata bollente a un motore statistico, sperando che questo sputi fuori la patch corretta al primo tentativo.

Ma chiunque progetti sistemi software complessi sa una verità scomoda che i venditori di tool omettono sistematicamente nei loro pitch commerciali: scrivere codice vergine rappresenta forse il 20% del lavoro. L’altro 80% è leggere, investigare, isolare il problema, fare smontaggio logico sui propri errori e capire perché la macchina non si sta comportando come previsto. Se esternalizzate la fase di debugging all’intelligenza artificiale, non siete degli architetti del software. Siete semplicemente dei dattilografi ciechi che premono tasti a caso sperando di fare centro.

Il tradimento dell’astrazione e il conto del cloud

E la colpa non è solo della pigrizia intellettuale, ma dell’astrazione eccessiva che l’industria ci ha venduto come la terra promessa.

Oggi si parla solo di funzioni “serverless”, di servizi cloud gestiti, di framework monolitici che “fanno tutto loro” dietro le quinte. I programmatori junior perdono il contatto fisico con la memoria, con i processi del sistema operativo, con i log grezzi e con i protocolli di rete fisici. Tutto è nascosto sotto un rassicurante tappeto di interfacce grafiche smussate.

Ma il problema dell’astrazione è che, prima o poi, perde colpi. Mostra le sue crepe. E quando l’architettura cloud va in un loop infinito perché non avete capito come gestire la concorrenza sui dati (dai, su!), e la vostra azienda si ritrova una fattura da 10.000 euro in una sola notte per chiamate API impazzite (fatto tristemente vero), vi assicuro che l’Intelligenza Artificiale non interverrà a pagare il conto, né risponderà al telefono al cliente inferocito.

Il debugging come metodo scientifico

Il debugging è, nella sua essenza più pura, il metodo scientifico applicato alla macchina. Richiede di formulare un’ipotesi, isolare le variabili, testare l’assunto, fallire e riprovare. Delegare questo processo alla macchina significa delegare il proprio pensiero critico e la propria comprensione del dominio.

Per risolvere i problemi veri in produzione, quando i server crollano e i soldi bruciano, dovete saper scendere in sala macchine. Dovete sporcarvi le mani di grasso, aprire il terminale, disabilitare le interfacce rassicuranti e leggere i log grezzi del server riga per riga.

Dovete imparare ad amare gli errori, perché l’errore rosso a schermo è l’unico, rarissimo momento in cui la macchina vi sta parlando in modo sincero e non mediato dal marketing. L’errore è l’apostrofo rosso tra le parole “M’è partito!”.

Chiudete la chat dell’oracolo. Aprite la noiosa, lunghissima e schifosamente deterministica documentazione ufficiale. E sforzatevi di leggere cosa vi sta dicendo quel dannato e bellissimo testo rosso.

Sipario.

Questo è il patto implicito e secolare che abbiamo sempre avuto con la tecnologia. Ma cosa succede quando il martello inizia a vibrare nella cassetta per richiamare la tua attenzione? Cosa succede quando, mentre lo usi, il manico cambia forma per accarezzare i tuoi recettori nervosi, convincendoti che non dovresti mai più smettere di martellare?

In queste settimane è andato in scena un paradosso perfetto che racchiude questa distorsione. E parte, ironia della sorte, proprio da una mia scelta operativa.

Iscriviti ora

La religione del sistema operativo e la perdita del pragmatismo

Nei giorni scorsi ho preso una decisione tecnica banale e puramente pragmatica: ho formattato le mie macchine piallando le partizioni Linux per tornare definitivamente a Windows 11.

Apriti cielo!

I puristi della linea di comando e i paladini dell’open source a tutti i costi mi hanno inondato di messaggi, trattandomi come un eretico che ha barattato l’anima con la comodità. Ma questa reazione, apparentemente goliardica, è in realtà la spia rossa di una malattia infantile che infesta in modo cronico il settore dello sviluppo software: il feticismo dello strumento.

Oggi c’è un’intera generazione di aspiranti programmatori (ma anche di navigati senior) che scambia l’ambiente di lavoro per un’identità culturale. Passano le nottate a personalizzare l’interfaccia grafica del terminale (è un po’ come curare il raffreddore a un pidocchio), autoconvincendosi di stare facendo “alta progettazione”. Ma l’ambiente locale non è il fine, è il mezzo. Se il tuo sistema operativo entra in conflitto costante con gli applicativi aziendali, se perdi tre ore a configurare un driver di rete o a litigare con le dipendenze invece di studiare l’architettura dei sistemi o i lock relazionali di un database, non sei un professionista migliore. Sei solo un hobbista molto innamorato del proprio martello.

Il pragmatismo batte l’ideologia, sempre. Lo strumento deve sparire sullo sfondo, farsi trasparente, per lasciarti fatturare, studiare o insegnare. Non può e non deve essere un feticcio.

Il design predittivo: quando lo strumento ti divora

C’è però un rovescio della medaglia molto più oscuro in questo rapporto malato con i mezzi digitali. Il problema vero, quello con impatti sociali devastanti, esplode quando lo strumento non vuole sparire, ma è scientificamente e pernicisamente progettato per divorarti.

Mi riferisco alla storica e clamorosa condanna arrivata in questo marzo 2026 per Meta e Google, chiamate a rispondere nei tribunali della dipendenza indotta nei minori (per i miei corsisti che si sono sorbiti in aula “The Social Dilemma” non sarà certo una novità).

Leggere le carte di quella sentenza dovrebbe essere obbligatorio in ogni corso di programmazione. Non stiamo parlando del classico e noioso sermone sui “giovani che passano troppo tempo davanti agli schermi”. I giudici hanno messo nero su bianco una verità architettonica ineluttabile: quelle interfacce sono armi. Sono state disegnate deliberatamente, iterazione dopo iterazione, con l’unico scopo di sfruttare i nostri bias cognitivi, sequestrare l’attenzione e bruciare i recettori della dopamina di ragazzini con la corteccia prefrontale ancora in via di sviluppo.

È lo stesso pattern di controllo e di feticismo, applicato semplicemente su due scale diverse:

• lo sviluppatore venera il suo ecosistema chiuso, illudendosi di avere il controllo totale mentre perde di vista le vere dinamiche del mercato;

• l’utente base viene fagocitato da un design predittivo spietato, che lo trasforma da utilizzatore attivo a prodotto da macello;

• la macchina, in entrambi i casi, detta le regole d’ingaggio e si sostituisce alla decisione umana.

L’odore del gesso e l’autodifesa algoritmica

È esattamente per questo motivo che, quando entro nelle aule degli ITS o nei percorsi GOL per la riqualificazione professionale, cambio completamente approccio rispetto ai manuali canonici.

Prima ancora di spiegare a un ragazzo un ciclo iterativo, le query SQL o come far stampare un “Hello World” a schermo, devo assicurarmi che capisca in che campo minato sta mettendo i piedi. Devo parlargli di autodifesa algoritmica.

Oggi la tentazione del “vibe coding” è fortissima: l’illusione di poter delegare il lavoro a un’IA generativa, scopiazzando codice che non si sa leggere, pur di ottenere un risultato immediato. Ma insegnare a uno studente la sintassi di un linguaggio senza fornirgli gli anticorpi critici per capire l’impatto etico, psicologico e architettonico di quel codice, non è formazione. È addestramento tattico. È mandare truppe disarmate e bendate al fronte, con il solo scopo di fargli costruire gabbie digitali sempre più belle per i propri coetanei.

L’umanesimo digitale non è un concetto astratto da salotto. È la trincea quotidiana in cui impari a smontare il giocattolo per capire esattamente come funziona, prima che sia il giocattolo a smontare te.

Staccare la spina è un atto politico

In questo scenario brutale, dobbiamo smettere di usare parole a sproposito. Il cosiddetto “digital detox” ha smesso da tempo di essere quella roba radical chic per manager stressati, che vanno in ritiro yoga nel bosco solo per potersi scattare un selfie da postare al rientro.

Oggi staccare la spina è un atto di sopravvivenza e di igiene mentale. È un reset fisiologico e sistemico, l’unico modo reale per disintossicare circuiti cerebrali costantemente sotto assedio.

Riprendete il controllo del vostro martello. E se non vi serve, per carità, mettetelo via.

Buona domenica.

Sipario!

Lascia un commento

L’ideologia del momento è il cosiddetto vibe coding: l’illusione che basti descrivere un’idea a un chatbot, magari correggendo il tiro “a intuito”, per trasformarsi in sviluppatori provetti. Si delega totalmente la scrittura e, cosa ben più grave, la comprensione logica del codice.

Tutto bellissimo, finché non ci si scontra con la dura realtà dei server di produzione.

Solo pochi giorni fa, un operatore ha affidato a un agente AI le chiavi dell’infrastruttura per fare un po’ di “manutenzione” e risolvere delle banali duplicazioni di record. Il risultato: l’AI ha eseguito pedissequamente i comandi, applicando una logica sintatticamente corretta ma contestualmente disastrosa, e ha piallato due anni e mezzo di database di produzione in un istante.

Questo evento non è un semplice incidente di percorso, è un manifesto. Dimostra esattamente cosa succede quando si confonde un esecutore velocissimo, privo di cognizione del business, con un decisore competente. L’AI non sa cosa sia un danno d’immagine, non sa cosa significhi perdere fatturato e, soprattutto, non va in galera quando i dati sensibili dei clienti finiscono in fumo.

La morte del programmatore “coltellino svizzero”

Fino a un paio di anni fa, il mercato premiava il profilo generalista. Saper scrivere un’API CRUD (Create, Read, Update, Delete) in Node, impaginare una vista decente in React e fare due query in croce su MySQL ti garantiva un posto fisso e uno stipendio di tutto rispetto. Eri un “tuttofare”, un coltellino svizzero dello sviluppo. Le aziende ti assumevano perché costavi meno di tre specialisti e riuscivi a tenere in piedi la baracca.

Oggi, quel livello di mediocrità generalista è morto e sepolto.

L’intelligenza artificiale è diventata bravissima a fare “un po’ di tutto”. Produce codice boilerplate in pochi secondi, impagina componenti, struttura form di login e collega endpoint senza battere ciglio, al costo di venti euro al mese e senza mai chiedere ferie. Se la vostra unica competenza è incollare frammenti di codice presi dai tutorial di YouTube o generati da Claude, siete la prima linea che verrà spazzata via. Il mercato non paga più per la mera “digitazione” del codice base, perché il costo di quella specifica operazione di manovalanza sta tendendo a zero.

L’illusione del debito tecnico a costo zero e il paradosso del testing

Il vero dramma del delegare la programmazione all’AI senza avere basi solide è la totale cecità di fronte al debito tecnico.

Chi genera diecimila righe di codice che non comprende si sta mettendo in casa una bomba a orologeria. C’è chi sostiene candidamente sui social che questo non sia un problema, giustificandosi con frasi del tipo: “tanto non devo leggerlo io, lo farà la prossima AI”. È un ragionamento suicida, l’equivalente digitale di dire: “non mi interessa se i freni dell’auto sono rotti, tanto guido bendato”.

Il debito tecnico non è un semplice capriccio stilistico per puristi del codice pulito. Si traduce in colli di bottiglia architetturali, vulnerabilità profonde, deadlock sul database quando il traffico aumenta e sistemi che crollano esattamente nel momento del bisogno.

Qualcuno prova a difendere questa pratica paragonando lo spaghetti-code dell’AI all’utilizzo di librerie closed-source. Ma è una fallacia logica enorme: una libreria consolidata ha un vendor, documentazione, API deterministiche e team dedicati alla sua manutenzione. Il vibe coding genera invece un blob probabilistico, monouso e opaco, di cui siete gli unici responsabili pur non sapendo come funzioni.

E non pensate che basti scrivere qualche test automatizzato (sempre tramite AI) per salvarvi. Fare “testing a scatola chiusa” su un sistema di cui si ignora la logica interna significa coprire solo i percorsi felici. I veri disastri si nascondono nei temuti casi limite che l’AI ha generato a vostra insaputa. Quando il carrello dell’e-commerce smette di funzionare di sabato mattina, facendo perdere migliaia di euro al cliente, non potete fare un rollback a tentoni sperando che il bot capisca il contesto aziendale per risolvere il bug. Il cliente farà causa a voi, non all’algoritmo.

La sopravvivenza nel 2026: il modello a “T”

Se la manovalanza è delegata alla macchina, il vostro valore sul mercato risiede esclusivamente nella progettazione, nell’architettura e nel pensiero critico. Il professionista ricercato oggi (e pagato a peso d’oro) deve avere un profilo a “T”:

• la stanghetta orizzontale rappresenta le competenze trasversali e la velocità di esecuzione, in quanto saper spaziare su più linguaggi e sbrigare le pratiche di routine è qualcosa che oggi potete, e assolutamente dovete, delegare e accelerare tramite l’AI;

• la stanghetta verticale è la vostra vera polizza a vita, ovvero un dominio di specializzazione estrema, profonda e verticale, in cui l’intelligenza artificiale si perde in allucinazioni e fallisce miseramente.

Per smettere di essere manovali facilmente rimpiazzabili e diventare professionisti insostituibili dello sviluppo, dovete studiare in modo ossessivo ciò che la macchina non sa gestire in autonomia. Questo include:

• il design di architetture resilienti: capire cosa succede quando un nodo di un’architettura a microservizi cade e come evitare che si porti dietro l’intero sistema;

• la gestione avanzata dei database: andare oltre la semplice query e dominare le transazioni, prevenire i lock delle tabelle ed evitare letture sporche che alterano i bilanci;

• i sistemi offline e la sincronizzazione: gestire i conflitti di dati senza duplicare gli ordini quando un utente compra in metropolitana senza rete e poi si riconnette;

• la sicurezza infrastrutturale: progettare lo scoping chirurgico dei permessi sui servizi cloud, prevenire l’escalation dei privilegi e blindare i sistemi contro attacchi mirati.

L’intelligenza artificiale è uno strumento straordinario, ma solo per chi sa già esattamente cosa sta costruendo. Vi dona i superpoteri, permettendovi di passare dall’essere Clark Kent a diventare Superman. Ma c’è un dettaglio fondamentale: se non avete mai aperto un libro su come si progetta un sistema informatico, non diventerete Superman. Diventerete solo un pericolo pubblico armato di script generati a caso, in attesa che il mercato faccia spietata selezione naturale al vostro primo bug in produzione.

Smettete di imparare a scrivere codice. Iniziate a imparare come si progetta un software.

​Le ultime due settimane sono state un osservatorio privilegiato su uno dei fenomeni più pericolosi e sottovalutati dell'industria digitale contemporanea. Non parlo dell'ennesimo modello di Intelligenza Artificiale che promette di rivoluzionare i flussi di lavoro, ma di qualcosa di molto più subdolo e silenzioso: la morte dell'Architettura del Software per mano dell'assemblaggio compulsivo.

​Ci stiamo abituando all'astrazione. Più i nostri strumenti diventano "intelligenti" e facili da usare, più ci allontaniamo dal metallo, dai cavi, dalle regole fisiche che governano la rete.

​Oggi parliamo di scatole nere, di cloud infallibili che collassano, di guerre algoritmiche e del motivo per cui il vostro prossimo, disastroso problema in produzione non sarà risolto chiedendo aiuto a ChatGPT.

​L'illusione dell'infallibilità (ovvero: «senza TCP cade tutto»)

​Qualche sera fa, su Threads, discutevo di resilienza dei sistemi informatici. Un utente — un tecnico che si vanta orgogliosamente di gestire servizi cloud — ha cercato di deridere il concetto di "autenticazione offline" e "sessioni di emergenza".

​La sua tesi era brutalmente semplice: se il servizio cloud di autenticazione va giù, non è colpa mia. Se non c'è rete, semplicemente non lavori. Il problema si risolverà da solo con l'autoscaling o il failover di Amazon AWS o Azure.

​Questa mentalità non è solo un'opinione divergente; è il cancro dell'IT moderno. È l'esatta, preoccupante rappresentazione della «Generazione Scatola Nera».

​Siamo arrivati storicamente al punto in cui un operatore del settore confonde l'Architettura del Software (la progettazione deliberata di un sistema capace di degradare con grazia in caso di disastro) con l'Assemblaggio di Servizi (incollare librerie scritte da terzi e pregare ogni mattina che l'infrastruttura di Jeff Bezos non stacchi mai la spina).

​C'è un equivoco di fondo enorme su cosa sia il Cloud. Il Cloud non è una nuvola magica e incorruttibile; è, molto banalmente, il computer di qualcun altro. E i computer si rompono. I cavi sottomarini vengono tranciati. Gli instradamenti BGP vengono dirottati. I server vanno a fuoco (chiedete a OVH a Strasburgo).

​Se progettate software per la logistica, per il pronto soccorso di un ospedale o per una catena di montaggio, e assumete che la connessione TCP sia eterna, siete un pericolo pubblico. I sistemi critici non si basano sulla speranza o sul "failover" automatico di un provider californiano. Si basano su architetture Local-First: database sincronizzati fisicamente in locale sulle macchine, logiche di Optimistic UI per far lavorare gli operatori offline, e sistemi di sblocco delle credenziali basati sull'hardware fisico (Secure Enclave, biometria).

​Il professionista progetta calcolando esattamente il momento in cui il cavo di rete verrà tagliato. Il dilettante si fa un caffè, fissa un monitor nero e aspetta che torni la connessione per poter riprendere a esistere.

​La guerra tra macchine: il caso Microsoft

​Se pensate che questo discorso riguardi solo i database, guardate cosa è successo proprio questa settimana nel campo della sicurezza.

​Nel suo ultimo Patch Tuesday, Microsoft ha corretto decine di vulnerabilità, tra cui due pericolosi zero-day. Ma la vera notizia — riportata in modo eccellente dai colleghi di Cyber Security 360 — è un'altra: per la prima volta, Microsoft ha corretto una vulnerabilità scoperta interamente dall'Intelligenza Artificiale. Fermatevi a riflettere sulle implicazioni di questa notizia. Non è un semplice aggiornamento di sistema; è un cambio di paradigma bellico.

​Oggi, legioni di sviluppatori junior, presi dall'ansia prestazionale, usano Copilot, Cursor o ChatGPT per farsi generare interi moduli applicativi. Incollano nei loro progetti blocchi di codice oscuri, di cui non comprendono né la logica sottostante né la gestione della memoria. Così facendo, iniettano inconsapevolmente decine di micro-vulnerabilità all'interno dell'infrastruttura aziendale.

​Se l'AI è ora in grado di scoprire le vulnerabilità scansionando autonomamente i sistemi operativi, quanto ci vorrà prima che un attore malevolo usi un LLM addestrato specificamente per trovare le falle nel codice che voi vi siete fatti generare ieri da un altro LLM?

​Stiamo entrando nell'era della guerra "AI contro AI". L'Intelligenza Artificiale che vi fa risparmiare tre ore oggi in fase di sviluppo, è la stessa tecnologia che verrà usata domani per bucare i vostri server in tre millisecondi. E se voi siete solo degli "assemblatori" che non conoscono l'architettura del proprio software, quando subirete un attacco non saprete nemmeno da dove è entrato il nemico.

​Il mutuo a tasso usuraio e le allucinazioni

​Delegare la propria sopravvivenza al cloud è ingenuo, ma delegare l'architettura logica a un modello probabilistico è puro suicidio aziendale.

​Nei giorni scorsi mi sono scontrato in laboratorio con un problema su un database Firebase. Dovevo strutturare una query complessa (una Collection Group). Ho interrogato l'AI, che in due secondi netti mi ha sputato fuori una sintassi elegante, pulita, apparentemente perfetta.

​L'ho incollata. Ho avviato l'emulatore. Crash.

​Perché? Perché l'AI conosce la sintassi (il dizionario di un linguaggio), ma è spazialmente cieca: ignora l'architettura fisica (il server). In un database NoSQL, quella query meravigliosa non può girare se prima un operatore in carne e ossa non entra nel pannello di controllo, configura fisicamente un indice composto, attende che il server allochi lo spazio su disco e propaghi i dati nei vari nodi mondiali.

​L'AI ti fornisce la vernice, ma non progetta le fondamenta. Ti nasconde la dura realtà del ferro sotto il tappeto rassicurante del "codice che compila senza errori".

​I consigli d'amministrazione oggi stappano champagne perché usano l'AI per generare migliaia di righe di codice in metà del tempo, abbattendo radicalmente i costi di sviluppo immediati. Quello che i manager non sanno, o fingono di non sapere, è che non stanno affatto risparmiando: stanno contraendo un mutuo a tasso usuraio chiamato «Debito Tecnico». E gli interessi di quel mutuo si pagano in blocco il giorno in cui il sistema deve scalare o subisce un attacco.

​Il mercato del lavoro che verrà

​Liberiamoci di un'ultima grande illusione: saper digitare un prompt complesso in una chat testuale non è una professione del futuro. E non è nemmeno una "competenza digitale" (il DigComp che difendo strenuamente in aula). È pura, semplice obbedienza a un'interfaccia.

​Nei prossimi anni, il mercato sarà inondato di software obeso, instabile e indecifrabile, sputato in automatico da operatori che non sanno cosa sia un protocollo HTTP, come funzioni il DOM di una pagina web o come si prevenga un Memory Leak ad ogni rotazione dello schermo.

​Quando quel castello di carte crollerà inevitabilmente — e crollerà, perché il cloud cade e le macchine si attaccano a vicenda — le aziende non cercheranno un «Prompt Engineer» per farsi spiegare dall'oracolo di turno perché il server sta andando a fuoco.

​Cercheranno disperatamente chi possiede i fondamenti. Cercheranno chi ha studiato la logica booleana, il funzionamento delle reti TCP/IP, l'ottimizzazione dei database. Cercheranno un Architetto, ovvero qualcuno capace di fare ingegneria inversa sui danni causati dalle macchine.

​Le aziende pagano e pagheranno fior di quattrini i veri professionisti per assumersi l'onere e la responsabilità dei fallimenti, non per alzare le mani al cielo al primo timeout di rete dicendo: "non è colpa mia".

​Studiate i protocolli. Studiate l'hardware. Studiate la teoria dei sistemi. Lasciate l'hype a chi non ha mai dovuto ripristinare un servizio critico alle tre del mattino.

​Buona settimana di Deep Work a tutti.

​Marcello Tecnologo della comunicazione digitale

​Nel mirino: cosa aspettarsi la prossima settimana

​Il dibattito non si ferma qui. Sui miei canali social, nei prossimi giorni, smonteremo un altro pezzo di narrativa tossica. Parleremo di:

• ​L'impatto ambientale dell'incompetenza: smettiamo di parlare solo dei data center. La vera spazzatura elettronica (e-waste) nasce sulle nostre scrivanie, quando generiamo codice obeso e deleghiamo a un server da 1000W il compito di correggere un ciclo for scritto male.

• ​L'astrazione analogica (Il momento "Gesso"): i nuovi aggiornamenti sul progetto Kotlin dimostreranno perché l'architettura del software si disegna con carta e penna, a computer spento, lontani dalle distrazioni dell'editor.

• ​La bolla del "Lifelong Learning" performativo: perché la pioggia di certificati da due ore su LinkedIn è una farsa, e perché il mercato tornerà presto a premiare i risolutori di problemi, non i "Prompt Engineer" spaventati.

​Ti sei ritrovato in questa analisi o hai colleghi che vivono immersi nell'hype dei tool magici? Inoltra questa mail, oppure vieni a dirmi la tua su Threads.

Se state leggendo queste righe, avete superato con successo un'altra settimana di rumore di fondo, di notifiche incessanti e di titoli sensazionalistici sulla presunta e imminente fine del lavoro umano (e del mondo…).

In questi giorni il mercato tecnologico ci ha fornito due casi di studio che, pur appartenendo a settori apparentemente distanti anni luce tra loro, convergono verso un'unica, ineluttabile verità. Ci spiegano con la freddezza clinica dei dati perché, oggi più che mai, le competenze ingegneristiche e logiche di base (il nostro "gesso") siano l'unica vera difesa contro le derive di un'innovazione accelerata artificialmente e guidata in via esclusiva dalle logiche di profitto (il "tech").

Mettetevi comodi, spegnete le notifiche e chiudete le schede in background del vostro browser. Iniziamo.

1. Il Pentagono, la linea rossa e l'etica a geometrie variabili

Per gran parte della settimana appena trascorsa, la stampa generalista ha celebrato in coro una presunta vittoria morale della Silicon Valley. Anthropic, l'azienda sviluppatrice del modello Claude, si era formalmente rifiutata di concedere al Pentagono l'integrazione delle proprie intelligenze artificiali all'interno dei sistemi d'arma automatici statunitensi e di controllo di massa.

Poi, a ridosso del fine settimana, l'impianto narrativo è crollato. Il governo degli Stati Uniti ha definito Anthropic «un fornitore inaffidabile», l'ha estromessa dai tavoli di negoziazione e ha siglato a tempo di record un accordo sostitutivo con OpenAI. Il CEO di quest'ultima, Sam Altman, si è affrettato a dichiarare alla stampa di aver mantenuto inalterati i paletti di sicurezza del precedente fornitore.

Vi invito a svestire i panni dei tifosi e a indossare quelli degli analisti. Se le regole d'ingaggio, i vincoli del software e le policy etiche imposte dalle due aziende fossero state realmente sovrapponibili, per quale motivo tecnico o burocratico il Dipartimento della Difesa avrebbe dovuto stracciare un contratto per firmarne un altro in corsa, esponendosi peraltro a un danno d'immagine? Nell'ingegneria del software, così come negli appalti governativi di altissimo livello, non si sostituisce un'architettura a parità di condizioni. Lo si fa esclusivamente se il nuovo fornitore garantisce una flessibilità che il precedente negava.

La risposta è puramente commerciale: di fronte a budget militari virtualmente illimitati, l'etica aziendale scopre di possedere interfacce programmabili molto più elastiche del previsto.

Ma al netto del cinismo geopolitico, emerge un problema di fondo che rappresenta il vero terrore di chi questi sistemi li progetta. Un Large Language Model non è un software deterministico. L'informatica tradizionale, quella su cui si regge il mondo dal dopoguerra a oggi, si basa sul determinismo assoluto: a un determinato input (X) corrisponde sempre e immancabilmente lo stesso output (Y).

L'intelligenza artificiale generativa, al contrario, è un motore puramente probabilistico. Non possiede un modello ontologico del mondo reale. Non sa cosa sia un missile, non comprende il concetto di bersaglio. Calcola semplicemente la sequenza di dati statisticamente più plausibile in base al proprio addestramento. A volte inventa librerie di codice inesistenti, altre volte entra in cortocircuiti logici inspiegabili. Si chiama "allucinazione", e non è un fastidioso bug temporaneo in attesa di essere corretto con una patch: è un difetto di fabbrica ineliminabile, intrinseco nella natura stessa delle reti neurali basate su architettura transformer.

Voi affidereste mai l'autorizzazione di un attacco militare a un software che, se sottoposto a uno stress test non previsto, potrebbe iniziare a generare dati inventati con assoluta e pacata arroganza?

Oggi abbiamo scoperto pubblicamente il limite invalicabile dell'intelligenza artificiale. Non risiede nella morale, ma nell'affidabilità sotto stress nei sistemi critici. Il fatto che la fame di supremazia militare stia deliberatamente ignorando questo limite ingegneristico è un'ottima ragione per iniziare, in modo molto razionale, a preoccuparsi.

2. Caveau digitali e l'illusione della sicurezza algoritmica

Dalle infrastrutture militari passiamo a quelle civili, dove i danni sono forse meno letali ma altrettanto devastanti per il tessuto sociale. Negli scorsi giorni, il colosso dei pagamenti PayPal ha dovuto ammettere una violazione colossale: per 165 giorni ininterrotti, i dati sensibili dei clienti della loro piattaforma per i prestiti aziendali (non presente in Italia , per fortuna!) sono rimasti esposti al pubblico.

Leggendo i report tecnici dell'incidente, la verità emerge in tutta la sua disarmante banalità. Non c'è stato alcun attacco hacker quantistico orchestrato da potenze ostili. Nessun malware di ultima generazione. Nessuna intelligenza artificiale malevola in grado di bucare i firewall dell'azienda. C'è stato, molto più semplicemente, un catastrofico errore umano sfuggito durante un aggiornamento di routine.

Qualcuno ha digitato in modo errato una riga di codice. Qualcun altro ha approvato l'aggiornamento senza revisionarlo adeguatamente. I sistemi di controllo automatizzato non possedevano i test necessari per intercettare la vulnerabilità prima della messa in produzione. E, cosa ancora più grave, nessun analista della sicurezza si è accorto per quasi sei mesi che i dati stavano defluendo indisturbati dai server.

Il capolavoro assoluto, l'apoteosi del grottesco aziendale, è rintracciabile nella dichiarazione rilasciata dall'ufficio stampa: «I nostri sistemi non sono stati compromessi, è stato solo un errore di codice». In termini pratici, equivale a comunicare ai correntisti che nessuno ha scassinato la banca con la fiamma ossidrica, ma che la porta blindata è stata banalmente dimenticata aperta.

Cosa unisce le forzature del Pentagono al disastro informatico di PayPal? L'assenza drammatica del controllo umano. O, per meglio dire, una superficialità sistemica dilagante.

Viviamo in un'epoca in cui diamo per scontata l'infallibilità dei sistemi complessi. Possiamo impiegare tutta la potenza computazionale del pianeta per generare testo in millisecondi, ma se alla base non poniamo un'architettura rigorosa, una cultura del collaudo ossessiva e una mente umana capace di fare vera garanzia di qualità, stiamo solo innalzando castelli di carte sempre più alti. L'anello debole della catena non è quasi mai il silicio; è sempre l'operatore distratto.

3. Oltre il copia-incolla: anatomia del debito cognitivo

I disastri infrastrutturali non si generano per caso in una giornata sfortunata. Sono il risultato terminale di un declino metodologico che si stratifica lentamente nel tempo. È una prassi che, purtroppo, osservo diffondersi e normalizzarsi quotidianamente nelle aule in cui insegno e negli uffici di molte aziende: la rapida proliferazione della figura del "pappagallo erudito".

Come abbiamo visto, tecnicamente un modello linguistico è esattamente questo: un pappagallo digitale dotato di una sintassi impeccabile, che ha fagocitato l'intero scibile umano, ma che non ha la benché minima comprensione semantica di ciò che elabora. Si limita a ripetere pattern. Il vero cortocircuito della nostra era inizia nel momento in cui noi esseri umani decidiamo di imitare il comportamento della macchina.

Sempre più spesso vedo studenti, ma anche professionisti alle prime armi (e non solo, ahimè), delegare in toto a strumenti come ChatGPT la scrittura e la risoluzione del codice di programmazione. L'intelligenza artificiale risponde in tempo reale, producendo blocchi di istruzioni eleganti, puliti e che, di frequente, funzionano al primo colpo. Ma quando chiedo all'autore di spiegarmi la logica architetturale che sorregge una determinata riga di quel codice, la reazione è pressoché identica: il silenzio. Hanno eseguito un copia-incolla tecnicamente perfetto di cui ignorano totalmente i fondamenti teorici.

Ogni singola volta che deleghiamo il pensiero logico-critico a una macchina pur di risparmiare dieci minuti di fatica mentale, stiamo contraendo un "debito cognitivo". Il meccanismo è identico a quello del debito finanziario: oggi ottieni un vantaggio immediato portando a termine il compito in anticipo, ma domani pagherai degli interessi salatissimi. I muscoli della nostra logica, se non sottoposti a uno sforzo continuo, si atrofizzano a una velocità allarmante. E quando quel codice incollato si romperà nel mondo reale — perché i requisiti del cliente cambiano o perché un aggiornamento rende obsoleta una tecnologia — nessuno saprà più come intervenire. Guarderanno quel codice come si osserva un reperto archeologico incomprensibile.

Lasciate che vi faccia una previsione basata sui dati: l'intelligenza artificiale sostituirà senza alcuna pietà i dattilografi del codice, i "battitori di tastiera" che si limitano ad assemblare pezzi trovati in rete. Il mercato del lavoro, tra pochissimi anni, non pagherà un solo centesimo chi saprà unicamente chiacchierare con un prompt. Al contrario, retribuirà a peso d'oro chi possiederà la logica strutturale e le competenze di base necessarie per validare, correggere e architettare ciò che l'oracolo sintetico avrà sputato fuori.

4. Il lavoro profondo come atto di ribellione

Esiste un solo antidoto per non farsi sostituire, per arrestare l'atrofia mentale e per non trasformarsi in esecutori passivi: recuperare in modo ostinato la capacità di concentrazione assoluta. Quello che l'informatico Cal Newport ha magistralmente definito deep work (lavoro profondo).

Nel corso di questa settimana, durante un'esercitazione pratica particolarmente complessa sulla gestione di basi di dati con una classe di adulti, ho imposto un esperimento pratico: la regola dei venti minuti. Ho fatto allontanare fisicamente gli smartphone dalle scrivanie. Ho preteso la chiusura di tutte le schede del browser non strettamente necessarie. Ho sospeso ogni notifica. Sui monitor dovevano rimanere unicamente i dati grezzi e il problema logico da risolvere. Tutto questo nel silenzio più assoluto.

I primi cinque minuti si sono rivelati un'agonia tangibile. Era letteralmente possibile osservare l'astinenza fisica da dopamina digitale scorrere nella stanza. L'ansia da disconnessione combatteva violentemente contro l'attrito cognitivo richiesto dal problema. Ma intorno al decimo minuto, la dinamica è mutata. I cervelli hanno smesso di cercare scappatoie e hanno iniziato a elaborare il contesto. Il silenzio si è fatto denso e produttivo. Al ventesimo minuto, quando ho annunciato la fine dell'esperimento, in molti non volevano smettere di lavorare. Erano entrati in uno stato di flusso ininterrotto.

L'attenzione non è un dono di natura, è un muscolo. E come tutti i muscoli, va allenato con carichi progressivi. Se regalate costantemente la vostra concentrazione agli algoritmi, permettendo a un'applicazione di frammentare il vostro pensiero ogni tre minuti, non vi stanno rubando soltanto il tempo libero: vi stanno ipotecando il portafoglio futuro. Vi stanno sottraendo la capacità di analizzare, elaborare e risolvere problemi prolungati e complessi. E quella capacità è, di fatto, l'unica vera competenza per cui il mercato sarà disposto a riconoscervi un valore reale domani.

Torniamo sempre al teorema fondamentale che muove il mio lavoro di divulgazione: l'intelligenza artificiale è un formidabile moltiplicatore, non un sostituto. La formula matematica che vi ho spesso presentato è spietata: se le vostre competenze di base valgono zero, zero moltiplicato per l'AI farà sempre zero. Se le vostre competenze di base valgono uno, la tecnologia vi porterà a dieci (forse anche a 100!).

Usate l'intelligenza artificiale come un esoscheletro cognitivo per accelerare l'esecuzione dei compiti meccanici. Ma continuate a usare il gesso, il sudore mentale e il lavoro profondo per progettare, pensare e validare.

Buona domenica. Spegnete il router e riprendetevi il vostro cervello.

Marcello Marinisi

Se state leggendo queste righe e avete provato a imparare a programmare (o a usare un software complesso) negli ultimi anni, probabilmente vi è successo almeno una volta.

La scena è classica: trovate un video su YouTube dal titolo promettente, tipo "Crea un clone di Spotify in 3 ore con React e Python".

Lo aprite. Lo seguite passo passo. Il tizio nel video digita, voi digitate. Lui installa una libreria, voi la installate. Lui scrive una funzione, voi la copiate identica, virgola per virgola.

Alla fine delle tre ore, premete "Run" e... magia! Il progetto funziona!

Vi sentite come un Dio del Codice. Sentite quella scarica di dopamina che vi dice: "Ho capito tutto, sono pronto".

Poi chiudete il video.

Aprite un file vuoto per provare a fare una modifica banale, o per iniziare un progetto vostro molto più semplice, magari una lista della spesa.

E lì, cala il gelo.

Il cursore lampeggia nel vuoto. Il cervello è una tabula rasa. Non sapete da dove iniziare. Non sapete nemmeno come importare le librerie che avete usato cinque minuti prima.

Il senso di onnipotenza svanisce all'istante, sostituito da un'ansia paralizzante.

Benvenuti nel “Tutorial Hell”.

L'inferno dei tutorial è un luogo affollatissimo, dove l'apprendimento va a morire cullato dall'illusione della competenza.

Oggi analizziamo perché succede (spoiler: non siete stupidi, è il metodo che è rotto) e come uscirne vivi con delle competenze reali in tasca.

L'inganno di Dunning-Kruger: perché ci sentiamo geni (prima di crollare)

Per capire perché il Tutorial Hell è così seducente, dobbiamo scomodare la psicologia cognitiva. Quello che vivete seguendo un video guidato è la manifestazione perfetta dell'Effetto Dunning-Kruger.

Si tratta di un bias cognitivo secondo cui le persone con scarse competenze in un campo tendono a sovrastimare enormemente la propria abilità.

Quando seguite un tutorial, l'istruttore vi sta tenendo per mano. Vi protegge dagli errori, dalle scelte architetturali difficili e dai bug frustranti.

Questo percorso "senza attrito" vi spara dritti sulla vetta di quello che a me piace chiamare il "Monte della Saccenza" (Mount of Stupid, in originale, ma preferisco essere gentile).

Lassù, sulla cima, vi sentite invincibili. Pensate: "Wow, programmare è facile! Ho appena fatto un'app in due ore!".

Ma è un'illusione ottica. Non avete scalato la montagna; vi ci hanno portato in elicottero.

Appena provate a fare da soli, l'elicottero riparte e voi precipitate nella “Valle della Disperazione”.

Vi rendete conto che non sapete perché stavate scrivendo quel codice, sapevate solo ricopiarlo.

Ed è qui, proprio in questa valle buia e frustrante, che inizia il vero apprendimento.

L'Exit Strategy: 3 regole d'oro per imparare davvero

Come si esce dalla valle? Smettendo di cercare la strada facile e iniziando a cercare l'attrito. L'apprendimento richiede sforzo attivo, non consumo passivo.

Ecco le mie 3 regole (testate in aula) per trasformare un tutorial da intrattenimento a formazione.

1. La Regola del Sabotaggio (Break Things)

Questa è la più importante. Non copiate mai il codice identico a quello del video. Mai.

Dovete introdurre delle varianti intenzionali che vi costringano a pensare.

• L'istruttore sta creando un e-commerce di scarpe? Voi fatelo per una pizzeria.

• Lui usa un database SQL? Voi provate a salvare i dati su un file JSON.

• Lui mette tutto il codice in un file unico? Voi provate a spezzarlo in tre file diversi.

Questo “sabotaggio controllato” rompe il flusso passivo. Vi costringe a chiedervi: "Se cambio il nome di questa variabile qui, cosa si rompe laggiù?".

Dovrete riscrivere parti di logica per adattarle alla vostra variante. È in quel momento di riscrittura che il cervello passa dal riconoscere al capire.

2. Il "Commento per un Bambino"

Per ogni blocco di codice significativo che copiate (o scrivete), obbligatevi a scrivere un commento che spieghi il perché, non il cosa.

• Sbagliato (descrive l'azione): # Crea una variabile x (Grazie, lo vedo da solo).

• Giusto (spiega l'intenzione): # Qui salvo l'input dell'utente in una variabile temporanea per poter controllare se è vuoto prima di inviarlo al database.

Questa tecnica si chiama Rubber Duck Debugging (spiegare il codice a una paperella di gomma). Se non sapete spiegare il perché di una riga di codice in italiano semplice, significa che non l'avete capita. Fermatevi. Riguardate il video. Non andate avanti finché non sapete spiegarlo alla paperella.

3. La regola dei “20 minuti di sofferenza”

Quando vi bloccate (e succederà, specialmente se applicate la regola 1), non andate subito a cercare la soluzione o a chiedere a ChatGPT "fix this code". Datevi 20 minuti di orologio.

In quei 20 minuti dovete “soffrire”.

Dovete leggere l'errore rosso (sì, leggetelo tutto, spesso dice esattamente cosa non va!). Dovete provare a stampare variabili a caso per vedere cosa contengono. Dovete leggere la documentazione ufficiale della libreria.

È in quei 20 minuti di frustrazione che i neuroni si connettono e creano nuove strade sinaptiche. Quella sensazione di "testa che scoppia" è il suono della competenza che si forma. Se saltate la sofferenza, saltate l'apprendimento.

Cosa c'entra il DigComp 3.0?

Tutto questo non è solo "buon senso", è codificato nel nuovo framework europeo per le competenze digitali (DigComp 3.0).

Il documento mette al centro l'Area 5: Problem Solving.

Uscire dal Tutorial Hell significa passare dalla competenza passiva (Area 1: Information Literacy) a quella attiva (Area 5).

In particolare, la competenza 5.3 (Creatively using digital technology) ci dice una cosa fondamentale: essere competenti non significa conoscere a memoria i comandi (quello lo fa l'AI), ma saper “identificare bisogni e risolverli concettualmente”.

Il tutorial vi dà la soluzione a un problema che non avete.

La competenza reale nasce quando avete un problema vostro (creato con la Regola 1) e usate la tecnologia per risolverlo (con la Regola 3), sbagliando cento volte nel processo.

Conclusione

Non abbiate paura dell'editor vuoto. Quello spazio bianco non è un vuoto di memoria, è uno spazio di opportunità.

La prossima volta che seguite un corso, spegnete il video a metà e provate a finire da soli.

Probabilmente sbaglierete. Il codice esploderà.

Festeggiate!

Significa che avete appena smesso di giocare a fare i programmatori e avete iniziato a esserlo davvero.

Buona domenica di “errori” creativi.

Marcello

Se questa newsletter ti è stata utile, inoltrala a un amico che ha 10 corsi Udemy iniziati e zero progetti finiti. 😅

Se guardo indietro alle settimane trascorse dal nostro ultimo appuntamento, vedo un filo rosso inquietante che collega tutte le notizie che ho commentato, dal CES 2026 ai dati ISTAT sulla scuola.

Questo filo rosso ha un nome preciso, anche se fa male pronunciarlo: colonizzazione digitale.

Oggi proviamo a guardare i numeri in faccia e a capire se (e come) possiamo evitare di diventare solo dei "consumatori passivi" di tecnologia altrui. Solo dei prodotti pronti per essere venduti al migliore offerente.

Il grande freddo dei numeri

Lunedì scorso ho condiviso un dato che mi toglie il sonno.

Mentre il mondo corre (l'AI ha generato 1,3 milioni di nuovi posti di lavoro specializzati a livello globale), l'Italia passeggia svagata, come se il problema non la riguardasse.

• Adozione AI: in Italia solo l'8,2% delle imprese utilizza soluzioni di Intelligenza Artificiale. In Germania siamo quasi al 20%.

• Investimenti: la nostra spesa in Venture Capital (innovazione pura) è lo 0,07% del PIL. La Francia investe il triplo.

Ma il colpo di grazia è arrivato ieri, con i dati ISTAT sull'educazione: siamo terzultimi in Europa per spesa nell'istruzione (4,1% del PIL).

Mettete insieme questi tre punti e il disegno è chiaro:

1. non stiamo investendo sulle macchine (AI nelle aziende);

2. non stiamo investendo sulle teste (Scuola e Istruzione);

3. stiamo aspettando che qualcuno venga a salvarci.

Il dono delle perline

La definizione di "Colonia Digitale" è semplice: un Paese che importa infrastruttura critica e conoscenza, ed esporta solo dati grezzi e denaro.

È la stessa dinamica del colonialismo storico: noi diamo materie prime nobili in cambio di prodotti finiti costosi.

Guardiamoci allo specchio:

• l'hardware: i chip che usiamo sono americani (NVIDIA, Intel, AMD) o taiwanesi (TSMC). Non abbiamo sovranità sul silicio;

• il software: i modelli su cui stiamo costruendo il futuro sono americani (OpenAI, Google, Anthropic) o cinesi;

• i dati (la miniera): noi forniamo la materia prima (i nostri dati, la nostra privacy, la nostra creatività, le nostre abitudini), loro li estraggono, li raffinano e ci rivendono il servizio in abbonamento.

Al CES 2026 ho visto un tripudio di gadget inutili (frigoriferi parlanti, laptop che si aprono da soli) pensati per abbagliarci e abbindolarci.

Sono le "perline di vetro" moderne dei neo-colonizzatori.

Noi compriamo lo specchietto per le allodole, felici del nuovo giocattolo, mentre loro possiedono la miniera e continuano ad arricchirsi sulle nostre spalle.

La resistenza parte dall'aula (e dalla cantina)

È tutto perduto? Diventeremo un parco giochi turistico per nomadi digitali californiani?

Non per forza.

Nel mio piccolo, nei laboratori di IeFP, nei corsi ITS qui in Sicilia (che, ricordo, è maglia nera per investimenti, eppure resiste con un orgoglio incredibile), vedo la via d'uscita.

La via d'uscita non è "fare un'altra ChatGPT italiana". È troppo tardi (e troppo costoso) per partecipare a quella competizione.

La via d'uscita si chiama ingegneria dell'applicazione.

Non dobbiamo costruire il motore (ce l'hanno già loro), dobbiamo imparare a costruire la macchina che ci sta intorno meglio di chiunque altro.

Dobbiamo prendere quei modelli e calarli verticalmente nelle nostre eccellenze: nell'agrifood, nella meccanica di precisione, nel turismo culturale, nell'artigianato.

Agli studenti dico:

Smettetela di studiare "Prompt Engineering" (che equivale solo a chiedere per favore in inglese). Studiate, piuttosto, System Integration.

Studiate Data Governance (come proteggere i dati aziendali affinché non escano dall'azienda) e cybersecurity.

Studiate come far girare questi modelli in locale, su server che controllate voi, staccando la spina dal cloud americano. Questa è la vera sovranità digitale.

Il consiglio della settimana: torniamo al "ferro"

Se vogliamo smettere di essere una colonia, dobbiamo smettere di trattare la tecnologia come magia e ricominciare a trattarla come meccanica.

Il mio invito è questo: non limitatevi a usare un software. Chiedetevi sempre dove risiedono i dati.

• Self-Hosting: se usate un'automazione (tipo n8n, di cui abbiamo parlato per la falla di sicurezza ravvisata in questi giorni), provate a ospitarla su un vostro server, non nel cloud altrui. È più difficile? Sì. Ma è vostro.

• Fediverso: sganciatevi dalle big tech anche nel sociale. Iniziate a esplorare il Fediverso (Mastodon, Pixelfed). Lì il grafo sociale appartiene a voi, non all'algoritmo di un miliardario.

La sovranità digitale non la fanno i governi con i decreti. La facciamo noi, un server locale alla volta, una riga di codice consapevole alla volta.

Buona domenica di resistenza.

Marcello

P.S.

Nei giorni scorsi parlavamo di Wikipedia come monumento al web libero. Ricordatevi che l'Open Source è l'arma più potente contro la colonizzazione. Supportatelo, usatelo, studiatelo. Senza Open Source, siamo solo affittuari nel computer di qualcun altro.

👉🏻 Se ti è piaciuta questa newsletter, inoltrala a un amico o a un collega che pensa che "il cloud è solo il computer di qualcun altro".

Se siete qui, probabilmente, è perché siete stanchi del “rumore”. Siamo al 5 di gennaio, il momento dell’anno in cui il feed di ogni professionista si riempie di buoni propositi: “Quest’anno imparerò a programmare con l’AI”, “Quest’anno automatizzerò tutto il mio lavoro”, “Quest’anno lancio 3 startup”, “Come pianificare il tuo 2026” e compagnia cantante.

Io ho un solo proposito per voi: smettetela di cercare scorciatoie.

Iscriviti ora

La Matematica dell’Intelligenza Artificiale

C’è una formula che ho scritto sulla lavagna (quella vera, col gesso che sporca) durante l’ultima lezione in IeFP prima delle feste. Voglio condividerla con voi perché è la base di tutto quello che leggerete in questa newsletter.

La formula è questa:
0 x AI = 0

L’Intelligenza Artificiale Generativa non è una bacchetta magica. È un moltiplicatore.
Funziona esattamente come una leva o un amplificatore audio:

• Se in ingresso metti un segnale pulito e forte (Competenza 1), l’AI lo amplifica e lo porta a 10.

• Se in ingresso non metti nulla o metti solo confusione (Competenza 0), l’AI amplificherà il nulla. O peggio, amplificherà la tua mediocrità a una velocità che non riuscirai a gestire.

Cronache dall’aula

Perché sono così drastico? Perché lo vedo succedere ogni giorno. Lavorando nella formazione professionale (IeFP, ITS, corsi GOL), ho un osservatorio privilegiato. Vedo ragazzi sveglissimi e adulti in riqualificazione che cadono nella stessa trappola: cercano una soluzione facile.

Vedo studenti generare in 30 secondi blocchi di codice Python perfetti o email di marketing impeccabili usando ChatGPT.
Sembrano dei geni. Sembrano pronti.
Poi succede l’inevitabile: l’imprevisto.

Il codice dà un errore imprevisto oppure la strategia di marketing richiede una sensibilità umana che il prompt non aveva. E lì cala il gelo. Lo studente che ha usato l’AI per sostituire lo studio si blocca. Non sa dove guardare. Non sa fare “debug”, perché non ha mai capito la logica che sta dietro a quel codice. Ha guidato una Ferrari senza aver mai preso la patente. Risultato? Alla prima curva, si schianta.

Il Paradosso del Geek

Io sono nato tecnologicamente col Commodore 64. Appartengo a quella generazione di nerd che doveva configurare gli IRQ della scheda audio a mano per poter giocare a Doom. Era frustrante? Sì. Era una perdita di tempo? Forse. Ma ci insegnava una cosa fondamentale: come funzionano le cose sotto il cofano. Era comunque bellissimo!

Oggi il rischio è l’astrazione totale. Premiamo un bottone e succede la magia. Ma se vuoi lavorare con la tecnologia (e non farti lavorare DALLA tecnologia), devi tornare a sporcarti le mani. Devi usare il cervello, la tua creatività, perché altrimenti non avrai nessun plus rispetto a un elaboratore che viaggia a una velocità milioni di volte superiore alla tua.

Il mio consiglio per il 2026

Non usate l’AI per saltare i passaggi difficili. Usatela solo dopo aver capito come farli a mano.

• Scrivete quella mail di vendita da zero. Fatela schifosa, imperfetta, poi correggetela. Dopo chiedete a Claude di migliorarla.

• Scrivete quel codice SQL a mano, sbagliando le join, perché è così che si impara! Poi chiedete a GPT di ottimizzarlo.

Costruite il vostro “Numero 1”. Costruite la vostra competenza di base. Solo allora l’AI vi renderà dei supereroi.
Altrimenti, sarete solo degli utenti passivi che generano spazzatura sintetica ad alta velocità.

Cosa aspettarsi da questa Newsletter

Se vi sentite in sintonia con questo discorso, siete nel posto giusto. Questa newsletter non avrà una cadenza ossessiva (ho delle lezioni da preparare e una vita da vivere!), ma arriverà ogni due settimane circa.

Cosa troverete qui:

1. Realtà: storie vere dai corsi di formazione professionale (cosa funziona e cosa no);

2. Analisi: smontiamo l’hype del momento e cerchiamo l’utilità reale dei nuovi tool;

3. Cultura: un po’ di sana nostalgia geek e riflessioni sul futuro del lavoro.

Niente guru, niente fatturato facile, niente filtri.

Benvenuti nella realtà.

A presto,
Marcello

Iscriviti ora