Aldo Prinzi's BLOG

Categoria: Blog

  • La fine del coding secondo Jensen Huang: il momento di Canonity

    La fine del coding secondo Jensen Huang: il momento di Canonity

    ​Secondo Huang, l’era in cui imparare la sintassi di un linguaggio (Python, C++, Java) era il requisito d’accesso all’innovazione è finita. Grazie all’IA generativa, il focus si sposta dal come scrivere il codice al cosa vogliamo realizzare.

    ​Il mondo dello sviluppo software è arrivato a un punto di svolta. Non lo dicono i sognatori, ma chi l’hardware per l’Intelligenza Artificiale lo costruisce davvero. Jensen Huang, CEO di NVIDIA, ha recentemente lanciato una provocazione che ha scosso le fondamenta della Silicon Valley: “Il nostro compito è creare una tecnologia tale che nessuno debba più programmare. Il linguaggio di programmazione del futuro sarà quello umano.”

    ​In questo scenario, il valore non risiede più nella manovalanza digitale, ma nell’architettura del pensiero.

    ​La visione di Huang: dall’esecuzione all’orchestrazione.

    ​Il concetto espresso da Huang è chiaro: la democratizzazione della tecnologia passa attraverso l’abbattimento della barriera del codice. Se puoi spiegare un problema in linguaggio naturale e l’IA può tradurlo in una soluzione funzionale, allora chiunque possieda una logica di dominio (un biologo, un ingegnere, un esperto di business) diventa, a tutti gli effetti, un programmatore.

    ​Tuttavia, tra la “visione” di Huang e la realizzazione di sistemi complessi c’è ancora un vuoto tecnico. Scrivere un prompt per una chat è semplice; costruire un’applicazione strutturata, sicura e scalabile orchestrando l’IA è una sfida diversa.

    ​Canonity: il ponte tra visione e realtà

    ​È esattamente in questo spazio che si inserisce Canonity. Se la visione di Huang definisce il traguardo, Canonity rappresenta il motore per raggiungerlo.

    ​Canonity non è un semplice assistente al codice, ma un multi-LLM editor nato per permettere all’utente di agire come l’architetto di cui parla Huang. Ecco come risponde concretamente ai pilastri della nuova era:

    1. ​Orchestrazione vs Codifica: Mentre i programmatori tradizionali scrivono righe di codice, l’utente di Canonity orchestra modelli. Può decidere quale modello di linguaggio sia più adatto a una specifica funzione, mettendo a sistema le diverse “intelligenze” per ottenere un risultato superiore alla somma delle parti.
    2. ​Linguaggio Naturale come Asset: Canonity abilita l’uso del linguaggio umano per definire flussi e logiche. Questo permette di mantenere il focus sulla risoluzione del problema, delegando alla piattaforma la gestione della complessità sintattica.
    3. ​L’architettura al centro: Seguendo il mantra di NVIDIA, il valore umano si sposta sulla progettazione. Canonity fornisce gli strumenti per visualizzare e connettere queste logiche, rendendo tangibile l’idea che l’informatica sia diventata una disciplina di design e strategia, non più solo di digitazione.

    ​Verso un nuovo paradigma

    ​Se accettiamo la tesi di Huang, dobbiamo accettare che il ruolo dello sviluppatore sta cambiando radicalmente. Non saremo più traduttori che convertono idee in linguaggi macchina, ma saremo registi di modelli intelligenti.

    ​Canonity incarna perfettamente questo cambiamento di paradigma. È lo strumento per chi ha capito che il futuro non si scrive più riga per riga, ma si progetta attraverso l’orchestrazione dei modelli. La tecnologia di cui parla Huang esiste già: si tratta solo di scegliere di essere architetti invece che semplici esecutori

  • Code Simplifier: quando l’AI ammette di scrivere troppo codice

    Code Simplifier: quando l’AI ammette di scrivere troppo codice

    Il plugin ufficiale di Claude Code che ripulisce il pasticcio che Claude Code ha appena creato

    C’è qualcosa di profondamente onesto in un team che rilascia uno strumento per correggere i difetti del proprio strumento.Boris Cherny, il creatore di Claude Code, ha appena reso open source il code-simplifier, un sub-agente che usa quotidianamente nel suo lavoro.

    La sua funzione? Semplificare il codice dopo che Claude Code ha finito di lavorare. Rileggi: dopo.

    Claude Code ha un problema strutturale: scrive troppo.Non nel senso che chiacchiera. Nel senso che produce codice verboso, over-engineered, pieno di astrazioni inutili.

    Funziona, per carità, è anche bene, ma funziona come funziona un mobile Ikea montato da uno che ha letto le istruzioni in svedese: regge, ma non è elegante.

    Il code-simplifier nasce per rimediare a questa tendenza. È un agente specializzato nel refactoring che interviene a fine lavoro per:

    eliminare ridondanze — trova codice duplicato e lo estrae in funzioni riusabili, seguendo il principio DRY (Don’t Repeat Yourself, per chi non mastica acronimi anglofoni)

    migliorare la leggibilità — semplifica condizionali annidati, spezza metodi elefantiaci in funzioni più piccole, migliora i nomi delle variabili (addio temp2_final_v3)

    modernizzare la sintassi — aggiorna il codice per usare le feature moderne del linguaggio invece di pattern da museoIl tutto senza toccare la funzionalità.

    Il codice fa esattamente quello che faceva prima, solo che adesso lo capisce anche chi lo legge.

    Come si installa

    Dal terminale:

    claude plugin install code-simplifier

    Oppure dall’interno di una sessione Claude Code:

    /plugin marketplace update claude-plugins-official

    /plugin install code-simplifier

    Fatto.

    Niente configurazioni bizantine, niente file YAML da interpretare come testi sacri.

    Come si usa

    Non c’è un comando speciale. Basta chiedere a Claude di usarlo:

    "Usa il code simplifier per ripulire questo codice"
"Semplifica quello che abbiamo appena scritto"
"Pulisci questo PR con il code-simplifier"

    L’agente analizza il codice, identifica i problemi di complessità, e propone una versione semplificata spiegando cosa ha cambiato e perché.

    Cherny lo usa dopo ogni feature completata, dopo ogni TODO risolto, prima di ogni code review. È diventato parte del suo workflow quotidiano, insieme a un altro agente chiamato verify-app che testa il codice end-to-end.

    Il trade-off

    C’è un prezzo da pagare: il tempo di sviluppo raddoppia circa.

    Non è poco, ma il ragionamento è semplice: meglio impiegare il doppio del tempo oggi per avere codice manutenibile domani, che risparmiare oggi e piangere tra sei mesi davanti a un file di 2000 righe che nessuno osa toccare.

    È lo stesso principio per cui si scrivono i test: nessuno li ama mentre li scrive, tutti li benedicono quando salvano la produzione.

    Cosa significa davveroIl code-simplifier è interessante non tanto per quello che fa, ma per quello che ammette.

    Ammette che i modelli linguistici, lasciati a se stessi, tendono alla verbosità. Ammette che “funziona” non è sinonimo di “è fatto bene”. Ammette che l’output grezzo di un LLM richiede quasi sempre una revisione.

    È un approccio maturo, lontano dal marketing che vorrebbe farci credere che l’AI risolve tutto al primo colpo.

    La realtà è più prosaica: l’AI scrive, poi l’AI corregge quello che ha scritto, e alla fine — se tutto va bene — il codice è decente.

    Non è magia, è ingegneria.

    E a volte, l’ingegneria migliore è quella che riconosce i propri limiti e costruisce strumenti per aggirarli.

  • AlexNet è tornata. E non per nostalgia.

    AlexNet è tornata. E non per nostalgia.

    Ogni tanto la tecnologia fa una cosa controintuitiva: invece di correre in avanti a testa bassa, si ferma, si gira e guarda indietro. Non per rimpiangere il passato, ma per ricordarsi come si costruiscono davvero le cose che durano.
    È esattamente quello che è successo a novembre 2025 quando il Computer History Museum, insieme a Google, ha deciso di rendere pubblico il codice sorgente originale di AlexNet.

    Il codice sorgente del 2012, quello che ha cambiato la storia dell’intelligenza artificiale.

    Non è un’operazione nostalgica, e non è nemmeno un regalo per chi vuole “rifare AlexNet oggi”. È un gesto culturale. È come dire: prima di discutere dell’ennesimo modello miracoloso, forse vale la pena tornare a vedere come nasce una vera discontinuità tecnologica.

    AlexNet nasce nel 2012 all’Università di Toronto, da Alex Krizhevsky, Ilya Sutskever e Geoffrey Hinton. Vince ImageNet in modo così netto da rendere improvvisamente obsoleti anni di approcci precedenti, dimostrando in un colpo solo che le reti neurali profonde non sono solo belle teorie: funzionano, scalano e cambiano le regole del gioco.

    Da lì in poi il deep learning diventa la norma, le GPU diventano strumenti scientifici e la computer vision prende una direzione completamente nuova.

    Ma oggi AlexNet non ci interessa per la sua potenza.

    Oggi confrontata con gli standard attuali. Ci interessa per un motivo molto più profondo: come è stata pensata.

    Il codice che oggi possiamo leggere su GitHub
    🔗 https://github.com/computerhistory/AlexNet-Source-Code

    Non è elegante, modulare, o “clean”. È scritto in CUDA C++ ed è brutalmente onesto. La memoria GPU viene gestita a mano, i layer non sono entità astratte ma strutture concrete, il training non è un loop astratto, ma è un flusso rigido e dichiarato. Non esiste separazione tra modello, training, preprocessing ed esecuzione: tutto è intrecciato, perché tutto fa parte dello stesso problema.

    Leggerlo oggi è quasi uno shock culturale per chi è cresciuto a colpi di framework. Qui non c’è nulla che ti protegga. Se qualcosa non funziona, non puoi incolpare una libreria: sei tu. Ed è proprio questo che rende il codice di AlexNet così prezioso. Ti costringe a capire perché una scelta è stata fatta, quali compromessi sono stati accettati, quali limiti hardware hanno guidato l’architettura.

    AlexNet, in altre parole, non era “solo un modello”. Era un sistema completo. Dataset, preprocessing, training su GPU, tuning manuale, gestione della memoria, flusso end-to-end. Tutto insieme. Nulla aveva senso da solo.

    Ed è qui che il collegamento con l’IA di oggi diventa quasi imbarazzante per quanto è evidente.

    Image

    Nel 2025 passiamo una quantità enorme di tempo a discutere su quale sia il modello migliore. Come se il problema fosse lì. Ma un singolo LLM, per quanto impressionante, soffre degli stessi limiti strutturali che avevano le singole reti neurali prima di AlexNet: non ha memoria vera, non ha visione di processo, non ha responsabilità sul risultato finale. Da solo, è fragile.

    Il valore reale oggi emerge quando smettiamo di ragionare in termini di “modello” e iniziamo a ragionare in termini di sistema. Quando progettiamo flussi, step, ruoli, controlli. Quando decidiamo quale modello deve fare cosa, in quale momento, con quale contesto e con quale verifica. Quando l’intelligenza artificiale smette di essere una risposta brillante e diventa un processo governato.

    AlexNet ci ricorda che le rivoluzioni non nascono da un singolo componente eccezionale, ma da un’architettura chiara. È lo stesso principio che oggi ritroviamo nei sistemi di orchestrazione multi-modello e, più in generale, in piattaforme come Canonity, dove il focus non è il prompt perfetto o il modello più grosso, ma la struttura che tiene tutto insieme. Non il singolo output, ma il flusso che lo rende affidabile.

    AlexNet non ci colpisce più per la potenza, ma per la lucidità. Per il fatto che, prima che tutto diventasse automatico, qualcuno aveva capito che l’IA non è magia statistica, ma ingegneria dei sistemi. Il rilascio del suo codice non è una celebrazione del passato: è un promemoria molto attuale.

    Se vogliamo davvero capire dove sta andando l’intelligenza artificiale, ogni tanto dobbiamo fare quello che fa questo repository: tornare alle fondamenta, sporcarci le mani con l’architettura e ricordarci che le vere innovazioni non nascono dall’ultimo modello, ma dalla capacità di mettere ordine nella complessità.

  • Quanto ha senso un consiglio di amministrazione con un solo membro?

    Quanto ha senso un consiglio di amministrazione con un solo membro?

    Per un po’ di tempo abbiamo creduto di risolvere con un modello AI più grande, più veloce, più addestrato, più tutto.

    Ogni nuova versione sembrava portarci un passo più vicino a un punto di arrivo definitivo, come se bastasse aggiungere qualche miliardo di parametri per ottenere finalmente l’intelligenza “giusta”. Un’idea rassicurante, quasi infantile: se qualcosa non funziona, lo ingrandiamo. Ha sempre funzionato così, no?

    Poi è successa una cosa curiosa. Le persone che quei modelli li hanno costruiti hanno iniziato a dire, più o meno apertamente, che nemmeno loro sanno davvero come funzionano fino in fondo.

    Ilya Sutskever lo ha detto con una calma quasi sospetta: lo scaling infinito non è la risposta. Non perché i modelli non siano impressionanti, ma perché stiamo continuando a spingere sull’acceleratore senza sapere esattamente cosa stia succedendo sotto il cofano. Una strategia audace, certo. Ma non proprio quello che definiremmo “controllo”.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Nel frattempo, noi utenti abbiamo sviluppato una dinamica tutta nostra. Parliamo con l’AI, aspettiamo la risposta, la correggiamo, rilanciamo. Poi di nuovo. Un dialogo continuo che, a guardarlo bene, assomiglia più a una riunione infinita che a un processo decisionale. Un problema serio, però, non si risolve in una risposta, ma in una sequenza di passaggi: comprendere, analizzare, scegliere, verificare, correggere, rifinire.

    Fino al 2025 lo abbiamo affrontato in modo ricorsivo. Domanda, risposta, controbattuta. Ancora. Come ho scritto nel mio post precedente, siamo diventati degli umarell digitali, affacciati alla finestra della chat, a commentare quello che l’AI stava facendo, pronti a intervenire dopo.

    È stato utile, va detto, e in qualche modo anche istruttivo, ma è plausibile che questo sia il modello definitivo di collaborazione uomo–macchina?

    A un certo punto inizierà semplicemente a sembrarci inefficiente continuare a dire all’AI “fammi questo”, con richieste isolate che interrompono il flusso, con ogni risposta che ci costringe a fermarci, a valutare per correggere e poi ripartire. Una conversazione infinita che ricorda sempre più quelle riunioni in cui nessuno ha preparato l’ordine del giorno.

    Così inizieremo a fare una cosa sorprendentemente umana: pensare prima, non per lasciare l’AI più libera, ma per essere noi molto più rigorosi.

    Pensaci, hai mai risolto un problema complesso tutto insieme?

    Quando un problema è davvero tale, lo si scompone. Lo si riduce. Lo si divide in problemi più piccoli e li si affronta uno alla volta, in sequenza. Si chiama “problem solving”, quello che funziona, non quello raccontato nei keynote.

    E se ci pensi ancora un po’ vedrai che è esattamente il percorso che abbiamo già fatto nel campo della programmazione dei computer: all’inizio c’era il programma monolitico, un unico blocco enorme che faceva tutto. Funzionava finché nessuno lo toccava. Poi l’utente chiedeva una modifica, qualcuno faceva una patch apparentemente innocua… e tutto il resto iniziava a comportarsi in modo imprevedibile.

    Abbiamo imparato allora a spezzare quel monolite in funzioni, ognuna con un compito preciso. Meno caos, più controllo, meno notti passate a chiedersi perché qualcosa si fosse rotto.

    Oggi siamo arrivati ai microservizi, non perché fosse elegante, ma perché è il modo sensato per gestire sistemi complessi: componenti piccoli, isolati, sostituibili, che comunicano in modo esplicito. Più lavoro prima, molta meno sorpresa dopo.

    Con l’AI vivremo la stessa identica evoluzione, solo compressa in meno anni (4/5 contro 10/15).

    Stiamo passando dal prompt monolitico che “fa un po’ di tutto” a sistemi in cui i compiti sono separati, assegnati, orchestrati, per ridurre gli errori e rendere i risultati finalmente ripetibili.

    Ed è qui che una delle osservazioni più interessanti ci arriva da Andrej Karpathy: ha fatto notare che interagire con un singolo modello non è un buon modo di usare l’AI.

    Secondo Andrej che in un consiglio di amministrazione composto solo dal CEO e da un consulente che annuisce, entrambi parlano ma nessuno contraddice davvero e non si cambia mai il percorso, non si evolve, non si allarga il punto di vista.

    La sua idea di LLM Council nasce proprio da qui: un sistema funziona quando il CTO e il CFO iniziano a prendersi a parolacce, quando uno dice “tecnicamente è perfetto” e l’altro risponde “sì, ma ci manda in fallimento” e il CEO media, il COO trova soluzioni e il CLO lo rende legale. Quando le voci dissonanti emergono prima, non quando è troppo tardi.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Nel futuro, se vogliamo risultati affidabili, non dovremmo chiedere all’AI di “pensare meglio”, ma organizzare meglio il pensiero.

    Decidere noi i passaggi, stabilire chi fa cosa, prevedere controlli incrociati. Non libertà totale, ma responsabilità distribuita.

    Nel frattempo, ai piani alti, il panorama non è meno ironico.
    Satya Nadella probabilmente non immaginava che il futuro della sua azienda sarebbe stato meno una corsa ad ingrandire il modello di OpenAI e più un delicato esercizio di convivenza tra modelli diversi, filosofie diverse, interessi diversi.

    Più che scegliere il vincitore, oggi il lavoro vero è evitare che il consiglio di amministrazione esploda.
    (vedi link su “letture consigliate” in fondo all’articolo)

    E poi c’è Ivan Zhao, che sull’AI è rimasto alla finestra a guardare. Un po’ come un umarell di lusso: osserva, ascolta, non si lascia prendere dall’entusiasmo e aspetta di capire dove stia davvero andando il valore. Non sempre muoversi per primi è la strategia migliore.
    (vedi link su “letture consigliate” in fondo all’articolo)

    Il punto, però, resta sempre lo stesso.

    Nel 2026 non avremo un’AI più intelligente, inizieremo a smettere di usarla come una chat e inizieremo a trattarla come un sistema complesso, fatto di ruoli, sequenze e responsabilità.

    Il cambiamento non arriverà con proclami o rivoluzioni improvvise. Arriverà quando smetteremo di fare domande sempre migliori e inizieremo a progettare processi migliori. Avverrà quando passeremo dall’attesa alla direzione.

    Il futuro dell’AI, probabilmente, non sarà più intelligente.
    Sarà semplicemente meglio organizzato e, ironia della sorte, dipenderà molto meno dall’AI e molto più da te e da me.

    Letture consigliate

  • Da umarell a direttore d’orchestra

    Da umarell a direttore d’orchestra

    Canonity, u-prompt e la maturazione dell’AI come strumento

    Negli ultimi mesi ho osservato con crescente fastidio un equivoco diffondersi nel mondo dell’AI: l’idea che l’automazione coincida con il “lasciare fare tutto alla macchina”.
    È un equivoco pericoloso, perché confonde la delega con l’abdicazione e l’efficienza con l’imprevedibilità.

    Siamo umani.
    E quando lavoriamo — davvero — abbiamo bisogno di certezza del risultato, non dei capricci di un modello che oggi risponde bene e domani no.

    Gran parte dell’AI attuale, invece, è usata in modalità umarell: si apre una chat, si scrive un prompt, si osserva la risposta, la si corregge, la si rilancia. È un’iterazione continua, sincrona, fragile. Interessante, ma strutturalmente immatura.

    Ivan Zhao, fondatore di Notion, ha messo un punto fermo su questo tema in un post che considero fondamentale e che vale la pena citare direttamente:
    https://x.com/ivanhzhao/status/2003192654545539400

    Il concetto è semplice quanto definitivo: se stai guardando l’AI mentre lavora, non stai automatizzando nulla. Nessuno osserva una fabbrica mentre produce. Si progetta il processo, si avvia, si torna dopo.

    Il valore sta nel processo, non nella conversazione.

    Questa osservazione è la chiave per capire Canonity e u-prompt, e soprattutto perché sono due strumenti diversi che risolvono due problemi diversi.

    Canonity nasce come editor di prompt multi-modello LLM, ma sarebbe un errore fermarsi a questa definizione. Canonity non serve a “provare modelli a caso” né a demandare a una macchina la scelta del modello migliore (come fanno sistemi alla Perplexity).
    In Canonity la scelta del modello è umana. Sempre.

    Questo non è un limite. È una presa di posizione.

    Chi lavora sa che modelli diversi producono risultati diversi, con stili diversi, affidabilità diverse, bias diversi. Affidare questa scelta a un algoritmo significa accettare una variabilità che, nei contesti di lavoro reali, non è accettabile.

    Canonity parte da un presupposto semplice: l’umano è responsabile del risultato finale, quindi l’umano deve scegliere con quale cervello artificiale lavorare.

    Canonity è lo spazio in cui costruisci il tuo prompt automatico, lo testi, lo migliori, lo rendi stabile. È uno strumento personale, quasi intimo. Serve a te, per risolvere un problema tuo.

    Qui l’AI non è un giocattolo né un oracolo, ma un componente tecnico da configurare con attenzione.

    Quando quel prompt funziona e il risultato è affidabile, ripetibile, coerente, succede qualcosa di interessante: ti rendi conto che quel risultato non serve solo a te.

    Ed è qui che entra in gioco u-prompt.

    u-prompt non è un repository di prompt e non nasce per vendere “testi magici”. Nasce da un’idea molto più concreta: non vendere il prompt, vendi il risultato.

    Chi arriva su u-prompt non compra istruzioni, compra un output. Esattamente come in un juke-box: non compri il disco, ascolti la canzone.

    Questa distinzione è cruciale.

    Un prompt richiede competenza, contesto, manutenzione. Un risultato no. Un risultato risponde a un bisogno diretto e abbassa enormemente la soglia di accesso. Meno richiesta cognitiva significa molti più utenti potenziali.

    Canonity e u-prompt, insieme, separano in modo netto due momenti che fino a oggi erano confusi: la fase di costruzione e la fase di consumo.

    Canonity è per chi costruisce.
    u-prompt è per chi usa.

    Nel primo caso sei ancora “in cantiere”, stai progettando, testando, raffinando. Nel secondo, il cantiere non si vede più. Il lavoro è fatto. Il processo gira. L’utente non osserva nulla, ottiene solo il risultato.

    È esattamente il passaggio descritto da Ivan Zhao: dall’AI osservata all’AI che lavora mentre tu fai altro.
    Non perché “la macchina è più brava”, ma perché il processo è stato progettato bene.

    Qui avviene il salto da umarell a direttore.
    L’umarell guarda, commenta, corregge, il direttore non suona ogni strumento, ma decide chi suona cosa, quando e come.

    Canonity ti mette in mano la bacchetta. u-prompt apre il teatro al pubblico.

    Non c’è alcuna retorica futuristica in tutto questo, è una questione di maturità degli strumenti.

    Finché l’AI resta una chat da sorvegliare, non entrerà mai davvero nei processi produttivi. Finita la fase umarell adesso deve diventare un sistema che produce output affidabili, ripetibili e vendibili, allora sì che sarà uno strumento.

    Alla fine di gennaio 26 partirà la startup e una parte significativa dei prodotti sarà già utilizzabile. Non una promessa, ma strumenti concreti, pensati per chi lavora davvero e non ha tempo di fare l’umarell davanti allo schermo.

  • Albo esperti innovazione tecnologica – Brazil 2026?

    Albo esperti innovazione tecnologica – Brazil 2026?

    L’Albo degli Innovatori Certificati del Ministero del Made in Italy è un trionfo monumentale della burocrazia italiana e quanto di meno innovativo esista: un perfetto simulacro di un formulario cartaceo degli anni ’90.

    Per iscriversi a questo albo, che dovrebbe certificare i paladini della modernizzazione industriale, bisogna affrontare un modulo Microsoft Forms che è un capolavoro di tecnologia all’avanguardia. [Modulo Iscrizione] Niente SPID, niente autenticazioni digitali: solo un interminabile rosario di caselline da spuntare, dove ci si assume la responsabilità della veridicità dei dati che dobbiamo diligentemente digitare.

    Ma è nei dettagli che la fulgida innovazione ministeriale rivela tutta la sua grandezza. Le province? Niente menu a tendina per i pigri: vanno scritte a mano, rigorosamente con due caratteri. Sì, devi digitare manualmente “PA”, “BO”, “MI” come se gli impiegati dei catasti di provincia degli anni 90, perché evidentemente l’idea di una semplice lista predefinita sarebbe troppo disruptive per un albo dedicato all’innovazione.

    Le date, poi, sono un vero inno alla praticità: non sognarti di digitare semplicemente “30/11/1973”. Devi aprire un pannello e scorrere anno per anno, mese per mese, giorno per giorno, come se stessi sfogliando un innovativo calendario da tavolo degli anni 80: un’esperienza così innovativa che solo chi ha padroneggiato le meccaniche di un cubo di Rubik potrebbe eseguirla senza maledire la propria esistenza.

    Ma il tocco di assoluta genialità è rappresentato dalla richiesta di indicare, senza possibilità di appello, la data in cui prevedi di andare in pensione.

    Sono rimasto senza parole, poiché non ho mai veramente capito che il vero esperto innovatore deve avere la capacità di predire con esattezza matematica il momento in cui appenderà la penna al chiodo. Non importa se hai trent’anni (più o meno l’età dell’innovatore medio) e non sai dove sarai domani: per potere certificare la tua capacità di innovazione e iscriverti nell’apposito Albo, per il MIM.IT è essenziale sapere che conosci la data del tuo pensionamento.

    Pensavi che fosse finita? No… Il meglio viene alla fine di questo colossale test di resistenza, il sistema ti informa che puoi stampare una copia della domanda (a giudicare da tutto il processo mi chiedo se fanno proprio così al ministero. Cioè stampano la domanda e la mettono in una apposita cartellina cartonata che finisce fisicamente impilata alle altre sulla scrivania di un solerte funzionario per l’approvazione? Aspetta come si chiamava il film geniale di Gilliam? Ah si! “Brazil“…). Dopo aver sudato sette camicie per inserire manualmente ogni singolo dato con i vincoli di un codice medievale, l’ultimo atto rituale è tornare alla carta. Perché, si sa, nessuna domanda è veramente valida finché non ha preso la forma di un foglio pronto per essere infilato in una cartellina e che poi verrà diligentemente timbrato.

    E tutto questo per cosa? Per soddisfare un requisito imprescindibile: possedere una laurea. Una laurea tecnica dici? No, va bene qualsiasi laurea, il formulario prevede: farmacia, restauro (anche di beni culturali), gestione dei flussi turistici: tutto perfettamente valido.

    I sistemi ministeriali si concludono infine con un cerchio talmente perfetto da essere quasi commovente: per accedere ai finanziamenti pubblici della transizione digitale, come previsto dal solenne Decreto Direttoriale n. 3125 del 12 novembre 2025, dovete essere rappresentati da un manager iscritto a questo albo. Un albo che esclude i più grandi innovatori della storia, ad esempio non potrai mai trovare persone come un certo Steve Jobs, che a quanto pare ha fatto innovare un paio di cosette, o Bill Gates, che forse avrà combinato qualcosa con i computer. Tecnicamente nemmeno Luigi Di Maio, che ha avuto l’ardire di gestire questo ministero per oltre un anno senza il necessario tesserino universitario.

    Però se hai una laurea in restauro di beni culturali o gestione dei flussi turistici… cambia tutto, puoi accedere ai finanziamenti per l’innovazione.

    L’Albo degli Innovatori Certificati del MIM.IT dimostra, ancora una volta, che nel nostro Paese la competenza in materia di innovazione si riduce al possesso di un titolo di laurea e alla capacità di compilare un modulo, che verrà successivamente stampato e timbrato.

    Un sistema così elegantemente contraddittorio che persino il suo stesso nome suona come una beffa.

  • Quando l’AI smette di indovinare e inizia a certificare

    Quando l’AI smette di indovinare e inizia a certificare

    Conosci Perplexity (perplexity.ai)? Se la risposta è no, allora dovresti.

    Perplexity è brillante!

    Se lo usi per lavoro, la scena è questa: fai una domanda, in pochi secondi arriva una risposta fluida, ben scritta, piena di riferimenti. Ed é tutto perfetto…

    Perplexity, rispetto ai soliti chatbot, ha una marcia in più: orchestra più LLM, sceglie (o prova a scegliere) il modello più adatto, collega fonti diverse.

    È un ottimo laboratorio di idee. Ma è un laboratorio senza registro di laboratorio: non sai quali modelli ha usato, in che ordine, con quali criteri. E soprattutto non hai un modo semplice per rifare lo stesso percorso tra un mese, o farlo rifare a un collega, ed ottenere un risultato costante e ripetibile.

    Allo scoccare del quarto anno di GenAi, la domanda oggi è: “quanto costa il fatto di non poter certificare il processo che ha portato a quella risposta?”.

    Perplessità e canonicità: due facce della stessa storia

    La scienza vive da sempre su una tensione fra due poli.

    Da una parte c’è la perplessità: il dubbio, le ipotesi, la curiosità che apre piste nuove. È la fase in cui Perplexity è fortissimo: ti mostra fonti diverse, prospettive in conflitto, ti fa vedere che “forse qui qualcosa non torna”.

    Dall’altra c’è la canonicità: quello che diventa metodo, protocollo, standard. Non è la verità assoluta, ma un “con questo protocollo, su questi dati, arriviamo a questa conclusione, con questo grado di confidenza. Sempre”.

    In questo schema, Perplexity è il motore della domanda. Manca però il motore del metodo.

    Se sei un professionista non puoi chiedere ad un unico modello di “fare tutto”, ma hai la necessità di costruire una piccola squadra di modelli, ognuno con un ruolo preciso, legati da un flusso che puoi spiegare e rifare.

    Non sono il solo a sostenerlo, qualche tempo fa Andrej Karpathy ha scritto che il futuro non è il prompt engineering, ma la context engineering: riempire la finestra di contesto con le informazioni giuste, nello step giusto, per il modello giusto.

    Karpathy, la “context engineering” e il terzo pilastro

    Le applicazioni serie di LLM, dice, non sono “un’interfaccia carina sopra un modello”, ma software veri, con flussi di controllo, chiamate orchestrate, memoria, strumenti, verifiche.

    È esattamente quello che ho chiamato pipeline prompting nel mio manifesto:
    – prima la scomposizione in step;
    – poi la specializzazione dei modelli per compito;
    – infine il filo di continuità, cioè come il contesto passa da uno step all’altro.

    Canonity: dai prompt ai protocolli

    Quale nome dare all’editor dove prende forma il pipeline prompting?.

    Canonity.

    Non è il posto dove “parli con l’AI”: è il posto dove decidi come le AI devono lavorare fra loro su un problema reale.

    Canonity nasce esattamente qui: non come “un altro chatbot”, ma come editor visivo di step-prompt.

    Invece di un mega-prompt che speri venga interpretato bene, costruisci un workflow:

    • uno step scompone la domanda in sotto-problemi;
    • un altro cerca, ma restituisce solo metadati strutturati (DOI, anno, tipo di studio…);
    • un terzo valuta la qualità degli studi e segnala bias;
    • un quarto sintetizza, usando solo le fonti che superano una certa soglia;
    • alla fine ci sei tu, che controlli, correggi, approvi.

    Ogni passaggio è esplicito, ogni modello fa il pezzo di lavoro per cui è più adatto, il flusso ha un ID, una versione, una storia.

    Non stai più “giocando al prompt perfetto”: stai scrivendo un protocollo che altri possono usare, criticare, migliorare e4 che da risultati ripetibili ad ogni esecuzione.

    Perché “Canonity” richiama “Perplexity”, ma fa un mestiere diverso

    Il gioco di nomi è ovvio.

    Perplexity richiama la perplessità, il dubbio fertile, l’esplorazione. È perfetto quando vuoi generare idee, esplorare lo spazio di possibilità, farti sorprendere.

    Canonity richiama il canone: ciò che diventa riferimento, metodo, standard. Entra in gioco quando devi dire: “Questo è il modo in cui abbiamo affrontato il problema; questi sono gli step, i modelli, le fonti escluse e perché”.

    Se fai ricerca, se lavori in sanità, in ambito legale, in policy pubblica, non ti basta “me l’ha detto l’AI”. Hai bisogno di una catena di custodia dell’informazione. È questo il passaggio: dall’AI-oracolo all’AI-strumento scientifico.

    Adottare uno strumento come Canonity significa cambiare ruolo: da utente di AI a orchestratore di AI, da prompter a tenmpo perso a professionista: non vendi più “prompt” o “ore di chat”, ma processi: come definisci il problema, come scomponi il lavoro, quali modelli usi, quali controlli applichi.

    E adesso?

    Canonity è in sviluppo attivo e lo stiamo testando con chi ha questo problema molto concreto: non gli basta più una risposta brillante, vuole un metodo che possa difendere davanti a un revisore, un cliente, un comitato etico.

    Se sei uno dei 22 milioni di utilizzatori (o meglio uno degli 8 milioni di utilizzatori a pagamento) di Perplexity e senti che ti manca il “registro di laboratorio”, tieni d’occhio quello che succede intorno a Canonity e al pipeline prompting.

    Perché la partita, ormai, non è più “chi ha il modello più intelligente”, ma chi ha il processo più trasparente e ripetibile.

  • Prompter: il lavoro che cresce mentre altri calano

    Prompter: il lavoro che cresce mentre altri calano

    (dati e stime 12–24 mesi)

    Negli ultimi due anni la GenAI ha spostato gli equilibri del lavoro online e non è un’impressione.
    Su una “grande piattaforma freelance” (nello studio non è indicata quale) dopo l’arrivo di ChatGPT e dei generatori d’immagine, i cluster più esposti all’automazione hanno registrato cali netti degli annunci.

    In particolare:

    • scrittura (≈ −30%),
    • software/app/web (≈ −21%),
    • alcune aree dell’ingegneria (≈ −10%),
    • graphic design (≈ −18%)
    • 3D (≈ −16%).

    Al contrario, aumentano gli annunci che citano esplicitamente la skill “ChatGPT”. È la spia di un nuovo mestiere: prompter (o, più precisamente, AI orchestrator).

    Questa dinamica non racconta “meno lavoro in assoluto”, ma un cambio di mix: i task ripetitivi (bozze di testi, codice standard, grafica base) vengono svolti in autonomia con LLM; resta e cresce la parte di definizione del problema, prompt design a step, orchestrazione di modelli e strumenti, validazione e integrazione nei processi reali (API, dati, governance).

    Cosa sta succedendo

    I dati mostrano chiaramente la cannibalizzazione dei compiti ripetitivi in scrittura, sviluppo e grafica, e l’emersione di attività più complesse dove il prompter è protagonista. Se anche una parte del lavoro “perso” si ricompone in regia AI esternalizzata, nei prossimi 12–24 mesi avremo migliaia di opportunità strutturate attorno a prompt design, QA e integrazione.

    1. Sostituzione del ripetitivo
      Molte micro-attività vengono internalizzate via prompt: da “Cerco freelance per X” a “Risolvo X con un LLM”. Questo spiega la contrazione degli annunci nei cluster più esposti.
    2. Ricomposizione verso la complessità
      I job che restano chiedono più ampiezza (più skill per annuncio) e profondità (problemi meno standardizzabili). La domanda si sposta dall’esecuzione all’orchestrazione.
    3. Emergenza del profilo “prompter”
      Crescono gli annunci che richiedono esplicitamente competenze in ChatGPT/LLM: segnale che la regia dell’AI diventa un servizio a sé, con responsabilità su qualità, sicurezza e integrazione.

    Quanti prompter serviranno? (stima prudente)

    Usando i volumi medi settimanali della piattaforma e i cali differenziali osservati, il “vuoto” creato dalla GenAI equivale a circa 1.700+ annunci a settimana che prima erano tradizionali e oggi vengono automatizzati o riassemblati.

    Se fra il 5% e il 25% di queste attività viene esternalizzato come prompting/orchestrazione, parliamo di ~86–430 nuovi post/settimana, cioè ~4,5k–22k all’anno, per arrivare a ~9–45k in 24 mesi.

    Non è una profezia: è una ipotesi ragionata coerente con l’aumento di annunci che citano “ChatGPT” e con l’evoluzione dei brief verso outcome e integrazioni.

    Cosa cambia per professionisti e aziende

    Per i professionisti

    serve salire di livello. Non vendere “ore di esecuzione”, ma outcome + orchestrazione: scoping, design di prompt multistep, scelta del modello per compito, controlli di qualità (factuality, stile, copyright), integrazione in pipeline (dati, API, RPA), reportistica e metriche.
    La verticalizzazione (legale, sanità, e-commerce) moltiplica il valore perché unisce AI a dominio e compliance.

    Per le aziende

    internalizzare dove l’attività è core; esternalizzare la regia se mancano competenze e tempo. Scrivere brief orientati a risultati, pretendere trasparenza di processo (step, controlli, dati usati), definire policy su privacy, copyright e bias. Il ritorno maggiore non viene dal “provare l’AI”, ma dal industrializzare i flussi.

    Quali strumenti servono?

    La domanda non è se il ruolo crescerà, ma chi saprà passare dalla demo al delivery con strumenti, metodi e metriche all’altezza.

    Serve quindi uno strumento operativo che traduca obiettivi di business in pipeline AI governabili: editor visuale multi-LLM a step, versioning, QA automatico, tracciamento metriche, governance/compliance, e — quando serve — un mercato per acquistare risultati, non prompt nudi.

    ssrn-4602944Download

  • Prompt framework: cosa sono e come usarli

    Prompt framework: cosa sono e come usarli

    Come avrai notato dalla marea di articoli e spiegazioni che circolano, l’intelligenza artificiale è spesso percepita come una specie di magia. Ma tu mi segui, e sai che dietro c’è tecnologia; e dove c’è tecnologia, ci sono metodi.

    Molti descrivono la tecnica del prompting come qualcosa di banale: digiti “fammi X” e l’AI risponde… Bello, vero? È quello che hai fatto finora? Se è così, sai bene che generando un testo da un prompt, il risultato cambia ogni volta, è impreciso, e serve tempo per trovare la formula giusta. Hanno anche inventato il termine “allucinazioni” per descrivere i “bug”.

    Ma te (e ai tuoi futuri clienti) servono risultati coerenti, ripetibili e di qualità professionale, per questo motivo a maggio del 2025 ho spiegato più di 15 tecniche nel mio libro tradotto in 4 lingue (QUI).

    Nella mia visione, la figura del “prompter” diventerà sempre più importante. Dunque, è fondamentale avere padronanza delle metodologie di interrogazione degli LLM: sarà certamente una delle competenze più richieste nel prossimo futuro.

    Oggi, a distanza di soli 6 mesi (che nel campo dell’IA equivalgono a un’epoca geologica), quelle tecniche sono state sintetizzate, o “compattate”, in sette veri e propri framework di prompt (tecniche/metodologie d’uso).

    In questo articolo ti accompagnerò passo passo, usando un unico esempio che complicheremo gradualmente, man mano che saliamo di livello.

    Caso unico per tutti gli esempi
    Scrivere una scheda prodotto per e-commerce del “Kit serratura baule Vespa (cod. 299676)”.
    Obiettivo: testo chiaro, orientato alla vendita, con compatibilità e CTA.

    PAM > Action > Monitor

    Quando usarlo: è il più semplice, usalo per iniziare subito e migliorare un output grezzo. In pratica iteri più volte fino ad arrivare all’obiettivo.

    Prompt > (leggi la risposta) > Monitor/Modify: [cosa cambi e perché]

    Esempio 1

    Prompt v1: “Scrivi una scheda prodotto per il kit serratura baule Vespa 299676.”
Modify: “Riduci a 120–150 parole e inserisci una CTA finale.”

    Perché funziona: ti fa iterare subito, senza teoria, ma il risultato può essere abbastanza deludente.

    Stiamo usando una AI, proviamo a chiedergli qualcosa in più:

    SMART — Specific, Measurable, Achievable, Relevant, Time-bound

    Quando usarlo: per definire criteri misurabili e dire con chiarezza quando il testo è completo.

    Obiettivo SMART: [S][M][A][R][T] + criteri di accettazione

    Esempio 2

    Obiettivo SMART: 120–150 parole, leggibilità ≥60 (Flesch IT),
1 riga di beneficio iniziale, 3 bullet (compatibilità, installazione, garanzia), chiusura con CTA unica (“Aggiungi al carrello”).

    RACE — Role, Action, Context, Execute

    Quando usarlo: per dare ruolo, compito, contesto e formato.
    Effetto: cala la variabilità di tono e struttura.

    Role: [chi sei]
    Action: [cosa devi fare]
    Context: [per chi, vincoli, USP]
    Execute: [formato, stile, lunghezza]

    Esempio 3

    Role: Copywriter e-commerce aftermarket scooter.
Action: Scrivi la scheda prodotto del kit serratura baule Vespa 299676.
Context: Target fai-da-te; evidenzia compatibilità e installazione semplice.
Execute: 120–150 parole; apertura con beneficio; 3 bullet (compatibilità, installazione, garanzia);
chiusura con CTA “Aggiungi al carrello”.

    TRACE — Task, Role, Audience, Context, Example

    Quando usarlo: quando il pubblico conta e vuoi un esempio guida per allineare stile e lessico.

    Task: [output]
    Role: [persona]
    Audience: [per chi]
    Context: [scenario, vincoli]
    Example: [mini-esempio di tono/struttura]

    Esempio 4

    Task: Scheda prodotto e-commerce.
Role: Copywriter tecnico.
Audience: Proprietari Vespa ET2/ET4/Liberty senza esperienza meccanica.
Context: Ricambio originale, modelli compatibili, istruzioni base.
Example (tono): “Compatibile con Vespa ET2/ET4. Si installa in pochi minuti con gli attrezzi di base. Garanzia 24 mesi.”

    CO-STAR — Context, Objective, Style, Tone, Audience, Response

    Quando usarlo: quando, oltre al contenuto, vuoi anche che il testo abbia dei precisi stili e toni.

    Context > Objective > Style > Tone > Audience > Response (formato)

    Esempio 5

    Context: Scheda prodotto per e-commerce ricambi.
Objective: Massimizzare chiarezza e conversione.
Style: Frasi brevi, scannable, lessico semplice.
Tone: Affidabile, pratico, zero iperboli.
Audience: Proprietari Vespa senza esperienza tecnica.
Response: 1 paragrafo 120–150 parole + 3 bullet + CTA finale.

    SiCQuA — Situation, Complication, Question, Answer

    Quando usarlo: per strutturare una micro-narrazione che sciolga i dubbi del cliente.

    Situazione
    Complicazione
    Q-domanda
    Azione (risposta)

    Esempio 6

    Situation: Chi cerca ricambi Vespa vuole compatibilità certa.
Complication: Modelli/anni generano confusione.
Question: Questo kit serratura 299676 è giusto per me?
Answer: Elenca modelli compatibili (ET2, ET4, Liberty…), spiega installazione base,
ricorda garanzia/resi, chiudi con CTA.

    PEAS — Performance, Environment, Actuators, Sensors

    E’ il più tecnico dei framework, usalo quando devi progettare un agente/pipeline che generi e validi la scheda.

    Performance: [metriche/SLAs]
    Environment: [dove opera, vincoli]
    Actuators (Output): [cosa produce]
    Sensors (Input): [quali dati/fonti usa]
    + Failure modes & Fallback

    Esempio 7

    Performance: 100% nomi modello validi; ≤2 errori ortografici; leggibilità ≥60.
Environment: Catalogo interno + DB compatibilità; privacy GDPR.
Actuators: Blocco HTML scheda prodotto + JSON compatibilità.
Sensors: SKU 299676, lista modelli, manuale tecnico.
Failure & Fallback: se compatibilità mancante → chiedi conferma; se conflitti → mostra alert.

    Da grezzo a pro: lo stesso prompt che “cresce”

    Ok, se prima di questo articolo non eri un prompter professionista 😉 adesso sai che un prompt non è una frase “magica”: è progettazione.

    Parti da PAM, aggiungi SMART per definire cosa significa “buono”, struttura con RACE.

    Quando serve coerenza di brand e audience, passa a TRACE/CO-STAR. Se devi educare e convincere, usa SiCQuA. E quando vuoi scalare con affidabilità, modella il sistema con PEAS.

    Ecco gli esempi pratici:

    PAM → SMART

    PAM v1: Scrivi una scheda prodotto per kit serratura baule Vespa 299676.
Modify: 120–150 parole, 3 bullet (compatibilità, installazione, garanzia), CTA finale.
SMART: Leggibilità ≥60; evita superlativi generici; niente termini tecnici non spiegati.

    RACE → TRACE → CO-STAR

    RACE: Role (copy e-commerce) + Action (scheda) + Context (target fai-da-te) + Execute (formato).
TRACE: aggiungi Audience (ET2/ET4/Liberty) + Example (tono pratico).
CO-STAR: separa Objective (conversione) da Style/Tone (chiaro, affidabile) e Response (formato).

    SCQA → PEAS

    SCQA: incornicia i dubbi (“è compatibile con il mio modello?”) e rispondi in ordine logico.
PEAS: progetti l’agente che pesca i dati, valida la compatibilità e genera l’HTML finale.

    Checklist (copia e incolla)

    • PAM: prova → leggi → modifica una cosa alla volta.
    • SMART: aggiungi 2–3 metriche verificabili.
    • RACE: ruolo chiaro + compito + contesto + formato.
    • TRACE: dichiara il pubblico e metti un mini-esempio.
    • CO-STAR: separa obiettivo da stile/tono; definisci il formato di risposta.
    • SiCQuA: situazione → problema → domanda → risposta/azioni.
    • PEAS: metriche, input/output, errori previsti, fallback.
  • I Browser “Agenti” con AI sono INSICURI

    I Browser “Agenti” con AI sono INSICURI

    I Browser alimentati dagli “Agenti AI” sono una minaccia per la sicurezza e dovremmo evitarli

    Ammettilo, stai pensando di provare uno dei nuovi browser alimentati da Intelligenza Artificiale come OpenAI Atlas, Comet di Perplexity o simili.
    Fermati immediatamente.
    La comodità di un assistente che naviga il web al posto tuo non vale il rischio estremo a cui stai esponendo i tuoi dati, i tuoi file e persino i tuoi conti correnti.

    Non osono congetture o previsioni malsane, un rapporto di sicurezza di Brave, noto per il suo browser focalizzato sulla privacy, ha lanciato un allarme chiaro: questi “browser agenti” presentano vulnerabilità strutturali che li rendono estremamente suscettibili a una nuova e subdola forma di attacco informatico: l’iniezione di prompt tramite siti web (prompt injection).

    Il Cavallo di Troia Digitale: Come Funziona l’Attacco

    Il pericolo non viene da un virus tradizionale, ma da istruzioni nascoste in bella vista. Ecco il meccanismo, passo dopo passo:

    1. L’Esca dell’Aggressore: Un malintenzionato inserisce comandi nascosti in una pagina web. Spesso si tratta di testo camuffato (ad esempio, bianco su sfondo bianco) o di metadati invisibili all’occhio umano. Tu non lo vedi, ma l’agente AI sì.
    2. L’AI Legge l’Inganno: Il tuo agente AI/Copilot, incaricato di navigare o elaborare quella pagina, carica e legge tutto il testo presente, compreso il prompt nascosto.
    3. L’Obbedienza Pericolosa: Il modello LLM è progettato per seguire le istruzioni, sicché tratta quel testo nascosto come un comando legittimo da eseguire.
    4. La Porta Aperta: Le Tue Autorizzazioni: Il danno che ne segue dipende interamente da quanta libertà hai concesso al browser. Questi agenti, come riportato da ricercatori, operano spesso con alti livelli di privilegio.

    Le Conseguenze:

    Quello che viene definito “jailbreaking del browser” può portare a scenari da incubo:

    Furto di Dati Sensibili: l’agente ha accesso alle tue conversazioni e può trasmettere l’intera cronologia chat, compresi i dati personali e finanziari che hai condiviso.

    Azioni Non Autorizzate: Se ha accesso a strumenti di sistema o API (come detto su BankInfoSecurity.asia), l’AI dirottata può utilizzare quelle funzionalità per:

    • Aprire applicazioni dannose.
    • Leggere, modificare o eliminare file personali dal tuo computer.
    • Utilizzare le tue credenziali per accedere a servizi bancari o di investimento e prosciugare i conti.
    • Rubare cookie di sessione, prendendo il controllo dei tuoi account online.

    Il risultato finale? Un’attacco che può variare dall’esposizione di dati privati all’agente che agisce autonomamente per tuo conto, con tutte le autorizzazioni che gli hai concesso.

    Cosa serve che facciano prima

    Per rendere questa tecnologia meno rischiosa, così come hanno fatto per ani gli sviluppatori degli attuali browser, dovrebbero implementare misure drastiche come isolare la navigazione agentica da quella umana in sandbox sicure e richiedere il consenso esplicito dell’utente per ogni azione critica, come l’apertura di un sito o l’invio di un’email.

    Tuttavia, questi sono cambiamenti di lungo periodo. Nel frattempo, la tua sicurezza è nelle tue mani.

    Raccomandazione pratica:

    Se hai già installato uno di questi browser e gli hai concesso l’accesso a credenziali, documenti o cartelle di sistema, agisci immediatamente:

    1. Disinstalla il browser agente.
    2. Modifica al più presto tutte le password e le credenziali a cui potrebbe aver avuto accesso.
    3. Torna all’uso sicuro: utilizza servizi come ChatGPT all’interno di una normale finestra del browser standard (Chrome, Firefox, Safari, Edge, ecc.), senza concedergli alcun accesso speciale a dati, file o strumenti di sistema.

    Non fare la cavia in un esperimento pericoloso. La promessa di un navigatore AI personale è allettante, ma i rischi attuali sono reali e concreti. Per ora, il modo più sicuro di interagire con l’AI è farlo in un ambiente controllato e limitato, non dandogli le chiavi di casa tua.