AI per lo sviluppo software

Il tuo problema non è l'AI, è aver smesso di farti domande prima di chiederle

Un fix suggerito dall'assistente che funziona non è la stessa cosa di un fix che hai capito. La differenza sembra sottile finché non ti ritrovi, tre mesi dopo, davanti allo stesso bug senza sapere da dove ripartire.

Il campanello d'allarme: un fix che funziona ma non capisci

Capita a chiunque usi un assistente AI per programmare: un campo torna null nella risposta di un'API, non sempre, solo abbastanza spesso da essere fastidioso. Prima di avere un assistente sottomano, il percorso era quasi sempre lo stesso: rileggere l'endpoint, controllare dove quel campo dovrebbe essere popolato, seguire la richiesta dall'inizio alla fine, provare, rompere, sistemare, capire. Con un assistente, il percorso si accorcia drasticamente: descrivi il sintomo, l'assistente individua magari un await mancante in una catena di promesse, il campo smette di essere null. Fatto.

Tranne che, se ti chiedono di spiegare perché mancava proprio quel await e cosa stava correndo contro cosa, a volte non sai rispondere. Hai un endpoint che funziona e un buco esattamente dove dovrebbe esserci la tua comprensione. Non è un problema di correttezza — il fix è corretto — è un problema di cosa ti resta in testa dopo.

Perché una risposta giusta è più pericolosa di una sbagliata

Una risposta sbagliata dell'assistente si nota quasi subito: il codice non compila, il test fallisce, qualcosa si rompe, e per forza di cose indaghi. In quel percorso, paradossalmente, impari comunque qualcosa. Una risposta corretta invece te la fai andare bene e basta, perché funziona. Ma proprio lì il pensiero critico si disattiva: nessuno ricontrolla il compito quando il risultato sembra già quello giusto.

Il rischio non è immediato. È che tra tre mesi, in produzione, alle due di notte, ti ritrovi davanti a un bug nella stessa area di codice e scopri di non avere il modello mentale che ti serve per orientarti velocemente — perché quel modello mentale, l'ultima volta, non l'hai costruito tu: l'ha usato l'assistente per generare la risposta, e a te è arrivato solo il risultato.

Tre domande prima di applicare qualsiasi fix

Non serve smettere di usare l'assistente, né rifare tutto a mano per principio: sarebbe un passo indietro ingiustificato. Serve inserire un piccolo checkpoint tra "l'assistente propone" e "io applico". Tre domande, sempre le stesse, bastano quasi sempre:

// Prima di applicare un fix suggerito dall'assistente:

// 1. PERCHÉ succedeva?
//    Non "cosa cambia il fix", ma qual era la causa reale.
//    Se non sai rispondere, chiedi all'assistente di spiegartelo
//    prima di applicare — non dopo.

// 2. QUALI ALTERNATIVE esistevano?
//    Il fix proposto è l'unico modo, o solo il primo che ha
//    trovato? A volte una soluzione più semplice (o più coerente
//    col resto del codice) resta nascosta se non la chiedi.

// 3. DOVE ALTRO potrebbe presentarsi lo stesso problema?
//    Un await mancante in una catena di promesse è quasi mai
//    un caso isolato: se il pattern si ripete altrove nel file,
//    il bug si ripresenterà con un altro nome.

Il punto centrale è ribaltare l'ordine: oggi il flusso più comune è "problema → prompt → risposta → copia → fatto". Le tre domande rimettono in mezzo il passaggio che conta, "problema → perché → alternative → dove altro → soluzione", senza allungare il lavoro di molto — spesso bastano due righe in più nella stessa conversazione con l'assistente, perché sa rispondere anche a quelle, se solo gliele chiedi.

Dove conviene rallentare, dove no