Tempo medio di lettura: 33 minuti

Tutto è iniziato qualche sera fa, mentre mi incaponivo sull’idea di aggiungere qui sul sito un indicatore del tempo di lettura stimato e una barra di avanzamento per i testi più lunghi. Niente di trascendentale, sia chiaro: è un calcolo aritmetico elementare. Prendi il numero di parole, lo dividi per la velocità media di lettura di un essere umano adulto e sputi fuori un numero.

Oggi, l’approccio standard a un problema del genere prevede un rituale fisso: si apre un motore di ricerca, si cerca un plugin preconfezionato, si scarica un pacchetto JavaScript da qualche megabyte – spesso infarcito di tracciamenti e animazioni di cui nessuno sente il bisogno – e lo si lancia dentro la pagina sperando che non rompa nient’altro. Il risultato? Un indicatore luccicante, trecento millisecondi di ritardo nel caricamento della pagina e un’assoluta ignoranza di cosa stia succedendo sotto il cofano.

Io ho preferito fare la fine del dinosauro: sedermi, calcolare la metrica lato server con poche righe di codice pulito e integrarla direttamente nella struttura.

Mentre guardavo quella barra muoversi millimetro dopo millimetro, mi è venuto da ridere. L’indicatore del tempo di lettura nasce come un patto di onestà con il lettore: ti dico prima quanto tempo della tua vita ti sto chiedendo. Ma per poter essere onesti sul tempo degli altri, bisogna prima essere stati maniacalmente onesti con il proprio codice. Bisogna averlo pesato, misurato, pulito.

E invece ci circondiamo di scatole nere. Ormai il web è un enorme gioco delle tre carte tecnologico, dove l’importante è che la facciata appaia dritta, non importa se dietro è tenuta in piedi dallo spago e da tre strati di framework ridondanti. Mi sono chiesto: ma se persino chi fa questo mestiere rinuncia a capire come gira un bit sul proprio server, che fine ha fatto l’informatica?

La sovranità del ferro: l’hosting, il codice e l’orgoglio della prima riga

Sento già l’obiezione del modernista da tastiera, quello cresciuto a pane e servizi cloud da cento euro al mese: “Ma chi te lo fa fare? Oggi ci sono le piattaforme totalmente automatizzate, l’infrastruttura è un concetto superato, clicchi un bottone ed è fatta”.

Ecco, chiariamo un punto. Questo sito sta su un hosting. Non ho (non più) un server fisico che ronza sotto la scrivania raffreddato da un vecchio ventilatore da tavolo, non mi occupo io di cambiare i moduli di RAM difettosi o di garantire che la doppia linea elettrica sia protetta dai fulmini. Quella splendida epoca per me è ormai è finita. C’è un limite oltre il quale l’artigianato diventa masochismo. Ma delegare la manutenzione del ferro non significa abdicare alla sovranità di ciò che ci metti dentro.

La mia scelta è caduta su WordPress. E qui, lo so, i puristi del codice duro e puro avranno un sussulto. E un po’, a dirla tutta, hanno anche ragione. WordPress, la piattaforma associata nell’immaginario collettivo ai blog di cucina o ai siti aziendali tutti uguali, pieni di plugin pesanti e vulnerabilità assortite.

Dimmi come usi, e ti dirò che informatico sei

Ma c’è modo e modo di usare uno strumento.

Un conto è usare la versione “pappa pronta”, un altro è fare le cose come si deve: il pacchetto l’ho scaricato io, l’ho caricato sul server io, e il database (non MySQL, ma il suo fork MariaDB) l’ho installato, configurato, ottimizzato e agganciato a mano, riga per riga. Nessun installatore automatico in un clic che decide per te i prefissi delle tabelle (magari lasciando il canonico e vulnerabile wp_), nessuna scatola chiusa di cui non conosci le credenziali profonde.

E poi c’è la questione del template. Non sono andato a cercarmi uno di quei temi commerciali mostruosi che promettono di fare tutto — dal sito di e-commerce alla gestione di una flotta di droni — e che pesano quaranta megabyte solo di configurazioni. Sono partito dal template più spoglio, basico e “spartano” che ho trovato sulla rete. Una tela bianca, quasi trasparente tessuta da un certo Thapelo Moeti (credetemi, dal suo codice è uno che sa cosa vuol dire programmare), un template che già di suo è un mezzo capolavoro di spartana raffinatezza.

Da lì in poi, è iniziato il lavoro di cesello: ho aperto i file PHP, ho preso l’accetta e ho iniziato a personalizzare il codice direttamente. Se c’era una funzione ridondante, eliminata. Se c’era una chiamata a funzioni esterne che non mi serviva, cancellata. Lo stile visivo e la logica delle pagine non sono il risultato di un configuratore grafico dove trascini i blocchi con il mouse, ma della mia manipolazione diretta dei fogli di stile e dei file core del tema.

Il dettaglio della gestione

Gestire un sito “fatto e finito” in questo modo è una questione di igiene mentale e professionale. Significa governare una catena di relazioni precise, dove ogni anello ha un senso:

  • La pulizia semantica contro le matrioske di codice: se apro il sorgente di una mia pagina, vedo una struttura logica. C’è un inizio, uno sviluppo, una fine. Se apro il sorgente di un sito WordPress gestito da un “assemblatore” con i moderni page builder visivi, mi trovo davanti a un incubo di tag <div> nidificati l’uno dentro l’altro come matrioske impazzite. Pagine da cinque righe di testo che pesano quattro megabyte solo di impalcatura strutturale. È l’equivalente di costruire un canile usando la stessa quantità di cemento di un grattacielo a Dubai.
  • La guerra al “Bloatware”: modificare il PHP del template a mano significa che se una regola o una funzione non serve, semplicemente non viene eseguita. Oggi va di moda installare quindici plugin diversi per fare cose banali (come, appunto, calcolare un tempo di lettura o mostrare i post correlati). Risultato? Il server fatica, il database si ingolfa di query inutili e il browser dell’utente deve scaricare e processare migliaia di righe di codice spazzatura. Noi lo chiamiamo progresso; io lo chiamo pigrizia mascherata da efficienza.
  • La sicurezza della solitudine: un sito WordPress senza una collezione di trenta plugin di terze parti, senza script di tracciamento esterni, senza librerie remote richiamate chissà dove, è un sito intrinsecamente sicuro e fulmineo. Non perché io sia un guru della cybersecurity, ma perché la superficie d’attacco è ridotta al minimo indispensabile. Non c’è una porta sul retro lasciata aperta dall’estensione per i commenti scritta da uno sviluppatore neozelandese che ha abbandonato il progetto cinque anni fa.

Gestione = controllo (dell’informatico)

Mantenere questo livello di controllo a 360 gradi costa fatica. Richiede di ricordarsi la sintassi, di studiare i protocolli, di non accettare la prima soluzione comoda che capita. Ma restituisce una cosa che oggi sembra merce rara: l’indipendenza. Se domani il mercato decide che un certo plugin di grido diventa a pagamento o cambia licenza, chi ha costruito la sua casa mattone su mattone non batte ciglio. Gli altri corrono ai ripari, piangendo in forum affollati.

STOP!

Ok, me lo vedo già, il fenomeno di turno che arriva e punta il dito: “Fai tutto sto bel discorso e poi parti da un template scritto da altri? Bella coerenza!” La mia risposta è di una semplicità disarmante: sì, e quindi?
C’è un abisso invalicabile tra l’utilizzare il lavoro di un professionista in modo consapevole e l’abdicare al pensiero delegando a una scatola chiusa. Thapelo Moeti, il creatore del template, è un gran programmatore: vorrei essere bravo anche solo la metà di lui. Il suo codice è pulito, snello e privo di fronzoli; usarlo mi ha fatto risparmiare giorni di lavoro, evitando di dover reinventare la ruota.
La differenza sta tutta nel metodo. L’assemblatore moderno installa un pacchetto alla cieca, ci butta sopra dieci plugin per farlo funzionare e, se qualcosa si rompe, prega l’AI che gli sputi fuori una pezza da incollare sopra. Io quel pacchetto l’ho aperto, e ci ho guardato dentro ben bene; ho preso il lavoro di Thapelo, l’ho analizzato riga per riga, l’ho smontato e l’ho gestito io, piegandolo alle mie esigenze. Ogni singola modifica e lo stesso contatore del tempo di lettura sono stati inseriti con piena consapevolezza. Se domani qualcosa va in crash, non devo chiedere aiuto a un algoritmo: so esattamente dove mettere le mani perché quel codice adesso lo governo.
Collaborare e sfruttare l’astrazione consapevole è l’essenza dell’informatica; il “clicca e spera”, invece, è la sua tomba. Mantenere il controllo totale sulle proprie fondamenta non è una contraddizione, è dignità professionale.

Ok, ora possiamo ripartire

La grande abbuffata dell’AI: utile per l’idraulico, letale per l’informatico

Ed è proprio in questo contesto di pigrizia strutturale, dove l’importante è “mettere in piedi qualcosa purché funzioni alla svelta”, che si innesta l’ultima, trionfale frontiera dell’automazione: l’intelligenza artificiale generativa che promette di scriverti un sito intero in tre secondi netti, partendo da una riga di descrizione.

Intendiamoci subito, per evitare che qualcuno pensi al solito riflesso condizionato del luddista con il principio di ulcera: l’utilità di questi strumenti è indiscutibile. Ma, come per ogni tecnologia, il valore non sta nell’attrezzo in sé, bensì nella risposta a una domanda fondamentale (che poi in effetti sono due): chi lo sta usando, e per quale mestiere?

Prendiamo il caso di un idraulico, di un ristoratore di provincia o di un artigiano che modella il legno. Persone che giustamente investono dodici ore al giorno nella qualità del loro lavoro reale. Hanno bisogno di una presenza online, di una vetrina digitale minimale che dica dove trovarli, a che ora aprono e che faccia vedere due foto dei loro prodotti. Per loro, l’AI che sputa fuori una pagina standard partendo da tre righe di istruzioni è una benedizione collettiva. Permette di colmare un divario digitale a costo quasi zero, senza costringerli a spendere budget che non hanno o a perdere nottate a capire la differenza tra un posizionamento relativo e uno assoluto nei fogli di stile.

Il loro valore risiede nella tenuta dei tubi che saldano o nel sapore dei tortelli che servono a tavola. Che il codice dietro quella vetrina sia un ammasso informe di istruzioni ridondanti, pesante da caricare e strutturalmente sbilenco, all’economia della loro attività non importa nulla. In questo caso, l’intelligenza artificiale compie la sua missione più nobile: democratizza uno strumento di supporto per promuovere un altro mestiere.

Informatico ed AI: chi usa chi?

Il paradosso inquietante — e lasciatemelo dire, a tratti grottesco — sorge quando questo identico approccio viene adottato, sbandierato e difeso da chi, sulla carta, di mestiere fa il programmatore o lo sviluppatore web.

Se un professionista dell’informatica decide di abdicare al controllo di base a 360 gradi sul codice che produce, c’è un problema di fondo che non riguarda più la tecnologia, ma l’identità stessa della professione. Perché dovresti rinunciare a pensare la struttura di una pagina? Perché dovresti delegare la logica di funzionamento a un modello probabilistico che si limita a prevedere la parola successiva basandosi sulla media statistica di tutto ciò che ha trovato pescando nel gran calderone del web?

La risposta che ci sentiamo ripetere fino alla nausea dai guru del marketing digitale è sempre la stessa: “Produttività”. Bisogna fare più cose, più velocemente. Se un’AI ti scrive una funzione in cinque secondi anziché in venti minuti, hai risparmiato tempo.

Ma siamo sicuri che quel tempo sia davvero risparmiato?

Nel mio manifesto l’ho scritto chiaramente: delego volentieri all’intelligenza artificiale il ruolo di copy-editor per la caccia ai refusi o per scovare quel microscopico bug sintattico che sfugge all’occhio stanco dopo ore di debug. La macchina è bravissima a fare il lavoro di routine, il controllo ortografico del codice. Ma usarla come “autrice” dell’architettura significa accettare una scatola chiusa dentro un’altra scatola chiusa.

Quando chiedi a un algoritmo di generare un blocco di logica, non stai creando; stai semplicemente validando l’output di un intermediario. Se quel codice funziona al primo colpo, ti senti un’aquila del software. Se però quel codice nasconde una sottigliezza algoritmica inefficiente, o una vulnerabilità che si attiva solo in determinate condizioni di carico sul database, ti ritrovi in mano un oggetto di cui non conosci la genealogia profonda. Non l’hai pensato tu, non l’hai disegnato tu: sei solo il custode distratto di un pezzo di software orfano.

Rinunciare a questo controllo significa smettere di essere architetti e accettare il ruolo di spettatori del proprio lavoro. E se l’informatica perde la pretesa di governare la logica della macchina riga per riga, smette di essere una disciplina scientifica e diventa una pura attività di consumo.

Il tramonto del programmatore informatico e l’era degli “incollatori di script”

L’obiezione sorge spontanea, ed è una di quelle che fotografa senza sconti la realtà del mercato attuale: “Ma quale idraulico, oggi, spenderebbe migliaia di euro per pagare uno specialista e farsi fare un sito vetrina, quando con pochi euro e tre clic può fare tutto da solo?”

La risposta è disarmante nella sua schiettezza: nessuno. Nessun artigiano sano di mente lo farebbe, e ha perfettamente ragione.

Se vent’anni fa mettere online una pagina web richiedeva necessariamente qualcuno che sapesse configurare un server Apache, addomesticare i fogli di stile e combattere contro le bizzarrie criminali di Internet Explorer, oggi quel bisogno è evaporato. Con piattaforme commerciali o con i generatori AI integrati nei servizi di hosting, l’artigiano compila tre campi, trascina una foto, paga l’abbonamento mensile e il sito è online. Fine del problema.

L’intelligenza artificiale e l’automazione di massa hanno letteralmente cannibalizzato la fascia bassa del mercato. Hanno estinto, per selezione naturale, quella figura di “webmaster della domenica” che campava ordinando template su internet, installando pacchetti WordPress preconfezionati e rivendendoli a peso d’oro a chi non sapeva dove mettere le mani. Quel tipo di attività è morta, ed è un bene: l’automazione ha ripulito il settore da un servizio a bassissimo valore aggiunto.

Il cambio di paradigma dell’informatico medio

A livello superficiale, qualcuno potrebbe persino chiedere: ma ormai quale informatico dovrebbe preoccuparsi di imparare a controllare così a fondo un sito internet? Perché impazzire a limare il singolo kilobyte di codice PHP, a configurare il database a mano o a ottimizzare maniacalmente i fogli di stile? I server costano pochissimo, la potenza di calcolo è praticamente infinita e gli utenti viaggiano tutti con connessioni in fibra o in 5G. Chi se ne frega se una pagina pesa dieci megabyte invece di cinquanta kilobyte? Tanto la banda c’è.

È un ragionamento lineare, quasi seducente. Ha il sapore dell’efficienza pragmatica: non sprecare ore di lavoro umano (che costa caro) per ottimizzare risorse hardware (che costano pochissimo, …in verità non poi così poco, ma sto divagando). Se la macchina può sopperire alla pigrizia del programmatore, che lo faccia.

Peccato che questa tesi si regga su un’enorme illusione ottica e che, dietro la facciata del progresso, nasconda un cortocircuito culturale spaventoso. Il vero dramma non è l’idraulico che usa lo strumento automatico; il dramma è che chi si definisce “sviluppatore” e dovrebbe progettare l’architettura di un sistema complesso, ha iniziato ad adottare lo stesso identico approccio mentale dell’idraulico.

A new era

Siamo entrati ufficialmente nell’era degli “assemblatori di codice”, o se vogliamo essere più onesti, degli incollatori di script.

La mutazione generazionale è evidente a chiunque frequenti le stanze dello sviluppo software negli ultimi anni. Un tempo, l’essenza dell’informatica risiedeva nel problem solving algoritmico: avevi una risorsa limitata e dovevi spremerti le meningi per scrivere la logica più efficiente possibile per raggiungere l’obiettivo. Oggi, la prima reazione davanti a un problema tecnico non è più la riflessione, ma la delega.

Si interroga l’AI generativa, si copia il blocco di codice sputato fuori dal prompt e lo si incolla nel proprio editor, spesso incrociando le dita. Se la pagina si carica e non restituisce un errore macroscopico in console, il compito viene considerato assolto.

Cui prodest?

Questo modo di lavorare, giustificato dal mantra del “tanto c’è banda”, produce una serie di conseguenze sistemiche il cui conto si paga:

  • L’estinzione della memoria storica: stiamo crescendo una generazione di tecnici che sa richiamare un’API o utilizzare un framework di grido, ma che non ha la benché minima idea di come funzioni il protocollo HTTP sottostante, di come si strutturi una query SQL ottimizzata o di come il browser renderizzi effettivamente i blocchi sullo schermo. Se si spegne la rete, l’assemblatore si ritrova completamente inerme.
  • La cultura del “funzionicchia” e il carico sull’utente: quando un programmatore rinuncia al controllo, scarica il barile dell’inefficienza sul dispositivo dell’utente. Quel sito pesante, costringerà lo smartphone del lettore a compiere milioni di cicli di calcolo superflui. La batteria si scarica prima, scalda e l’esperienza utente si degrada non appena ci si allontana dalla fibra dell’ufficio. Trasformare il software in un pachiderma, solo perché l’hardware lo permette, è un atto di profonda pigrizia.
  • L’incubo della manutenzione: finché il castello di carte sta in piedi, tutto bene. Ma il software cambia, evolve, si rompe. Il giorno in cui quel database configurato alla “vivailparroco” smette di rispondere perché il traffico aumenta, l’assemblatore si ritrova cieco davanti alla sua stessa creatura.
  • La perdita del controllo: accettare l’idea che non serva più controllare il codice significa consegnarsi mani e piedi ai grandi monopolisti dei servizi digitali. Se non sai più come si costruisce una struttura da zero diventi un ostaggio tecnologico. Se domani quel fornitore cambia le regole del gioco o raddoppia i prezzi…

Per l’idraulico funziona per l’informatico no

L’idraulico ha il diritto sacrosanto di ignorare cosa sia la complessità computazionale, perché il suo valore si misura sulla tenuta dei tubi che salda. Ma se l’informatico abdica al vizio di pensare e rinuncia al controllo a 360 gradi sulla macchina, smette di essere un progettista. Diventa un utente di lusso, un passacarte tecnologico che mette la firma su decisioni d’architettura prese da un modello statistico.

L’automazione ha liberato l’artigiano dalla dipendenza tecnica. Ma se chi fa questo mestiere la usa per liberarsi dallo sforzo del pensiero logico, non sta aumentando la propria produttività: sta solo certificando la propria obsolescenza.

La catena di montaggio senza ingegneri: chi progetterà le macchine di domani e il grande equivoco del “rimpiazzo”

Arrivati a questo punto, solleviamo il velo sull’ultimo, vero tabù di tutta questa vicenda. C’è una domanda ancora più profonda, quasi vertiginosa, che nessuno nel circo del marketing tecnologico sembra voler porre, ma che è l’unica che conta davvero sul lungo periodo: tutte queste meraviglie che usiamo oggi — le connessioni superveloci in fibra, i chip al silicio microscopici, i server virtuali elastici e, ironia della sorte, le stesse intelligenze artificiali generative — da dove arrivano?

La risposta è banale: qualcuno le ha pensate. Qualcuno ha passato notti insonni a comprendere la fisica dei semiconduttori, a ottimizzare i protocolli di rete riga per riga, a testare architetture software complesse e a rilasciare sistemi stabili. Dietro ogni singola “scatola nera” automatica che oggi permette a un assemblatore di cliccare un bottone e sentirsi un demiurgo digitale, ci sono decenni di autentico, ostinato e profondo saper pensare. Ci sono generazioni di scienziati, ingegneri e programmatori che hanno scavato la roccia con il piccone della logica per costruire le fondamenta su cui oggi poggiamo i piedi.

E qui sta il punto di contatto definitivo: il processo mentale che serve a creare l’algoritmo di un’intelligenza artificiale o a progettare una rete neurale è esattamente lo stesso che serve a costruire un semplice sito internet riga per riga.

Il pensiero è pensiero, l’informatico è uomo

Non c’è una differenza qualitativa nella natura del pensiero. In entrambi i casi, l’essenza del lavoro risiede nel dominare la catena delle relazioni logiche, nel capire come un input si trasforma in output, nel prevedere l’eccezione, nell’ottimizzare la risorsa e nel mantenere il controllo totale sulla struttura. Certo, cambiano la scala e la complessità matematica, ma l’igiene mentale e il rigore richiesti sono identici. Chi impara a padroneggiare il codice di una pagina web, a piegare il PHP alle proprie esigenze o a pulire un database MySQL a mano, sta allenando lo stesso identico muscolo cognitivo di chi progetta i sistemi operativi del futuro.

E qui si innesta e si chiude il cerchio con la tesi del tramonto del programmatore, svelando l’idolo horror del momento, il mantra apocalittico sbandierato dai profeti della Silicon Valley: “L’intelligenza artificiale rimpiazzerà completamente la professione dell’informatico”. È una tesi che riempie le pagine dei giornali, ma che a un’analisi appena più profonda mostra delle lacune logiche imbarazzanti. Presenta una superficialità pericolosa, figlia della totale ignoranza di cosa sia, concretamente, questo mestiere.

La definizione di “informatico”

Il primo, colossale errore risiede nella domanda stessa: che cosa significa, oggi, “informatico”? Parlare genericamente di informatico come di un blocco unico e monolitico è come parlare di “medico” per dire che un cardiochirurgo, un dermatologo, un farmacologo e l’amministratore di un ospedale fanno esattamente la stessa cosa. L’informatica non è un mestiere, è un ecosistema di discipline profondamente diverse, ognuna con il proprio rigore e la propria materia prima. Cito ad esempio di 4 macro-categorie di “informatici”:

  • Il DBA (Database Administrator): è il guardiano dei dati. Colui che progetta le strutture concettuali, che ottimizza gli indici e che sa esattamente come evitare che un server si inginocchi quando un milione di utenti interroga contemporaneamente il sistema. L’AI può scriverti una query, ma non ha la visione d’insieme per capire l’architettura dei dati di un’azienda (no, nemmeno le AI fatte apposta, almeno non ancora).
  • Il Sistemista: è l’uomo del ferro e delle reti. Quello che configura i protocolli di sicurezza, gestisce il routing, bilancia i carichi sui server e interviene a cuore aperto quando l’infrastruttura decide di fare le bizze (qualcuno dirà che adesso c’è il cloud, senza pensare a che cos’è nel concreto questo cloud).
  • L’Analista: è colui che traduce il caos dei bisogni umani (spesso confusi e contraddittori) in specifiche logiche e matematiche. È il ponte tra la realtà e la macchina, un compito che richiede empatia, psicologia e una comprensione profonda dei processi reali.
  • Il Programmatore: l’artigiano che traduce quelle specifiche in codice pulito, efficiente e mantenibile.

E quindi?

Pensare che un algoritmo probabilistico basato sul testo, ancorché iper-specializzato, possa cancellare di colpo tutte queste professionalità significa non aver capito che il codice è solo l’ultimo miglio di un processo lunghissimo.

Ma la lacuna più grande della tesi del rimpiazzo è di natura squisitamente logica ed è il cuore del problema di chi progetterà il domani: chi, se non un ottimo “informatico”, può davvero controllare l’AI sotto il cofano?

I modelli logistici di AI che usiamo oggi non sono entità mistiche scese dal cielo; sono costrutti matematici complessi, reti neurali che girano su cluster di server giganteschi, ottimizzati da algoritmi di compressione della memoria, gestiti da pipeline DevOps mastodontiche e alimentati da database distribuiti dalla complessità mostruosa. Chi ha progettato l’architettura hardware e software di queste intelligenze artificiali? Chi ha scritto i compilatori, ottimizzato i driver delle GPU e ripulito i set di dati per addestrarle? Gli “informatici”. Quelli veri, quelli con il controllo a 360 gradi.

Se la narrazione corrente vince, se l’idea che “capire il codice non serve più perché tanto c’è la macchina che lo fa per te” diventa la norma della formazione, e smettessimo di crescere DBA, sistemisti e programmatori consapevoli, l’evoluzione delle stesse intelligenze artificiali si fermerebbe. La macchina non può programmare se stessa oltre il limite della propria statistica; ha bisogno dell’intelligenza umana per ridefinire i paradigmi, per trovare soluzioni a problemi mai visti prima e per correggere i propri stessi errori. Se non si domina il piccolo, se si rinuncia a governare l’architettura elementare di un sito perché considerata “robetta artigianale superata”, si perde la capacità stessa di concepire il grande. Il gioco finisce lì.

In che era stiamo entrando davvero?

Ci stiamo avviando a grandi passi verso uno scenario di “feudalesimo tecnologico”: un mondo in cui pochissime grandi multinazionali possiedono e comprendono gli algoritmi di base, i sistemi operativi e le infrastrutture fisiche, mentre una sterminata massa di “professionisti” declassati si limita a fare manutenzione di facciata a sistemi di cui ignora completamente il funzionamento intimo. Diventiamo come quegli abitanti delle civiltà post-apocalittiche nei romanzi di fantascienza, che venerano macchine ancestrali lasciate dagli antenati, sanno quali pulsanti premere per farle funzionare, ma non hanno la più pallida idea di come ripararle se smettono di girare.

L’informatica è sempre stata una disciplina di astrazione, è vero: si costruiscono strati sopra strati per non dover reinventare la ruota ogni volta. Ma c’è una differenza fondamentale tra l’astrazione consapevole e l’ignoranza istituzionalizzata. L’astrazione ti permette di dimenticare momentaneamente il dettaglio per guardare il quadro generale; l’ignoranza ti impedisce di scendere a riparare il motore quando si rompe.

Dove si inserisce, quindi l’AI?

L’AI non rimpiazzerà l’informatico; rimpiazzerà l’impiegato del codice, il passacarte digitale, l’assemblatore distratto che copia e incolla pezzi di software senza capirli. Ecco perché difendere il controllo a 360 gradi del proprio piccolo spazio digitale non è un vezzo nostalgico da dinosauri innamorati della riga di comando. Non è la patetica resistenza di chi rifiuta il futuro. Al contrario, è un atto di igiene intellettuale e di responsabilità etica. È il tentativo di mantenere viva la scintilla del dubbio, della curiosità e del rigore logico in un’epoca che premia la pigrizia spacciandola per efficienza.

Se smettiamo di capire come funzionano gli strumenti che usiamo, smettiamo di essere i padroni della tecnologia e ne diventiamo, semplicemente, gli inquilini. E a un inquilino, si sa, basta che la luce si accenda quando preme l’interruttore; ma se l’intero impianto elettrico della società comincia a fare scintille, c’è un disperato bisogno di qualcuno che sappia ancora leggere lo schema dei fili.

La burocrazia dell’astrazione: quando il processo uccide il codice (e il trionfo degli “esseri eterei”)

Se la perdita del controllo tecnico e la delega all’intelligenza artificiale rappresentano la minaccia esterna, esiste una forza interna al mondo dello sviluppo software che sta compiendo lo stesso identico lavoro di logoramento: l’iper-strutturazione metodologica. Mi riferisco alla sfilata trionfale di sigle e filosofie che negli ultimi decenni hanno colonizzato i reparti IT: prima il Waterfall, poi la rivoluzione dell’Agile, lo Scrum, i framework DevOps, e chi più ne ha più ne metta.

Chiariamo subito un equivoco, a scanso di fraintendimenti: non c’è nulla di intrinsecamente sbagliato in queste metodologie. Dare una struttura al lavoro, stabilire delle regole chiare, organizzare il flusso di rilascio del software e automatizzare i test sono pratiche non solo giuste, ma sacrosante quando la scala dei progetti aumenta. Il problema sorge quando si supera quel limite invisibile oltre il quale la regola smette di servire la realtà e inizia a sostituirla. Quando il processo diventa più importante del prodotto. Le regole devono aiutare la realtà, non astrarla fino a renderla completamente avulsa dal concreto.

Gli attori del teatrino informatico

Ed è proprio in questa frattura tra l’impalcatura teorica e la concretezza del codice che si inseriscono le figure centrali di questo teatrino. Diciamocelo chiaro e tondo, senza girarci troppo intorno: oggi trovare un Project Manager o uno Scrum Master che capisca qualcosa di informatica — o di qualunque altra cosa concreta che abbia a che fare con la materia prima del progetto — è diventata una rarità assoluta.

Ci troviamo davanti a una sorta di essere etereo. Una figura che non scrive una riga di codice, non sa configurare un database, non ha la minima idea di cosa sia una chiamata asincrona e vive in una dimensione parallela fatta esclusivamente di diagrammi di Gantt, fogli Excel colorati, slide di PowerPoint e bacheche Jira (orresco referens). Il suo intero universo professionale è composto da parole d’ordine vuote, mutuate dall’ultimo manuale di management americano: allineamento, sinergia, flessibilità, vision. È un burocrate puro, un guardiano del processo che ha scambiato la mappa con il territorio. E la verità, per quanto sgradevole da ammettere, è che questo genere di figura è perfettamente inutile quando non, addirittura, attivamente dannosa.

A questo proposito, circola da decenni negli ambienti tecnici una storiella classica, un paradigma che illustra alla perfezione la cecità intellettuale di questa categoria. Chiediamo subito scusa alle signore per la natura sfacciatamente irriverente e irrispettosa dell’esempio, ma la metafora è purtroppo lo specchio fedele di una tragica realtà aziendale: il Project Manager etereo è quello convinto che, se la gestazione di un bambino richiede nove mesi, basti assumere nove donne contemporaneamente per far nascere un bambino in un mese solo.

Il distacco dalla concretezza

Dietro l’ironia feroce di questo paradosso si nasconde il dramma quotidiano di chi scrive codice. L’essere etereo, non avendo alcun contatto con la materia concreta, è convinto che lo sviluppo software sia una mera questione di aritmetica e di risorse intercambiabili. Non capisce che la programmazione è un’attività intellettuale e sequenziale, dove la logica ha i suoi tempi biologici e le sue dipendenze strutturali. Se un’architettura PHP richiede tempo per essere assimilata e scritta con criterio, raddoppiare il numero di persone sul progetto non dimezzerà i tempi; spesso, anzi, creerà solo più caos, costringendo i tecnici a passare le giornate a spiegare ai nuovi arrivati dove mettere le mani.

Oggi assistiamo a un paradosso grottesco: si passano ore e ore in riunioni quotidiane a spostare cartellini virtuali su una bacheca Kanban, si discute animatamente sulle metriche di “velocità del team”, si pianificano “sprint” bisettimanali con il rigore di un piano quinquennale, e poi… il codice che viene effettivamente rilasciato è un ammasso informe di script incollati dall’AI, pesante, inefficiente e instabile.

L’essere etereo è inutile perché non porta alcun valore aggiunto al manufatto. Se un programmatore si scontra con un bug strutturale complesso, con un collo di bottiglia nel database o con un template PHP che si comporta in modo imprevisto, il manager non può aiutarlo. Tutto ciò che può fare è chiedergli, ogni due ore: “A che punto sei? Riusciamo a chiudere il ticket entro stasera?”. È l’equivalente di un capocantiere che non sa come si impasta il cemento ma pretende di spiegare ai muratori il ritmo con cui posare i mattoni.

Le conseguenze

E diventa dannoso nel momento in cui la sua totale ignoranza della materia concreta si scontra con la gestione dei tempi. Non capendo la complessità intrinseca del software, ragiona per analogie astratte e scadenze arbitrarie. Per lui, scrivere una funzione logica complessa o cambiare il colore di un bottone sono attività equivalenti, misurabili in “punti di complessità” decisi a tavolino. Se il team tecnico fa notare che un’architettura è fragile e che servirebbe tempo per riscriverla e ottimizzarla da zero, il manager subisce un cortocircuito: “Non c’è tempo, dobbiamo rilasciare la feature, mettete una pezza e andiamo avanti”.

Questa burocratizzazione è la perfetta alleata della pigrizia tecnica e dell’uso indiscriminato delle intelligenze artificiali “incolla-script”. Il manager non vuole un codice pulito, efficiente e sovrano; vuole che la casella su Jira diventi verde nel giorno prestabilito, per poter mostrare la sua slide colorata al direttore generale.

Cosa ne deriva?

Il programmatore non è più un artigiano della logica che cerca la soluzione ottimale; è diventato un operaio di linea che deve solo chiudere il suo ticket nel minor tempo possibile, non importa come. Molto meglio chiedere all’AI di scrivergli una pezza veloce, incollarla, verificare che la pagina “funzionicchia” e passare oltre. Il processo è salvo, la metrica è verde, il manager è felice. Peccato che l’applicazione sia diventata un mostro un po’ più pesante e ingovernabile.

Le regole dovrebbero servire a garantire la solidità del manufatto informatico, non a creare un’impalcatura così densa da nascondere la totale mancanza di sostanza sottostante. Quando la gestione del processo diventa fine a se stessa e viene affidata ad analfabeti della materia, il collasso qualitativo è inevitabile. Ci si dimentica che, alla fine di tutta la fiera, ciò che conta davvero è come gira quel bit sul server, quanto è pulito quell’HTML e quanta consapevolezza c’è stata dietro la scrittura di ogni singola riga. La realtà non si cura dei cartellini colorati su una bacheca: si cura solo di come risponde il server quando un utente clicca su un link. E lì, l’astrazione manageriale evapora all’istante.

Conclusioni: la fisica delle piccole cose

Me lo immagino, il lettore arrivato pazientemente alla fine di questo lungo sfogo, che si gratta la testa e dice tra sé e sé: “’Mazza, tutta sta roba partendo da un semplice contatore di tempo di lettura? Ma questo che è? Ha tirato in ballo i massimi sistemi dell’informatica, il declassamento di una professione, il feudalesimo tecnologico e i Project Manager eterei, solo perché voleva mettere una barra di avanzamento su un blog WordPress?”

L’obiezione ci sta tutta, lo ammetto. Può sembrare l’iperbole di un tizio nerd con troppo tempo libero (cosa di cui abbiamo già parlato). Ma la verità è che nell’informatica, così come nella fisica, le leggi che governano l’universo si riflettono fedelmente anche nella più piccola delle particelle.

Quel piccolo contatore di tempo è stato solo il sasso che, lanciato nello stagno, ha mostrato le crepe di una superficie che tutti si ostinano a dichiarare solida. È la dimostrazione che non esistono “piccoli dettagli” quando si parla di architettura software: o si domina la struttura dall’inizio alla fine, con rigore e consapevolezza, oppure si accetta di essere semplici passeggeri su un treno guidato da automatismi di cui ignoriamo la destinazione.

Piccole? Vi par poco?

Costruire un sito internet riga per riga, sporcandosi le mani con il PHP, configurando il database a mano e rifiutando la pappa pronta dei page builder o degli script prelevati a colpi di prompt, non è un vezzo nostalgico. È una dichiarazione d’indipendenza. È il rifiuto del web “gridato”, pesante, standardizzato e ingordo di risorse.

Il mio consiglio — perché di un consiglio etico e professionale si tratta, non certo di una pretesa — a chi vuole ancora fare questo mestiere con dignità è semplice: torniamo a rivendicare la sovranità del nostro codice. Non lasciamo che i processi burocratici o le scorciatoie probabilistiche delle intelligenze artificiali ci tolgano il vizio più nobile che abbiamo: lo sforzo del pensiero logico.

Alla fine della fiera, quando un utente cliccherà su una pagina di questo sito, saprà esattamente quanti minuti della sua vita gli sto chiedendo per leggere le mie parole. Ma saprà anche che quel tempo è rispettato da un contenitore leggero, pulito e pensato apposta per lui. Perché dietro quel contatore non c’è una scatola nera assemblata a caso: ci sono solo un server, un database, poche righe di codice consapevole e un essere umano che sa ancora esattamente cosa c’è scritto dentro.

Post Scriptum: la biro spaziale e la matita di grafite

E se dopo tutte queste parole ci fosse ancora qualcuno non del tutto convinto, qualcuno rimasto dell’idea che, in fondo, complicarsi la vita a scrivere codice a mano sia solo un anacronismo nell’era delle intelligenze artificiali e dei server infiniti, vorrei lasciargli un’ultima immagine su cui riflettere.

È una vecchia storiella che circola da decenni negli ambienti scientifici e ingegneristici. Gli storici dicono che sia falsa, o quantomeno ampiamente romanzata, ma la sua morale rimane drammaticamente, meravigliosamente vera.

Si racconta che negli anni Sessanta, in piena corsa allo spazio, la NASA si scontrò con un problema apparentemente insormontabile: le normali penne a sfera non funzionavano in assenza di gravità, perché l’inchiostro non riusciva a scendere verso la punta. Gli americani, fedeli alla loro filosofia dell’iper-tecnologia e del budget illimitato, investirono anni di ricerca e milioni di dollari per progettare la Space Pen: una penna fantascientifica con cartuccia pressurizzata all’azoto, inchiostro speciale e leghe metalliche avanzate, capace di scrivere capovolta, nel vuoto e a temperature estreme.

E i Sovietici?

I sovietici, davanti allo stesso identico problema logistico, scelsero un approccio diverso: diedero ai loro cosmonauti una matita.

Ecco, il web contemporaneo, i framework da centinaia di megabyte, l’AI usata per incollare script a casaccio e le impalcature burocratiche dei manager eterei sono la nostra Space Pen da milioni di dollari. Uno sforzo monumentale, costosissimo e iper-ingegnerizzato per superare problemi che noi stessi abbiamo creato allontanandoci dalla logica elementare delle cose.

Scrivere una pagina pulita, riga per riga, capendo cosa fa il database e come risponde il server, è la nostra matita di grafite. È la soluzione più semplice, leggera, economica e intrinsecamente efficiente. Funziona sempre, non ha bisogno di aggiornamenti di licenza, non consuma risorse inutili e fa esattamente quello che deve fare: lasciare un segno chiaro su un foglio bianco.

Forse è arrivato il momento di rimettere la biro nel cassetto e ricominciare a temperare le matite.