Come Uso l'AI, per Davvero | GrowFlow Studio

Risposta diretta: la domanda giusta sull'AI non è più "la usi?" — quella l'ha già superata quasi tutto il settore. La domanda giusta è: quando il modello ti dice una cosa sbagliata con la stessa identica sicurezza con cui te ne direbbe una giusta, tu te ne accorgi prima o dopo che diventi un problema vero? La differenza sta tutta lì, ed è una disciplina più che uno strumento.

TL;DR

L'uso dell'AI non è più una domanda binaria (sì/no): la usano quasi tutti. La domanda che conta è dove ti fidi e dove verifichi.
L'AI è fortissima per accelerare le bozze, il codice ripetitivo, l'esplorazione iniziale. È più debole esattamente dove serve più giudizio — ed è lì che rallento apposta.
Non correggo mai un bug "perché la spiegazione sembra plausibile": provo a riprodurlo per davvero, prima di correggerlo, il più possibile sempre.
Controllo la fonte primaria, quando posso, invece del riassunto che qualcuno (umano o modello) ne fa — vale per il codice, per i log, per i dati.
C'è una categoria di cose che non affido mai a un modello, a prescindere da quanto sia bravo: tutto ciò che, se sbaglio a fidarmi, non si può disfare.

La domanda che si liquida in trenta secondi

"Come usi l'AI nel lavoro?" È diventata una domanda di rito. La senti nei colloqui, nelle call con i clienti, nelle riunioni dove qualcuno deve decidere quanto investirci. E quasi sempre riceve la stessa risposta da trenta secondi — la mia compresa: la uso per andare veloce, resto sempre critico. È uno slogan, non una descrizione.

Il problema di quello slogan è che non contiene niente di verificabile. Non dice su cosa la usi davvero, dove smetti di fidarti, cosa cambia nel lavoro quando produrre costa quasi zero. Qui provo a scrivere la versione lunga: quella che in un'ora non c'è mai il tempo di dare, ed è l'unica utile a chi deve decidere come usarla in azienda.

Il punto non è "se" uso l'AI, è "dove" mi fido

Fidarsi non è un interruttore acceso/spento — è una decisione che prendo caso per caso, e la regola con cui la prendo è semplice da dire e un po' più difficile da rispettare sempre: più una decisione è facile da disfare, più sono disposto a delegarla senza verificarla subito. Più è costosa da disfare, più cerco di verificarla prima, non dopo.

Una bozza di funzione, un primo tentativo di query, la struttura di un test: costano poco sbagliarli, li rileggo e li correggo in pochi secondi, quindi lì l'AI mi fa risparmiare tantissimo tempo e la lascio andare veloce. Una decisione di design che userò per mesi, un'affermazione su come si comporta davvero una libreria o un sistema esterno, qualsiasi cosa tocchi dati o accessi sensibili: lì rallento apposta, perché il costo di scoprire l'errore dopo è quasi sempre più alto del tempo che avrei risparmiato a fidarmi prima.

La disciplina che conta di più: provare a riprodurre prima di correggere

Se un modello mi propone una spiegazione plausibile per un bug — e ne propone quasi sempre una, con lo stesso tono sicuro che userebbe per quella giusta — la domanda che mi faccio non è "ha senso?" ma "l'ho visto succedere con i miei occhi, o mi sto fidando di una storia ben raccontata?". Prima di toccare una riga di codice per correggere qualcosa, provo a riprodurre il problema per davvero: lo faccio succedere di nuovo, in condizioni controllate, e solo a quel punto correggo. Non perché non mi fidi in generale — ma perché una spiegazione plausibile e una vera hanno spesso la stessa forma quando te le racconta qualcuno di convincente, umano o AI che sia. L'unico modo per distinguerle, quando conta, è andare a vedere.

La stessa disciplina vale al contrario: quando trovo un errore rileggendo il mio stesso codice — cosa che provo a fare sempre, anche su codice che "ha funzionato al primo colpo" — cerco di non fidarmi nemmeno della mia prima impressione su cosa lo abbia causato. Lo riproduco, lo isolo, e solo dopo scrivo la correzione. È più lento di "sembra che il problema sia qui, sistemo e vado avanti". Ma è una delle differenze più reali tra codice che funziona e codice di cui so che funziona.

Controllare la fonte, non il riassunto

Un modello che ti descrive come si comporta una libreria, un'API, un sistema che non hai scritto tu, ti sta dando — nella migliore delle ipotesi — un riassunto accurato di quello che ha visto altrove. Un riassunto, per quanto accurato, non è la fonte. Quando una decisione dipende da "questo si comporta davvero così?", provo ad andare a guardare la fonte primaria: il codice vero, la risposta vera di un sistema vero, il log vero di un'esecuzione vera — invece della descrizione di terza mano di come dovrebbe comportarsi.

Non è scetticismo verso l'AI in particolare: è più o meno lo stesso principio che applicherei a un collega bravissimo che mi dice "quella libreria funziona così" a memoria. Bravissimo non vuol dire infallibile, e la memoria — sua, mia, o quella statistica di un modello — è spesso il posto sbagliato dove far vivere un fatto che si può verificare in trenta secondi.

Quello che non delego, a prescindere da quanto il modello sia bravo

C'è una categoria di cose per cui la regola "verifica se conta" non basta, perché anche un solo errore è già troppo: tutto ciò che tocca l'accesso a dati o sistemi — chiavi, credenziali, qualunque cosa che, se finisce nel posto sbagliato anche una volta sola, non si può far finta che non sia successo. Lì non delego la decisione, e non delego nemmeno la verifica: la faccio a mano, ogni volta, senza troppe eccezioni per la fretta. Non è paranoia — è più che altro riconoscere quali errori sono reversibili e quali no, e trattarli di conseguenza in modo diverso.

La domanda che vale davvero

Ormai chiunque sa rispondere "sì, uso l'AI, mi fa risparmiare tempo" — di per sé non è più un segnale di granché, perché è vero per quasi tutti. Il segnale più interessante è cosa succede nel momento esatto in cui il modello sbaglia con sicurezza: il tuo modo di lavorare è impostato per farti accorgere di quell'errore prima che costi qualcosa, o solo dopo? Io non ho una risposta valida per sempre — ho un'abitudine che provo a rispettare ogni volta, e che a volte mi rallenta apposta proprio quando sarebbe più comodo non farlo. Quella, più di qualsiasi strumento, è la risposta che un colloquio da un'ora non ha mai avuto il tempo di farmi dare per intero.

FAQ

Qual è l'errore più comune in chi delega troppo all'AI?

Trattare la sicurezza con cui un modello risponde come se fosse un indicatore di correttezza. Non lo è: un modello può essere ugualmente sicuro quando ha ragione e quando ha torto. Il modo più affidabile per distinguere i due casi resta verificare, non ascoltare il tono della risposta.

Come si decide cosa verificare e cosa no, senza perdere tutto il tempo guadagnato?

Guardando quanto costa disfare l'errore, non quanto sembra probabile che l'AI abbia ragione. Se sbagliare costa un rollback di due minuti, si può andare veloci. Se sbagliare costa una settimana o un dato che non torna indietro, meglio verificare prima, quasi sempre.

Riprodurre un bug prima di correggerlo non fa perdere tempo rispetto a "sistemare e andare avanti"?

Nell'immediato sì, qualche minuto in più. Ma aiuta a evitare quella categoria di correzioni che sembrano funzionare e nascondono il problema vero un livello più in profondità — quelle, quando ricompaiono, costano molto più tempo, di solito nel momento peggiore possibile.

Se in azienda stai cercando di capire come usare l'AI in modo che acceleri davvero il lavoro senza spostare il rischio da qualche parte dove nessuno lo vede, è uno dei temi che affronto come Fractional CTO: parliamone.