L'AI ti fa costruire più veloce, non decidere meglio

Uso l'AI tutti i giorni per scrivere codice, per il primo giro sui testi e per guardare dentro i dati. Mi fa risparmiare ore vere, e non ho nessuna intenzione di smettere.

Però la leva che dà è su una dimensione sola: quanto in fretta produci. Non tocca l'altra, cioè se quello che produci è la cosa giusta. E siccome il costo di andare nella direzione sbagliata cresce con la velocità, uno strumento che ti fa andare più veloce senza migliorare la direzione può peggiorare il risultato.

La regola che uso: solo dove riconosco già una risposta sbagliata

Uso l'AI dove ho abbastanza competenza da accorgermi se mi sta dando una cosa sbagliata. Dove non ce l'ho, non la uso per decidere: la uso al massimo per farmi una mappa che poi verifico altrove.

La ragione è che questi strumenti producono risposte plausibili con la stessa sicurezza sia quando hanno ragione sia quando hanno torto. Il filtro non può essere il tono della risposta, perché il tono è identico. Il filtro devi essere tu.

Questo ribalta l'intuizione comune. L'AI sembra più utile dove sai meno, ed è invece esattamente lì che è più pericolosa, perché non hai modo di controllarla. Dove sai molto ti fa risparmiare tempo senza rischio. Dove sai poco ti fa correre al buio.

Dove mi dà leva reale

Capire codice che non ho scritto io. È il caso d'uso migliore in assoluto. Farsi spiegare una parte di codice sconosciuta è più veloce che leggerla, e verificare la spiegazione è immediato: apro il file e controllo.

I cambi ripetitivi. Rinominare, sistemare tipi, scrivere migrazioni, generare dati di test. Lavoro che va fatto, che nessuno vede, e su cui prima perdevo pomeriggi interi. Qui la verifica è banale: o compila e i test passano, o no.

Il primo giro sui testi, mai l'ultimo. Butto giù la struttura, la faccio riscrivere, poi tengo la struttura e riscrivo io le frasi. Se pubblico il testo generato si sente subito, e comunque il mio problema non è mai stato la grammatica: è dire una cosa che penso davvero.

Farmi le domande sui dati. Incollare un export e chiedere cosa salta all'occhio. Non perché trovi risposte che io non troverei, ma perché mi fa le domande in venti secondi invece che in mezz'ora. Le risposte poi le controllo io sui dati veri.

Il filo comune: in tutti e quattro i casi la verifica costa meno della produzione. È questa la condizione che rende l'AI conveniente, non la difficoltà del compito.

A mano non scrivo quasi più codice

Qui ognuno può prendere l'approccio che preferisce, e non ho nessuna intenzione di dire come si deve lavorare. Io a mano ormai non scrivo praticamente più niente.

Quello che non è cambiato è la revisione. Il codice lo leggo, lo capisco e lo correggo, perché è l'unico punto in cui la regola di prima resta in piedi: se non sai riconoscere una risposta sbagliata, delegare la scrittura vuol dire solo accumulare problemi che scoprirai dopo.

Più entri dentro allo strumento, più puoi costruirti sistemi che si rivedono da soli, con dei cicli di controllo che ripassano sopra a quello che hanno appena prodotto. E i modelli stanno migliorando in fretta: il codice che producono adesso è più preciso e più affidabile di quello di prima. Fra un anno questa sezione andrà probabilmente riscritta, ed è un buon segno.

L'ottanta per cento arriva in fretta, il venti per cento è il lavoro

La velocità che l'AI ti dà non è distribuita in modo uniforme sul progetto. La prima parte la costruisci molto velocemente: la struttura, le schermate, il percorso principale. In pochi giorni hai qualcosa che sembra finito.

Non lo è. Quello che manca è il venti per cento che decide se il prodotto si usa davvero: i casi limite, gli stati vuoti, cosa succede se l'utente torna indietro a metà, l'errore scritto in modo che si capisca, il flusso senza buchi. Prese una per una sono piccolezze. Messe insieme costano più tempo dell'ottanta per cento di prima.

Il problema non è tecnico, è di aspettative. Se consideri il progetto finito quando arrivi all'ottanta per cento, prometti una data che non rispetterai e ti fermi esattamente dove il prodotto smette di essere una demo. La velocità iniziale è vera, ma è velocità sulla parte che era già la più facile.

Dove smette di funzionare

Smette di funzionare nel momento in cui il problema non è più "scrivere" ma "decidere cosa vale la pena scrivere".

Quale problema risolvere, per chi, cosa lasciare fuori dalla prima versione, quando chiudere: sono tutte domande dove non esiste una risposta corretta da recuperare. Dipendono da cosa hai visto tu parlando con le persone e da quanto rischio sei disposto a prendere. Un modello può darti gli argomenti a favore di qualunque opzione, il che è il contrario di essere aiutato a scegliere.

Ed è il punto in cui ho pagato il prezzo più alto in passato, molto prima di usare strumenti del genere. Due anni su un mercato che non avevo verificato non sono stati un problema di velocità: costruivo eccome. Se in quel periodo avessi avuto l'AI, avrei costruito la cosa sbagliata in un anno invece che in due, e la lezione sarebbe arrivata prima solo per caso.

Cosa cambia davvero: la manutenzione, non la creatività

Il guadagno vero non è nelle idee, è nella parte noiosa. Rinominare cose, sistemare tipi, riscrivere una funzione in modo più leggibile, scrivere il commento che nessuno scrive mai.

Questo ha un effetto secondario che vale più del tempo risparmiato: rende conveniente fare le cose fatte bene. Prima rimandavo il refactoring perché costava un pomeriggio. Adesso costa venti minuti, quindi lo faccio. Il codice dei progetti che mando avanti lavorando da solo è più pulito oggi di quando lavoravo in team, e non perché sia migliorato io.

Come lo uso in pratica

1. Definisco il problema per iscritto prima di aprire qualsiasi strumento. Se non riesco a scriverlo in tre righe, l'AI amplifica la confusione invece di risolverla.
2. Chiedo la parte meccanica, mai la direzione. "Riscrivi questa funzione con questa firma" sì. "Cosa dovrei costruire" no.
3. Verifico sempre, e la verifica deve costare poco. Se controllare la risposta costa quanto scriverla, non ho guadagnato niente.
4. Il testo finale lo riscrivo. Sempre.
5. Le decisioni di prodotto le prendo parlando con le persone, non con un modello.