Sette app in pochi giorni

A inizio ottobre uno sviluppatore di Atlanta, Brandon Thomas, ha pubblicato ArtCraft: sette applicazioni open source che rifanno Photoshop, Lightroom, Illustrator, Premiere e le altre della suite Adobe. Scritte in Rust, con Claude Opus 5.5, rilasciate con licenza MIT o Apache 2.0. Qualche giorno dopo sono arrivati anche i cloni di Word, Excel e PowerPoint.

In otto giorni i repository hanno superato le 42.000 stelle su GitHub. Il clone di Photoshop da solo ne aveva più di 23.000, insieme a 447 issue aperte.

La reazione è stata quella che vi immaginate. Sui social e su Reddit si legge che il software proprietario è finito, che Adobe ha i giorni contati, che finalmente l’open source si riprende quello che le Big Tech gli hanno preso. Uno dei fondatori di ArtCraft l’ha chiamato una specie di karma cosmico. Intanto tra i repository più in tendenza su GitHub è finito uno strumento che promette di far smontare a un agente qualsiasi applicazione.

Capisco l’entusiasmo. Chi ha pagato per anni un abbonamento Adobe, con penali di disdetta e il cloud obbligatorio, ha più di un motivo per godersi il momento. Però da tech lead, e da persona che il software lo costruisce per i clienti, sento il bisogno di frenare un attimo. Ci sono due domande che in questo coro non sento fare.

L’open source vive se qualcuno ci investe

Sia chiaro: l’open source è uno dei motori di innovazione più potenti che abbiamo. Linux, PostgreSQL, Kubernetes, gran parte dello stack su cui lavoro ogni giorno. Nessuno di noi tornerebbe indietro.

Ma questi progetti non sono nati dal nulla e non stanno in piedi da soli. Dietro Linux ci sono aziende che pagano migliaia di sviluppatori. Dietro Kubernetes c’è stato Google, e poi una fondazione finanziata da chi su Kubernetes ci guadagna. L’open source che dura è quasi sempre quello attorno a cui qualcuno ha costruito un modello economico.

Quando quel modello si rompe, succede quello che abbiamo visto con Elastic, Redis, HashiCorp. Aziende che avevano scelto l’open source hanno cambiato licenza, perché altri prendevano il loro lavoro e lo rivendevano senza restituire nulla. Ogni volta la comunità si è indignata. Ogni volta il problema era lo stesso: chi investe deve poter recuperare l’investimento.

C’è poi l’altro lato, quello di chi il software lo adotta. Un’azienda che sceglie uno strumento non compra solo funzionalità. Compra la ragionevole certezza che tra tre anni esisterà ancora, che le vulnerabilità verranno corrette, che i file di oggi si apriranno domani, che ci sarà qualcuno da chiamare quando qualcosa si rompe.

Un clone in alpha con centinaia di issue aperte e un team di quattro persone non offre niente di tutto questo. Può diventarlo, e glielo auguro. Ma oggi è un prototipo impressionante, non un’alternativa su cui un’azienda può basare il proprio lavoro. Chi lo confonde con una sostituzione pronta all’uso fa lo stesso errore di chi giudica un progetto dalla demo.

Se copiare costa una settimana, chi paga la ricerca?

La seconda domanda mi preoccupa di più. Photoshop non è diventato Photoshop in una settimana. Dietro ci sono più di trent’anni di tentativi, funzioni nate e abbandonate, migliaia di conversazioni con fotografi e designer per capire cosa serviva davvero. Quel lavoro è la parte costosa. Scrivere il codice, a un certo punto, è stato il meno.

Il reverse engineering, anche nella versione “clean-room” che ArtCraft rivendica, parte dal comportamento osservabile. Copia la risposta. Non rifà il percorso che ha portato a quella risposta, e non saprebbe rifarlo per la prossima.

Ora provate a mettervi nei panni di chi decide un budget di ricerca e sviluppo. Se una qualunque innovazione visibile può essere replicata in pochi giorni da un piccolo team con un modello, il ritorno di quell’investimento si accorcia drasticamente. La conseguenza razionale è investire meno, o chiudersi di più: brevetti, codice offuscato, funzioni spostate sul server dove nessuno le può osservare. Non a caso ad aprile Airbus ha annunciato l’acquisizione di un’azienda specializzata proprio nel proteggere il software dal reverse engineering fatto con l’AI.

Qui c’è un paradosso che i più entusiasti non vedono. I cloni copiano lo stato dell’arte di oggi. Se smettiamo di finanziare chi lo spinge avanti, tra cinque anni avremo ottimi cloni di software fermo al 2026. Il copiatore vive del lavoro dell’innovatore. Senza l’innovatore resta poco da copiare.

E vale la pena notare un dettaglio: nemmeno ArtCraft è beneficenza. Le app sono gratuite, ma il progetto si finanzia vendendo l’accesso al proprio modello di generazione di immagini, integrato nelle app stesse. L’open source, qui, è un canale di distribuzione. Legittimo, ma è un modello di business come gli altri.

Quello che non si copia guardando lo schermo

Non credo però che la ricerca sparisca. Credo che si sposti. Se le funzionalità visibili diventano facili da replicare, il valore si concentra su ciò che dall’esterno non si vede.

• La conoscenza del dominio. Sapere perché un fotografo lavora in un certo modo vale più dello strumento che lo asseconda.
• I dati e l’integrazione. Un prodotto inserito nei processi di un cliente, collegato ai suoi sistemi, non si sostituisce clonando l’interfaccia.
• L’affidabilità nel tempo. Aggiornamenti, sicurezza, compatibilità, supporto. Tutto quello che un’azienda compra quando sceglie un fornitore.
• La relazione. Chi conosce il cliente sa cosa costruire dopo. Il clone sa solo cosa è già stato costruito.

Il vantaggio competitivo basato sulle feature si sta comprimendo. Quello basato sulla fiducia e sulla continuità, secondo me, vale ogni giorno di più.

Cosa ne faccio io, da tech lead

Nel mio lavoro questa storia si traduce in due abitudini.

La prima riguarda le scelte tecnologiche. Quando il team propone uno strumento open source, la domanda non è “è gratis?” e nemmeno “funziona?”. È: chi lo manterrà tra tre anni, e con quali soldi? Se la risposta è “quattro persone entusiaste e tante stelle su GitHub”, ci va un piano B.

La seconda riguarda il valore di quello che facciamo per i clienti. Se un’interfaccia si può rifare in un pomeriggio con un modello, il nostro valore non è mai stato l’interfaccia. È capire il problema, mantenere il sistema, farlo evolvere quando il contesto cambia. È lo stesso discorso che faccio da mesi sul software generato con l’AI: scriverlo è diventato facile, tenerlo in piedi no.

L’open source resta una delle cose migliori che il nostro settore abbia prodotto. Proprio per questo merita più di un applauso ogni volta che qualcuno clona un prodotto famoso. Merita la domanda scomoda su chi pagherà la prossima idea, quella che oggi ancora nessuno può copiare.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Da qualche giorno, almeno secondo la Casa Bianca, l’intelligenza artificiale non esiste più. Al suo posto c’è la Superintelligenza, sigla SI. Nessun salto tecnologico, nessun nuovo modello: è cambiato solo il nome.

Cosa è successo

Il 22 settembre, all’Assemblea Generale dell’ONU, Trump ha annunciato che i documenti del governo USA useranno “super” al posto di “artificiale”, perché quest’ultima parola farebbe sembrare la tecnologia finta. Il nome è stato scelto con una serie di sondaggi su Truth Social, tra Superior, Extreme e Supreme Intelligence. Il messaggio finale: chi vince la SI, vince. E gli Stati Uniti, a suo dire, sono molto avanti rispetto alla Cina.

Piccolo problema: “superintelligenza” significa già un’altra cosa. Nella ricerca indica un’intelligenza che supera quella umana in quasi ogni compito: il traguardo, non il punto di partenza. Chiamare così il chatbot che ci riassume le email vuol dire dichiarare raggiunto qualcosa che nessuno ha ancora raggiunto.

È marketing, e pure fatto bene

“Artificiale” suona come surrogato. “Super” suona come primo della classe. Non è una questione di precisione, è posizionamento: lo stesso schema del Golfo del Messico diventato Golfo d’America. Rinominare per rivendicare. L’AI è di tutti; la SI, nella narrazione, è americana. Il messaggio non è per gli ingegneri, ma per investitori, elettori e concorrenti.

Con un’ironia: anche “artificial intelligence” negli anni ’50 fu una scelta di comunicazione, pensata per suonare ambiziosa e attirare fondi. Siamo solo passati da un’etichetta ambiziosa a una ancora più ambiziosa.

Perché interessa a chi fa software

Le parole spostano le aspettative, e le aspettative qualcuno le deve gestire. Se già oggi ci sentiamo dire “l’ho fatto con l’AI in cinque minuti”, figuriamoci con la superintelligenza. Il nome non migliora l’output, non riduce gli errori, non scrive i test. Alza solo l’asticella. E il divario tra promessa e realtà, nei progetti, lo colmiamo noi.

Quindi no, non è finita l’era della AI. È finita, forse, l’era del nome. Quando la superintelligenza arriverà davvero ce ne accorgeremo, e non servirà un sondaggio sui social per deciderlo.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Abbiamo passato decenni a costruire macchine che lavorassero al posto nostro. Adesso che ci riescono, ci lamentiamo che lo fanno meglio di noi.

Non è una novità. La lavatrice doveva liberarci dal bucato, il foglio di calcolo dai conti a mano, il compilatore dall’assembly. Ogni volta abbiamo festeggiato il tempo guadagnato e, allo stesso tempo, rimpianto qualcosa che non sapevamo di tenere così tanto.

Con l’intelligenza artificiale però il rimpianto ha un sapore diverso. Non ci sta togliendo la fatica: ci sta mettendo davanti a uno specchio.

In questi giorni ho visto il video di un ragazzo che raccontava la sua tesi. Sei mesi di lavoro: studiare gli algoritmi, fare i calcoli, scrivere il codice, disegnare i grafici. Il percorso classico, fatto bene.

Sei mesi contro tre ore

Poi, per curiosità, ha dato l’introduzione della tesi a ChatGPT. In tre ore ne è uscita una tesi completa. E, a detta sua, migliore della sua.

La cosa che mi ha colpito non è il risultato. È la sua faccia mentre lo raccontava. Non c’era entusiasmo per lo strumento, c’era una domanda: allora a cosa sono serviti quei sei mesi?

È una domanda legittima. Ma credo sia posta male.

Non è solo una questione di codice

Lo stesso schema lo vedo nella robotica. Per anni abbiamo detto che i robot avrebbero fatto i lavori pesanti, ripetitivi, pericolosi. Quelli che nessuno voleva fare.

Oggi un braccio robotico assembla con una precisione che nessun operaio può mantenere per otto ore. Un robot di magazzino non si stanca e non sbaglia scaffale. E invece di dire “finalmente”, diciamo “ci rubano il lavoro”.

Volevamo macchine brave. Le abbiamo avute. Solo che le immaginavamo brave fino a un certo punto: abbastanza da aiutarci, non abbastanza da superarci.

Cosa ci dà fastidio, davvero

Non ci dà fastidio che la macchina lavori. Ci dà fastidio che il suo lavoro renda visibile quanto valeva il nostro, misurato solo sul prodotto finale.

Per anni abbiamo confuso lo sforzo con il valore. Sei mesi di tesi sembravano valere di più di tre ore perché erano costati di più. Ma il costo non è mai stato il punto.

Quello che il ragazzo ha costruito in sei mesi non è la tesi. È la capacità di capire se una tesi è buona. Senza quei sei mesi non saprebbe dire che quella di ChatGPT è migliore. Non saprebbe nemmeno dove controllare se ha sbagliato un calcolo.

L’AI produce l’artefatto. Il giudizio su quell’artefatto resta a chi ha fatto la strada lunga almeno una volta.

E per chi guida un team?

Lo vivo anche io, nei progetti con i clienti. Sempre più spesso sento dire “quella cosa l’ho fatta con Claude in pochi minuti”. E la prima reazione, lo ammetto, è sentirsi sminuiti.

Poi mi ricordo di cosa viene dopo quei pochi minuti. Qualcuno deve capire se il codice regge, se è sicuro, se si potrà mantenere tra due anni. Qualcuno deve dire di no a una soluzione che funziona oggi e crolla domani.

Per un tech lead questo cambia tre cose:

• Smettere di misurare le persone sulle ore. Se il valore era lo sforzo, l’AI lo ha azzerato. Se il valore è il giudizio, è appena diventato più prezioso.
• Proteggere la strada lunga per i junior. Chi non ha mai fatto un calcolo a mano non saprà riconoscere quando la macchina sbaglia.
• Usare l’AI come acceleratore, non come alibi. Si usa, si verifica, si capisce. Sempre.

Forse va bene così

Non siamo mai contenti. Quando le macchine non sapevano fare niente, ci lamentavamo che erano stupide. Ora che sanno fare molto, ci lamentiamo che sono troppo brave.

Forse l’insoddisfazione non è un difetto. È il segnale che stiamo cercando il nostro posto in un mondo che cambia più in fretta di noi.

Quei sei mesi non sono stati buttati. Sono il motivo per cui quel ragazzo, oggi, sa riconoscere una buona tesi quando la vede. Anche se non l’ha scritta lui.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Ti è mai capitato di stare in una riunione e sentire frasi come “l’agente usa MCP per chiamare i tool, ma la context window è piena e il modello allucina”? Tutti annuiscono. Tu annuisci. Poi torni alla scrivania e cerchi su Google.

Tranquillo, non sei solo. Il mondo dell’intelligenza artificiale corre veloce e si porta dietro un vocabolario tutto suo, fatto di inglesismi e sigle. La buona notizia è che dietro quasi ogni parola c’è un concetto semplice. Vediamoli insieme, senza formule e senza ansia.

Le fondamenta

Modello

È il “cervello” dell’AI: un enorme file pieno di numeri che, messi insieme, sanno fare una cosa, per esempio scrivere testo, riconoscere immagini o tradurre. Quando senti “è uscito un nuovo modello”, è come dire che è uscita una nuova versione di quel cervello, di solito più brava della precedente.

LLM (Large Language Model)

Un modello linguistico di grandi dimensioni. È il tipo di AI che sta dietro a Claude, ChatGPT, Gemini e simili. Ha “letto” una quantità enorme di testi e ha imparato come si costruiscono le frasi, i ragionamenti, il codice. Il suo mestiere, in fondo, è uno solo: prevedere quale parola viene dopo. Solo che lo fa così bene da sembrare che capisca.

Parametri

Sono i numeri dentro il modello, le “manopole” che si regolano durante l’apprendimento. Quando leggi “un modello da 70 miliardi di parametri”, pensa a 70 miliardi di manopole. Più parametri di solito significa più capacità, ma anche più costi per farlo funzionare.

Addestramento (training)

È la fase in cui il modello impara. Gli si mostrano miliardi di esempi e lui aggiusta le sue manopole finché non diventa bravo. È un processo lunghissimo e costosissimo, che avviene una volta sola (o quasi) prima che il modello arrivi nelle nostre mani.

Inferenza

Se l’addestramento è andare a scuola, l’inferenza è il giorno dell’esame. È il momento in cui il modello, già addestrato, usa quello che sa per rispondere a te. Ogni volta che scrivi una domanda a un chatbot e ricevi una risposta, quella è inferenza. Quando le aziende parlano di “costi di inferenza”, parlano di quanto costa far rispondere il modello a milioni di persone.

Parlare con il modello

Prompt

È semplicemente quello che scrivi all’AI: la domanda, la richiesta, le istruzioni. Il cosiddetto prompt engineering è l’arte di scrivere richieste chiare. Spoiler: funziona come con i colleghi. Più contesto dai, migliore è il risultato.

Token

L’AI non legge parole intere, ma pezzetti di parole chiamati token. “Incredibile” potrebbe diventare “In”, “cred”, “ibile”. I token sono l’unità di misura di tutto: si paga a token, si misura la lunghezza a token, i limiti sono in token. Pensali come le monete del mondo AI.

Finestra di contesto (context window)

È la “memoria a breve termine” del modello: quanta roba riesce a tenere in mente contemporaneamente durante una conversazione. Si misura in token. Se la conversazione diventa troppo lunga e supera la finestra, il modello inizia a “dimenticare” le cose dette all’inizio. Come quando al telefono ti dettano un numero troppo lungo.

Allucinazione

Quando l’AI si inventa qualcosa con assoluta sicurezza: una citazione mai detta, un libro mai scritto, una funzione che non esiste. Non lo fa per cattiveria. Ricordi che il suo mestiere è prevedere la parola successiva? A volte la previsione più “plausibile” non è quella vera. Per questo le risposte importanti vanno sempre verificate.

Temperatura

Una manopola che regola quanto l’AI è creativa o prevedibile. Temperatura bassa: risposte precise, sempre simili, ottime per dati e codice. Temperatura alta: risposte più fantasiose e variabili, utili per brainstorming e scrittura creativa.

Multimodale

Un modello che non capisce solo il testo, ma anche immagini, audio, documenti o video. Puoi fotografare uno scontrino e chiedergli di dividere il conto: quello è multimodale.

Dal chiacchierare al fare

Tool (strumenti)

Da solo, un modello sa solo scrivere. Ma se gli dai degli strumenti, come la possibilità di cercare sul web, leggere un file, fare un calcolo o mandare una mail, può agire nel mondo. Il tool use è proprio questo: il modello decide quale strumento usare e quando.

Agente

Qui arriva la parola del momento. Un agente è un’AI a cui non chiedi una singola risposta, ma un obiettivo. “Trovami tre fornitori, confronta i prezzi e preparami una tabella.” L’agente ragiona, pianifica i passi, usa gli strumenti, controlla i risultati e va avanti finché non ha finito. La differenza con un chatbot? Il chatbot ti dice come si fa. L’agente lo fa.

Harness

Letteralmente vuol dire “imbracatura”, come i finimenti di un cavallo. Ed è un’ottima immagine: il modello è il cavallo, forte ma senza direzione. L’harness è tutto quello che gli sta intorno e lo rende utile: le istruzioni di sistema, gli strumenti a disposizione, la gestione della memoria, i controlli, il ciclo “pensa, agisci, verifica”. Lo stesso modello dentro due harness diversi può comportarsi in modo molto diverso. Per questo, oggi, costruire un buon harness conta quasi quanto avere un buon modello.

MCP (Model Context Protocol)

Una specie di presa universale per l’AI. Prima, collegare un modello a Gmail, a un database o a un gestionale richiedeva ogni volta un lavoro su misura. MCP è uno standard aperto che definisce un modo comune per farlo: chi crea un servizio espone un “connettore” MCP, e qualsiasi AI compatibile può usarlo. Pensa alla USB: una porta, mille dispositivi.

Guardrail

Sono i “guardrail” proprio come in autostrada: regole e controlli che impediscono all’AI di uscire di strada. Evitano che dia risposte pericolose, che esegua azioni non autorizzate o che parli di cose che non le competono.

Come si rende un modello più bravo

Fine-tuning

Prendi un modello già addestrato e gli fai fare un “corso di specializzazione” su un tema preciso, con dati tuoi. È come assumere un laureato brillante e formarlo sulle procedure della tua azienda.

RAG (Retrieval-Augmented Generation)

Nome complicato, idea semplicissima: prima di rispondere, l’AI va a cercare le informazioni giuste in una raccolta di documenti (i manuali aziendali, le FAQ, i contratti) e poi risponde basandosi su quelli. È l’esame “a libro aperto”. Riduce le allucinazioni e permette all’AI di conoscere cose che non ha mai visto durante l’addestramento.

Embedding

Il modo in cui l’AI trasforma parole e frasi in coordinate numeriche, come punti su una mappa. Concetti simili finiscono vicini: “gatto” sta vicino a “felino”, lontano da “trattore”. È la tecnologia che rende possibile il RAG e la ricerca “per significato” invece che per parola esatta.

Ragionamento (reasoning)

Alcuni modelli, prima di rispondere, “pensano ad alta voce” dentro di sé: scompongono il problema, provano strade diverse, si correggono. Ci mettono un po’ di più, ma su problemi complessi (matematica, codice, analisi) i risultati migliorano parecchio. È la differenza tra rispondere d’istinto e prendersi un minuto per rifletterci.

Le sigle da riunione

AI generativa: l’AI che crea contenuti nuovi (testi, immagini, musica) invece di limitarsi a classificarli o analizzarli.

GPT: sta per Generative Pre-trained Transformer. “Transformer” è l’architettura, cioè la struttura interna, su cui si basano quasi tutti i modelli linguistici moderni. Non è sinonimo di “AI”, anche se spesso lo si usa così.

API: la “porta di servizio” attraverso cui i programmi parlano con il modello, senza passare dalla chat. È quello che usano gli sviluppatori per integrare l’AI nelle loro app.

GPU: i processori grafici nati per i videogiochi, che si sono rivelati perfetti per far girare l’AI. Sono il motivo per cui si parla tanto di chip, data center ed energia.

Open weights: modelli i cui “pesi” (i famosi parametri) sono pubblici e scaricabili. Puoi farli girare sui tuoi server, invece di usarli solo tramite il servizio di un’azienda.

AGI (Artificial General Intelligence): un’ipotetica AI capace di fare qualsiasi compito intellettuale al livello di un essere umano. Se ne parla tantissimo, non c’è accordo su cosa significhi esattamente né su quando (e se) arriverà.

Vibe coding: scrivere software descrivendo a parole quello che vuoi e lasciando che sia l’AI a scrivere il codice. Divertentissimo per i prototipi, da maneggiare con cura quando il progetto diventa serio.

In chiusura

Il vocabolario dell’AI sembra una barriera, ma è soprattutto un insieme di metafore: cervelli, memorie, esami, strumenti, imbracature. Una volta capita l’idea dietro la parola, la sigla smette di fare paura.

E la prossima volta che in riunione qualcuno dice “l’agente allucina perché la context window è satura”, potrai annuire. Ma stavolta sapendo esattamente di cosa si parla.

Happy

1 100 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Ogni generazione di sviluppatori senior ha pensato che quella dopo avesse la vita troppo facile. Chi ha imparato senza Stack Overflow ha guardato con sospetto chi ci è cresciuto dentro, e chi è cresciuto con Stack Overflow ha detto le stesse cose sui framework che nascondono tutto. Quasi sempre si sbagliavano: gli strumenti alzavano il livello del punto di partenza e la competenza si ricostruiva un po’ più in alto.

Prima di scrivere il resto di questo articolo mi sono chiesto se non stia facendo esattamente lo stesso errore. Non ne sono del tutto sicuro. Però credo che questa volta ci sia una differenza che vale la pena guardare da vicino, e non riguarda quanto è potente lo strumento: riguarda in quale punto del percorso toglie attrito.

Lo stesso strumento fa due cose opposte

Quando io uso l’intelligenza artificiale per generare un modulo, sto delegando qualcosa che so fare. Leggo il risultato e vedo subito se la gestione degli errori è messa dove serve, se quella query diventerà un problema con dieci volte i dati, se quella scelta mi vincola su una cosa che tra sei mesi dovrò cambiare. Non lo vedo perché sono più intelligente: lo vedo perché quelle tre cose le ho già sbagliate, e le ho pagate.

Quando un junior usa lo stesso strumento, sta delegando qualcosa che non ha mai fatto. Il risultato è identico. Quello che manca è tutto quello che succedeva prima che il risultato arrivasse.

È lì che si formava la competenza. Non nel codice finito, che era anzi la parte meno interessante, ma nelle quattro ore passate a capire perché non partiva, nel dead end preso e abbandonato, nell’errore letto tre volte prima di accorgersi che diceva esattamente cosa fare. Quelle ore sembravano tempo perso, e in senso stretto lo erano: producevano poco. Producevano però un modello mentale di come le cose si rompono, che è l’unica cosa che poi permette di guardare del codice e sentire che qualcosa non torna prima di sapere perché.

Quell’attrito non era un difetto del processo. Era il processo.

Il plateau invisibile

C’è un effetto collaterale meno ovvio e secondo me più insidioso.

Prima, il livello di un junior si vedeva dal suo output. Il codice diceva dov’era: cosa aveva capito, cosa stava ancora imitando, cosa non aveva mai incontrato. Era un segnale rumoroso ma leggibile, e serviva a due persone — a chi lo seguiva, per calibrare il lavoro da assegnargli, e a lui, per sapere dove si trovava.

Oggi quel segnale è quasi sparito. L’output di un junior con un buon assistente è spesso indistinguibile da quello di una persona con cinque anni di esperienza. Sembra una buona notizia, e in parte lo è. Ma significa anche che nessuno dei due — né chi guida né chi impara — ha più un modo semplice di sapere a che punto è la crescita. La differenza salta fuori tutta insieme, e sempre nel momento peggiore: il primo problema che non assomiglia a niente di già visto, il primo incidente in produzione, la prima volta che lo strumento propone una soluzione plausibile e sbagliata.

Il rischio non è avere junior meno capaci. È avere junior che sembrano competenti, si sentono competenti, e scoprono di non esserlo in una situazione dove quella scoperta costa cara a tutti.

E poi c’è il problema economico

Qui la faccenda smette di essere pedagogica.

I compiti che davamo ai junior avevano tutti le stesse caratteristiche: ben delimitati, a basso rischio, ripetitivi, con un risultato verificabile. Erano i gradini bassi della scala, e servivano esattamente a quello — far salire qualcuno.

Sono anche, con precisione quasi comica, i compiti che oggi l’intelligenza artificiale svolge meglio. Più veloce, a costo quasi nullo, senza bisogno di supervisione.

Quindi il problema non è solo “come faccio a insegnare”. È che il lavoro con cui si insegnava non ha più una ragione economica per esistere. Chi decide come allocare le persone su un progetto si trova davanti a una scelta che dieci anni fa non c’era: quel task lo do a una persona che deve imparare, sapendo che ci metterà tre giorni invece di venti minuti e che il risultato sarà peggiore, oppure lo chiudo stasera. La seconda opzione è sempre difendibile sul singolo progetto, e sistematicamente disastrosa sui tre anni.

Nessuno prende mai la decisione di smettere di formare le persone. Si arriva lì una consegna alla volta.

Cosa provo a fare, senza sapere se basta

Non ho una risposta pulita. Ho alcune cose che sto provando, con risultati diseguali.

Prima scrivi, poi confronta. Su un pezzo scelto — non su tutto, sarebbe insostenibile — chiedo che la prima stesura sia fatta a mano, e solo dopo generata. Il valore non è nella versione scritta a mano, che quasi sempre è peggiore. È nel confronto: perché lo ha risolto così, cosa non avevo considerato, cosa invece nel mio era meglio e va tenuto. Il confronto insegna moltissimo, ma funziona solo se hai qualcosa da confrontare.

La review si sposta dal codice al ragionamento. Non chiedo più solo se funziona. Chiedo perché quella scelta, cosa è stato scartato, cosa si rompe se il carico decuplica, cosa succede se quel servizio esterno risponde lento invece che dare errore. Se le risposte non ci sono, il codice non passa — anche quando funziona perfettamente. Non è pignoleria: è che il codice che nessuno sa spiegare è codice che nessuno potrà cambiare.

Il debug di roba scritta da altri, presto. Un incidente in produzione insegna in un pomeriggio quello che un task assegnato non insegna in un mese, e non è delegabile: l’assistente ti aiuta a leggere lo stack trace, non ti toglie la responsabilità di capire perché quel sistema è fatto così. È anche l’unico attrito rimasto che non si può comprimere.

Proprietà lunga su qualcosa di piccolo. Un componente vero, in produzione, seguito per mesi. Le conseguenze delle proprie scelte che tornano indietro dopo sei mesi sono il maestro più efficace che conosco, e sono l’esatto opposto della logica del task chiuso in venti minuti.

La cosa che non so

Resta aperta un’obiezione seria, che mi faccio da solo.

Forse la competenza che stiamo cercando di preservare non è più quella che serve. Forse il mestiere si sposta davvero verso il giudizio, la revisione, la capacità di decidere cosa vale la pena costruire — e forse quelle si possono allenare direttamente, senza passare dalle quattro ore sull’errore di compilazione. Se è così, quello che ho scritto qui sopra è nostalgia travestita da metodo, e tra dieci anni farà sorridere come le prediche su Stack Overflow.

Non riesco a escluderlo. So solo che il giudizio, per come l’ho visto formarsi nelle persone con cui ho lavorato, è sempre arrivato dopo aver sbagliato abbastanza volte da riconoscere le forme. E che non ho ancora visto nessuno svilupparlo guardando funzionare cose che non ha capito.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Il debito tecnico ha una qualità che oggi rimpiango: si vede.

Lo riconosci mentre leggi. La funzione da quattrocento righe, il campo chiamato flag2, la logica di business finita dentro il controller, il modulo che tutti sanno di dover riscrivere e nessuno riscrive mai. Fa male al momento del contatto, e questo è esattamente ciò che lo rende gestibile: un dolore immediato è un segnale, e sui segnali si può decidere. Sai cos’hai, sai più o meno cosa costerebbe sistemarlo, e se scegli di non farlo è una scelta.

Da un paio d’anni sto vedendo accumularsi qualcosa di diverso, che non ha nessuna di queste proprietà. Lo chiamo debito di comprensione, per mancanza di un nome migliore.

Definizione

È codice corretto, funzionante, spesso scritto meglio della media del progetto che nessuno in azienda sa spiegare.

Non “nessuno ha letto”. Nessuno sa spiegare: perché quella scelta e non un’altra, quali alternative sono state scartate, cosa succede se l’input arriva in un formato leggermente diverso, quale vincolo del sistema quel pezzo sta rispettando senza dirlo. Il codice è lì e fa il suo lavoro. Il modello mentale che lo ha prodotto non è mai entrato in nessuna testa.

La differenza rispetto al debito tecnico è che qui non c’è niente da vedere. Il linter è verde. La copertura dei test è buona, perché i test li ha generati lo stesso strumento. La complessità ciclomatica è più bassa della media del repository. Nessuna metrica che usiamo oggi si accorge di questo debito, per la semplice ragione che tutte le nostre metriche guardano il codice, e il codice non ha alcun problema. Il problema è dall’altra parte, nelle persone, e lì non misuriamo niente.

Non è nuovo, è solo accelerato

Vale la pena essere onesti: questo debito è sempre esistito. La persona che se ne va portandosi via l’unico modello mentale di un sottosistema. Il modulo scritto in una notte prima della consegna e mai più guardato. La libreria integrata copiando l’esempio della documentazione e funzionante per motivi che nessuno ha indagato. Codice che nessuno capisce ne abbiamo sempre avuto.

Quello che è cambiato è il tasso di accumulo. Prima il debito di comprensione cresceva alla velocità con cui una persona poteva produrre codice senza capirlo e quella velocità era bassa, perché scrivere codice che non capisci è comunque faticoso e lento. C’era un limite fisico che faceva da freno, non per virtù ma per attrito.

Quel limite non c’è più. Oggi una persona può immettere in un sistema, in una settimana, più codice non compreso di quanto ne avrebbe prodotto in un anno. E può farlo mentre tutti gli indicatori di qualità migliorano.

Come si manifesta

Il debito di comprensione non si annuncia. Si vede di riflesso, e quasi sempre in fenomeni che attribuiamo ad altro:

La modifica piccola che nessuno vuole prendere in carico. Un cambiamento apparentemente banale su una certa area, e in pianificazione cala il silenzio. Non è pigrizia: è che nessuno sa cosa si romperà.

Le stime che si gonfiano su zone precise del sistema senza che nessuno sappia dire perché. Se chiedi, ti risponderanno “quella parte è delicata”. Delicata di solito significa opaca.

“Funziona, non toccarlo”. La frase più costosa dell’intero mestiere, e il sintomo più diretto.

I bug risolti aggiungendo codice invece che togliendolo. Chi ha il modello del sistema rimuove la causa; chi non ce l’ha aggiunge una condizione attorno al sintomo. È un indicatore che si legge nei diff, ed è piuttosto affidabile.

La riscrittura che sembra più economica della modifica. Su un componente di sei mesi fa. Quando arriva questo, il debito non è da pagare: è già stato pagato, in perdita.

Un modo per misurarlo

Non ho una metrica automatica da proporre e diffido di chi la propone. Ho un esercizio, che si fa in mezz’ora su una lavagna.

Si elencano le aree del sistema, e per ognuna si scrive quante persone sono in grado di spiegarla senza aprirla: cosa fa, perché è fatta così, cosa la rompe. Non “quante ci hanno lavorato”. Quante la sanno spiegare.

È il bus factor applicato alla comprensione anziché all’accesso, e il risultato è di solito peggiore di quanto chiunque si aspettasse soprattutto sulle parti costruite di recente e in fretta, che sono anche quelle che in retrospettiva sembravano essere andate meglio.

Cosa lo riduce

La regola del “spiegamelo”. In revisione non passa ciò che l’autore non sa spiegare, anche quando funziona perfettamente. Il criterio non è “l’ho letto”, è “so dirti cosa succede se”. Va detto chiaramente al team che questo non è un test di lealtà verso gli strumenti: vale identico per il codice scritto a mano, e ha sempre dovuto valere. È solo che prima capitava di rado di scrivere qualcosa che non si sapeva spiegare.

Documentare le decisioni, non il codice. Il codice generato è già ampiamente commentato, spesso più del necessario, e quei commenti dicono cosa fa che era la parte già leggibile. Quello che manca è il perché: quali alternative sono state considerate, quale vincolo ha deciso, cosa era vero al momento della scelta e potrebbe non esserlo più. Bastano dieci righe per decisione, tenute vicino al codice.

Chiedere le alternative scartate al momento giusto. Il momento in cui il contesto è massimo è quando il codice viene generato, non sei mesi dopo. “Cosa hai considerato e perché hai escluso il resto” è la domanda che trasforma un output in una comprensione, e costa trenta secondi allora contro tre giorni poi.

Rotazione deliberata. Chi non ha scritto una parte deve metterci le mani prima che sia un’emergenza. È l’unico modo per scoprire quanto è opaca mentre scoprirlo costa poco.

E contrarlo consapevolmente, quando serve. Come per il debito tecnico, non è la contrazione il problema. Per uno script interno, un prototipo, una cosa che vivrà tre settimane, generare qualcosa che nessuno capisce è perfettamente razionale. Il debito diventa pericoloso quando è una scoperta invece che una decisione — quando ci si accorge di averlo il giorno in cui bisogna ripagarlo.

Perché conta più di prima

Il debito tecnico ha un’ultima proprietà consolante: è ripagabile con lavoro. Anche molto, anche noioso, ma lavoro e oggi il lavoro di riscrittura costa meno di quanto sia mai costato.

Il debito di comprensione no. Non si ripaga generando altro codice, perché il codice non è mai stato il problema. Si ripaga solo con il tempo di persone che si siedono e ricostruiscono un modello mentale che nessuno ha mai avuto, partendo da un artefatto che non è stato scritto per essere spiegato. È l’unica forma di debito che gli strumenti che lo producono non aiutano a estinguere.

Il debito tecnico si vede nel codice. Il debito di comprensione si vede solo nelle persone — e per questo, quando lo vedi, di solito è tardi.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Invece di cercare l’ennesimo tema pronto ho descritto quello che volevo. Il lavoro più importante, però, non l’ha fatto l’AI.

Il tema giusto è sempre quello di qualcun altro

Chi ha un blog su WordPress conosce il rito. Si apre la directory dei temi, si sfogliano le demo, se ne installano tre o quattro. Ognuno ha qualcosa che non serve: slider, page builder, pannelli con quaranta opzioni. E ognuno manca proprio della cosa che volevi.

Personalmente ho passato tantissimo tempo a installare, nagivare, cercare, configurare temi per trovare quello che meglio si adattasse alle mie esigenze, e sopratutto che fosse un tema light e non un configuratore pieno di mille funzioni per me inutili.

Il motivo è semplice. Un tema pensato per migliaia di siti deve accontentare tutti, e quindi non è fatto su misura per nessuno. Questa volta ho provato a fare il contrario: invece di adattarmi a un tema, ho descritto quello che volevo.

Ho scritto i requisiti, non il codice

Ho aperto una conversazione con Claude e ho scritto quello che scriverei in un brief per il mio team.

Volevo un layout chiaro, leggero e minimale. In home, l’ultimo articolo in evidenza e sotto le anteprime dei precedenti. Poi le categorie e la ricerca. Un box con il link al mio libro. E un box con gli altri miei siti, che si notasse senza invadere la pagina.

Nessuna specifica tecnica e nessun mockup. La prima versione è arrivata già completa: template PHP, stili, font, e i box del libro e dei siti modificabili da Aspetto > Personalizza, senza toccare il codice.

Il lavoro vero è stato guardare e correggere

La prima versione era buona, ma non era ancora il mio blog. Il lavoro è iniziato lì, con un giro di revisione alla volta: guardavo il risultato, decidevo cosa cambiare e lo chiedevo.

Ogni mio articolo ha un’immagine, quindi le anteprime in home dovevano mostrarla. Ho molte categorie, e un elenco lunghissimo nella barra laterale era rumore: ora si vedono le otto con più articoli e un pulsante apre le altre. Nella pagina dell’articolo ho tolto del tutto la barra laterale, perché lì conta solo leggere. Infine ho spostato il box degli altri siti sopra le categorie.

Ogni modifica ha richiesto pochi minuti. Ma nessuna di queste decisioni poteva prenderla l’AI, perché dipendevano da come è fatto il mio blog e da come lo voglio.

C’è stato anche un bug vero. Controllando le anteprime su mobile è emerso che i blocchi di codice più lunghi allargavano la pagina oltre lo schermo. Su un blog dove capita spesso di pubblicare codice non è un dettaglio. È stato corretto, ma bisognava accorgersene.

L’AI ha scritto il codice. Sapere cosa volevo, e accorgermi di cosa non andava, è rimasto compito mio.

Cosa c’è dentro Margine

Il nome viene dalle note a margine: quelle che si scrivono leggendo, con l’evidenziatore in mano. Il giallo dell’evidenziatore compare in pochi punti. Sottolinea il titolo dell’ultimo articolo, compare quando passi il mouse sui titoli e colora il box con i miei altri siti.

Alcune scelte non si vedono ma contano.

• Font inclusi nel tema. I caratteri sono salvati dentro il tema e non vengono caricati da Google Fonts. Il browser di chi legge non contatta server esterni, un aspetto che in Europa ha anche risvolti legati al GDPR.
• Leggerezza. Niente framework e un solo piccolo script, quello che apre e chiude le categorie. Se JavaScript è disattivato, le categorie vengono mostrate tutte.
• Pagina dell’articolo. Il testo sta in una colonna di lettura comoda. L’immagine in evidenza è più larga del testo.

Il conto da pagare

Un tema fatto su misura non è gratis, anche se non l’ho comprato.

Non riceve aggiornamenti automatici. Se una nuova versione di WordPress cambia qualcosa, sistemarlo tocca a me. Non c’è un forum di supporto né una community che ha già incontrato lo stesso problema. E un tema non è un file qualsiasi: gira sul server e passa per ogni pagina del sito. Pubblicarlo senza capire cosa fa sarebbe come approvare una pull request senza leggerla.

Per me è un costo accettabile, perché il codice lo so leggere e modificare. Per chi non sviluppa, un tema ben mantenuto resta probabilmente la scelta più sensata. L’AI abbassa il costo di costruire qualcosa, ma non quello di mantenerlo nel tempo.

Cercare o costruire

Per anni la domanda è stata: quale tema scelgo? Per software piccolo e su misura come questo, la domanda sta diventando un’altra: so descrivere quello che mi serve?

Costruire costa sempre meno. Quello che non cala è la fatica di decidere: sapere cosa vuoi, riconoscere quando il risultato non va bene, prenderti la responsabilità di quello che metti online. Chi sa farlo ha un vantaggio vero. Chi non lo sa rischia di passare dal catalogo dei temi a quello delle risposte dell’AI, prendendo la prima che sembra funzionare.

Margine è online e mi piace. Se trovi qualcosa che non va, scrivimelo, oltre all’autore del blog, sono anche il suo sviluppatore.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Perché nell’era dei coding agent, la figura del programmatore diventa più strategica — non per revisionare le righe di codice, ma per decidere se quello che è stato costruito ha senso nel contesto in cui dovrà vivere.

C’è una scena che si ripete ogni giorno in decine di team di sviluppo: uno sviluppatore apre il suo tool AI preferito, descrive in linguaggio naturale una funzionalità, e in pochi secondi riceve indietro un blocco di codice pulito, ben strutturato, documentato. Il codice compila. I test passano. La PR viene aperta.

Fin qui tutto bene. Il problema arriva dopo.

Perché quel codice, tecnicamente ineccepibile, potrebbe essere completamente sbagliato per il sistema in cui dovrà vivere. Potrebbe ignorare le convenzioni interne non documentate da nessuna parte. Potrebbe aggirare un layer di autenticazione aziendale. Potrebbe replicare una logica già esistente altrove nel codebase, ma con un nome diverso. Potrebbe scalare in modo incompatibile con l’architettura scelta tre anni fa per ragioni che il team attuale ha dimenticato.

L’AI non lo sa. Non può saperlo.

Il codice corretto nel contesto sbagliato

Per anni abbiamo dibattuto se l’AI avrebbe “rubato il lavoro ai programmatori”. Era la domanda sbagliata. La domanda giusta è: quale lavoro sta cambiando, e in che direzione?

La risposta che emerge dai dati degli ultimi mesi è chiara: l’AI eccelle nel trasformare intenzioni in codice. È straordinariamente brava a scrivere boilerplate, a generare test, a costruire endpoint CRUD, a scaffoldare UI. Tutto quello che un tempo era il pane quotidiano — e il principale collo di bottiglia — delle squadre di sviluppo.

Quello che l’AI non sa fare è capire il contesto. I senior developer confermano di passare tempo a correggere suggerimenti AI che mancano l’intento architetturale: non perché il codice sia sbagliato in assoluto, ma perché non è quello che quel sistema, in quel momento, con quella storia alle spalle, avrebbe dovuto ricevere.

“L’AI non prende le decisioni difficili su architettura, compliance o sicurezza. Non può capire pienamente la business logic di un’azienda. Quella supervisione resta in mano agli ingegneri esperti.”

Questa non è una critica all’AI. È una descrizione precisa di come funziona: ottimizza sulla base di pattern generali. Ma ogni azienda è una deviazione dai pattern generali.

Non è code review. È validazione contestuale.

C’è una distinzione importante da fare, e spesso viene persa nel dibattito pubblico.

Quando si parla di “supervisione umana sul codice AI”, si pensa immediatamente alla code review tradizionale: qualcuno che legge le righe, controlla la sintassi, verifica la logica. Un processo lineare, scalabile, in qualche modo automatizzabile anch’esso.

Ma quello di cui stiamo parlando è qualcosa di diverso. È la capacità di rispondere a domande che non stanno nel codice:

Questo componente rispetta la nostra strategia di separazione dei dati per i clienti enterprise? Questo pattern di retry è compatibile con i limiti di rate del servizio esterno che usiamo in produzione? Questa struttura del database è coerente con come evolverà il prodotto nei prossimi dodici mesi?

Sono domande che richiedono conoscenza dell’organizzazione, non del linguaggio di programmazione. Richiedono di aver vissuto le scelte passate, di conoscere i vincoli non scritti, di capire dove il sistema sta andando oltre il ticket corrente.

Il programmatore esperto, in questo scenario, non è un controllore di qualità. È un traduttore tra due mondi: l’AI, che conosce il codice, e l’azienda, che conosce se stessa.

Il rischio invisibile: la produttività che nasconde la fragilità

I numeri sulla produttività sono reali. I team che adottano strumenti AI scrivono più codice, aprono più PR, consegnano più velocemente. Ma c’è un dato che viene spesso ignorato: i team che usano AI riportano un aumento del 41% nel code churn e una diminuzione della stabilità del delivery.

Più codice non significa più valore. Significa più superficie da mantenere, più potenziali punti di rottura, più debito tecnico nascosto sotto uno strato di sintassi perfetta.

La produttività individuale sale. La confidenza collettiva no. I developer scrivono più veloce, ma passano più tempo a questionare, revisionare e validare quello che viene spedito. Il collo di bottiglia non è sparito: si è spostato a valle.

E questo è esattamente il punto in cui la figura del senior developer diventa critica. Non per rallentare il processo, ma per dare direzione alla velocità. Per trasformare la quantità di output in qualità di sistema.

Cosa cambia concretamente nel lavoro quotidiano

I dati di inizio 2026 mostrano uno spostamento già in atto: i senior developer riportano che il loro tempo si è redistribuito dall’80% di coding a circa il 60% tra architettura e review, 30% mentoring, e solo il 10% di coding vero e proprio.

Non è una riduzione di valore. È una elevazione del livello in cui il valore viene creato.

In pratica, questo significa spostare l’attenzione da “questo codice funziona?” a domande più profonde: questo codice appartiene a questo sistema? È strutturato in modo che tra sei mesi un altro developer — umano o AI — possa capire le decisioni prese? Si integra con le scelte architetturali esistenti senza creare dipendenze nascoste? Rispetta i vincoli di compliance del settore in cui operiamo?

Il codice generato dall’AI è come un candidato brillante al colloquio: sa rispondere bene alle domande standard. Il programmatore esperto è chi sa fare le domande che non stanno nel template del colloquio.

Il contesto aziendale non è documentabile. Si porta addosso.

C’è un’ultima considerazione, forse la più sottovalutata.

Molto del contesto aziendale che conta — le ragioni di una scelta architetturale fatta due anni fa, la complessità di un’integrazione con un sistema legacy, le aspettative implicite di un cliente chiave — non è scritto da nessuna parte. Vive nella testa delle persone che ci hanno lavorato.

L’AI può leggere la documentazione, i commenti nel codice, i file di configurazione. Non può leggere le discussioni Slack cancellate, le decisioni prese in una call informale, il motivo per cui quella tabella del database si chiama in quel modo che sembra strano ma ha una ragione precisa.

Questo è il vantaggio competitivo del programmatore esperto nell’era dell’AI: non la velocità di scrittura, non la conoscenza dei framework, ma la capacità di portare dentro ogni decisione tecnica il peso specifico di un’organizzazione reale, con la sua storia, i suoi vincoli e le sue ambizioni.

L’AI sa costruire. Il programmatore esperto sa costruire qui, per questo, in questo modo — e sa spiegare perché la differenza conta.

Articolo basato su ricerche e dati da: Veracode GenAI Code Security Report (2025), Gartner (ottobre 2025), daily.dev Vibe Coding Report (2026), Anthropic Agentic Coding Trends Report (2026), CIO.com Senior Developer Roles (2025), formation.dev How AI Changes Senior Engineers (2025).

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

“Il Web è stato progettato per essere uno spazio universale, accessibile da chiunque, ovunque.”

— Tim Berners-Lee

C’era una volta Internet. Una rete nata per condividere liberamente conoscenza, collegare persone, costruire ponti tra mondi diversi. Un luogo aperto, accessibile, decentralizzato. Chi ha vissuto i primi anni del Web ricorda con entusiasmo un mondo nuovo da esplorare, dove ogni clic era una scoperta, ogni sito una porta aperta sulla creatività altrui.

Oggi quella visione sembra lontana. E una domanda si fa sempre più urgente: stiamo perdendo Internet?

Dal Web 1.0 al 3.0: un’evoluzione (involutiva?)

Abbiamo imparato a distinguere il Web 1.0, fatto di pagine statiche e siti vetrina, dal Web 2.0, quello partecipativo, sociale, in cui tutti potevano produrre contenuti. Poi è arrivato il Web 3.0, promesso come rivoluzione decentralizzata, basata su blockchain, identità digitali e autonomia individuale.

Ma la realtà è diversa: il Web si è evoluto, sì, ma la sua gestione si è sempre più accentrata. I grandi soggetti privati – Meta, Google, Amazon, Apple, TikTok – hanno preso il controllo delle interfacce, dell’accesso, dell’esperienza.

L’interfaccia è cambiata: ora c’è l’AI

Con l’arrivo delle intelligenze artificiali generative, qualcosa è cambiato ancora più profondamente. Per cercare un’informazione, non si usa più un motore di ricerca, si fa una domanda a un assistente AI. Per organizzare un viaggio, si usa un’app. Per imparare qualcosa, ci si affida a un video “short”, non a un forum o un blog.

Stiamo costruendo uno strato di astrazione sopra la rete. E in questo strato, non vediamo più cosa c’è sotto. Non sappiamo da dove proviene un’informazione, chi l’ha creata, se è verificata. L’AI ci dà una risposta e noi ci fidiamo. Ma la rete, quella vera, è nascosta.

Aprire un negozio? Usa i social, non un sito

Un tempo, se volevi vendere online, la prima cosa che facevi era creare un sito web. Ora ti dicono: “Apri una pagina Instagram, un account WhatsApp Business, un profilo TikTok”. Gli e-commerce si spostano dentro le piattaforme, che offrono strumenti semplici, sì, ma a costo della libertà e del controllo.

Lo stesso accade per l’informazione, la cultura, la musica. Tutto è dentro un’app. Tutto è mediato da un algoritmo. Internet non è più un mare aperto: è un insieme di laghi recintati.

Censura e servizi a pagamento: due facce della stessa prigione

Un’altra minaccia silenziosa è la censura selettiva, esercitata sia da governi autoritari sia da piattaforme private. Interi siti vengono oscurati, contenuti rimossi, voci critiche silenziate – spesso senza un processo trasparente, senza diritto di replica. L’idea di una rete libera si scontra con l’interesse politico e commerciale di controllarla.

In parallelo, servizi un tempo gratuiti diventano a pagamento, o limitati a chi può permettersi l’accesso premium. L’informazione di qualità, l’educazione online, persino la visibilità sui social sono ormai beni venduti al miglior offerente. La rete, da strumento di democratizzazione, rischia di diventare uno strumento di esclusione.

Cosa stiamo perdendo davvero

Dietro questa trasformazione c’è una perdita sottile, ma enorme:

• Perdiamo la scoperta non filtrata. Navigare oggi è come sfogliare un catalogo su misura: ti mostrano solo ciò che (secondo loro) vuoi vedere.
• Perdiamo la creatività libera. I contenuti nascono per piacere agli algoritmi, non per esprimere un’idea autentica.
• Perdiamo la trasparenza. Non sappiamo più chi controlla i dati, da dove arrivano le informazioni, come vengono classificate.
• Perdiamo la rete come luogo pubblico. È diventata una somma di spazi privati.
• Perdiamo l’accesso universale. Tra censura e paywall, il sapere torna a essere un privilegio.

Internet oggi: una scatola nera?

La rete esiste ancora. Esistono i server, i cavi, i protocolli. Esistono ancora i siti indipendenti, i blog personali, i progetti open source. Ma sono sempre più invisibili, sepolti sotto strati di applicazioni, interfacce, store, feed.

Vediamo solo quello che altri hanno deciso di mostrarci. La rete, quella vera, è diventata una scatola nera.

C’è ancora speranza?

Sì, ma dobbiamo ritrovare consapevolezza. Dobbiamo ricordarci che possiamo ancora:

• Navigare fuori dalle piattaforme.
• Leggere fonti originali.
• Pubblicare su spazi indipendenti.
• Usare motori di ricerca diversi.
• Costruire siti, blog, progetti fuori dai recinti chiusi.
• Sostenere economicamente chi crea contenuti liberi, senza algoritmi e senza censura.

Forse non riavremo mai più “Internet come una volta”. Ma possiamo ancora difendere l’idea di una rete aperta, costruita dalle persone, per le persone.

“Abbiamo costruito il Web, possiamo ricostruirlo. Possiamo scegliere una rete diversa.”

— Anonimo, ma potrebbe essere ognuno di noi

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %

Il sipario si è riaperto sui palchi italiani e la musica dal vivo è tornata a vibrare nelle piazze, negli stadi e nei palazzetti. Dopo il silenzio forzato causato dalla pandemia, la voglia di partecipare a un concerto, di cantare a squarciagola insieme a migliaia di persone, è più forte che mai. Tuttavia, questo tanto atteso ritorno ha portato con sé una sorpresa amara: i prezzi dei biglietti sono lievitati in modo esponenziale. Oggi, assistere a un concerto in Italia è diventato per molti un lusso.

Ma cosa si nasconde dietro questa impennata dei costi? E perché la musica, un tempo esperienza popolare e condivisa, sembra oggi sempre più riservata a pochi?

I fattori chiave dietro l’aumento dei costi

Diversi elementi, alcuni globali e altri specifici del mercato post-pandemico, stanno convergendo per spingere i prezzi dei biglietti verso l’alto:

• La Fame da Live: La Domanda Repressa:
  • Anni di restrizioni e annullamenti hanno creato una domanda accumulata enorme. I fan desiderano ardentemente rivivere l’esperienza del concerto, e questa “fame” spinge naturalmente i prezzi verso l’alto. Eventi che vanno sold-out in pochi minuti sono la prova tangibile di questa sete di musica dal vivo.
• Aumento dei Costi di Produzione:
  • L’inflazione generale ha colpito ogni settore, inclusa l’organizzazione di eventi. I costi per il noleggio delle strutture, l’energia (luci, audio), i materiali per scenografie e allestimenti, e i trasporti (carburante per tir e bus turistici) sono aumentati sensibilmente.
  • Anche il personale (tecnici, sicurezza, montatori) ora ha costi maggiori, in parte per adeguamento all’inflazione, in parte per la carenza di alcune figure professionali emerse dopo la pandemia.
  • Le produzioni sono poi sempre più complesse: gli spettacoli attuali spesso richiedono investimenti massicci in tecnologia, schermi LED, effetti speciali che gravano sul budget complessivo.
• Cachet degli Artisti Maggiorati:
  • Le superstar internazionali, e in misura crescente anche gli artisti italiani di primo piano, hanno presumibilmente aumentato i loro compensi. Questo può essere un modo per recuperare i mancati guadagni del periodo pandemico o semplicemente per capitalizzare l’elevata domanda e il successo attuale. Un cachet più alto si traduce direttamente in un prezzo del biglietto più elevato.
• Il Ruolo del Dynamic Pricing:
  • Sempre più piattaforme di vendita adottano il “dynamic pricing”, un sistema di prezzi dinamici. Questo significa che il costo del biglietto non è fisso, ma varia in tempo reale in base alla domanda. Se un concerto è molto richiesto, il prezzo può aumentare man mano che i biglietti vengono venduti, anche per i posti rimanenti. Questo meccanismo, comune nel settore aereo o alberghiero, è relativamente nuovo nel mondo dei concerti e può portare a differenze di prezzo significative per lo stesso settore a seconda del momento dell’acquisto.
• Il Peso del Bagarinaggio Online (Secondary Ticketing):
  • Un problema annoso che si è acuito nell’era digitale è il bagarinaggio online. Piattaforme non ufficiali o singoli rivenditori acquistano in massa i biglietti per poi rivenderli a prezzi esorbitanti, a volte il doppio o il triplo del valore nominale. Sebbene in Italia siano state introdotte norme per contrastarlo, il fenomeno persiste e contribuisce enormemente alla frustrazione dei fan e alla percezione di prezzi “folli”.
• L’Attrattiva dei Pacchetti VIP:
  • Molti artisti e promoter offrono pacchetti VIP che includono posti privilegiati, meet & greet, merchandise esclusivo o accesso a soundcheck. Questi pacchetti, estremamente costosi, riducono la disponibilità di biglietti “standard” a prezzi più accessibili, spingendo i fan a spendere di più per assicurarsi un posto.

L’impatto in Italia: Quando la musica diventa un lusso

In Italia, questa tendenza è particolarmente sentita. Basta confrontare i prezzi di un concerto di un grande artista internazionale oggi con quelli di qualche anno fa per notare un balzo notevole. Un biglietto per un parterre che nel 2019 poteva costare 50-70 euro, oggi può facilmente superare i 90-100 euro, senza contare le commissioni di servizio. Per i posti nelle tribune più costose o i pacchetti VIP, si possono toccare cifre di 200, 300 euro o più.

Questa situazione sta generando una crescente frustrazione tra i fan, che si sentono spesso esclusi o costretti a rinunciare a un’esperienza culturale che prima era più accessibile. Le discussioni sui social media e nei forum online pullulano di lamentele riguardo ai prezzi e alla difficoltà di ottenere biglietti onesti. C’è il rischio concreto che la musica dal vivo, un tempo un’esperienza popolare e inclusiva, diventi sempre più un lusso per pochi.

Conclusioni: Un futuro sostenibile per la musica live?

La musica dal vivo è un motore culturale ed economico fondamentale, capace di creare connessioni uniche tra artisti e pubblico. Tuttavia, l’attuale escalation dei prezzi solleva interrogativi sulla sua sostenibilità a lungo termine. Sarà fondamentale trovare un equilibrio tra i crescenti costi di produzione, le legittime esigenze degli artisti e il potere d’acquisto dei fan. Altrimenti, l’entusiasmo per il ritorno ai concerti potrebbe presto trasformarsi in una melodia amara.

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %