Prevenire il Debito Cognitivo: Perché Riscrivere Manualmente il Codice LLM è Meglio di Copia-Incolla

In un'epoca in cui gli assistenti di codifica AI promettono una produttività 10x, un approccio controcorrente sta guadagnando terreno: riscrivere manualmente ogni riga di codice prodotta dai modelli linguistici di grandi dimensioni (LLM). Lo sviluppatore Ankur Sethi sostiene che questa deliberata inefficienza sia la migliore difesa contro il crescente debito cognitivo nei progetti software.

Il Problema del Debito Cognitivo

Usare gli LLM per generare intere funzionalità lascia gli sviluppatori insoddisfatti e disorientati, secondo Sethi. Sebbene continui a usare assistenti di codifica in progetti personali, ha scoperto che permettere all'AI di vagare liberamente creava una 'enorme quantità di debito cognitivo'.

Il problema centrale è la comprensione. Anche quando un problema è noioso—come aggiungere tagging a un sito Django—gli sviluppatori vogliono fondamentalmente capire come funziona la soluzione. Semplicemente rivedere le PR generate dall'AI non è la risposta. Sethi descrive questo come 'scorrere centinaia di righe di codice eccessivamente difensivo, mal commentato e sottilmente errato' che non è divertente, specialmente per progetti personali dove la gioia deriva dal processo, non dal risultato.

La Soluzione della Riscrittura Manuale

La soluzione di Sethi è elegantemente semplice: istruisce il suo assistente di codifica a non modificare mai i file direttamente. Invece, ogni modifica proposta appare nella chat, che poi digita manualmente nel suo editor. Le sue istruzioni per l'agente affermano esplicitamente: 'Voglio capire ogni riga di codice che entra in questo progetto. Non creare, modificare, spostare, rinominare o eliminare file di progetto a meno che non te lo chieda esplicitamente.'

Il compromesso è significativo. Invece di essere 10x più veloce, Sethi stima di essere solo circa 2x più veloce. Ma i benefici vanno ben oltre la velocità. Mentre digita manualmente ogni riga, costruisce un modello mentale di come il codice funziona e si inserisce nel suo codebase esistente. Questo lo costringe a rallentare, rendendo più probabile che rilevi allucinazioni o scelte progettuali sbagliate.

Costruire una Mappa Spaziale

Il vantaggio più critico di questo flusso di lavoro è lo sviluppo di una mappa spaziale del codebase. Sethi spiega che ciò significa sapere esattamente dove risiede ogni bit di funzionalità. Quando sono necessarie modifiche, sa esattamente dove apportarle. Questa consapevolezza spaziale non solo lo aiuta a lavorare più velocemente all'interno dei progetti, ma migliora anche la sua capacità di dare istruzioni e guidare l'LLM in futuro.

Questo approccio rispecchia i consigli tradizionali di programmazione. Gli sviluppatori esperti spesso sconsigliavano di copiare e incollare codice da libri o blog. Invece, raccomandavano di digitare manualmente gli esempi per garantire una comprensione completa. Sethi vede il suo flusso di lavoro con gli LLM come lo stesso processo di apprendimento applicato agli strumenti moderni.

Prospettive della Comunità

La comunità degli sviluppatori ha risposto con opinioni sfumate. Un ex insegnante di informatica ha notato che, sebbene digitare codice offra benefici, comprendere prima l'esempio e poi replicarlo in modo indipendente potrebbe essere più efficace. Un altro sviluppatore ha osservato che gli LLM si sono evoluti significativamente—dalla fase 'Apprendista Stregone' di Sonnet 3.7 nell'inverno 2025 allo status di 'eccellente tirapiedi' di Sonnet 4.5 nell'autunno 2025, descritto come il 'punto dolce per minimizzare il debito cognitivo'.

Non tutti sono d'accordo con l'approccio manuale. Alcuni sviluppatori sostengono che con i moderni strumenti IDE, possono digitare codice abbastanza velocemente da preferire scriverlo da zero. Il sentimento è che se il codice è 'fondamentalmente noioso e prevedibile', non vogliono affatto digitarlo—preferirebbero usare modelli di completamento per il boilerplate.

La Preoccupazione Più Ampia del Settore

La preoccupazione di fondo riguarda la traiettoria dell'industria del software. Sethi teme che 'l'industria del software stia assumendo una grande quantità di debito cognitivo che dovremo ripagare molto presto'. Avverte di un futuro in cui gli sviluppatori non capiranno più come sono assemblate grandi parti della nostra infrastruttura digitale.

Un commentatore della comunità ha inquadrato questo come un 'futuro alla WALL-E' in cui gli umani vengono progressivamente rimossi dal ciclo. Gli incentivi nel settore puntano tutti a rimuovere ulteriormente l'umano dal processo di sviluppo, cosa che molti trovano terrificante.

Implementazione Pratica

Per gli sviluppatori che vogliono provare questo approccio, Sethi raccomanda di aggiungere istruzioni chiare ai file dell'agente. I punti chiave includono: mostrare le modifiche proposte nella chat invece di modificare direttamente i file, visualizzare i comandi invece di eseguirli, ed evitare spiegazioni di sintassi o API a meno che non siano esplicitamente richieste.

Il flusso di lavoro riconosce che gli sviluppatori sono professionisti esperti che non hanno bisogno di essere guidati per mano. Quando incontrano API o algoritmi sconosciuti, possono fermarsi per fare ricerche o chiedere spiegazioni all'LLM, mantenendo il controllo sul proprio processo di apprendimento.

Perché è Importante

Questo dibattito tocca domande fondamentali sul futuro dello sviluppo software. Man mano che gli strumenti AI diventano più capaci, la tensione tra produttività e comprensione si intensifica. L'approccio di Sethi offre una via di mezzo—usare gli LLM per accelerare il lavoro preservando al contempo la comprensione profonda che rende efficaci gli sviluppatori.

Il metodo di riscrittura manuale può sembrare inefficiente, ma rappresenta una scelta deliberata di valorizzare la comprensione rispetto all'output grezzo. In un settore che corre verso l'automazione, questo approccio più lento e deliberato potrebbe essere la chiave per mantenere qualità e autonomia nello sviluppo software.