Le mani e la macchina #
Mio nonno faceva (ANCHE) il falegname. Quando gli chiedevi come facesse a capire se un pezzo di legno era buono, non tirava fuori teorie. Si fermava, lo girava tra le mani, lo annusava, e poi diceva: “lo senti”.
Ogni volta che ripenso a quella scena mi viene da sorridere, e poi mi prende una specie di nostalgia strana. Perché io faccio software da vent’anni e quando un cliente mi chiede come faccio a sapere se un sistema è buono, vorrei poter rispondere allo stesso modo. Vorrei poter dire “lo senti” e chiudere lì.
Solo che la verità è più complicata, e forse è proprio questo il punto.
Il software non lo tocchi. Non lo annusi. Non lo guardi controluce per cercare le venature. Eppure è ovunque. È la cosa più potente e più invisibile che abbiamo costruito.
E quando una cosa è così invisibile, la fiducia diventa tutto.
Il mondo gira su cose che non vedete #
Stamattina avete fatto colazione. Il latte che avete comprato è arrivato al supermercato attraversando una catena logistica governata da software. Il pagamento al registratore di cassa è passato attraverso più sistemi di quanti ne immaginiamo, spesso senza che nessuno se ne accorga.
Il semaforo che avete incrociato uscendo di casa esegue un algoritmo. L’ascensore ha un firmware. Il vostro stipendio è un numero in un database.
Non lo dico per fare scena. È solo il mondo com’è adesso.
E qui arriva il paradosso che mi inquieta un po’. Quasi nessuno, tra chi prende decisioni su come funziona la società, ha una comprensione profonda di come funzionano questi sistemi. Non per stupidità o pigrizia. Piuttosto per un difetto strutturale nella nostra cultura: per anni abbiamo trattato la tecnologia come una cosa da tecnici, un reparto, un angolo della mappa.
Nel frattempo è diventata il tessuto connettivo di tutto.
Quando un consiglio di amministrazione approva un sistema basato su ai per filtrare le candidature, sta prendendo una decisione tecnologica? Sì. Ma sta anche prendendo una decisione etica, giuridica, sociale. Sta decidendo quali pregiudizi sono accettabili, quale margine di errore è tollerabile, quanta opacità è ammissibile in un processo che cambia la vita delle persone.
E spesso non lo sa.
Cosa succede quando nessuno capisce la macchina #
C’è una storia che nel nostro settore conosciamo bene, ma che raramente raccontiamo fuori dalle nostre stanze.
Dentro quasi ogni sistema che usate, dal sito della banca all’app con cui ordinate la cena, ci sono piccoli pezzi di codice scritti da persone che non incontrerete mai. Sono librerie open source: componenti gratuiti, condivisi, mantenuti spesso da singoli individui nel loro tempo libero.
Qualche tempo fa qualcuno ha tentato di inserire una porta segreta in una di queste librerie, un componente usato da milioni di server nel mondo. Il tentativo è stato scoperto quasi per caso: un ingegnere si è accorto che il sistema impiegava mezzo secondo in più ad avviarsi. Mezzo secondo.
Da quel mezzo secondo si è risaliti a un’operazione sofisticata, probabilmente sponsorizzata da uno Stato, che avrebbe potuto compromettere infrastrutture critiche su scala globale.
La cosa che dovrebbe togliere il sonno non è che qualcuno ci abbia provato. È che l’intera catena di sicurezza dipendeva da una persona sola, un volontario, che manteneva quel codice nel tempo libero mentre combatteva con il burnout.
Non è un aneddoto isolato. È un modello. E mi chiedo spesso quanto possa reggere.
L’ai non è intelligente (e va bene così) #
Qui bisogna essere chiari, perché il marketing ha fatto un lavoro incredibile nel confondere le acque.
I sistemi che chiamiamo “intelligenza artificiale” non pensano. Non capiscono. Non hanno intenzioni, desideri, obiettivi propri. Sono macchine statistiche di una potenza senza precedenti, capaci di trovare pattern in quantità di dati che nessun essere umano potrebbe processare, e di generare risultati che appaiono intelligenti.
Questa distinzione non è accademica. È pratica. È una di quelle cose che cambiano il modo in cui prendi decisioni.
Se pensate che l’ai capisca, finirete per trattarla come un esperto. Vi fiderete del suo giudizio. Le delegherete scelte. E quando sbaglierà, perché sbaglia e lo fa anche in modi sottili, non avrete gli strumenti per accorgervene.
Se invece la vedete per quello che è, uno strumento potentissimo, allora torna tutto in una prospettiva più sana. Uno strumento va guidato, verificato, messo in sicurezza. Un bisturi è straordinario nelle mani di un chirurgo, ed è un pericolo nelle mani di chiunque altro. La differenza non è nel bisturi.
Per chi scrive software questa consapevolezza cambia il lavoro. Forse non scriviamo più ogni singola riga, o almeno non nello stesso modo. Ma dobbiamo comprendere ogni singola riga, perché siamo noi a rispondere di ciò che il sistema fa.
La macchina genera. L’umano garantisce.
E questa garanzia ha un peso che nessun modello statistico può assumersi.
L’europa fa qualcosa di coraggioso (e quasi nessuno se ne accorge) #
Mentre le big tech americane e cinesi corrono, l’europa fa una cosa diversa. Scrive regole.
Lo so, la reazione istintiva è lo sbadiglio. Regole, burocrazia, lentezza, l’ennesimo freno all’innovazione.
Però fermatevi un attimo. Forse, e dico forse, è una delle poche mosse davvero politiche che stiamo vedendo.
L’europa sta dicendo che la tecnologia non è al di sopra della legge. Che se produci un software che prende decisioni sulle persone, devi poter spiegare come funziona. Che se il tuo prodotto digitale ha una vulnerabilità, ne sei responsabile, come un produttore di automobili è responsabile di un difetto ai freni.
Ai Act, Cyber Resilience Act, Product Liability Directive, European Accessibility Act. Nomi aridi, sì. Ma dietro c’è un’intuizione molto concreta: nel ventunesimo secolo, regolare la tecnologia significa regolare la società.
Per chi fa impresa questo vuol dire costi e complessità, sarebbe ingenuo negarlo. Ma vuol dire anche un’altra cosa che mi sembra sottovalutata: un vantaggio competitivo potenziale enorme.
Quando il mercato globale si sveglierà chiedendo prodotti digitali sicuri, trasparenti, accessibili, chi avrà già costruito queste qualità nel proprio modo di lavorare sarà avanti.
La compliance può essere un peso, certo. Ma può anche essere un investimento, se la integri nel processo e non la tratti come un foglio da firmare alla fine.
Un sbom compilato per obbligo è un file in una cartella. Un sbom compilato con consapevolezza è una mappa del tuo prodotto, uno strumento di governo, quasi una dichiarazione di maturità.
Open source: il dono più grande e più fragile dell’era digitale #
C’è qualcosa di profondamente bello nell’open source. Qualcuno scrive un pezzo di codice, lo pubblica, e dice al mondo: prendilo, usalo, miglioralo.
È generosità, ma non nel senso romantico. È la costruzione di un bene comune.
E su questo bene comune poggia l’economia digitale globale. Non è un’esagerazione. Se quel software dovesse essere riscritto da zero, il valore stimato sarebbe nell’ordine di migliaia di miliardi. Ma chi lo mantiene riceve una frazione minuscola di quel valore.
Il problema è sistemico. Le grandi piattaforme costruiscono servizi miliardari su librerie mantenute da volontari esausti. I governi usano open source in infrastrutture critiche senza contribuire davvero alla manutenzione. Le aziende integrano componenti aperti nei loro prodotti proprietari senza sapere cosa hanno dentro, fino a quando una vulnerabilità li costringe a scoprirlo nel peggiore dei modi.
Cory Doctorow parla di enshittification, quel ciclo in cui le piattaforme estraggono valore fino a degradare l’ecosistema. L’open source però non è una piattaforma. È più simile a un giardino.
E un giardino, se tutti raccolgono e nessuno annaffia, muore.
La buona notizia è che qualcosa si muove. L’europa, con il CRA, inizia a distinguere tra chi mantiene codice per passione e chi lo commercializza. Alcune aziende stanno creando fondi dedicati. Ma la risposta più efficace resta la più semplice, e anche la più scomoda.
Se usi open source nel tuo prodotto, contribuisci. Con codice, con fondi, con riconoscimento. Non perché devi. Perché è intelligente, e perché è giusto.
Accessibilità: il test definitivo delle nostre intenzioni #
C’è un modo quasi infallibile per capire se un’azienda prende sul serio i propri valori. Non guardate la pagina “chi siamo”. Guardate se il suo sito funziona con uno screen reader.
L’accessibilità è quel punto in cui la retorica incontra la realtà. Puoi parlare di inclusione e diversità quanto vuoi, ma se il tuo prodotto digitale non è utilizzabile da chi ha una disabilità visiva, motoria o cognitiva, quelle parole diventano vuote.
E poi, diciamolo, non stiamo parlando di una nicchia.
In europa decine di milioni di persone vivono con qualche forma di disabilità. A queste si aggiungono gli anziani, le persone con disabilità temporanee, chiunque si trovi in un contesto sfavorevole: il sole che batte sullo schermo, una connessione lenta, un dispositivo vecchio.
L’accessibilità non è un favore. È una misura della qualità del nostro lavoro. Un software accessibile è quasi sempre un software migliore: più pulito nel codice, più chiaro nell’interfaccia, più robusto.
L’European Accessibility Act renderà molte cose obbligatorie dal 2025. Ma chi aspetta la legge per fare la cosa giusta, secondo me, ha già perso il punto.
Ai developer: non siete in pericolo, siete in trasformazione #
Qui parlo a chi fa il mio stesso mestiere. A chi vive tra commit e deploy, tra bug e refactor.
Lo so che c’è paura. Lo vedo nelle conversazioni, nei messaggi, a volte nelle battute. La domanda è sempre quella, anche quando non viene detta: “tra cinque anni ci sarà ancora bisogno di me?”
Respiro.
Siamo passati dai fogli di calcolo ai database relazionali. Dai siti statici ai framework. Dal deploy manuale a ci/cd. E ora dal codice scritto a mano al codice assistito da ai. Ogni volta il terreno ha tremato. Ogni volta, chi ha saputo adattarsi ha scoperto che il nuovo terreno era più fertile del vecchio.
Il valore non è mai stato nella digitazione. Era nella comprensione. Nella capacità di guardare un problema e vedere la struttura sotto la superficie. Di parlare con un utente e tradurre frustrazioni in un sistema che funziona. Di scegliere quando costruire e quando riusare. Di sapere che un test non è burocrazia, è amore per il futuro.
Queste competenze non sono automatizzabili. Sono amplificabili.
La macchina che scrive codice è un moltiplicatore delle vostre capacità, ma solo se avete capacità da moltiplicare. Un ide con ai nelle mani di chi capisce cosa sta facendo è uno strumento straordinario. Nelle mani di chi non capisce, è un generatore di debito tecnico ad alta velocità.
Studiate, sì, ma non solo i nuovi strumenti, perché cambieranno. Studiate i fondamentali: architettura, design di sistemi, principi di sicurezza, accessibilità. Studiate le persone: come comunicano, cosa temono, cosa sperano. E studiate anche il contesto normativo, non perché sia divertente, ma perché definisce il campo da gioco.
E soprattutto non smettete di essere curiosi. La curiosità è una cosa strana, non sempre “produttiva” nel senso aziendale del termine. Però è uno dei pochi vantaggi competitivi che una macchina non può replicare davvero.
Una questione di fiducia #
Alla fine, tutta questa conversazione, sull’ai, sull’open source, sulla regolazione, sull’accessibilità, ruota intorno a una parola sola: fiducia.
Ci fidiamo dei sistemi che non vediamo? Dovremmo? E a quali condizioni?
La fiducia non si costruisce con le dichiarazioni di intenti. Si costruisce con scelte concrete, ripetute nel tempo, verificabili. Si costruisce documentando le dipendenze, testando il codice, rendendo accessibile il prodotto, spiegando le decisioni dell’algoritmo, rispondendo degli errori.
Per i decisori, la tecnologia non è un reparto. È il linguaggio in cui è scritta l’organizzazione. Non dovete diventare programmatori, per carità. Però dovete capire abbastanza da fare domande scomode ai fornitori, distinguere un rischio reale da una rassicurazione vuota, capire cosa c’è dentro il software che governa i processi.
Per noi developer, il lavoro non è mai stato solo tecnico. Ogni scelta architetturale è una scelta di valori. Ogni dato che decidiamo di non raccogliere è un diritto che scegliamo di rispettare. Ogni interfaccia che rendiamo accessibile è una porta che apriamo.
Il codice è potere, e il potere comporta responsabilità.
E quindi: il legno e il codice #
Mio nonno non avrebbe capito il mio lavoro. Probabilmente avrebbe scosso la testa davanti a certe parole, e poi avrebbe cambiato argomento.
Però credo che avrebbe capito il principio.
Lui sapeva che un mobile fatto bene si riconosce dai giunti che non si vedono. Dalla stabilità che dura nel tempo. Dalla cura messa nei dettagli che il cliente non noterà mai, ma che fanno la differenza tra un oggetto che dura vent’anni e uno che scricchiola dopo sei mesi.
Il buon software è uguale. Si riconosce da ciò che non si vede: dalla sicurezza che non viene violata, dall’accessibilità che non esclude nessuno, dalla privacy che non viene tradita, dalla documentazione che permette a chi viene dopo di capire cosa hai fatto e perché.
Non è un mestiere che l’ai ci porterà via. È un mestiere che l’ai, in un certo senso, ci sta restituendo nella sua forma più pura: non come atto meccanico di traduzione, ma come atto umano di cura.
E la cura, come sapeva mio nonno guardando il legno, la senti.
Questo articolo è per chi scrive codice e per chi ne dipende senza saperlo. Per chi decide senza capire e per chi capisce senza poter decidere. Forse per tutti noi, perché alla fine la risposta è sempre la stessa: dipende da noi.