Hai mai guardato un agente di codifica generare 1000 righe di codice in pochi secondi e pensato: “Questa roba è magia”? Sì, lo è. Ma come ogni magia, ha un prezzo. E quel prezzo spesso si chiama “codebase illeggibile” o “architettura che sembra disegnata da un troll”.
Un recente articolo ha messo in luce i pericoli di affidarsi troppo a questi “clanker” (così li chiama giustamente l’autore). La promessa è allettante: scrivere codice più veloce, automatizzare task ripetitive, persino fare reverse engineering di librerie misteriose. Ma la realtà è che, se non li usi con disciplina, questi strumenti trasformano il tuo progetto in un Frankenstein di duplicazioni, astrazioni inutili e dipendenze circolari.
Da smanettone, ho provato in prima persona. Ho usato un agente per generare un parser JSON personalizzato: in 10 minuti aveva già una versione funzionante. Poi ho cercato di integrare quella roba nel mio progetto principale. Disastro. Il parser aveva assunti nascosti sul formato dei dati, dipendeva da un modulo obsoleto, e peggio di tutto: non sapevo come funzionava veramente. Perché? Perché l’agente aveva fatto tutto “sotto il cofano” senza spiegazioni.
Ecco la regola d’oro che ho imparato: gli agenti vanno usati per il “rum” (le parti noiose e ripetitive), ma mai per il “sistema nervoso” del tuo progetto. Vuoi che generi un’utility di logging? Perfetto. Vuoi che ti suggerisca come ottimizzare un loop? Ottimo. Ma se pensi che possa disegnare l’architettura del tuo sistema, o prendere decisioni su API pubbliche… beh, preparati a pagare il conto.
Un altro problema sottovalutato? Il “vendor lock-in” nascosto. Molti di questi agenti funzionano meglio con i loro ecosistemi proprietari. Vuoi usare il plugin di ricerca avanzata? Devi iscriverti al loro servizio cloud. Vuoi salvare lo storico delle modifiche? Deve passare per i loro server. Se per te privacy e controllo sono importanti (e dovrebbero esserlo), questa è una sveglia.
Ma non è tutto nero. Gli agenti possono essere potenti alleati se usati con criterio. Ecco come li uso io:
1. Per la “prototipazione selvaggia”: butto giù una prima versione di un modulo sperimentale e poi la rivedo
2. Come “rubber duck” intelligente: gli chiedo di spiegare concetti complessi o di suggerire pattern
3. Per la manutenzione di routine: trovare tutte le istanze di una classe o applicare un refactoring semplice
La vera sfida? Resistere alla tentazione di premere “genera” quando il codice diventa complesso. Gli agenti sono come il cibo spazzatura: danno energia immediata, ma a lungo termine ti indeboliscono. Meglio mangiare (e scrivere) cose buone, anche se ci vuole più tempo.
La prossima volta che un agente ti propone di riscrivere l’intero backend in un weekend, fermati. Respira. E chiediti: “Questa cosa la capisco veramente?” Se la risposta è no, è meglio usare carta e penna. O perlomeno un editor con i suggerimenti di completamento. Ma quelli li conosciamo tutti, vero?