Nessuno sa cosa sta facendo. Non nel senso banale e un po' autoassolutorio che si usa nelle conversazioni tra colleghi, quando qualcuno alza le spalle e dice che improvvisiamo tutti. In un senso più preciso, più inquietante, e soprattutto più strutturale: la complessità degli oggetti tecnici che abbiamo costruito ha superato la capacità di qualsiasi singolo essere umano di comprenderli. Non per difetto di intelligenza o di formazione. Per una ragione che ha a che fare con la natura stessa di questi oggetti.
Per la maggior parte della storia della tecnica, era possibile trovare almeno una persona che capisse un artefatto nella sua interezza. L'acquedotto romano, il telaio meccanico, la locomotiva a vapore, persino un aereo della seconda guerra mondiale: sistemi complicati, certamente, ma in ultima analisi riconducibili a un sapere unitario. Un ingegnere sufficientemente preparato poteva tracciare la catena causale da un capo all'altro. Poteva dire: so come funziona, so perché funziona, so cosa succede se si rompe. Questa possibilità non era un dettaglio. Era il fondamento su cui poggiava l'idea stessa di competenza tecnica, e insieme a lei l'idea di responsabilità.
Quel fondamento non c'è più.
La soglia #
Il punto di rottura non è stato improvviso. Si è accumulato lungo decenni, invisibile come tutti i cambiamenti che avvengono per stratificazione anziché per frattura. Ogni strato di astrazione aggiunto sopra il precedente risolveva un problema e ne creava un altro: rendeva il livello sottostante opaco. Il programmatore che scrive codice applicativo oggi non conosce davvero il framework che usa. Chi conosce il framework non conosce il runtime. Chi conosce il runtime non conosce il sistema operativo, non fino in fondo. Chi conosce il sistema operativo non conosce il microcodice del processore. E nessuno, proprio nessuno, conosce l'intera catena di dipendenze che un singolo comando di installazione scarica dalla rete e rende parte del proprio software.
Questo non è un'esagerazione polemica. È una descrizione fattuale. Un progetto software medio, nel 2026, include centinaia di dipendenze dirette e migliaia di dipendenze transitive. Ciascuna di queste è stata scritta da qualcun altro, con le proprie dipendenze, le proprie vulnerabilità, le proprie decisioni architetturali prese in un contesto che nessun utilizzatore a valle ricostruirà mai. Eseguire software oggi significa fidarsi. Non nel senso nobile della fiducia tra persone, ma nel senso epistemologico di chi rinuncia a verificare perché la verifica è materialmente impossibile.
C'è stata un'epoca in cui la parola "ingegnere" implicava la possibilità di un controllo totale sul proprio oggetto di lavoro. Quell'epoca è finita. Non tornerà.
Il sapere come illusione di scala #
Il problema non è che sappiamo poco. È che il tipo di sapere che possediamo non è commisurato alla complessità di ciò che operiamo. Sappiamo cose, certo. Sappiamo anche molte cose. Ma il sapere che serve per comprendere un sistema distribuito moderno non è la somma dei saperi individuali: è un sapere che richiederebbe una mente capace di tenere insieme simultaneamente strati che per loro natura sono progettati per essere separati.
L'astrazione, che è il meccanismo fondamentale del pensiero computazionale, funziona proprio perché nasconde. È il suo merito e la sua trappola. Un'interfaccia ben progettata ti libera dal bisogno di sapere cosa succede sotto. Ma quando qualcosa va storto, quando un sistema si comporta in modo imprevisto, scopri che "sotto" c'è un mondo che nessuno nella stanza conosce, e che forse nessuno al mondo conosce nella sua interezza. Non perché il sapere non esista, ma perché è distribuito in modo irrecuperabile tra migliaia di persone che non si sono mai parlate.
È una condizione epistemologica nuova. Non ha precedenti nella storia della tecnica, e ne ha pochi nella storia del pensiero. Il più vicino è forse il problema della divisione del lavoro così come lo descriveva Adam Smith, ma con una differenza sostanziale: Smith parlava di un processo produttivo in cui ogni operaio capiva il proprio pezzo. Qui nessuno capisce davvero nemmeno il proprio pezzo, perché il proprio pezzo poggia su altri pezzi che sfuggono per definizione.
La catena spezzata della responsabilità #
Se nessuno comprende il sistema nella sua interezza, la domanda su chi sia responsabile non ha una risposta soddisfacente. Non perché manchino candidati, ma perché il concetto stesso di responsabilità presuppone qualcosa che qui manca: la possibilità di sapere.
Responsabilità, nella sua radice, significa capacità di rispondere. Di dare conto delle proprie scelte. Ma come si dà conto di una scelta fatta in un contesto che non si poteva comprendere per intero? Come si risponde di un sistema il cui comportamento emerge da interazioni tra componenti che nessun singolo attore ha progettato né previsto?
Il diritto, che su questo ha riflettuto molto più dell'informatica, ha sviluppato nel tempo l'idea di diligenza: non serve capire tutto, basta agire con la cura ragionevolmente attesa da chi svolge quel ruolo. È un compromesso pragmatico e per molti secoli ha funzionato. Ma funzionava perché la distanza tra ciò che si poteva sapere e ciò che si doveva decidere era colmabile con lo studio e l'esperienza. Oggi quella distanza non è colmabile. Non è un divario che si chiude con più formazione o più impegno: è un divario strutturale, prodotto dalla complessità dell'oggetto, non dall'inadeguatezza del soggetto.
La legislazione europea recente lo intuisce, anche se non lo dichiara. Il Cyber Resilience Act, la Product Liability Directive, l'AI Act: tutti questi strumenti normativi cercano di ricostruire catene di responsabilità in un contesto dove quelle catene sono fisicamente spezzate. Lo fanno con strumenti classici: obblighi di documentazione, valutazioni di conformità, registri di rischio. Sono tentativi seri e in molti casi benvenuti. Ma poggiano su un presupposto silenzioso che merita di essere messo in luce: presuppongono che da qualche parte ci sia qualcuno che sa.
Il produttore deve documentare i rischi del proprio prodotto. Ma il produttore non conosce le dipendenze transitive del proprio codice. L'importatore deve verificare la conformità. Ma la conformità è definita rispetto a standard che descrivono proprietà del sistema che nessuno può verificare nella pratica. L'utente deve dare un consenso informato. Ma l'informazione necessaria per un consenso genuino richiederebbe competenze che nemmeno chi ha scritto il software possiede.
Non è cinismo. È la descrizione accurata di una situazione che abbiamo creato passo dopo passo, in buona fede, risolvendo ogni volta il problema immediatamente davanti a noi e aggiungendo ogni volta un grammo di opacità al sistema complessivo.
Il mito della specializzazione #
Una risposta che si sente spesso è che la specializzazione risolve il problema. Nessuno deve capire tutto: basta che ognuno capisca bene il proprio pezzo, e l'insieme funzionerà. È il principio della divisione del lavoro applicato alla conoscenza, ed è enormemente attraente perché permette di non affrontare la questione di fondo.
Ma non funziona. Non funziona perché i confini tra i "pezzi" sono arbitrari e permeabili. Un problema di sicurezza attraversa tutti gli strati. Un requisito normativo taglia trasversalmente frontend, backend, infrastruttura, fornitori terzi. Una decisione architetturale presa cinque anni fa in un contesto che non esiste più vincola oggi scelte che chi la prese non avrebbe potuto immaginare.
La specializzazione funziona quando i componenti sono davvero indipendenti. Il software non è fatto di componenti indipendenti. È fatto di dipendenze, nel senso più letterale: ogni parte dipende da altre parti, e il comportamento dell'insieme non è deducibile dal comportamento delle parti. È ciò che la teoria dei sistemi chiama emergenza, e l'emergenza è precisamente l'avversario della specializzazione. Il bug più insidioso è sempre quello che vive nello spazio tra le specializzazioni, dove nessuno guarda perché nessuno pensa che sia il proprio territorio.
L'incompetenza di chi legifera #
C'è un caso particolare che merita attenzione, non per spirito accusatorio ma perché è strutturalmente illuminante: l'incompetenza di chi scrive le norme.
Un legislatore che scrive regole sul software è nella stessa posizione epistemologica di chiunque altro: non può comprendere il sistema nella sua interezza. Ma a differenza di un programmatore o di un architetto software, il legislatore non ha nemmeno la conoscenza parziale che viene dall'uso quotidiano. Opera su descrizioni di descrizioni, su astrazioni di astrazioni, mediate da consulenti che a loro volta mediano il sapere di specialisti.
Questo non è un argomento contro la regolamentazione. Al contrario: è un argomento sulla natura della regolamentazione possibile. Normare ciò che non si comprende per intero non è un fallimento, è la condizione di partenza. La domanda non è se il legislatore sia competente — non può esserlo, nel senso pieno del termine, e non per colpa sua. La domanda è se le norme che produce siano abbastanza robuste da funzionare nonostante l'incompetenza strutturale di chi le ha scritte, di chi le deve applicare, e di chi le deve verificare.
A volte la risposta è sì. Il GDPR, con tutti i suoi limiti, ha introdotto un principio di cautela che funziona precisamente perché non richiede comprensione tecnica: tratta i dati personali come se fossero pericolosi, indipendentemente dal fatto che tu capisca i meccanismi specifici del pericolo. È una norma progettata per l'incompetenza, e per questo funziona meglio di molte norme che presuppongono competenza.
Socrate nel ciclo di sviluppo #
C'è una frase che viene attribuita a Socrate con la frequenza e l'imprecisione riservate a tutte le frasi troppo utili: "so di non sapere." La si cita come gesto di umiltà, a volte come civetteria intellettuale. Ma nella sua versione più radicale, quella dell'Apologia platonica, il punto è diverso e molto più scomodo: Socrate non dice semplicemente che la sua conoscenza è limitata. Dice che chi crede di sapere è in una condizione peggiore di chi sa di non sapere, perché all'ignoranza aggiunge l'illusione.
Applicata al presente tecnologico, la tesi socratica acquista un peso che Platone non avrebbe potuto immaginare. L'industria del software è costruita su una doppia illusione di sapere: quella di chi costruisce i sistemi (che crede di controllarli) e quella di chi li usa (che crede di capirli). Entrambe sono funzionali. Senza la prima illusione nessuno scriverebbe codice, perché l'onestà integrale sulla propria ignoranza sarebbe paralizzante. Senza la seconda nessuno userebbe software, perché il consenso informato autentico produrrebbe un rifiuto di massa.
Funzioniamo, come individui e come industria, grazie a una sospensione volontaria dell'incredulità epistemologica. Non diversamente da come funziona la finanza, o la politica, o qualsiasi altro sistema complesso in cui la fiducia sostituisce la comprensione.
Ma c'è una differenza. La finanza e la politica hanno sviluppato nel tempo una consapevolezza istituzionale della propria fragilità epistemologica. Le banche centrali esistono perché sappiamo che il sistema finanziario non si autoregola. Le costituzioni esistono perché sappiamo che il potere non si autolimita. L'informatica non ha ancora sviluppato nulla di equivalente. Non ha istituzioni progettate per gestire il fatto che nessuno sa. Ha standard, ha best practice, ha framework di certificazione: tutti strumenti che presuppongono la possibilità del sapere anziché fare i conti con la sua impossibilità.
Decidere senza sapere #
La condizione quotidiana di chi lavora nella tecnologia è questa: decidere senza sapere. Non nel senso drammatico di una scommessa alla cieca, ma nel senso ordinario e un po' logorante di chi ogni giorno compie scelte con conseguenze pluriennali basandosi su informazioni che sa essere incomplete, in contesti che sa destinati a cambiare, per requisiti che sa essere provvisori.
Una stima è una dichiarazione di probabilità soggettiva spacciata per previsione. Una scelta architetturale è un atto di fede nella stabilità di condizioni che non sono stabili. Un refactoring è una scommessa sul fatto che il costo presente sarà ripagato da benefici futuri che nessuno può garantire. Ogni sprint è un esercizio di epistemologia applicata sotto costrizione temporale, condotto da persone che non hanno studiato epistemologia e che non vengono pagate per riflettere sulle condizioni di possibilità del proprio sapere, ma per produrre risultati.
Questa non è una denuncia. È una descrizione. E il punto non è che le cose dovrebbero andare diversamente: è che non possono andare diversamente. L'incompetenza strutturale non è un problema da risolvere. È la condizione in cui operiamo, e che continueremo a operare finché costruiremo sistemi la cui complessità eccede la capacità di comprensione di chi li costruisce.
La questione, allora, non è come eliminare l'incompetenza. È come abitarla.
Abitare l'incompetenza #
Se la competenza, nel senso classico di padronanza completa del proprio dominio, non è più raggiungibile, allora ciò che chiamiamo con quel nome è diventato qualcos'altro. Non un sapere, ma un saper fare in assenza di sapere. Una forma di saggezza pratica che somiglia più alla phronesis aristotelica che all'episteme: non la conoscenza delle cause prime, ma la capacità di agire bene in situazioni particolari e incerte.
Il buon tecnico, oggi, non è chi sa di più. È chi gestisce meglio la propria ignoranza. Chi sa dove sono i confini di ciò che capisce, chi sa chiedere, chi sa quando fermarsi, chi sa costruire sistemi che falliscono in modo prevedibile anziché catastrofico. Sono tutte competenze, ma sono competenze sulla propria incompetenza. Sono meta-competenze, se si vuole usare un termine brutto per un'idea importante.
E qui si apre un paradosso che merita di essere guardato in faccia. La cultura professionale del software premia il sapere e punisce il non-sapere. Chi ammette di non capire perde credibilità. Chi dice "non lo so" in una riunione viene percepito come debole. Chi stima con onestà viene punito dal confronto con chi stima con ottimismo. L'intero sistema di incentivi è costruito per mascherare l'incompetenza anziché per gestirla, il che produce il risultato opposto: incompetenza non riconosciuta, non gestita, non metabolizzata. Incompetenza pericolosa.
Una cultura professionale matura farebbe il contrario. Partirebbe dall'assunto che nessuno capisce il sistema nella sua interezza, e costruirebbe processi, strumenti, istituzioni progettati per funzionare in quella condizione. Non è utopia: è ingegneria dell'ignoranza, ed è esattamente ciò che facciamo quando scriviamo test automatizzati (verifichiamo perché non ci fidiamo della nostra comprensione), quando facciamo code review (cerchiamo gli errori che il nostro punto cieco ci impedisce di vedere), quando adottiamo il principio del privilegio minimo (limitiamo il danno che la nostra ignoranza può causare).
Questi non sono palliativi. Sono le pratiche più sofisticate che l'industria del software abbia prodotto, e sono tutte, alla radice, tecniche per gestire l'incompetenza. Nessuno le chiama così, perché il nome sarebbe scomodo. Ma lo sono.
L'onestà come metodo #
Forse l'unica risposta disponibile all'incompetenza strutturale non è una soluzione ma un atteggiamento: l'onestà epistemologica come pratica quotidiana. Sapere di non sapere non come formula vuota, ma come punto di partenza operativo di ogni decisione.
Questo non significa paralisi. Significa decidere sapendo di decidere al buio, e costruire reti di sicurezza proporzionate a quella consapevolezza. Significa documentare non solo ciò che si è fatto, ma perché lo si è fatto e su quali assunti — perché quegli assunti si riveleranno sbagliati e chi verrà dopo avrà bisogno di capire non la soluzione, ma il ragionamento che l'ha prodotta. Significa smettere di trattare le stime come promesse e le architetture come monumenti.
Non è una proposta rivoluzionaria. È la descrizione di ciò che le persone migliori già fanno, spesso in silenzio, spesso in contrasto con la cultura che le circonda. L'incompetenza strutturale non è un nemico da sconfiggere. È il terreno su cui camminiamo, e l'unica scelta disponibile è tra camminarci con gli occhi aperti o con gli occhi chiusi.
Noi, come specie, abbiamo costruito un mondo che non siamo in grado di capire. Non è una tragedia. È forse la cosa più umana che abbiamo mai fatto.