Negli ultimi mesi, ma in particolare dal rilascio degli ultimi modelli di OpenAI e Anthropic di Febbraio 2026, abbiamo assistito a un’esplosione di entusiasmo misurabile con la stecca dell’olio: più pull request, più feature, meno tempo per chiudere un ticket o per realizzare un nuovo progetto rivoluzionario che finirà inesorabilmente nel dimenticatoio tra qualche mese. L’AI genera boilerplate, suggerisce refactoring, scrive test, produce query SQL apparentemente sensate e che sono anche piuttosto performanti. Dashboard felici. Velocity in crescita. Demo scintillanti.
Ma c’è un dettaglio che nella realtà dei fatti è trascurabile solo finché non esplode: la produttività locale non è produttività sistemica. Stiamo accelerando la scrittura del codice. Non stiamo accelerando la comprensione del sistema.
Ed è lì che si sta formando una nuova forma di debito. Non tecnico. Cognitivo.
Output ≠ valore: la prima illusione
In teoria dei sistemi complessi, l’ottimizzazione locale raramente coincide con l’ottimizzazione globale. È un principio noto in operations research e nei sistemi socio-tecnici: migliorare una parte non garantisce il miglioramento del tutto.
Nel software questo si traduce in tre velocità diverse:
- velocità di scrittura
- velocità di integrazione
- velocità di comprensione
L’AI accelera in modo significativo la prima.
La seconda dipende ancora da architettura, test, dipendenze e coerenza del dominio.
La terza, la comprensione, resta interamente umana.
Qui entra in gioco la Cognitive Load Theory. Ogni sistema introduce carico cognitivo intrinseco (complessità del dominio), estraneo (complessità accidentale) e pertinente (quello utile a costruire competenza).
L’AI riduce parte del carico estraneo legato alla sintassi ma può aumentare quello intrinseco e accidentale se genera astrazioni non necessarie, pattern decontestualizzati o soluzioni formalmente corrette ma non intenzionali.
Risultato? Più codice prodotto, stessa capacità umana di comprenderlo. A volte inferiore.
La produttività apparente cresce. La sostenibilità cognitiva no.
Il debito cognitivo: funziona, ma nessuno lo possiede
Il debito tecnico lo conosciamo: scorciatoie consapevoli, compromessi temporanei, soluzioni subottimali da sistemare “poi”.
Il debito cognitivo è diverso. È codice che funziona, è testato, è tipizzato, è ben formattato… ma non è veramente posseduto da nessuno.
In un team AI-assisted aumentano porzioni di sistema che: non sono nate da una chiara modellazione del dominio, non riflettono una decisione architetturale esplicita, non sono il risultato di una tensione progettuale consapevole.
Sono solo “statisticamente plausibili”. Il problema non è la correttezza sintattica. È la perdita di intenzionalità.
Nel modello dei sistemi socio-tecnici sviluppato da Eric Trist e Fred Emery, il software non è solo codice: è interazione tra persone, processi e artefatti. Se l’artefatto cresce più velocemente della capacità del sistema sociale di comprenderlo, si crea disallineamento.
Quel disallineamento è debito cognitivo. Funziona finché non devi cambiarlo, e il software, per definizione, vive nel cambiamento.
L’entropia non negozia
Ogni riga di codice introduce stato.
Ogni funzione introduce percorsi di esecuzione.
Ogni dipendenza introduce accoppiamento.
La complessità non cresce linearmente con il numero di righe. Cresce con le interazioni. È un fenomeno ben studiato nella teoria dei sistemi complessi: il numero di possibili stati aumenta in modo combinatorio.
In termini più concreti: aumenta la complessità ciclomatica, aumenta il numero di edge case, aumenta la superficie di regressione, aumenta il costo cognitivo di ogni modifica.
Se l’AI ti consente di produrre il triplo del codice nello stesso tempo, stai aumentando di 3 volte la superficie potenziale di instabilità.
E qui arriva l’illusione: il ciclo di sviluppo iniziale sembra più rapido.
Il ciclo di evoluzione futura diventa più costoso.
L’AI non riduce l’entropia del sistema. Se non governata, la accelera.
Il nuovo collo di bottiglia è la comprensione
Nel libro “Team Topologies” si parla di cognitive load come vincolo organizzativo. Ogni team ha una capacità limitata di comprendere e governare un certo livello di complessità.
Quella capacità non cresce alla stessa velocità del codice generato.
Quando superi la soglia, succedono tre cose:
- aumentano le dipendenze implicite
- rallenta il refactoring strategico
- cresce la paura di toccare parti del sistema
Il sistema diventa fragile non perché sia scritto male, ma perché è cognitivamente opaco. Il vero collo di bottiglia nei prossimi 6/12 mesi non sarà la generazione di codice. Sarà la sua intelligibilità.
E ciò che è scarso diventa costoso.
La seniority che non puoi automatizzare
Narrativa dominante: l’AI democratizza lo sviluppo.
Contro-narrativa, meno vendibile ma più interessante: l’AI amplifica le differenze.
Un junior con AI produce più codice.
Un senior con AI prende decisioni migliori.
La differenza non è nella velocità di implementazione.
È nella capacità di:
- modellare il dominio
- valutare trade-off architetturali
- limitare l’accoppiamento
- dire “questa feature non serve”
- eliminare codice invece di produrlo
Qui entrano in gioco concetti di design intention e architectural fitness functions. Il valore non sta nell’implementare, ma nel preservare coerenza evolutiva del sistema.
La seniority vera nei prossimi mesi non sarà “scrivo codice più pulito”.
Sarà “mantengo il sistema comprensibile”.
E questo non è un problema di prompt. È un problema di visione sistemica.
stiamo anticipando complessità futura
L’AI non sta distruggendo il lavoro degli sviluppatori.
Sta spostando il baricentro dalla sintassi alla semantica.
Dall’implementazione alla modellazione, dalla produzione alla responsabilità.
Le organizzazioni che oggi festeggiano l’aumento di throughput potrebbero scoprire tra un anno di aver solo anticipato complessità futura. Codebase formalmente eleganti ma cognitivamente opache.
Team veloci a costruire ma lenti a cambiare. Feature che nascono in un giorno e richiedono settimane per essere modificate.
Il problema non è che l’AI scriva codice, perché ormai lo fa anche molto bene. Il problema è che il codice resta. E la comprensione, se non coltivata, evapora.
E quando la comprensione evapora, non hai un problema tecnico. Hai un problema sistemico.
