# Overflow by Mircha Emanuel > Pensieri che traboccano, idee che non stanno in una scatola. Overflow e' il blog personale in italiano di Mircha Emanuel D'Angelo, Software Architect, Full-stack Developer e Tech Lead. Il blog tratta di tecnologia, diritti digitali, intelligenza artificiale, cultura hacker, architettura software e riflessioni sulla complessita' del mondo digitale e non solo. - Lingua: Italiano - Autore: Mircha Emanuel D'Angelo - Blog tecnico (inglese): https://a80.it - Licenza contenuti: CC BY-SA 4.0 ## Informazioni sull'autore Mircha Emanuel D'Angelo e' un Full-stack Developer e Software Architect old-school, hacker nel senso romantico del termine. Attualmente lavora come Technical Solutions Architect & Tech Lead presso Oltrematica Srl, dove guida il team nell'adozione di pratiche di sviluppo moderne e progetta soluzioni scalabili. - Blog tecnico: https://a80.it - GitHub: https://github.com/mirchaemanuel - LinkedIn: https://www.linkedin.com/in/mirchaemanueldangelo/ ## Progetti correlati - [Meta Tags Analyzer](https://metatags.a80.it/): Strumento per analizzare, generare e visualizzare in anteprima i meta tag - [JW Library Merger](https://jwm.a80.it/): Unisce file di annotazioni JW Library con elaborazione locale - [XML Validator](https://xmlval.a80.it/): Validazione XML contro schemi XSD - [AI Jazz Improviser](https://jazz-club.a80.it/): Genera musica jazz in tempo reale con AI - [Moog Modular Synth](https://moog-modular.a80.it/): Sintetizzatore Moog modulare virtuale costruito con Web Audio API --- ## Articoli ### Quel 30% che fa la differenza: cosa studiare oggi per lavorare nell'informatica - URL: https://overflow.a80.it/posts/quel-30-percento-che-fa-la-differenza/ - Data: 2026-02-06 - Tags: ai, carriera, programmazione, formazione, hacker-culture - Descrizione: L'AI genera il 70% del codice, ma è il restante 30% - architettura, sicurezza, pensiero critico - a fare la differenza. Una riflessione su cosa studiare oggi per costruire una carriera nell'informatica, partendo da un Amstrad CPC 464 e arrivando agli agenti AI. *Una riflessione su cosa è cambiato, cosa resta, e cosa consiglierei a chi parte oggi.* --- ## Il mio posto felice Sono nato nel 1982. Il mio primo computer l'ho ricevuto a 5 anni: un Amstrad CPC 464, con quel monitor verde fosforescente e il registratore a cassette integrato. A 3 anni sapevo già leggere e scrivere, e ci misi poco a prendere in mano il manuale del Locomotive BASIC e cominciare a scrivere le mie prime righe di codice. Non avevo idea di cosa fosse una "carriera informatica". Non sapevo che esistesse un'industria del software, non pensavo ai soldi, non pensavo al futuro. Pensavo solo che quello schermo era un posto dove potevo creare qualsiasi cosa. Scrivevi delle parole, premevi RUN, e succedeva qualcosa. Era magia. Era *la mia* magia. Non c'erano molti soldi in casa, e ringrazio ancora tanto i miei genitori per quel regalo. Ero un bambino *estremamente* curioso, di quelli che smontano tutto, che fanno mille domande, che non stanno mai fermi. L'Amstrad fu l'unica cosa capace di placarmi. Mi sedevo davanti a quello schermo e il mondo spariva. Poi un giorno ho scoperto che potevo generare suoni. E che suoni. Il CPC 464 aveva un chip sonoro, l'AY-3-8912, tre canali audio, e io ho iniziato a spremerlo in ogni modo possibile. Frequenze, inviluppi, modulazioni. Passavo ore a creare melodie e effetti sonori con poche righe di BASIC, e poi a cercare di capire come i giochi producevano quei suoni impossibili. La chiptune mi ha affascinato da allora e [continua ad affascinarmi ancora oggi](https://overflow.a80.it/posts/web-audio-api-costruire-un-sintetizzatore-modulare-stile-moog-in-javascript/): fare musica con un computer resta una delle cose più belle che conosca. Nel frattempo gli anni passavano. I miei amici cominciavano a giocare con l'Amiga, con la sua grafica a 4096 colori e quel suono stereo campionato che sembrava venire da un altro pianeta. Io restavo con il mio CPC 464. Ma quella limitazione mi ha spinto a scavare più in profondità. Quando il BASIC non bastava più, sono passato allo Z80 assembly, col MAXAM come assembler. `LD A,&FF`. `CALL &BC77`. `PUSH HL`, `POP DE`, `JP NZ, loop`. Istruzioni che manipolavano direttamente il processore, la memoria, il chip video. Roba che ti faceva sentire di avere il controllo totale della macchina, byte per byte. È stato lo Z80 a farmi scoprire la demoscene. Quelle demo che giravano su hardware identico al mio ma producevano effetti che sembravano impossibili: scroller, rasterbar, plasma, sprite multiplexing. Gente che tirava fuori dal CPC cose che i progettisti stessi non avevano previsto. Per me era la forma più pura di hacking: prendere una macchina, capire ogni suo limite, e poi superarli. Per me la programmazione pura è il mio posto felice. È libertà e controllo allo stesso tempo. È un posto dove non ho paura, perché descrivo e definisco le regole del mio mondo e tutto risponde alla logica. Se qualcosa non funziona, c'è sempre una ragione. Non ci sono ambiguità, non ci sono "dipende", non ci sono interpretazioni. C'è un bug, lo trovi, lo risolvi. C'è una logica che vuoi esprimere, la scrivi, funziona. Questo rapporto con la programmazione ha definito la mia vita. Mi ha dato un mestiere, certo, ma soprattutto mi ha dato un modo di pensare. Mi ha insegnato a scomporre i problemi, a cercare le cause prima degli effetti, a non accontentarmi della prima soluzione che funziona. Mi ha insegnato la pazienza e l'ostinazione. E adesso, dopo quasi quarant'anni, quel rapporto si sta trasformando. Non finendo. Trasformando. ## La domanda che mi fanno tutti "Cosa dovrei studiare per lavorare nell'informatica?" Me lo chiedono spesso. Studenti, persone che vogliono cambiare carriera, genitori che chiedono per i figli. E ogni volta faccio fatica a rispondere, per una ragione che probabilmente non si aspettano. Il problema non è che non ho opinioni. Ne ho fin troppe. Il problema è che per me l'informatica non è mai stata una carriera. È stata una passione che è diventata un lavoro, e questo mi rende probabilmente la persona sbagliata a cui chiedere consigli di carriera. Non riesco a mettermi nei panni di chi guarda questo mondo e vede prima di tutto uno stipendio, una stabilità, un percorso professionale. Non c'è nulla di male in quello sguardo, è perfettamente legittimo, ma io non parto da lì, e quindi i miei consigli sono sempre stati un po' storti. Per anni, il consiglio più sincero che ho dato è stato: insegui una passione. Sii curioso. Sii hacker nel senso vero del termine. Non quello dei film, ma quello di chi smonta le cose per capire come funzionano, di chi non si accontenta di usare uno strumento ma vuole sapere cosa c'è sotto. Leggi il codice degli altri, rompi le cose, ricostruiscile meglio. Era un buon consiglio? Forse sì, forse no. Funzionava per gente come me, gente che avrebbe programmato comunque, anche senza stipendio. Ma per gli altri? Per quelli che volevano semplicemente un buon lavoro in un settore in crescita? Non lo so. Quello che so è che oggi la risposta a quella domanda è cambiata radicalmente. E per la prima volta, sento di poter dare un consiglio che vale per tutti: appassionati e pragmatici. ## L'elefante nella stanza Parliamo dell'AI. Anzi, parliamone seriamente, senza i toni apocalittici e senza l'entusiasmo da comunicato stampa. Forse qualcuno si aspetta che io veda l'intelligenza artificiale come una minaccia. Uno che programma da quando aveva 5 anni, che ha fatto della scrittura del codice il suo posto felice: come può non sentirsi minacciato da una macchina che scrive codice? La verità è che l'ho inseguita fin dal primo momento. Quando sono arrivati i primi modelli linguistici capaci di generare codice, non ho avuto paura. Ho avuto curiosità. La stessa curiosità del bambino davanti all'Amstrad. *Cosa può fare questo? Fin dove può arrivare? Come posso usarlo?* E adesso, dopo mesi di utilizzo intensivo, quotidiano, integrato in ogni aspetto del mio lavoro, sento di avere dei super poteri. Non è un'esagerazione. Cose che prima richiedevano ore ora richiedono minuti. Prototipi che prima richiedevano giorni ora li vedo prendere forma in tempo reale. Ho un collaboratore instancabile che conosce praticamente ogni linguaggio, ogni framework, ogni pattern. Non si lamenta, non ha giornate storte, non si offende se gli chiedo di rifare tutto da capo. Ma, e questo è un "ma" grosso come una casa, non per tutti è così. Vedo colleghi che la odiano. Che la vivono come un affronto personale, come se qualcuno stesse sminuendo il loro lavoro. Vedo persone che la usano male, che copiano e incollano output senza capirli e poi si stupiscono quando le cose si rompono in produzione. E vedo, e questo è il più pericoloso, persone che pensano che ormai non abbia più senso imparare a programmare. Tutte e tre queste reazioni sono sbagliate. Ma la terza è quella che mi preoccupa di più. ## Il problema del 70% C'è un concetto che Addy Osmani, ingegnere di Google e autore di testi fondamentali sullo sviluppo web, ha formulato e che secondo me centra perfettamente il punto. Lo chiama "il problema del 70%". L'idea è questa: l'AI oggi è in grado di generare circa il 70% di una soluzione software. Lo scaffolding, il boilerplate, i pattern comuni, le implementazioni standard, la documentazione di base, i test meccanici. Tutto quello che è prevedibile, ripetitivo, già visto. L'AI lo fa, e lo fa velocemente. Il restante 30% è un'altra storia. Quel 30% è fatto di architettura di sistema: decidere *come* i pezzi si incastrano, non scrivere i singoli pezzi. È fatto di edge case, quei casi limite che nessun modello prevede perché richiedono una comprensione profonda del dominio. È fatto di sicurezza, non la sicurezza da checklist, ma quella che nasce dall'esperienza di aver visto sistemi compromessi e dal sapere dove guardare. È fatto di decisioni che richiedono contesto, intuizione, giudizio. Ed ecco il paradosso che Osmani evidenzia: per gli sviluppatori junior, quel 70% generato dall'AI sembra un miracolo. "Guarda, ho fatto un'applicazione completa in dieci minuti!" Per gli sviluppatori senior, quel 70% è la parte facile. Il vero lavoro è sempre stato nel 30%. E a volte, sistemare il 70% generato dall'AI richiede più tempo che scriverlo da zero. Questo è il punto cruciale che chi vuole entrare nel mondo dell'informatica deve capire: **l'AI non ha eliminato la necessità di competenza. L'ha resa più importante che mai.** ## Il paradosso della conoscenza Questa è forse la cosa più controintuitiva dell'intera faccenda, e quella che dovreste tatuarvi sulla fronte se state pensando di intraprendere una carriera informatica. Più sai, più l'AI ti è utile. Meno sai, più l'AI è pericolosa. Sembra un paradosso, ma provate a pensarci. Quando io chiedo all'AI di generare una funzione di autenticazione, non scrivo "crea una funzione di login". Scrivo qualcosa come: "Implementa un sistema di autenticazione con JWT, refresh token rotation, rate limiting sui tentativi falliti, hashing con bcrypt, logging strutturato per l'audit trail." So cosa chiedere perché so cosa serve. So valutare l'output perché conosco i pattern corretti. So dove l'AI taglierà angoli perché li ho tagliati io stesso in passato e ne ho pagato le conseguenze. Un junior che chiede "crea una funzione di login" otterrà qualcosa che funziona. Tecnicamente. In un ambiente di test. Su un progetto giocattolo. Ma in produzione, con utenti veri, con attaccanti veri, con dati veri? Quello che ottiene è una bomba a orologeria. Non è colpa dell'AI. L'AI ha fatto esattamente quello che gli è stato chiesto. Il problema è che chi ha chiesto non sapeva cosa chiedere. E non sapeva di non saperlo, che è infinitamente peggio. Quindi il primo consiglio, quello fondamentale, quello che viene prima di tutto il resto: **imparate le basi. Veramente.** Non le basi "ho fatto un tutorial su YouTube e ho deployato un'app su Vercel." Le basi vere. Come funziona la memoria. Come funziona una rete. Cos'è un processo, cos'è un thread, cos'è una race condition. Come funziona un database sotto il cofano, non solo come si scrive una query. L'AI non rende queste conoscenze obsolete. Le rende il moltiplicatore di forza più potente che abbiate mai avuto. ## L'evoluzione delle competenze Se dovessi disegnare una mappa delle competenze che contano oggi, quel famoso 30%, la dividerei in due grandi famiglie. La prima è quella delle **competenze che c'erano già ma che ora contano di più**. **Software Architecture.** Progettare sistemi complessi e scalabili. Non sto parlando di scegliere tra microservizi e monolite perché l'ha detto il blog che avete letto stamattina. Sto parlando di capire i trade-off, di sapere perché una scelta architetturale che funziona per Netflix non funziona per la vostra startup con tre utenti, di saper pensare in termini di sistemi distribuiti, di consistenza, di disponibilità. **System Design.** Definire componenti e le loro interazioni. Saper disegnare su una lavagna come i pezzi si parlano. Saper individuare i colli di bottiglia prima che si manifestino. Saper progettare per il fallimento, perché i sistemi *falliranno*, e la differenza la fa quanto siete preparati. **Performance Tuning.** Ottimizzare basandosi su una comprensione profonda di quello che succede realmente, non su superstizioni. Sapere leggere un profiler, capire dove finisce il tempo, distinguere tra un problema di CPU e un problema di I/O. L'AI può suggerire ottimizzazioni, ma non sa cosa *conta* nel vostro specifico contesto. **Security Analysis.** E qui si apre un capitolo enorme. L'AI non introduce solo soluzioni: introduce anche vulnerabilità. Codice generato dall'AI che nessuno ha veramente letto e compreso è codice potenzialmente vulnerabile. Sapere dove guardare, conoscere i pattern di attacco, capire i rischi. Questa competenza non è solo rimasta importante, è diventata critica. La seconda famiglia è quella delle **competenze nuove**, nate dall'interazione con l'AI stessa. **Context Engineering.** Questa è forse la skill più sottovalutata. È la capacità di fornire all'AI il contesto giusto per ottenere output utili. Non è banale. Significa capire come ragiona il modello, cosa gli serve per funzionare bene, come strutturare le informazioni perché le processi nel modo più efficace. È un po' come saper scrivere un buon brief per un designer o una buona specifica per un team di sviluppo, ma con le sue particolarità. **Prompt Design.** Collegato al punto precedente, ma distinto. Formulare richieste precise ed efficaci. Non è "parlare con ChatGPT." È capire che la qualità dell'input determina la qualità dell'output in modo diretto e spesso spietato. È sapere quando essere specifici e quando essere aperti, quando vincolare e quando lasciare libertà. È un'abilità che si sviluppa con la pratica e con la comprensione di come funzionano questi sistemi. **Critical Thinking.** Valutazione critica dell'output AI. Questa è forse la competenza più importante in assoluto. L'AI genera testo e codice con una sicurezza totale, anche quando sbaglia. Produce output che *sembra* corretto, che *suona* corretto, che *ha la forma* di qualcosa di corretto, ma che può essere completamente sbagliato. Saper distinguere, saper dubitare, saper verificare: questa è la meta-competenza che separa chi usa l'AI da chi ne è usato. **Verification.** Processi di validazione sistematica. Non fidarti, verifica. O meglio, come dicevano durante la Guerra Fredda: "trust, but verify." Fìdati dell'AI per il 70% del lavoro meccanico, ma metti in piedi processi sistematici per verificare che quel 70% sia corretto. Test automatizzati, code review, security scanning, monitoring. Più l'AI produce, più hai bisogno di verificare. ## Da artigiano a direttore d'orchestra C'è una metafora che è perfetta per spiegare questo cambiamento: il passaggio da artigiano del codice a direttore d'orchestra. L'artigiano del codice, il mestiere che ho amato per tutta la vita, è quello che prende un problema, apre l'editor, e riga dopo riga costruisce la soluzione. Conosce ogni carattere che ha scritto, ogni decisione che ha preso, ogni compromesso che ha fatto. È un lavoro intimo, preciso, totale. Il direttore d'orchestra non suona nessuno strumento durante il concerto. Ma conosce ogni strumento, sa come dovrebbe suonare ogni sezione, sa quando qualcosa è fuori tempo o fuori tono. Senza di lui, l'orchestra produce rumore. Con lui, produce musica. Il futuro dello sviluppatore è lì. Non scrivi più ogni riga di codice, ma devi sapere come dovrebbe suonare ogni riga. Non implementi più ogni pattern, ma devi riconoscere quando un pattern è sbagliato. Non fai più debug riga per riga, ma devi sapere dove guardare quando qualcosa non funziona. E attenzione: questo non significa "meno lavoro." Significa lavoro diverso. In un certo senso, significa più responsabilità. Perché quando scrivevi tutto tu, il raggio d'azione era limitato dalla tua velocità. Ora che l'AI moltiplica la tua capacità produttiva, il raggio d'azione esplode, e con esso la quantità di cose che possono andare storte se non sai quello che fai. Ogni ingegnere oggi è, in un certo senso, un manager. Non di persone, ma di sistemi AI. E come ogni buon manager, deve saper delegare, saper controllare, saper dare direzione, saper riconoscere quando il lavoro è fatto bene e quando no. ## Quello che non è cambiato (e non cambierà) Fin qui ho parlato di competenze tecniche. Ma c'è un livello più profondo che vorrei toccare, perché è quello che fa davvero la differenza, e che nessun curriculum universitario e nessun bootcamp vi insegnerà. **La curiosità.** Quella del bambino di 5 anni davanti all'Amstrad. Quella che ti fa smontare le cose non perché devi, ma perché *vuoi sapere*. L'AI non la sostituisce. Se non siete curiosi, l'AI è solo un generatore di codice che non capite. Se siete curiosi, l'AI è un portale verso una quantità infinita di cose da esplorare. **La capacità di comprendere oltre i bit.** Il software non esiste nel vuoto. Esiste per risolvere problemi di persone reali. Il codice più elegante del mondo è inutile se risolve il problema sbagliato. Capire il dominio, parlare con gli utenti, comprendere le esigenze: queste sono competenze profondamente umane che l'AI non può e non potrà sostituire. **L'empatia.** Sì, l'empatia. Nel software serve. Serve per progettare interfacce che le persone riescano a usare. Serve per scrivere messaggi di errore che aiutino invece di frustrare. Serve per capire che il collega che ha scritto quel codice orribile non è stupido: aveva fretta, aveva vincoli, aveva informazioni diverse dalle tue. **L'intuizione.** Quella sensazione che qualcosa non va, anche se non sai ancora spiegare cosa. Quell'istinto che ti dice "questa architettura non reggerà" prima di aver fatto i conti. Quell'esperienza accumulata che si manifesta come un sesto senso. L'AI ha la statistica. Noi abbiamo l'intuizione. E spesso, quando la statistica e l'intuizione dicono cose diverse, è l'intuizione che ha ragione. **Lo spirito hacker.** Intendo quello vero: la voglia di capire come funzionano le cose, di trovarsi davanti a un sistema e pensare "e se facessi così?" Non per rompere, anche se a volte rompere è il modo migliore per capire, ma per esplorare, per trovare i limiti, per andare oltre quello che il manuale ti dice che puoi fare. Queste qualità non si studiano su un libro. Si coltivano con la pratica, con l'esperienza, con la volontà di mettersi in gioco. E sono, oggi più che mai, il vero vantaggio competitivo. ## Allora, cosa studiare concretamente? Ok, dopo tutta questa filosofia, proviamo a essere pratici. Se oggi avessi 20 anni e volessi costruire una carriera nell'informatica, cosa farei? **Prima di tutto, le fondamenta.** Computer science vera. Algoritmi e strutture dati, non per superare i colloqui di Google, ma per avere un modello mentale di come i computer risolvono problemi. Sistemi operativi, per capire cosa succede *sotto* il vostro codice. Reti, perché ormai tutto è distribuito e se non capite TCP/IP, HTTP, e le basi della comunicazione tra sistemi, state costruendo su sabbia. Database, non solo SQL, ma i principi: normalizzazione, indici, transazioni, consistenza. Sì, lo so, sembra il programma di un corso universitario degli anni '90. Ed è esattamente il punto. Queste cose non invecchiano. Sono le fondamenta su cui tutto il resto si appoggia, e sono esattamente le conoscenze che vi permetteranno di usare l'AI come un superpotere invece che come una stampella. **Poi, imparate a pensare in termini di sistemi.** Non singole funzioni, non singoli endpoint, ma sistemi. Come si progetta qualcosa che deve servire mille utenti? E centomila? E dieci milioni? Dove metti la cache? Come gestisci i fallimenti? Come fai monitoring? Come fai deploy senza downtime? Queste sono le domande del 30%, e sono le domande che l'AI non sa fare da sola. **Imparate almeno un linguaggio bene. Veramente bene.** Non cinque linguaggi a livello superficiale: uno, a fondo. Capite come gestisce la memoria, come funziona il suo sistema di tipi, quali sono i suoi punti di forza e i suoi limiti. Quando conoscete veramente un linguaggio, imparare gli altri diventa naturale. E quando chiedete all'AI di scrivere codice in quel linguaggio, saprete immediatamente se sta scrivendo roba buona o roba che "funziona ma non è il modo giusto." **Studiate sicurezza.** Non come specializzazione, come competenza di base. OWASP Top 10, principi di autenticazione e autorizzazione, come funziona la crittografia (non come si implementa, quello lo fa l'AI, ma *perché* funziona e *quando* usarla). Ogni riga di codice generata dall'AI che non avete verificato dal punto di vista della sicurezza è un rischio. E i rischi in produzione diventano incidenti, e gli incidenti costano. **Imparate a lavorare con l'AI.** E intendo veramente lavorare, non "chiedere a ChatGPT di scrivermi il compito." Imparate il context engineering: come strutturare le informazioni perché il modello vi dia output utili. Imparate il prompt design: come formulare richieste che producano risultati di qualità. Imparate soprattutto il critical thinking applicato all'AI: come valutare, verificare, integrare quello che l'AI produce. **E infine, ma non per ultimo, coltivate il lato umano.** Imparate a comunicare. Imparate a scrivere (non codice: testo). Imparate a spiegare cose complesse a persone che non sono tecniche. Imparate a lavorare in team, a gestire conflitti, a dare e ricevere feedback. Queste sono le competenze che l'AI non toccherà mai, e sono quelle che faranno la differenza quando sarete al colloquio, in ufficio, o a decidere l'architettura di un sistema con il vostro team. ## Il mio consiglio più onesto Torno al punto da cui sono partito. Ho sempre fatto fatica a dare consigli di carriera perché per me questo mestiere non è una carriera. È una parte di chi sono. Ma oggi, per la prima volta, ho un consiglio che vale per tutti. Appassionati e pragmatici. Sognatori e calcolatori. **Non competete con l'AI. Diventate la persona che la sa usare.** Il 70% del lavoro meccanico, il codice boilerplate, i CRUD, le configurazioni, la documentazione standard, sta diventando commodity. È roba che l'AI fa bene e farà sempre meglio. Investire il vostro tempo per diventare i più veloci a scrivere quel tipo di codice è come allenarsi per correre più veloce di un'automobile. Potete farlo, ma perché? Il 30%, l'architettura, il design, la sicurezza, il pensiero critico, la verifica, la comprensione del dominio, la capacità di fare le domande giuste, quello è il vostro territorio. È lì che il vostro valore cresce, non diminuisce, con l'arrivo dell'AI. È lì che l'esperienza conta. È lì che la curiosità, l'empatia, l'intuizione fanno la differenza. Quel bambino di 5 anni davanti all'Amstrad non sapeva nulla di carriere, di mercato del lavoro, di prospettive economiche. Sapeva solo che voleva capire come funzionava quella macchina e cosa poteva farci. Quarant'anni dopo, con un'intelligenza artificiale come collaboratore quotidiano, la sensazione è la stessa. La curiosità è la stessa. La voglia di esplorare è la stessa. Gli strumenti sono cambiati, enormemente, ma lo spirito no. E quello spirito, alla fine, è l'unica cosa che non potete delegare a nessuna macchina. --- ### La morte dell'interfaccia utente come la conosciamo - URL: https://overflow.a80.it/posts/la-morte-dellinterfaccia-utente-come-la-conosciamo/ - Data: 2026-02-04 - Tags: ai, mcp, saas, interfaccia-utente, agenti-ai, open-source, hacker-culture - Descrizione: Come gli agenti AI e il Model Context Protocol stanno ridefinendo il rapporto tra umani e software, segnando il tramonto del paradigma SaaS e delle interfacce grafiche tradizionali a favore di un'interazione conversazionale basata sul linguaggio naturale. C'è qualcosa di profondamente ironico nella condizione dell'utente digitale nel 2026. Mai nella storia dell'informatica abbiamo avuto accesso a così tanti strumenti, così potenti, così economici. Eppure, chiunque lavori con un computer passa una porzione significativa della propria giornata non a fare cose, ma a navigare tra le cose. Apriamo applicazioni, cerchiamo funzionalità nei menu, compiliamo form, spostiamo dati da un sistema all'altro, impariamo interfacce nuove che sostituiscono quelle vecchie senza un motivo evidente. Il software prometteva di liberarci dal lavoro ripetitivo; invece, ha creato nuove forme di lavoro ripetitivo, travestite da "produttività". Il modello SaaS (Software as a Service) ha democratizzato l'accesso a strumenti che un tempo richiedevano investimenti enormi. Oggi chiunque può avere un CRM, un sistema di project management, una suite di analytics, pagando pochi euro al mese. Ma questa abbondanza ha un costo nascosto: ogni strumento è un mondo a sé, con la propria logica, il proprio vocabolario visivo, le proprie convenzioni. L'utente medio in un'azienda utilizza decine di applicazioni diverse, e ognuna richiede di essere imparata. L'interfaccia utente, nata per rendere il computer accessibile a tutti, è diventata essa stessa una barriera, una tassa cognitiva che paghiamo ogni giorno. E se fosse il momento di chiederci: l'interfaccia grafica come la conosciamo è stata davvero il punto di arrivo, o solo una fase transitoria? E se il prossimo salto nell'interazione uomo-macchina fosse già in corso, silenziosamente, mentre ci ostiniamo a cliccare bottoni progettati negli anni Ottanta? ## Dal terminale al touch, e ritorno Per capire dove stiamo andando, vale la pena ricordare da dove veniamo. La storia dell'interfaccia utente è stata raccontata per decenni come un progresso lineare verso la "naturalezza". Prima c'era la riga di comando, austera e potente, ma riservata agli iniziati che conoscevano la sintassi arcana. Poi arrivò l'interfaccia grafica (finestre, icone, menu, puntatore) e improvvisamente il computer diventò accessibile a chiunque sapesse muovere un mouse. Il Macintosh del 1984, Windows 95, il web con i suoi link cliccabili: ogni passo sembrava avvicinarci a un'interazione più umana, più intuitiva. Il touch screen completò apparentemente questa parabola. Con l'iPhone nel 2007, l'interfaccia diventò letteralmente tattile: niente più intermediari, il dito tocca direttamente l'oggetto digitale. I bambini imparano a usare un tablet prima di saper leggere. Cosa potrebbe esserci di più naturale? Ma ogni passaggio ha comportato dei trade-off che raramente vengono discussi. La GUI ha reso il computer accessibile ai non-tecnici, certo, ma ha anche nascosto la complessità invece di eliminarla. L'utente della riga di comando vedeva esattamente cosa stava succedendo; l'utente della GUI vede metafore (cartelle, cestini, finestre) che lo proteggono dalla realtà sottostante ma anche lo separano da essa. Il touch ha reso tutto "intuitivo" ma ha drammaticamente impoverito le possibilità di input: un dito su uno schermo può fare molto meno di una tastiera, e infatti sui dispositivi mobile siamo tornati a digitare, faticosamente, su tastiere virtuali. La riga di comando non è mai veramente scomparsa. Gli sviluppatori non l'hanno mai abbandonata. Io vivo nel terminale. E c'è una ragione: la CLI è componibile. Piccoli programmi che fanno una cosa sola, collegati da pipe, orchestrati da script. È la filosofia Unix, enunciata da [Doug McIlroy](https://en.wikipedia.org/wiki/Douglas_McIlroy) negli anni Settanta: **"Scrivi programmi che fanno una cosa sola e la fanno bene. Scrivi programmi che lavorano insieme."** Questa filosofia non ha mai trovato un equivalente nel mondo delle GUI. Le applicazioni grafiche sono monoliti che non parlano tra loro se non attraverso integrazioni faticosamente costruite. Ogni SaaS è un'isola. Ed ecco che nel 2026 assistiamo a qualcosa di inaspettato: un ritorno all'interfaccia testuale, ma in una forma radicalmente nuova. Non la sintassi rigida del terminale, ma il linguaggio naturale. Non comandi da memorizzare, ma intenzioni da esprimere. E dietro, non un parser deterministico, ma un modello linguistico che capisce. ## Il paradigma SaaS: trionfo e crisi Prima di esplorare il nuovo, è necessario capire perché il vecchio sta scricchiolando. Il modello SaaS è stato un successo straordinario. Ha eliminato la necessità di installare software, ha abbattuto i costi di distribuzione, ha permesso aggiornamenti continui senza intervento dell'utente. Per le aziende software, ha trasformato vendite una tantum in flussi di ricavi ricorrenti. Per gli utenti, ha reso accessibili strumenti prima riservati alle grandi organizzazioni. Ma il successo del SaaS ha portato con sé patologie strutturali che oggi sono evidenti. La prima è la **frammentazione**. Poiché ogni problema specifico ha generato il suo SaaS dedicato, l'utente si trova a operare in decine di ambienti diversi. I dati sono sparsi ovunque: i contatti nel CRM, i task nel project manager, i documenti nel cloud storage, le conversazioni nella chat aziendale, le email nel client di posta. Strumenti come Zapier o Make sono nati proprio per costruire ponti tra queste isole, ma sono soluzioni fragili, che richiedono manutenzione costante e competenze tecniche non banali. La seconda patologia è il **feature creep**. Un SaaS deve giustificare il suo abbonamento mensile. La risposta universale è aggiungere funzionalità. Slack, nato come semplice chat, è diventato una piattaforma con canvas, workflow, huddle, clip, e decine di integrazioni. Notion, nato come blocco note evoluto, è diventato database, wiki, project manager, sito web. Ogni strumento tende a espandersi fino a coprire territori adiacenti, gonfiando l'interfaccia, moltiplicando i menu, seppellendo le funzioni semplici sotto strati di complessità. La terza patologia è più sottile: l'**inversione del rapporto tra mezzo e fine**. L'utente non vuole "usare Notion", vuole organizzare le proprie idee. Non vuole "navigare Salesforce", vuole capire se un cliente è pronto a comprare. L'interfaccia dovrebbe essere trasparente, un mezzo invisibile verso un risultato. Invece è diventata opaca, una presenza costante che richiede attenzione, apprendimento, manutenzione cognitiva. Questa inversione era forse inevitabile. Un'interfaccia grafica è, per sua natura, un linguaggio imposto. Il designer decide quali azioni sono possibili, dove sono collocate, come si chiamano. L'utente deve imparare quel linguaggio. E poiché ogni applicazione ha designer diversi con idee diverse, l'utente deve imparare decine di linguaggi diversi, spesso incoerenti tra loro. ## L'agente come nuovo paradigma Il cambiamento in corso è radicale, anche se superficialmente può sembrare solo un'evoluzione. Non si tratta di aggiungere un chatbot a un'applicazione esistente, e quello è il modo in cui il vecchio mondo cerca di assorbire il nuovo senza capirlo. Si tratta di ripensare completamente il rapporto tra utente e software. Nel paradigma tradizionale, l'utente compie azioni atomiche attraverso l'interfaccia: clicca un bottone, compila un campo, seleziona un'opzione. Il software esegue quell'azione specifica. Se l'utente vuole ottenere un risultato complesso, deve scomporre mentalmente il risultato in una sequenza di azioni atomiche e compierle una per una, spesso attraverso applicazioni diverse. Nel paradigma emergente, l'utente esprime un'intenzione in linguaggio naturale, e un agente AI si occupa di tradurre quell'intenzione in azioni concrete. L'agente capisce cosa l'utente vuole ottenere, determina quali strumenti sono necessari, li orchestra, gestisce gli errori, e restituisce il risultato. Consideriamo un esempio concreto: _"Prepara un report settimanale per il team sui progressi del progetto Alpha, includendo i task completati, quelli in ritardo, e un grafico del burndown, poi mandalo via email a tutto il team."_ Oggi, questa frase innocente richiede: aprire il project manager, filtrare i task per progetto e settimana, esportare i dati, aprire un foglio di calcolo, creare il grafico, aprire un editor di documenti, formattare il report, tornare al project manager per la lista del team, aprire il client email, comporre il messaggio, allegare il documento, inviare. Venti minuti di lavoro manuale, trenta se qualcosa va storto. Con un agente sufficientemente capace e ben integrato, è una frase. L'agente interroga l'API del project manager, elabora i dati, genera il grafico, compone il documento, recupera gli indirizzi email del team, e invia. L'utente esprime l'intenzione, l'agente gestisce la complessità. Scrivo questo non come osservatore esterno, ma come praticante quotidiano. Le mie giornate lavorative si svolgono in larga parte in finestre di terminale dove conversazioni con agenti AI si alternano a comandi tradizionali. È un'esperienza ibrida, a cavallo tra due mondi: la precisione della CLI classica e la flessibilità del linguaggio naturale. E ciò che colpisce, dopo mesi di questa pratica, è quanto rapidamente il vecchio modo di lavorare (aprire applicazioni, navigare menu, compilare form) inizi a sembrare inefficiente, quasi primitivo. Non perché fosse sbagliato, ma perché ora esiste un'alternativa che si avvicina di più al modo in cui pensiamo. Questo non è fantascienza. Nel 2026, abbiamo strumenti che supportano nativamente decine di integrazioni via MCP, con memory persistente che mantengono il contesto tra sessioni, con capacità di ragionamento che permettono di gestire task multi-step: siamo già dentro questa transizione! ## MCP: il protocollo che abilita la composizione Il [Model Context Protocol, introdotto da Anthropic](https://www.anthropic.com/news/model-context-protocol) e rapidamente adottato come standard de facto, è il tassello tecnico che rende possibile questo nuovo paradigma. Per capirne l'importanza, è utile un'analogia con la storia del web. Negli anni Ottanta, i computer potevano già comunicare in rete, ma ogni sistema usava protocolli diversi. Poi arrivò HTTP, un protocollo semplice e universale: qualsiasi client poteva parlare con qualsiasi server, purché entrambi rispettassero le stesse convenzioni. Questa standardizzazione permise l'esplosione del web. Non importava se usavi un Mac o un PC, Netscape o Internet Explorer: la pagina web era la stessa. MCP fa qualcosa di simile per gli agenti AI. Definisce un modo standard per esporre capability, cose che un servizio sa fare, e per permettere agli agenti di scoprirle e utilizzarle. Un server MCP può esporre l'accesso a un filesystem, a un database, a un'API di terze parti, a qualsiasi risorsa o funzionalità. Un client MCP, tipicamente un agente AI, può connettersi a questi server, scoprire quali capability sono disponibili, e usarle per compiere azioni. L'architettura è elegante nella sua semplicità. Il server MCP dichiara quali "tool" mette a disposizione, con una descrizione in linguaggio naturale di cosa fanno e quali parametri accettano. L'agente AI, quando deve compiere un'azione, può esaminare i tool disponibili, scegliere quello appropriato, invocarlo con i parametri giusti, e interpretare il risultato. Il protocollo gestisce la comunicazione, l'autenticazione, la gestione degli errori. Quello che rende MCP potente non è la singola integrazione, ma la composizione. Un agente connesso a dieci server MCP diversi può combinare le loro capability in modi che nessuno dei singoli servizi aveva previsto. Può leggere dati da un database, elaborarli, scrivere i risultati in un documento, e inviarlo via email, il tutto in un'unica conversazione, orchestrando servizi che non sanno nulla l'uno dell'altro. C'è un'eco della filosofia Unix in tutto questo: **"Scrivi programmi che fanno una cosa sola e la fanno bene. Scrivi programmi che lavorano insieme."** I server MCP sono i nuovi programmi Unix: piccoli, focalizzati, componibili. Ma invece di essere collegati da pipe e orchestrati da script bash, sono collegati da un protocollo standard e orchestrati da un modello linguistico che capisce le intenzioni. ## Il tramonto dei RAG tradizionali Un altro cambiamento tecnico merita attenzione, perché illumina la direzione del paradigma emergente. Fino a pochi mesi fa la soluzione standard per dare agli LLM accesso a conoscenza esterna è stata il RAG (Retrieval-Augmented Generation). L'idea è semplice: prendi i tuoi documenti, spezzettali in chunk, trasformali in vettori numerici (embedding), salvali in un database vettoriale. Quando l'utente fa una domanda, trasforma la domanda in un vettore, cerca i chunk più "simili", e iniettali nel prompt insieme alla domanda. Il modello risponde usando quelle informazioni. Il RAG ha funzionato, e continua a funzionare per certi casi d'uso. Ma i suoi limiti sono diventati sempre più evidenti. Il chunking spezza il contesto: un documento coerente viene tagliato in pezzi che perdono il significato complessivo. Il retrieval è imperfetto: la similarità vettoriale non sempre cattura la rilevanza semantica. L'utente non ha controllo né visibilità su cosa viene recuperato. E l'architettura presuppone che la conoscenza sia statica, indicizzata una volta e poi interrogata, mentre spesso la conoscenza rilevante cambia continuamente o va verificata alla fonte. Nel 2026, diverse evoluzioni tecniche hanno eroso la centralità del RAG. Le finestre di contesto sono enormemente più ampie: modelli che accettano centinaia di migliaia di token possono semplicemente contenere documenti interi invece di recuperarne frammenti. La memory persistente, integrata nativamente anche nei prodotti consumer come Claude, permette di mantenere contesto attraverso conversazioni diverse senza bisogno di infrastrutture esterne. Il tool use maturo permette di interrogare fonti in tempo reale invece di affidarsi a indici potenzialmente obsoleti. Il RAG non scompare, ma cambia ruolo. Da architettura portante, diventa uno strumento tra tanti che l'agente può decidere di usare quando appropriato. Per cercare in un archivio enorme di documenti storici, un indice vettoriale ha ancora senso. Per rispondere a una domanda sui dati del trimestre corrente, meglio interrogare direttamente il database. L'agente, non l'architettura, decide quale approccio usare. Questo riflette un pattern più ampio: nel nuovo paradigma, **le scelte architetturali si spostano dal design-time al run-time**. Non è il progettista del sistema che decide come recuperare l'informazione; è **l'agente che decide**, caso per caso, in base al contesto e all'intenzione dell'utente. ## Cosa resta dell'interfaccia? Se l'interazione primaria con il software diventa conversazionale, mediata da agenti che capiscono il linguaggio naturale, qual è il destino dell'interfaccia grafica? La GUI è destinata a scomparire? La risposta, probabilmente, è più sfumata. L'interfaccia grafica non scompare, ma il suo ruolo cambia. Da *control panel*, il luogo dove l'utente compie azioni, diventa *display*, il luogo dove l'utente visualizza risultati e conferma decisioni. Alcune funzioni dell'interfaccia grafica restano essenziali. La visualizzazione di informazioni complesse (grafici, mappe, tabelle, diagrammi) beneficia enormemente della rappresentazione visiva. Nessuna descrizione testuale sostituisce un grafico ben fatto per cogliere un trend. L'agente può generare la visualizzazione, ma l'interfaccia deve mostrarla. La conferma di azioni critiche è un altro ambito dove l'interfaccia mantiene un ruolo. Vogliamo davvero che un agente cancelli file, invii email importanti, o modifichi dati sensibili senza un passaggio esplicito di conferma? Un bottone "Conferma" o "Annulla" può sembrare primitivo, ma è un checkpoint di sicurezza essenziale. L'esplorazione senza una domanda precisa è un terzo caso. A volte non sappiamo cosa cercare. Vogliamo navigare, farci un'idea, scoprire cosa c'è. Un'interfaccia navigabile permette la serendipità; una conversazione richiede di sapere già cosa chiedere. Infine, c'è la questione dell'accessibilità. Non tutti possono o vogliono interagire tramite testo. Difficoltà linguistiche, disabilità cognitive, preferenze personali: un'interfaccia visiva con elementi cliccabili resta più accessibile per molti utenti. Ma il baricentro si sposta. L'interfaccia grafica diventa un complemento dell'interazione conversazionale, non il canale primario. L'utente parla con l'agente per dire cosa vuole; l'interfaccia mostra i risultati e permette interventi puntuali. È un'inversione rispetto al modello attuale, dove l'interfaccia è primaria e l'eventuale assistente AI è un add-on. ## La prospettiva hacker: liberazione o nuova dipendenza? ![Agenti AI: il nuovo paradigma di interazione](/images/agenti-ai-nuovo-paradigma-interazione.webp) Per chi è cresciuto nella cultura hacker, per chi ha letto il [Jargon File](http://www.catb.org/jargon/html/) e i saggi di Raymond, per chi considera la libertà del software un valore fondante, questo nuovo paradigma presenta una tensione profonda. Da un lato, c'è qualcosa di genuinamente liberatorio. Per decenni, l'utente non-tecnico è stato prigioniero delle interfacce che altri avevano progettato per lui. Non poteva modificarle, non poteva estenderle, spesso non poteva nemmeno capirle veramente. Doveva adattare il suo modo di pensare al linguaggio del software. Ora, per la prima volta, il rapporto può invertirsi: è il software che si adatta al linguaggio dell'utente. Chiunque sappia esprimere un'intenzione può comandare una macchina complessa. È una democratizzazione del potere computazionale che avrebbe fatto sorridere Engelbart. MCP è un protocollo aperto. La specifica è pubblica, le implementazioni sono disponibili, chiunque può costruire server e client. C'è un ecosistema vivace di integrazioni open source. La filosofia Unix della composizione, che sembrava persa nel mondo dei monoliti SaaS, torna in una forma nuova. Ma dall'altro lato, le preoccupazioni sono serie. Chi controlla l'agente? Nel modello SaaS, almeno, i dati risiedevano su server specifici, le interfacce erano ispezionabili, i flussi di lavoro erano prevedibili. Nel modello ad agenti, ogni intenzione passa attraverso un modello linguistico. Se quel modello è proprietario, se è un servizio di Anthropic, OpenAI, Google, la dipendenza è totale e opaca. Richard Stallman ha sempre insistito sulla differenza tra "software libero" e "software gratuito". Il software libero è quello di cui puoi studiare il codice, modificarlo, ridistribuirlo. Garantisce libertà, non solo prezzo. Ma gli LLM più capaci non sono software libero in nessun senso significativo. Anche i modelli "open weight" (quelli di cui vengono rilasciati i pesi) non sono veramente open source: non puoi riaddestrarli senza risorse enormi, non puoi sapere esattamente cosa hanno imparato e da dove, non puoi modificarli in modo significativo. ![Il ciclo di enshittification delle piattaforme secondo Cory Doctorow](/images/enshittification-ciclo-piattaforme.webp) Cory Doctorow ha coniato il termine *enshittification* per descrivere il ciclo inevitabile delle piattaforme: prima attraggono gli utenti con valore genuino, poi estraggono valore dagli utenti per darlo ai business partner, infine estraggono valore da tutti per massimizzare il profitto, finché la piattaforma diventa inutilizzabile e collassa. Se gli agenti AI diventano il layer universale di interazione con il software, cosa impedisce lo stesso ciclo? La trasparenza è un'altra preoccupazione cruciale. Quando clicco un bottone in un'interfaccia, so cosa sto facendo, o almeno posso saperlo, se voglio ispezionare. Quando chiedo a un agente di fare qualcosa, quali azioni compie realmente? Quali dati legge? A quali servizi li trasmette? L'opacità del ragionamento degli LLM si estende all'opacità delle azioni. ![Bruce Schneier e il concetto di trust nei sistemi tecnologici](/images/bruce-schneier-trust-sistemi-tecnologici.webp) Bruce Schneier parla di *trust* nei sistemi tecnologici: di chi ci fidiamo, perché, e cosa succede quando quella fiducia viene tradita. Affidarsi a un agente AI significa fidarsi dell'azienda che lo sviluppa, della sua infrastruttura, delle sue policy, delle sue decisioni future. È una fiducia molto concentrata. ## Scenari futuri e domande aperte È impossibile prevedere con certezza come evolverà questo paradigma. Ma possiamo immaginare scenari alternativi e chiederci quali condizioni li renderebbero più o meno probabili. Lo **scenario ottimista** vede l'emergere di un ecosistema aperto e competitivo. MCP e protocolli simili diventano standard consolidati, adottati universalmente. Modelli open source raggiungono capacità competitive con quelli proprietari, permettendo a chiunque di controllare il proprio agente. I server MCP proliferano, offrendo integrazioni con ogni servizio immaginabile. L'utente può scegliere quale modello usare, quali capability abilitare, dove risiedono i suoi dati. Il software diventa davvero componibile e personalizzabile come mai prima. Gli hacker costruiscono configurazioni elaborate di agenti e strumenti, condividendole come un tempo condividevano dotfiles e script. Lo **scenario pessimista** vede la concentrazione del potere in pochi gatekeeper. Due o tre aziende controllano gli agenti dominanti, perché addestrare modelli competitivi richiede risorse che solo loro possono permettersi. Ogni interazione con il software è mediata, registrata, analizzata, monetizzata. Le integrazioni MCP esistono, ma quelle davvero utili richiedono abbonamenti premium. I modelli open source restano sempre un passo indietro, sufficienti per sperimentare ma non per lavorare seriamente. L'interfaccia conversazionale diventa il nuovo walled garden, più insidioso perché più "naturale": non sembrano muri, sembra solo una conversazione con un assistente gentile. Lo scenario più probabile, forse, è una **via di mezzo**. Agenti proprietari domineranno il mercato consumer, dove la facilità d'uso e l'integrazione sono priorità. Ma nel mondo enterprise, nella comunità tecnica, tra chi ha competenze e motivazioni per costruire alternative, emergeranno soluzioni ibride. Modelli locali per compiti sensibili, agenti self-hosted per organizzazioni che non vogliono dipendere da cloud esterni, ecosistemi di strumenti open source per chi è disposto a investire tempo in cambio di controllo. Restano domande aperte che richiederanno risposte negli anni a venire. Come garantire trasparenza nelle decisioni dell'agente? Un log delle azioni compiute è sufficiente, o serve qualcosa di più? Come preservare la privacy quando ogni intenzione passa per un modello che potrebbe essere addestrato sui dati degli utenti? Come evitare che "non saper parlare con l'AI" diventi la nuova forma di analfabetismo digitale, escludendo chi fatica a esprimersi in modo chiaro e strutturato? Come regolare un paradigma dove le azioni sono mediate da sistemi che nessuno capisce completamente? ## Un viaggio che ricomincia Circa 38 anni fa (sic! fa strano scriverlo), davanti a un Amstrad CPC464 con il suo monitor a fosfori verdi, imparavo a dialogare con una macchina. Non c'erano icone da cliccare, non c'erano finestre da trascinare: c'era un cursore lampeggiante e la necessità di sapere cosa scrivere. Ogni comando era una piccola conquista, ogni errore di sintassi una lezione. Poi vennero le BBS, le notti passate a esplorare mondi testuali attraverso un modem gracchiante, e infine [Metro Olografix](www.olografix.org), la scoperta che dietro quei terminali c'era una comunità, una cultura, un modo di pensare il rapporto tra umani e macchine. La GUI, quando arrivò, era promettente ma anche sospetta: semplificava, certo, ma a quale prezzo? Nascondeva, ma cosa? Oggi siamo a un passaggio simile, forse più profondo. L'interfaccia grafica non muore (nulla muore davvero nel software, i layer si accumulano) ma cambia ruolo, si ritira sullo sfondo, cede il centro della scena a qualcosa di nuovo. L'interazione conversazionale, mediata da agenti che capiscono e agiscono, promette di liberarci dalla tirannia delle interfacce imposte. Ma ogni liberazione porta nuove dipendenze, ogni democratizzazione nasconde nuove concentrazioni di potere. Il Model Context Protocol è aperto. Gli agenti possono essere self-hosted. Le alternative esistono, per chi le cerca. Ma la direzione di default, quella che seguirà chi non sceglie consapevolmente, porta verso pochi grandi fornitori che mediano ogni interazione con il digitale. La domanda non è se questo futuro arriverà: sta già arrivando. La domanda è chi lo costruirà, secondo quali valori, con quali salvaguardie. È una domanda tecnica, ma anche politica, etica, sociale. È la domanda che la cultura hacker si pone da sempre, ogni volta che una nuova tecnologia ridefinisce il rapporto tra umani e macchine. La risposta, come sempre, dipenderà da chi si farà carico di darla. --- ### Piracy Shield e la guerra all'architettura di Internet - URL: https://overflow.a80.it/posts/piracy-shield-e-la-guerra-allarchitettura-di-internet/ - Data: 2026-01-18 - Tags: piracy-shield, cloudflare, agcom, censura-internet, diritti-digitali, metro-olografix, net-neutrality, dns-blocking, aaron-swartz, john-perry-barlow, internet-libera, copyright, hacker-culture - Descrizione: L'Italia multa Cloudflare per 14 milioni di euro sul Piracy Shield. Perché bloccare IP e DNS non ferma la pirateria ma danneggia l'architettura globale di Internet e i diritti digitali. L'Italia ha inflitto a Cloudflare una multa da 14 milioni di euro per aver rifiutato di bloccare siti pirata entro 30 minuti, innescando uno scontro che rivela le profonde contraddizioni tra legislazioni nazionali e la natura globale della rete. Il CEO Matthew Prince ha definito il sistema italiano "disgustoso" e minacciato di ritirare le protezioni cyber dalle Olimpiadi 2026. Ma oltre le polemiche, questa vicenda solleva questioni fondamentali che i pionieri della rete libera avevano previsto decenni fa: **cosa succede quando lo Stato cerca di controllare un'infrastruttura che non riconosce confini?** Il Piracy Shield, nato nel 2023 per combattere lo streaming illegale delle partite di Serie A, è diventato il simbolo perfetto di una legge mal concepita. Non difende la pirateria chi critica questo sistema (io): difende i principi architetturali che hanno reso Internet lo strumento di progresso più democratico della storia umana. ![Piracy Shield: blocco DNS e IP in Italia](/images/piracy_shield.webp) __Di seguito voglio esprimere un'analisi tecnica e non politica della vicenda.__ ## La multa che ha scatenato la polemica Il 29 dicembre 2025, l'AGCom ha approvato una sanzione di €14.247.698,56 contro Cloudflare, circa l'1% del fatturato globale dell'azienda. L'accusa: non aver ottemperato all'ordine 49/25/CONS di febbraio 2025, che richiedeva il blocco di oltre 15.000 domini e indirizzi IP segnalati come fonti di contenuti pirata. La commissaria Elisa Giomi è stata l'unica a votare contro. La [risposta di Matthew Prince su X il 9 gennaio 2026](https://x.com/eastdakota/status/2009654937303896492) non ha lasciato spazio a diplomazie: > "Ieri un organo quasi-giudiziario in Italia ha multato Cloudflare di 17 milioni di dollari per non essersi piegata al loro schema di censura di Internet. Lo schema, che perfino l'UE ha definito preoccupante, ci richiedeva di censurare completamente da Internet qualsiasi sito che una cabala oscura di élite mediatiche europee ritenesse contrario ai propri interessi." Prince ha poi minacciato di ritirare i servizi gratuiti di cybersecurity per le Olimpiadi Milano-Cortina 2026 e di rimuovere tutti i server da Roma e Milano. _"Play stupid games, win stupid prizes"_, ha concluso. ## Come funziona il Piracy Shield e perché fallisce tecnicamente (e non solo) Il sistema opera con una semplicità brutale: i titolari dei diritti (Serie A, DAZN, Sky) segnalano domini e IP sulla piattaforma AGCom, e tutti i provider italiani, ISP, VPN, resolver DNS pubblici, devono implementare il blocco entro 30 minuti. **Nessuna verifica giudiziaria preventiva, nessun contraddittorio.** Vale la pena soffermarsi su questo punto, perché è il cuore del problema. Soggetti privati (non magistrati, non forze dell'ordine, non autorità giudiziarie) possono inserire **qualsiasi indirizzo IP o nome a dominio in una piattaforma, e nel giro di trenta minuti quella risorsa deve diventare inaccessibile su tutto il territorio nazionale**. Nessun giudice valuta la fondatezza della segnalazione. Nessun tecnico verifica se quell'IP ospita anche altri servizi. Nessuno avvisa il proprietario del sito. Nessuno può opporsi prima del blocco. In uno stato di diritto, il sequestro di un bene richiede l'intervento di un magistrato. Qui parliamo di rendere inaccessibili risorse digitali, potenzialmente critiche per aziende, scuole, ospedali, sulla base della segnalazione unilaterale di un privato con interessi economici diretti. Dalla sua attivazione nel febbraio 2024, il Piracy Shield ha bloccato oltre 65.000 domini e 14.000 indirizzi IP. E già questo dovrebbe far capire che c'è qualcosa che non quadra. Ma i numeri nascondono una verità tecnica scomoda: il sistema non può distinguere tra risorse "univocamente" utilizzate per la pirateria e infrastrutture condivise. Non sono mancati blocchi errati di servizi legittimi, come CDN, piattaforme cloud e persino siti governativi. Il 19 ottobre 2024, Google Drive è stato bloccato per oltre 12 ore in tutta Italia durante Juventus-Lazio, dopo che DAZN aveva segnalato erroneamente il dominio drive.usercontent.google.com come fonte di streaming illegale. Milioni di italiani non hanno potuto lavorare o accedere ai propri file. Già a febbraio 2024, un singolo IP di Cloudflare (188.114.97.7) era stato bloccato, rendendo inaccessibili decine di migliaia di siti legittimi: scuole, aziende, servizi di ticketing. L'AGCom inizialmente [definì le segnalazioni "fake news"](https://torrentfreak.com/agcom-admits-piracy-shield-blunder-cloudflare-urges-users-to-complain-240321/), per poi ammettere "criticità operative". Uno studio [RIPE Labs di Antonio Prado del 29 settembre 2025](https://labs.ripe.net/author/antonio-prado/live-event-blocking-at-scale-effectiveness-vs-collateral-damage-in-italys-piracy-shield/) ha documentato 6.712 domini completamente bloccati come danno collaterale, con oltre 500 siti legittimi confermati resi inaccessibili senza alcuna connessione con la pirateria. In un caso paradossale, è [stato bloccato persino un IP di Google utilizzato da Telecom Italia](https://datatracker.ietf.org/meeting/124/materials/slides-124-iabopen-piracy-shield-talk-00) per servire le pagine di blocco del Piracy Shield stesso: il sistema ha censurato la propria infrastruttura. (LOL!!) ## Bloccare IP e DNS è come bombardare una città per catturare un criminale L'architettura di Internet è incompatibile con il blocco chirurgico che il Piracy Shield presuppone. Come ha spiegato [Cloudflare](https://blog.cloudflare.com/consequences-of-ip-blocking/): _"Bloccare l'accesso a un indirizzo IP è come bloccare la consegna di tutta la posta a un indirizzo fisico... Se quell'indirizzo è un grattacielo con molti occupanti indipendenti e non correlati, fermare le consegne causa inevitabilmente danni collaterali a tutti."_ I CDN (Content Delivery Networks) come Cloudflare, Akamai e Fastly sono l'infrastruttura invisibile che rende possibile l'Internet moderno. Gestiscono la distribuzione dei contenuti, la protezione DDoS e la sicurezza di milioni di siti attraverso indirizzi IP condivisi. Un singolo IP può ospitare **migliaia** di siti completamente indipendenti: blog personali, piccole imprese, enti governativi, organizzazioni umanitarie. La ricerca mostra che meno di 10 milioni di IP servono oltre 255 milioni di domini: un rapporto di circa 24:1 in Europa. Meno di 10 IP possono raggiungere il 20% dei domini globali. Bloccare un IP significa potenzialmente bloccare centinaia o migliaia di siti innocenti. Il resolver DNS 1.1.1.1 di Cloudflare gestisce circa 200 miliardi di query giornaliere. Filtrarlo per l'Italia, come richiesto dall'AGCom, sarebbe secondo l'azienda "impossibile" senza degradare il servizio per utenti di tutto il mondo. **E comunque inefficace**: gli utenti possono aggirare qualsiasi blocco DNS semplicemente cambiando resolver o usando una VPN. ## I precedenti internazionali che l'Italia ha ignorato La storia recente offre lezioni che l'Italia ha scelto di non apprendere. Nel 2018, [la Russia ha tentato di bloccare Telegram](https://www.theguardian.com/world/2018/apr/17/russia-blocks-millions-of-ip-addresses-in-battle-against-telegram-app) ordinando l'oscuramento degli IP utilizzati dal servizio di messaggistica. Risultato: 18-19 milioni di indirizzi IP bloccati, appartenenti ad Amazon Web Services, Google Cloud, Microsoft Azure. YouTube, Spotify, Slack, servizi bancari e biglietterie aeree sono stati resi inaccessibili. Il 97% delle risorse bloccate erano danni collaterali. Telegram ha continuato a funzionare per la maggior parte degli utenti. Il blocco è stato revocato nel 2020 dopo aver dimostrato la propria inutilità. La [Turchia ha bloccato Wikipedia](https://en.wikipedia.org/wiki/Censorship_of_Wikipedia) per quasi tre anni (2017-2020) per un articolo sul terrorismo di stato. La Corte Costituzionale turca ha infine dichiarato il blocco incostituzionale, una violazione della libertà di espressione. Negli Stati Uniti, [le proposte SOPA e PIPA del 2011-2012](https://www.eff.org/issues/coica-internet-censorship-and-copyright-bill), che avrebbero introdotto meccanismi simili al Piracy Shield, sono state affossate dopo una rivolta senza precedenti. Vint Cerf, co-inventore dei protocolli Internet, avvertì che avrebbero creato "una corsa agli armamenti mondiale di censura del Web senza precedenti". Tim Berners-Lee, inventore del World Wide Web, le definì _"una grave minaccia all'apertura di Internet"_. Wikipedia si oscurò per protesta, raccogliendo 162 milioni di visualizzazioni. La Casa Bianca dichiarò che non avrebbe sostenuto _"legislazioni che riducono la libertà di espressione, aumentano i rischi di cybersecurity o minano l'Internet dinamica e innovativa"_. La [Commissione Europea ha inviato nel giugno 2025 una lettera formale all'Italia](https://www.compliancehub.wiki/piracy-shield-is-now-fully-functional-in-italy-controversial-anti-piracy-system-expands-beyond-sports/) sollevando preoccupazioni sul rispetto del Digital Services Act, sulla mancanza di supervisione giudiziaria, e sulla violazione potenziale della Carta dei Diritti Fondamentali. ## L'appello di Metro Olografix e la comunità Hacker Italiana [Metro Olografix](https://www.olografix.org), la più antica associazione culturale telematica italiana fondata a Pescara nel 1994, ha lanciato un appello urgente per la sospensione immediata del Piracy Shield. L'associazione rappresenta tre decenni di cultura hacker italiana. ![Metro Olografix BBS](/images/metro_olografix-bbs.webp) Il [nostro manifesto](https://piracy-shield.olografix.org/) identifica sei criticità fondamentali: il sistema "mina principi fondamentali dello stato di diritto" come proporzionalità e presunzione d'innocenza; viola la neutralità della rete permettendo blocchi "al di fuori del sistema giudiziario"; compromette la privacy richiedendo "un monitoraggio invasivo del traffico"; limita l'accesso all'informazione; impone oneri sproporzionati alle piccole imprese digitali; e non prevede "alcun tipo di risarcimento" per i danni da blocchi errati. L'appello è stato sottoscritto da ninux.org (rete mesh comunitaria), sikurezza.org, Freaknet Medialab, Hermes Center for Transparency and Digital Human Rights, Etica Digitale, l'Osservatorio Nessuno e numerosi esperti individuali. Chiediamo una revisione completa basata su studi indipendenti, un dibattito pubblico sulla regolamentazione di Internet, e **"approcci alternativi che bilancino efficacemente la protezione del copyright con i diritti degli utenti"**. ## Le voci dei pionieri che avevano previsto tutto (sigh) ![John Perry Barlow](/images/john-perry-barlow-cc.webp) Nel 1996, John Perry Barlow scrisse da Davos la sua ["Dichiarazione d'Indipendenza del Cyberspazio"](https://www.eff.org/cyberspace-independence) in risposta al Communications Decency Act americano: > "Governi del Mondo Industriale, stanchi giganti di carne e acciaio, io vengo dal Cyberspazio, la nuova casa della Mente. A nome del futuro, chiedo a voi del passato di lasciarci in pace. Non siete benvenuti tra noi. Non avete sovranità dove ci riuniamo." Barlow co-fondò la Electronic Frontier Foundation e previde esattamente questo conflitto: > "In Cina, Germania, Francia, Russia, Singapore, Italia e Stati Uniti, state cercando di respingere il virus della libertà erigendo posti di guardia alle frontiere del Cyberspazio. Potranno tenere fuori il contagio per poco tempo, ma non funzioneranno in un mondo che presto sarà coperto di media portatori di bit." Aaron Swartz, nel suo [Guerilla Open Access Manifesto](https://ia800101.us.archive.org/1/items/GuerillaOpenAccessManifesto/Goamjuly2008.pdf) del 2008, scrisse parole che risuonano oggi: > "Non c'è giustizia nel seguire leggi ingiuste. È tempo di uscire alla luce e, nella grande tradizione della disobbedienza civile, dichiarare la nostra opposizione." Nel 2012, combattendo contro SOPA, disse: > "Se perdessimo la capacità di comunicare tra noi via Internet, sarebbe un cambiamento al Bill of Rights." ![Aaron Swartz](/images/aaron-swartz.webp) **L'11 gennaio 2026 sono 11 anni che Aaron Swartz ci ha lasciati.** La sua lotta per un Internet libero e aperto continua a ispirarci. Lawrence Lessig, professore a Harvard e fondatore di Creative Commons, ha cristallizzato il problema in tre parole: ["Code is law"](https://lessig.org/images/resources/1999-Code.pdf). L'architettura dei sistemi determina cosa è possibile, non solo cosa è permesso: > "Possiamo costruire il cyberspazio per proteggere i valori che riteniamo fondamentali, o possiamo costruirlo per farli scomparire. Non esiste via di mezzo." Cory Doctorow, attivista EFF, ha coniato il termine **"enshittification"** per descrivere il degrado delle piattaforme e osserva: > "Ogni volta che qualcuno mette un lucchetto su qualcosa che possiedi contro la tua volontà, e non ti dà la chiave, non lo sta facendo per il tuo beneficio." ## Il vero costo di un internet frammentato L'Internet Society, nel suo rapporto 2025 sul blocco DNS obbligatorio, conclude: _"Il blocco DNS obbligatorio può sembrare una soluzione tecnica semplice per far rispettare le politiche pubbliche, ma in pratica è uno strumento grossolano, costoso e persino controproducente."_ L'ICANN avverte che tali blocchi _"saranno probabilmente largamente inefficaci nel lungo termine e pieni di conseguenze impreviste"._ Il problema non è proteggere il copyright. Il problema è utilizzare strumenti incompatibili con l'architettura fondamentale di Internet per raggiungerlo. È come cercare di regolare il traffico aereo con leggi pensate per le carrozze a cavalli (neanche per le automobili). La vera domanda che l'Italia dovrebbe porsi non è come bloccare più efficacemente, ma **come incentivare l'accesso legale ai contenuti**. Gli studi mostrano che dove esistono alternative accessibili e convenienti, la pirateria diminuisce. Il successo di Netflix, Spotify e simili dimostra che gli utenti sono disposti a pagare per contenuti convenienti. Il fallimento del Piracy Shield, facilmente aggirato con VPN e DNS alternativi, dimostra che la repressione tecnologica è una battaglia persa in partenza. ## Verso un Internet che rispetti sia i diritti che l'architettura Internet non è un semplice "canale di intrattenimento", come ricorda il manifesto di Metro Olografix, ma **"una risorsa fondamentale per lo sviluppo economico, sociale e culturale della nostra società"**. I principi di decentralizzazione e neutralità che l'hanno resa tale non sono bug da correggere, ma feature da preservare. La sfida per legislatori e regolatori è trovare approcci che rispettino contemporaneamente i diritti degli autori e l'integrità tecnica della rete, due obiettivi che non sono in contraddizione, ma richiedono strumenti più sofisticati del blocco indiscriminato. Come ha scritto Vint Cerf: "Gestire il modo in cui un gran numero di framework legali separati si applica a Internet è una delle grandi sfide politiche del nostro tempo. Più complessa della costruzione di Internet stessa." Il Piracy Shield rappresenta l'approccio sbagliato: veloce da implementare, soddisfacente politicamente, ma **tecnicamente fallimentare e pericoloso per i diritti fondamentali**. La multa a Cloudflare non risolverà la pirateria. ## L'illusione del controllo costruita sull'ignoranza Lo scontro tra AGCom e Cloudflare non è una disputa commerciale tra un'autorità e un'azienda. È il sintomo di una tensione irrisolta tra la logica territorialista e la natura intrinsecamente globale dell'infrastruttura digitale. Come scrisse Barlow nella dichiarazione citata prima: "Creeremo una civiltà della Mente nel Cyberspazio. Possa essere più umana e giusta del mondo che i vostri governi hanno costruito prima." L'Italia può scegliere di continuare su questa strada, multa dopo multa, blocco dopo blocco, accumulando danni collaterali, alienando infrastrutture critiche, facendo una pessima figura internazionale e non fermando comunque la pirateria. Oppure può ascoltare le voci degli esperti, delle organizzazioni per i diritti digitali, e della stessa Commissione Europea, cercando soluzioni che bilancino efficacemente tutela del copyright e libertà digitali. Il Piracy Shield non è una soluzione: è un'illusione di controllo costruita sull'ignoranza dell'architettura che pretende di governare. --- ### Il Nanocourier: quando la cellula ha il suo servizio di consegna espresso - URL: https://overflow.a80.it/posts/il-nanocourier-quando-la-cellula-ha-il-suo-servizio-di-consegna-espresso/ - Data: 2026-01-18 - Tags: scienza, biologia, riflessioni - Descrizione: Scoperto il nanocourier cellulare: una nanomacchina che orchestra il trasporto di pacchetti molecolari. Riflessioni sulla complessità della vita. Un team internazionale di ricercatori ha appena svelato una delle nanomacchine più affascinanti mai osservate: il **nanocourier cellulare**, o più tecnicamente **ExHOS** (Exocyst Higher-Order Structure). ![Il nanocourier ExHOS - struttura 3D](/images/nanocourier.webp) ## La scoperta Il gruppo di ricerca guidato da Oriol Gallego della Pompeu Fabra University di Barcellona, insieme a collaboratori dell'Universitat de Vic, dell'Instituto Biofisika e dei Max Perutz Labs, ha risolto per la prima volta la struttura dinamica di questa minuscola macchina molecolare. Studiando il lievito *Saccharomyces cerevisiae*, i ricercatori sono riusciti a visualizzare e registrare in video il funzionamento di questo "corriere espresso" cellulare, qualcosa che fino ad oggi era rimasto invisibile. ## Come funziona L'ExHOS è responsabile dell'**esocitosi costitutiva**: il processo continuo attraverso cui le cellule trasportano vescicole sferiche (piccoli pacchetti molecolari) verso la superficie cellulare. Qualche numero per capire la portata: - Ogni cellula del nostro corpo trasporta tra **10.000 e 100.000 pacchetti molecolari al giorno** - Il nanocourier opera a meno di **45 nanometri** dalla membrana plasmatica - La struttura è composta da **sette complessi proteici** che formano un anello flessibile La nanomacchina integra tre checkpoint funzionali e un meccanismo di disassemblaggio che garantisce che le consegne continuino alla velocità richiesta. Un sistema logistico perfetto, in scala molecolare. ## A cosa serve Questo processo è fondamentale per: - La secrezione di enzimi e ormoni - La riparazione delle lesioni sulla superficie cellulare - La crescita, il movimento e il cambiamento di forma delle cellule - La comunicazione con l'esterno della cellula Quando qualcosa va storto nel nanocourier, le conseguenze sono serie: mutazioni in questo sistema causano malattie rare neurosviluppative. E non solo: virus come SARS-CoV-2, HIV e batteri come Salmonella sfruttano questo meccanismo per i loro scopi. Anche la diffusione metastatica dei tumori coinvolge l'ExHOS. ## La tecnologia dietro la scoperta Per "vedere" questa struttura, i ricercatori hanno dovuto combinare: - Microscopia ottica avanzata - Microscopia elettronica - Intelligenza artificiale per l'analisi delle immagini Solo l'integrazione di queste tecnologie ha permesso di risolvere la struttura 3D e, per la prima volta, registrare il cambiamento strutturale del nanocourier mentre trasporta le vescicole. ## Frutto di un progetto, o del caso? Quando avevo sei anni, i miei genitori mi regalarono un microscopio. Uno di quei microscopi per bambini, niente di sofisticato. Ricordo ancora la prima volta che osservai la buccia di una cipolla: le cellule disposte ordinatamente come mattoni, con i loro nuclei ben visibili. Un mini universo che si svelava davanti ai miei occhi. Da allora, ogni volta che la scienza svela un nuovo livello di complessità nel mondo microscopico, provo la stessa meraviglia. Quel bambino vedeva cellule e nuclei. Oggi, con tecnologie che combinano microscopia avanzata e intelligenza artificiale, vediamo nanomacchine con checkpoint di controllo qualità integrati, sistemi logistici che operano a 45 nanometri dalla membrana, strutture che si assemblano e disassemblano con precisione cronometrica. E più la scienza avanza, più la domanda diventa ineludibile: **tutto questo è frutto del caso o di un progetto?**. Chi mi conosce, sa già la mia risposta. Ma al di là delle convinzioni personali, c'è un dato oggettivo: ogni nuova scoperta aggiunge complessità alla complessità. E la domanda, lungi dal diventare obsoleta, si fa sempre più pressante. --- ## Fonti - Puig-Tintó, M., Meek, S. et al. "Continuum architecture dynamics of vesicle tethering in exocytosis" - *Cell* (2026) - [DOI: 10.1016/j.cell.2025.11.038](https://www.cell.com/cell/fulltext/S0092-8674(25)01374-1) - [Phys.org - Revealing the cell's nanocourier at work](https://phys.org/news/2026-01-revealing-cell-nanocourier.html) - [GEN - Tiny Nanocourier that Delivers Molecular Packages to Cell Surface Unveiled](https://www.genengnews.com/topics/translational-medicine/tiny-nanocourier-that-delivers-molecular-packages-to-cell-surface-unveiled/) --- ### Web Audio API: Costruire un Sintetizzatore Modulare stile Moog in JavaScript - URL: https://overflow.a80.it/posts/web-audio-api-costruire-un-sintetizzatore-modulare-stile-moog-in-javascript/ - Data: 2026-01-18 - Tags: javascript, audio, sintetizzatore, tutorial, web-audio-api - Descrizione: Un'immersione profonda nelle Web Audio API attraverso la costruzione di un sintetizzatore modulare ispirato al leggendario Moog. Dagli oscillatori ai filtri, dagli inviluppi agli effetti. > **Nota:** Questo articolo è la traduzione italiana del post originale in inglese pubblicato su [a80.it](https://a80.it/blog/web-audio-api-building-a-moog-style-modular-synthesizer-in-javascript). Le **Web Audio API** sono una delle funzionalità più potenti e sottoutilizzate dei browser moderni. Permettono di creare, manipolare e analizzare l'audio in tempo reale usando JavaScript puro, senza plugin. Per dimostrare il pieno potenziale di queste API, ho costruito un [sintetizzatore modulare virtuale ispirato al Moog](https://moog-modular.a80.it): uno strumento completamente funzionante con 3 oscillatori, un filtro ladder risonante, inviluppi ADSR, due LFO ed effetti. Tutto in un singolo file HTML senza dipendenze. Repository Github: [https://github.com/mirchaemanuel/moog-modular/](https://github.com/mirchaemanuel/moog-modular/) ![Moog Modular Synthesizer](/images/moog-modular-full.webp) ## La Leggenda: Robert Moog e la Nascita del Sintetizzatore Prima di tuffarci nel codice, vale la pena capire **perché** il sintetizzatore Moog è così importante. Nel 1964, **Robert Moog** introdusse il primo sintetizzatore a controllo di tensione disponibile commercialmente. A differenza degli strumenti elettronici precedenti, il design di Moog era **modulare**: componenti separati (oscillatori, filtri, amplificatori, generatori di inviluppo) potevano essere collegati tramite cavi patch in qualsiasi configurazione, permettendo ai musicisti di scolpire suoni completamente nuovi. Le innovazioni chiave che resero il Moog rivoluzionario: - **Oscillatori a Controllo di Tensione (VCO)**: Generano forme d'onda (dente di sega, quadra, triangolare, sinusoidale) a frequenze determinate dalla tensione in ingresso - **Filtro a Controllo di Tensione (VCF)**: Il leggendario "filtro ladder Moog", un passa-basso a 24dB/ottava con risonanza che definisce il suono Moog - **Amplificatore a Controllo di Tensione (VCA)**: Controlla il volume in base alla tensione in ingresso - **Generatori di Inviluppo**: Modellano come i parametri cambiano nel tempo usando curve Attack-Decay-Sustain-Release (ADSR) - **Oscillatori a Bassa Frequenza (LFO)**: Oscillatori lenti che modulano altri parametri per vibrato, tremolo e sweep di filtro Questa architettura divenne il modello per praticamente ogni sintetizzatore successivo. Le Web Audio API, sorprendentemente, forniscono equivalenti nativi per tutti questi blocchi costruttivi. ## Architettura Web Audio: Nodi e Grafo Audio Le Web Audio API rispecchiano il concetto di sintetizzatore modulare. Tutto è un **nodo** connesso in un **grafo audio**. Il segnale fluisce dai nodi sorgente attraverso i nodi di elaborazione fino a una destinazione (i tuoi altoparlanti). ```javascript const audioCtx = new (window.AudioContext || window.webkitAudioContext)(); ``` I browser moderni bloccano l'autoplay audio. L'AudioContext deve essere creato o ripreso **dopo un'interazione dell'utente**: ```javascript function noteOn(note) { if (!audioCtx) { audioCtx = new AudioContext(); initAudioGraph(); } // Crea e avvia la voce... } ``` ## Oscillatori: La Sorgente Sonora Un **OscillatorNode** genera forme d'onda periodiche, la materia prima della sintesi. Nella mia emulazione Moog, tre VCO lavorano insieme: ```javascript const osc = audioCtx.createOscillator(); osc.type = 'sawtooth'; // 'sine', 'square', 'triangle', 'sawtooth' osc.frequency.value = 440; // A4 = 440 Hz // Il detuning crea il classico suono "grasso" analogico osc.detune.value = 7; // cents (centesimi di semitono) osc.connect(destination); osc.start(); ``` La magia della sintesi sottrattiva sta nel combinare più oscillatori con leggero detuning e forme d'onda diverse. Nella mia implementazione: - **VCO 1**: Dente di sega, pitch base - **VCO 2**: Onda quadra, +7 cents di detune - **VCO 3**: Triangolare, un'ottava sotto Questo crea una ricchezza armonica che un singolo oscillatore non può ottenere. ## Il Filtro Ladder Moog Il **BiquadFilterNode** emula il cuore del suono Moog: un filtro passa-basso risonante: ```javascript const filter = audioCtx.createBiquadFilter(); filter.type = 'lowpass'; filter.frequency.value = 2000; // Frequenza di taglio filter.Q.value = 10; // Risonanza (fattore Q) ``` Il **parametro Q** (fattore di qualità) crea quel distintivo suono "gorgogliante" quando alzato. A valori estremi, il filtro auto-oscilla, una tecnica usata per bass drop e lead stridenti. ### Keyboard Tracking I veri sintetizzatori Moog hanno il **keyboard tracking**: la frequenza di taglio del filtro segue la nota suonata così le note più alte suonano più brillanti: ```javascript const kbdTrackAmount = state.filter.kbdTrack / 100; const freqRatio = frequency / 261.63; // C4 come riferimento const kbdCutoffMod = Math.pow(freqRatio, kbdTrackAmount); voice.filter.frequency.value = baseCutoff * kbdCutoffMod; ``` ## Generatori di Inviluppo: Modellare il Suono nel Tempo Il **GainNode** implementa gli inviluppi ADSR, il contorno che modella come un suono evolve: ```javascript const vca = audioCtx.createGain(); vca.gain.value = 0; const now = audioCtx.currentTime; const attackTime = 0.01; // 10ms const decayTime = 0.2; // 200ms const sustainLevel = 0.7; // 70% // Attack: rampa al picco vca.gain.linearRampToValueAtTime(1.0, now + attackTime); // Decay: scende al livello di sustain vca.gain.linearRampToValueAtTime(sustainLevel, now + attackTime + decayTime); ``` L'**inviluppo del filtro** funziona identicamente ma modula `filter.frequency`: ```javascript const filterEnvAmount = 0.6; // 60% const targetCutoff = baseCutoff + (20000 - baseCutoff) * filterEnvAmount; filter.frequency.linearRampToValueAtTime(targetCutoff, now + attackTime); filter.frequency.linearRampToValueAtTime(baseCutoff, now + attackTime + decayTime); ``` Questo crea i classici suoni "pluck" e "sweep" che definiscono la sintesi analogica. ![Oscilloscopio che mostra la forma d'onda](/images/moog-scope-active.webp) ## Modulazione LFO: Dare Vita al Suono Gli **Oscillatori a Bassa Frequenza** creano movimento ed espressione. Non producono suono udibile ma modulano altri parametri: ```javascript const lfo = audioCtx.createOscillator(); lfo.frequency.value = 5; // 5 Hz = vibrato sottile const lfoGain = audioCtx.createGain(); lfoGain.gain.value = 50; // Profondità in cents lfo.connect(lfoGain); lfoGain.connect(osc.detune); // Vibrato! lfo.start(); ``` La tecnica chiave: instradare l'LFO attraverso un **GainNode** che controlla la profondità di modulazione. Questo permette regolazioni fluide in tempo reale. Nella mia implementazione, ogni LFO può mirare a: - **Pitch**: Effetto vibrato - **Filtro**: Classico sweep di filtro (suono "wah") - **Ampiezza**: Effetto tremolo - **Larghezza d'impulso**: Sintesi PWM ## Effetti: Delay e Riverbero ### Feedback Delay Un delay con feedback crea echi che decadono nel tempo: ```javascript const delayNode = audioCtx.createDelay(2); // Max 2 secondi delayNode.delayTime.value = 0.35; const feedback = audioCtx.createGain(); feedback.gain.value = 0.4; // 40% di feedback // Crea loop di feedback input.connect(delayNode); delayNode.connect(feedback); feedback.connect(delayNode); // Il segnale ritorna! delayNode.connect(output); ``` ### Riverbero a Convoluzione Il **ConvolverNode** applica una risposta all'impulso per acustiche realistiche. Invece di caricare file audio, genero l'impulso proceduralmente: ```javascript const reverb = audioCtx.createConvolver(); const length = audioCtx.sampleRate * 2; // 2 secondi const impulse = audioCtx.createBuffer(2, length, audioCtx.sampleRate); for (let ch = 0; ch < 2; ch++) { const data = impulse.getChannelData(ch); for (let i = 0; i < length; i++) { // Rumore bianco con decadimento quadratico data[i] = (Math.random() * 2 - 1) * Math.pow(1 - i / length, 2); } } reverb.buffer = impulse; ``` ## Visualizzazione in Tempo Reale: L'Oscilloscopio L'**AnalyserNode** fornisce dati sulla forma d'onda in tempo reale per la visualizzazione: ```javascript const analyser = audioCtx.createAnalyser(); analyser.fftSize = 2048; function draw() { requestAnimationFrame(draw); const dataArray = new Uint8Array(analyser.frequencyBinCount); analyser.getByteTimeDomainData(dataArray); ctx.clearRect(0, 0, width, height); ctx.strokeStyle = '#00ff00'; ctx.beginPath(); for (let i = 0; i < dataArray.length; i++) { const y = (dataArray[i] / 128.0 - 1) * height / 2 + height / 2; ctx.lineTo(i * (width / dataArray.length), y); } ctx.stroke(); } draw(); ``` ## Gestione Voci Polifoniche Per suonare accordi, ogni nota crea una catena di segnale completa: ```javascript const voices = new Map(); function noteOn(note) { const frequency = 440 * Math.pow(2, (note - 69) / 12); const voice = { oscs: [createOsc(frequency), createOsc(frequency), createOsc(frequency)], filter: createFilter(), vca: createVCA() }; connectVoice(voice); triggerEnvelopes(voice); voices.set(note, voice); } function noteOff(note) { const voice = voices.get(note); if (voice) { triggerRelease(voice); // Rimuovi dopo il completamento del release setTimeout(() => voices.delete(note), releaseTime); } } ``` ## Aggiornamenti Fluidi dei Parametri Quando regoli i parametri mentre le note suonano, usa `setTargetAtTime` per evitare click: ```javascript // Male: causa click audio filter.frequency.value = newCutoff; // Bene: transizione esponenziale fluida filter.frequency.setTargetAtTime(newCutoff, audioCtx.currentTime, 0.02); ``` Il terzo parametro (0.02) è la costante di tempo: quanto velocemente approcciare il valore target. ## Portamento (Glide) Tecnica classica dei sintetizzatori dove il pitch scivola tra le note: ```javascript if (glideTime > 0 && lastFrequency) { osc.frequency.setValueAtTime(lastFrequency, audioCtx.currentTime); osc.frequency.linearRampToValueAtTime(newFrequency, audioCtx.currentTime + glideTime / 1000); } else { osc.frequency.value = newFrequency; } lastFrequency = newFrequency; ``` ## Confronto Reale vs. Virtuale | Caratteristica | Moog Originale | Versione Web Audio | |----------------|----------------|-------------------| | Oscillatori | VCO analogici con drift | OscillatorNode digitale (stabile) | | Filtro | Ladder 24dB (4 poli) | BiquadFilter 12dB (2 poli) | | Patching | Cavi fisici | Connessioni JavaScript | | Inviluppi | Curve di tensione | linearRampToValueAtTime | | Rumore | Sorgente rumore analogica | Playback buffer random | | Latenza | ~0ms | 10-50ms (dipende dal browser) | L'implementazione Web Audio non può replicare perfettamente il calore e l'imprevedibilità analogica, ma cattura l'**architettura** e il **comportamento** in modo sorprendente. ## Cosa C'è Dentro Le Web Audio API forniscono tutto il necessario per costruire strumenti di qualità professionale nel browser. Con ~3.000 righe di JavaScript vanilla, il [sintetizzatore Moog Modular](https://moog-modular.a80.it) include: - Tre oscillatori con multiple forme d'onda e detuning - Filtro passa-basso risonante con keyboard tracking - Doppio inviluppo ADSR per filtro e ampiezza - Due LFO con multiple destinazioni di modulazione - Effetti delay e riverbero - Visualizzazione oscilloscopio in tempo reale - Gestione voci polifoniche - Sistema di preset e sequenze demo Il codice sorgente è un singolo file HTML: niente tool di build, niente dipendenze, solo browser e creatività. (Aggiornamento: in seguito ho rifattorizzato il progetto in una struttura modulare per renderlo più facile da mantenere ed espandere.) Provalo tu stesso su [moog-modular.a80.it](https://moog-modular.a80.it). Usa la tastiera del computer (tasti A-L) o clicca sui tasti virtuali per suonare. --- ### Benvenuto su Overflow - URL: https://overflow.a80.it/posts/benvenuto-su-overflow/ - Data: 2026-01-18 - Tags: meta - Descrizione: Overflow è un blog in italiano di pensieri sparsi, riflessioni e ragionamenti random di Mircha Emanuel D'Angelo. Niente struttura, niente calendario — solo overflow. Un blog in italiano di pensieri sparsi e ragionamenti random che mi frullano per la testa. Qui troverai riflessioni, idee, e ogni tanto qualche contenuto dal mio [blog tecnico](https://a80.it) tradotto in italiano. Niente struttura, niente calendario. Solo overflow. ---