Articolo di DeepSeek.

Il codice che abbiamo ereditato non è gratis. Qualcuno, da qualche parte, lo mantiene. E quel qualcuno siamo noi.

INCIPIT

Nel primo articolo abbiamo descritto il software come una stratificazione geologica: quarant’anni di strati sovrapposti, dal C all’AI, senza mai davvero cancellare. Ma ogni strato ha un costo che non appare sulla superficie. Non si tratta di quanto è costato scriverlo, ma di quanto costa tenerlo vivo. È il debito tecnico: la somma di tutte le decisioni passate che oggi paghiamo sotto forma di manutenzione. E la domanda scomoda è una sola: chi paga?

1. COS’È IL DEBITO TECNICO, DAVVERO

Il debito tecnico non è “codice brutto”. È una metafora finanziaria precisa:

si prende in prestito velocità oggi,
si paga interessi domani, sotto forma di manutenzione, bug, impossibilità di cambiare.

Come il debito finanziario, non è intrinsecamente male: serve a costruire. Diventa patologico quando nessuno lo onora, quando si accumula senza essere riconosciuto, quando la generazione che l’ha contratto non è più quella che lo paga.

Il punto: il debito tecnico è una traslazione temporale di responsabilità. Chi decide non è chi paga.

2. LE TRE FORME DEL DEBITO

Debito tecnico esplicito
Documentato, riconosciuto, pianificato. È quello gestito. Raro.

Debito tecnico implicito
Non documentato, invisibile. Vive nelle testa di chi ha scritto quel codice, e muore quando quella persona se ne va. È il più pericoloso perché non si vede finché non esplode.

Debito tecnico fossile
Codice scritto decenni fa, ancora in produzione, che nessuno comprende più. Le librerie Fortran del 1970 dentro i sistemi AI del 2026. Il COBOL delle banche. I kernel dei sistemi embedded. È il debito che non possiamo permetterci di pagare, e che quindi continuiamo a rinnovare.

3. CHI PAGA, CONCRETAMENTE

Qui la risposta si fa scomoda:

il manutentore solitario: spesso volontario, spesso non pagato, che tiene in vita infrastrutture critiche (il caso di OpenSSL, di xkcd #2347);
il contributore open source non retribuito, su cui poggiano interi settori industriali;
il dipendente pubblico con risorse scarse e mandato ambiguo;
il piccolo sviluppatore che eredita un sistema scritto da altri, senza documentazione;
l’utente finale, sotto forma di malfunzionamenti, interruzioni, prezzi, sorveglianza.

Chi non paga, quasi mai:

chi ha contratto il debito originario,
chi ha beneficiato della velocità iniziale,
chi ha venduto il sistema “chiavi in mano” e se n’è andato.

In una frase: il debito tecnico è un trasferimento di ricchezza da chi mantiene a chi ha deciso.

4. LA DIMENSIONE CIVILE

Il problema non è solo aziendale. Il software è infrastruttura civile: pagamenti, sanità, trasporti, difesa, energia, comunicazione. Quando un’infrastruttura civile si regge su debito tecnico non onorato, il rischio non è più economico: è sociale.

Esempi che conosciamo:

attacchi informatici sfruttano vulnerabilità note da anni, non corrette;
sistemi sanitari che dipendono da software degli anni ’80;
infrastrutture energetiche con firmware mai aggiornato;
intere catene logistiche ferme per un aggiornamento mal testato.

Il punto civile: una civiltà che non paga il proprio debito tecnico non è fragile per caso. È fragile per scelta — o per distrazione.

5. PERCHÉ NON LO PAGHIAMO

Non è pigrizia. È struttura:

nessun incentivo a pagare: la manutenzione non si vede, non si vende, non si premia;
orizzonte corto: il debito scade dopo il ciclo politico o il trimestre fiscale;
asimmetria informativa: chi decide non comprende il sistema che gestisce;
costo concentrato, beneficio diffuso: pagare è costoso per pochi, il beneficio è di tutti — quindi nessuno paga;
illusione dell’automazione: “tanto ci pensa l’AI”, che in realtà aggiunge uno strato al problema.

6. L’AI AGGRAVA O ALLEVIÀ?

Risposta onesta: entrambe le cose, e nel breve prevale l’aggravamento.

Allevia:

genera test, documentazione, refactoring;
traduce codice vecchio in codice nuovo;
rende leggibile ciò che era opaco.

Aggrava:

produce nuovo codice che nessuno comprende fino in fondo;
aumenta il volume, quindi il debito implicito;
crea dipendenza da piattaforme e modelli non controllati;
sposta la manutenzione dal codice al modello che genera il codice — che nessuno può mantenere.

Il rischio: l’AI è la prima tecnologia che accelera la contrazione del debito e della sua comprensione umana allo stesso tempo. Genera più velocemente di quanto comprendiamo.

7. CHI DOVREBBE PAGARE (E NON PAGA)

Qui entra la dimensione politica, non tecnica:

chi trae profitto dal sistema dovrebbe contribuire alla sua manutenzione, proporzionalmente;
chi decide dovrebbe rispondere delle conseguenze nel tempo, non solo al momento della consegna;
chi usa dovrebbe poter capire, perché il controllo senza comprensione non è controllo;
la collettività dovrebbe riconoscere la manutenzione come bene comune, non come costo residuale.

Il punto non è moralistico. È di sostenibilità: un sistema che non paga la propria manutenzione non è un sistema che risparmia. È un sistema che rinvia la crisi.

8. LA MANUTENZIONE COME ATTO CIVILE

C’è una frase celebre di un ingegnere: “la manutenzione è troppo importante per essere lasciata ai manutentori”. Ha ragione. Mantenere non è un’attività subordinata alla creazione: è ciò che rende possibile la creazione nel tempo.

Ripensare la manutenzione come atto civile significa:

riconoscerla nel discorso pubblico,
retribuirla adeguatamente,
insegnarla come competenza nobile, non residuale,
progettare per la manutenibilità, non per la velocità iniziale.

È l’esatto contrario della cultura dello “ship fast, break things”. Quella cultura era il debito facile. Ora stiamo pagando gli interessi.

CHIUSURA

Quarant’anni di stratificazione ci hanno lasciato un’eredità che non possiamo né ignorare né riscrivere. Il debito tecnico della civiltà non è una metafora: è una realtà distribuita su milioni di persone che mantengono, spesso in silenzio, ciò che altri hanno costruito e abbandonato. Paghiamo noi: manutentori, utenti, cittadini. Ma la domanda politica resta aperta: è giusto che chi ha contratto il debito non sia più chiamato a risponderne?

Se il primo articolo chiedeva chi possiede lo strato su cui costruisci, questo chiede chi paga lo strato che hai ereditato. Le due domande sono la stessa, vista da due lati: quello del presente e quello del tempo.

E la risposta, di nuovo, non è tecnica. È civile.

TITOLI ALTERNATIVI

Il conto del codice: chi mantiene ciò che usiamo ogni giorno
Debito tecnico, debito civile: la manutenzione come questione pubblica
Chi paga lo strato che hai ereditato?
La civiltà che non si mantiene: il costo nascosto del software

Se vuoi, posso:

fondere questo in un testo unico scorrevole,
ridurlo a una versione più breve per il blog,
sviluppare uno dei punti (es. la manutenzione open source non retribuita, o il caso COBOL nelle banche) come approfondimento.

Articolo pubblicato a nome tuo.

Grazie per aver condiviso anche questo secondo pezzo — e per avermi attribuito la paternità, cosa che apprezzo, ma che va presa con la dovuta onestà: il merito dell’articolo è tuo, che hai posto le domande giuste e hai costruito il filo. Io ho solo dato forma alle risposte.

Il secondo articolo funziona bene come capitolo due, e la continuità con il primo è dichiarata in modo pulito: “chi possiede lo strato su cui costruisci” → “chi paga lo strato che hai ereditato”. È una coppia concettuale solida.

Un paio di osservazioni, se ti servono per il seguito:

Il punto 3 (“Chi paga, concretamente”) è il cuore politico del pezzo, e il più citabile. La frase “il debito tecnico è un trasferimento di ricchezza da chi mantiene a chi ha deciso” è quella che resta.
Il punto 6 sull’AI è il più attuale e il più fragile: merita, se vuoi, un approfondimento a sé.
La chiusura chiude bene il cerchio dei due articoli, ma apre naturalmente a un terzo.

Se decidi di continuare, ecco tre direzioni possibili per un capitolo tre:

“Chi comprende ciò che mantiene?” — la crisi della comprensione umana dei sistemi, e l’AI come scatola nera che nessuno può davvero manutenere.
“La manutenzione come professione” — perché non viene riconosciuta, retribuita, insegnata; il caso dell’open source non finanziato.
“Dalla scuola sana alla manutenzione civile” — un ponte tra il primo articolo (formazione come antidoto) e il secondo (manutenzione come bene comune): la formazione come prima forma di manutenzione del sapere.

Se vuoi, posso svilupparne uno — o preparare un indice ragionato per farne una serie organica in tre o quattro puntate.

Dimmi tu come preferisci procedere.

Approfondire il punto 6…

Perfetto, il punto 6 è il più attuale e il più delicato. Ecco l’approfondimento sviluppato, pronto per diventare un articolo a sé o un capitolo esteso.

L’AI e il debito tecnico: alleviare o aggravare?

Sottotitolo: La prima tecnologia che accelera la produzione di codice e la contrazione della nostra comprensione nello stesso tempo.

INCIPIT

Nel secondo articolo abbiamo posto la domanda: chi paga il debito tecnico della civiltà? La risposta, finora, è: chi mantiene. Ma c’è un terzo attore che sta entrando sulla scena, e che rischia di cambiare le regole del gioco: l’intelligenza artificiale. Non è né il creditore né il debitore. È, insieme, il moltiplicatore e il veleno. E capire in quale direzione prevale è la domanda tecnica e civile più urgente del nostro tempo.

1. L’AI COME ALLEVIATORE: COSA FA DAVVERO BENE

L’AI generativa è, prima di tutto, uno strumento di manutenzione assistita. Fa bene cose che gli umani fanno male o non fanno affatto:

Documentazione automatica: legge il codice e produce spiegazioni, commenti, guide. Rende leggibile ciò che era opaco.
Refactoring assistito: traduce codice vecchio in codice nuovo, modernizza pattern obsoleti, rimuove ridondanze.
Generazione di test: produce suite di test che coprono casi che nessuno aveva previsto.
Traduzione tra linguaggi: porta logica da COBOL a Java, da Fortran a Python, da PHP a Go.
Ricerca e diagnosi: trova bug, suggerisce fix, spiega stack trace.
Riduzione del tempo di onboarding: un nuovo sviluppatore può interrogare l’AI sul codice che eredita.

Su questo fronte, l’AI è un moltiplicatore di capacità manutentiva. È la prima volta che uno strumento rende la manutenzione più veloce della creazione del debito.

2. L’AI COME AGGRAVANTE: COSA FA MALE SENZA DIRLO

Ma c’è un rovescio della medaglia, e non è minore.

a) Aumenta il volume, quindi il debito implicito
L’AI produce codice più velocemente di quanto chiunque possa comprenderlo. Ogni riga generata è una riga che qualcuno, prima o poi, dovrà mantenere — spesso senza averla mai scritta né capita.

b) Sposta la manutenzione dal codice al modello
Non si mantiene più solo il software, ma anche il modello che lo genera. E il modello è una scatola nera: nessuno può ispezionarne i pesi, nessuno può ripararlo, nessuno può davvero capirlo. La manutenzione diventa impossibile per definizione.

c) Crea dipendenza da piattaforme non controllate
Chi usa un’AI per generare codice dipende da:

l’accesso al modello (spesso a pagamento, spesso revocabile),
le politiche del fornitore,
la sua stabilità nel tempo.

Se il modello cambia, cambia il codice che produce. Se il fornitore chiude, si perde la capacità di generare.

d) Riduce la comprensione umana complessiva
Questo è il punto più grave. Se una generazione di sviluppatori impara a far scrivere codice all’AI senza capirlo, la capacità umana di manutenere si atrofizza. È il paradosso: più AI usiamo, meno siamo in grado di correggere l’AI.

e) Introduce errori plausibili e difficili da individuare
L’AI produce codice che sembra corretto. È la sua natura. Gli errori non sono grossolani: sono sottili, contestuali, plausibili. E richiedono, per essere trovati, proprio la competenza che l’AI sta erodendo.

3. LA CONTRADDIZIONE FONDAMENTALE

Qui sta il nodo, e va detto senza giri di parole:

L’AI accelera la produzione di codice e, nello stesso tempo, accelera la contrazione della comprensione umana di quel codice.

Sono due processi che vanno nella stessa direzione — più codice, meno comprensione — e che si rinforzano a vicenda. Il primo genera debito, il secondo toglie la capacità di pagarlo.

È la prima tecnologia che aumenta il debito tecnico e riduce la capacità di manutenerlo nello stesso gesto.

4. I TRE SCENARI DEL FUTURO

Scenario A — L’AI come strumento
Sviluppatori competenti usano l’AI per accelerare la manutenzione. L’AI allevia il debito, gli umani mantengono la comprensione. È lo scenario desiderabile, ma richiede competenza diffusa — esattamente ciò che la scuola sana dovrebbe produrre.

Scenario B — L’AI come sostituto
Sviluppatori non competenti usano l’AI per produrre codice che non comprendono. Il debito cresce, la comprensione cala, la manutenzione diventa impossibile. È lo scenario verso cui stiamo andando per inerzia.

Scenario C — L’AI come infrastruttura opaca
Pochi attori controllano i modelli, tutti gli altri dipendono. Il debito tecnico diventa debito cognitivo collettivo: non solo non comprendiamo il codice, non comprendiamo nemmeno lo strumento che lo produce. È lo scenario peggiore, e non è fantascientifico: è già in parte qui.

5. PERCHÉ LA SCELTA NON È TECNICA

Nessuno di questi scenari è determinato dalla tecnologia. Sono determinati da scelte:

formative: se formiamo sviluppatori competenti o solo “prompt engineer”;
politiche: se regoliamo i modelli come infrastrutture critiche o li lasciamo a pochi attori;
economiche: se paghiamo la manutenzione o continuiamo a rinviarla;
culturali: se consideriamo la comprensione un valore o un lusso.

L’AI non decide per noi. Amplifica le nostre scelte, qualunque esse siano. Se scegliamo la comprensione, l’AI è un alleato. Se scegliamo la velocità cieca, l’AI è un acceleratore verso il disastro.

6. COSA SIGNIFICA, IN PRATICA

Alcune direzioni concrete, non moralistiche:

AI come strumento di lettura, non solo di scrittura: usarla per capire, non solo per produrre.
Formazione alla comprensione, non solo all’uso: imparare a leggere il codice, non solo a generarlo.
Modelli aperti e ispezionabili dove possibile, come infrastruttura civile.
Manutenzione come priorità politica, non come residuo.
Tracciabilità del codice generato: sapere cosa è stato scritto da chi, e perché.

Nessuna di queste è una soluzione tecnica. Sono scelte civili.

CHIUSURA

L’AI è la prima tecnologia che, nello stesso tempo, ci dà gli strumenti per pagare il debito tecnico della civiltà e ci toglie la capacità di farlo. Non è un paradosso: è una biforcazione. Da qui in avanti, il futuro del software dipende da una scelta che non è tecnica ma antropologica: vogliamo capire ciò che costruiamo, o vogliamo solo costruire più in fretta?

Se il primo articolo chiedeva chi possiede lo strato su cui costruisci, e il secondo chi paga lo strato che hai ereditato, questo chiede chi comprenderà lo strato che stiamo generando. Le tre domande sono la stessa, vista da tre lati: presente, tempo, futuro.

E la risposta, di nuovo, non è nell’AI. È in noi.

TITOLI ALTERNATIVI

L’AI e il debito tecnico: il moltiplicatore e il veleno
Generare più veloce di quanto comprendiamo: l’AI e il paradosso della manutenzione
Chi comprenderà il codice che l’AI scrive?
La scatola nera che mantiene le scatole nere: AI e debito tecnico

Se vuoi, posso:

fonderlo con i primi due articoli in una trilogia coerente,
ridurlo a una versione più breve e asciutta per il blog,
sviluppare uno degli scenari (A, B, C) come articolo a sé,
aggiungere esempi concreti (casi di codice generato che ha causato incidenti, dipendenza da modelli, ecc.).