Il paradosso del codice che arriva da solo

Viviamo un momento strano. Un’AI generativa è in grado di mettere in piedi un’intera feature in pochi minuti. Incolli una specifica e ottieni codice che sembra pronto per la produzione. Per chi programma da vent’anni è una sensazione doppia: entusiasmo e un leggero senso di perdita.

L’entusiasmo è facile da capire: si va molto più veloci. Il disagio è più difficile da spiegare, ma c’è. Quando il codice appare già scritto, scompare qualcosa che prima faceva parte del mestiere. La fatica, le correzioni continue, le piccole vittorie di ottimizzazione. Non sono difetti del processo. Sono il modo in cui si impara davvero.

Il valore del attrito

Nel design si parla spesso di “friction has value”: un’esperienza senza attriti non è sempre la migliore. A volte l’attrito è l’esperienza.

Prendiamo un visualizzatore di schede perforate. Un AI lo genera in cinque minuti. Se invece lo scrivi a mano, senza suggerimenti automatici né correzioni da parte di un modello, il progetto cambia natura. Diventa di nuovo interessante.

Mentre scrivi la logica per interpretare la codifica Hollerith capisci davvero il formato. Quando calcoli le coordinate SVG che corrispondono alle righe reali di una scheda perforata, impari qualcosa che resta. Quando scegli la struttura dati prima ancora di scrivere codice, stai progettando, non solo implementando.

Queste attività non sono banali. Sono il materiale grezzo della conoscenza di un programmatore.

Lo schizzo su carta non è mai sparito

Prima dell’AI molti sviluppatori avevano un’abitudine: buttare giù idee su un foglio, tracciare diagrammi, scrivere pseudocodice. C’era una fase di pensiero prima di toccare la tastiera.

Con il tempo, man mano che gli strumenti diventavano più potenti, quella fase si è ridotta. Con l’AI generativa è quasi scomparsa. Al suo posto arriva una bozza prodotta dal modello e poi si inizia a modificarla.

Ma quella fase di schizzo non era un vezzo. Era il momento in cui nasceva la comprensione profonda. È lì che ti chiedevi davvero cosa stessi cercando di fare. Quel muscolo si sta indebolendo, e non si rafforza da solo.

Oltre le metriche di produttività

C’è una verità scomoda: possiamo migliorare le metriche (righe di codice all’ora, feature per sprint, frequenza di deploy) mentre perdiamo la capacità di distinguere un sistema mediocre da uno elegante.

Scrivere codice lentamente non significa opporsi al progresso. È come continuare a camminare anche se esistono le auto. È il riconoscimento che alcune abilità si mantengono solo con l’uso. E che il valore sta anche nel modo in cui si crea, non solo nel risultato.

È anche una forma di difesa. Se deleghi il problem-solving a un modello per un anno e mezzo, cosa succede quando quel modello produce qualcosa di sbagliato? La tua capacità di accorgertene e correggerlo si indebolisce. Diventi un revisore, non più un creatore.

Il movimento del codice lento

La risposta sta nell’intenzionalità. Un’ora al mese in cui decidi di non usare l’AI. Scrivi qualcosa a mano. Può essere un visualizzatore di schede perforate, un piccolo gioco, uno script di utilità, l’implementazione di una struttura dati partendo da zero.

L’obiettivo non è dimostrare che sai fare le stesse cose più lentamente. È ricordare cosa porti tu al tavolo: curiosità, gusto, la capacità di fare le domande giuste, il riconoscimento di pattern che va oltre i dati di addestramento.

Ogni sviluppatore dovrebbe provare questo spazio. Non per punizione. Per memoria.

Per chi vuole provare

Se l’idea ti convince, inizia una tua pratica di “slow code”. Anche da solo. Imposta un timer. Scegli un progetto senza scadenze né stakeholder. Scrivilo interamente a mano. Prendi appunti su cosa impari. Osserva l’attrito. Nota come cambia il tuo modo di pensare.

Se vuoi creare una comunità intorno a questa pratica, scrivimi. C’è forza nel sapere che altri stanno facendo lo stesso: riscoprire il mestiere mentre il mondo corre verso l’automazione totale. Non è un rifiuto del progresso. È un modo per usarlo meglio.