Oltre l'illusione: quando il codice generato con l'AI vale davvero

Negli ultimi dodici mesi gli strumenti di sviluppo assistiti dall'intelligenza artificiale hanno invaso il mercato. Velocizzano tutto, ma allo stesso tempo creano un problema di fiducia che pochi stanno affrontando apertamente.

Il punto non è se l'AI sappia scrivere codice. Il vero nodo è capire in che categoria rientra il progetto che stiamo costruendo. Senza questa distinzione, il software distribuito diventa una zona grigia piena di incognite.

Jig o prodotto: la differenza che cambia tutto

Prendiamo in prestito un'idea dal mondo dell'artigianato: la distinzione tra jig e prodotto.

Un jig è uno strumento che costruisci per te stesso. Serve a uno scopo preciso, lo realizzi in fretta e non deve resistere al giudizio altrui. Se smette di funzionare, il problema è solo tuo. Un prodotto invece è qualcosa che altre persone useranno e da cui dipenderanno. Richiede solidità, manutenzione e soprattutto fiducia.

La maggior parte dei progetti non viene classificata in anticipo. Questo è il primo errore.

Il jig: uno strumento su misura

Immagina di creare un tool da riga di comando che analizza l'output di Terraform e genera report personalizzati. Lo usi solo tu, dentro al tuo flusso di lavoro. Non ha bisogno di scalare, né di gestire casi limite che non ti riguardano.

In questi casi l'AI è un vantaggio enorme. Puoi chiedere a un modello: "crea un CLI tool che legge i miei output Terraform e li trasforma in report". In poche ore hai qualcosa di funzionante. Non è perfetto, ma per il tuo scopo lo è abbastanza.

Per i jigs l'approccio "vibe coding" funziona. Vai veloce, eviti di perdere tempo su dettagli irrilevanti e ottieni risultati.

Il prodotto: qualcosa di cui altri dipendono

Al contrario, se stai costruendo un'applicazione che altri sviluppatori useranno, o un servizio per i tuoi clienti, la situazione cambia.

In questo caso devi mantenere il controllo mentale dell'intero codice. Non importa se l'AI ha scritto parte del codice. Devi essere in grado di spiegare l'architettura, comprendere i compromessi e, se necessario, riprogettare il sistema da solo.