Più codice, meno comprensione

L'overhead invisibile

Quando chiedi a un assistente AI di scrivere una funzione, il tuo prompt non viaggia da solo.

Prima ancora che il modello legga la prima parola che hai digitato, il sistema ha già inviato migliaia di token di contesto: la struttura del progetto, i file aperti, la cronologia dei comandi recenti, lo stato dell'ambiente. Decine di migliaia di token che tu non hai scritto, che probabilmente non hai mai visto, e che determinano in larga parte la risposta che riceverai.

Non è un dettaglio da addetti ai lavori. È la manifestazione concreta di una dinamica che sta ridefinendo il nostro rapporto con il software che scriviamo.

L'overhead esiste per far funzionare il sistema, ed effettivamente funziona. Il modello indovina cosa vuoi fare con una precisione che fino a due anni fa sarebbe sembrata fantascienza. Ti suggerisce la funzione giusta, completa il boilerplate, propone l'architettura. Tu accetti, vai avanti, produci.

Il paradosso epistemologico

Il meccanismo si inceppa qui. Non nel codice: il codice funziona. Si inceppa nella relazione tra te e il sistema che stai costruendo.

Produciamo più software di quanto sia mai stato prodotto. Repository che crescono a ritmi insostenibili, feature che arrivano in produzione in ore, interi moduli generati in minuti.

Ma la comprensione architetturale, la mappa mentale che un developer costruisce nel tempo, quella conoscenza tacita che permette di anticipare i collassi prima che accadano, si sta assottigliando a ogni Accept premuto senza leggere fino in fondo.

Il paradosso è epistemologico prima che tecnico. Non è un problema di qualità del codice generato. È una trasformazione del modo in cui conosciamo i sistemi che costruiamo.

È la differenza tra imparare una strada perché l'hai percorsa centinaia di volte e arrivare a destinazione seguendo un navigatore che ti dice "gira a destra tra duecento metri". In entrambi i casi sei arrivato. Ma solo in un caso sai dove sei.

Questo scarto non è un incidente di percorso. È il prodotto di una cultura che ha smesso di premiare la comprensione e ha cominciato a misurare l'output. Pull request aperte, feature rilasciate, deploy al giorno: metriche che non catturano nemmeno l'ombra del lavoro cognitivo che serve per capire davvero un sistema. Un developer che passa tre ore a ragionare sull'architettura senza scrivere una riga non muove nessuno di questi indicatori. Eppure è il tipo di lavoro che impedisce ai sistemi di implodere sei mesi dopo, quando il contesto è cambiato e nessuno ricorda più perché quella decisione era stata presa in quel modo.

L'evoluzione dei modelli racconta la stessa storia con altri protagonisti. Più veloci, più economici, più accessibili. Ogni iterazione abbassa il costo della delega e alza il costo della comprensione, misurato in tempo e attenzione.

Non stiamo scegliendo consapevolmente di capire meno. Stiamo rispondendo agli incentivi che l'ecosistema ha costruito intorno a noi.

Non è che abbiamo smesso di voler capire. È che il costo di capire, in un sistema che premia solo la produzione, è diventato proibitivo.

Il limite di ogni soluzione tecnica

Questo è il punto che nessuna soluzione tecnica può affrontare. Puoi ridurre l'overhead, crittografare il traffico, ottimizzare i token, rendere il modello più trasparente. Ma non puoi obbligare un developer a interiorizzare una decisione architetturale che un modello ha preso in millisecondi basandosi su correlazioni statistiche.

Quella è una scelta individuale, ripetuta decine di volte al giorno, che nessuna patch può automatizzare.

La domanda che abbiamo smesso di fare non riguarda la velocità con cui scriviamo codice. Riguarda quanta parte dei nostri sistemi potremmo ricostruire da zero se domani l'assistente non ci fosse più. Non è una domanda sulla qualità del software. È una domanda sulla qualità della nostra relazione con quello che costruiamo.