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.

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. La qualità del codice che scrivo lavorando da solo è più alta 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.

Domande frequenti

Quali strumenti AI usi?

Cursor per il codice e Claude per il resto, tutti i giorni. Fanno parte dei nove strumenti che uso su ogni progetto, che ho elencato in il mio stack per lanciare un prodotto.

L'AI ti ha fatto scrivere prodotti migliori?

Mi ha fatto scrivere codice migliore, perché ha reso conveniente la manutenzione. Prodotti migliori no: quelli dipendono da cosa decido di costruire, e quella parte non è cambiata.

Fai scrivere all'AI i tuoi articoli?

Il primo giro sulla struttura sì, il testo finale no. Un articolo generato si riconosce, e comunque il valore di quello che scrivo sta nelle cose che ho fatto io, che un modello non può sapere.

Non è un rischio dipendere da questi strumenti?

Il rischio non è dipenderci per la parte meccanica: quella la sapevo fare e la so ancora fare, solo più lentamente. Il rischio è usarli dove non sai valutare la risposta, e lì la dipendenza diventa fiducia cieca.