Quando una civiltà perde la comprensione delle proprie macchine, non perde solo la tecnologia: perde la capacità di governarsi.

Ne Il ciclo della Fondazione di Isaac Asimov c’è un episodio che rende bene questa idea: il mercante Hober Mallow, in visita sul pianeta Siwenna (ancora formalmente sotto l’Impero Galattico, ma già in pieno declino)  incontra un “tecnico”, membro di una casta ereditaria incaricata di mantenere in funzione le ultime centrali nucleari del pianeta. Non sono scienziati: sono custodi di procedure tramandate, capaci di far funzionare macchine di cui hanno perso da generazioni la comprensione reale. La tecnologia, per loro, è diventata una forma di magia operativa: funziona, ma non è più intelligibile nella sua totalità.

Questa intuizione, letta oggi, ha un sapore sorprendentemente contemporaneo. Non perché siamo in una situazione così estrema, ma perché stiamo percorrendo una traiettoria che rende sempre più difficile, per il singolo individuo, mantenere una comprensione completa dei sistemi che utilizza e che contribuisce a costruire.

Nel mondo del software moderno questo fenomeno è già visibile, ed è interessante perché si manifesta su due livelli diversi, entrambi riconducibili alla stessa dinamica di fondo. Il primo è strutturale: un semplice progetto web, avviato con gli strumenti più comuni, porta con sé centinaia di megabyte di dipendenze, migliaia di pacchetti, e una catena di astrazioni che si estende ben oltre ciò che lo sviluppatore ha scritto direttamente. Il codice che si produce è spesso solo una piccola superficie visibile di un ecosistema molto più vasto, composto da librerie, framework, runtime e strumenti che evolvono indipendentemente. Questa frammentazione non è scelta da nessuno in particolare: è la conseguenza accumulata di decenni di stratificazione, esattamente come l’opacità tecnica di Siwenna.

Il secondo livello è invece culturale, ed è più recente: l’adozione crescente di approcci di sviluppo assistiti dall’intelligenza artificiale, spesso riassunti con l’espressione “vibe coding”. L’idea di fondo è quella di ridurre la scrittura esplicita del codice a favore di una descrizione più intuitiva del comportamento desiderato, lasciando agli strumenti il compito di generare l’implementazione. Se la prima forma di opacità è il risultato involontario di un ecosistema che cresce, questa seconda è una scelta deliberata di delega.
La realtà è che il punto d’arrivo, per chi scrive software senza più leggerlo o comprenderlo fino in fondo, è sorprendentemente simile.

Se da un lato questo approccio aumenta la velocità di prototipazione e abbassa la soglia di ingresso allo sviluppo software, dall’altro introduce una ulteriore disintermediazione tra il progettista e il sistema finale. Il codice non viene più necessariamente letto, scritto o compreso nella sua interezza, ma evocato, adattato e accettato in base al risultato atteso.

Un episodio recente rende concreto questo discorso altrimenti astratto. Qualche giorno fa mi è capitato di leggere di un’applicazione sviluppata su misura per un singolo cliente, installata direttamente sul server aziendale tramite container Docker. Una soluzione tecnicamente corretta, perfettamente allineata alle pratiche moderne di distribuzione software, ma che solleva una domanda più ampia: quanto di questa complessità è realmente necessaria, e quanto invece serve principalmente a semplificare la vita a chi sviluppa e distribuisce il software?
Il punto non è Docker in sé, né l’uso di strumenti di automazione o di containerizzazione. Il problema è la tendenza a introdurre livelli di astrazione non per risolvere un problema strutturale, ma per evitare il costo della comprensione del contesto in cui il software viene installato e mantenuto. In un ambiente con migliaia di clienti, sistemi eterogenei e necessità di scalabilità, questa scelta è spesso inevitabile e sensata. In un contesto invece ristretto, con poche installazioni ben definite, il risultato può essere un aumento della complessità complessiva del sistema, piuttosto che una sua riduzione.

Qui ritorna, in forma moderna, la preoccupazione evocata da Asimov. Non si tratta di una perdita improvvisa della conoscenza, ma di una sua progressiva frammentazione. Ogni livello di astrazione è costruito per semplificare ciò che sta sopra, ma al tempo stesso rende più opaco ciò che sta sotto.
Il risultato finale è un sistema che funziona, spesso molto bene, ma che richiede sempre meno persone in grado di comprenderlo nella sua interezza.

Questo fenomeno non è di per sé negativo. L’astrazione è una delle più grandi conquiste dell’ingegneria del software. Senza di essa non esisterebbero sistemi complessi né scalabili. Tuttavia, quando l’astrazione diventa un sostituto della comprensione invece che uno strumento per gestirla, allora si introduce un rischio sottile: quello di costruire sistemi che possiamo usare e modificare rapidamente, ma che diventano sempre più difficili da ricostruire, semplificare o riconsiderare dalle fondamenta.

Il punto critico non è quindi tecnologico, ma culturale. È la domanda su quanto sia ancora necessario comprendere ciò che si costruisce, e su quale sia il livello minimo di conoscenza accettabile per considerare un sistema “controllato”.
In un’epoca in cui la generazione automatica di codice e la proliferazione di framework rendono sempre più facile produrre software funzionante senza necessariamente comprenderlo fino in fondo, questa domanda diventa centrale. Non per rallentare l’innovazione, ma per evitare che la velocità di produzione superi la nostra capacità di governare ciò che produciamo.

Asimov immaginava un futuro in cui la tecnologia era diventata opaca per eccesso di distanza temporale. Oggi il rischio è diverso: non è il tempo a separarci dalla comprensione, ma la stratificazione intenzionale di strumenti pensati per ridurre lo sforzo cognitivo immediato.

E come spesso accade, ciò che semplifica il presente può complicare silenziosamente il futuro.

La foto del titolo è di M.C.Ssebunya con licenza CC0