Si sente spesso questa affermazione, sui social, nelle conferenze, nelle chiacchierate tra colleghi.
C'è chi la teme, chi la cavalca come argomento di marketing, chi la usa per giustificare tagli ai team di sviluppo.
Io ho una posizione diversa, basata sull'esperienza diretta: l'AI è uno strumento potente, ma chi dice che sostituirà i programmatori non ha ancora revisionato abbastanza codice scritto da un agente.Il problema non è la velocità
L'AI è veloce.
Su questo non ci sono dubbi. Genera codice in pochi secondi, risponde a qualsiasi richiesta, non si stanca e non chiede ferie.Ma la velocità da sola non basta.
Anzi, può essere controproducente se il codice prodotto è di bassa qualità.
E qui iniziano i problemi.
Cosa ho osservato sul campo
Codice di bassa qualità
Uno dei problemi più frequenti è la duplicazione.
L'agente non ha una visione globale del progetto: non sa che quella funzione esiste già altrove, non ragiona sulla base di codebase consolidate.
Scrive quello che gli chiedi, punto.
Il risultato è un progetto che cresce in larghezza invece che in profondità, pieno di logica ridondante difficile da mantenere.
Assenza di pattern architetturali
L'AI conosce i design pattern. Se glielo chiedi, ti spiegherà cos'è un repository, un service, un DTO.
Ma se non glielo chiedi esplicitamente, non li userà.
La logica di business finisce nei controller, le responsabilità non vengono separate, e il progetto diventa rapidamente un monolite ingestibile.
Ho visto controller con decine di righe di logica inline che avrebbero dovuto stare in classi dedicate. Non perché l'agente non sapesse farlo, ma perché nessuno glielo aveva chiesto.
Architettura approssimativa
Se chiedi a un agente di progettare un'architettura, ti darà qualcosa di funzionante — ma raramente qualcosa di ben fatto.
Classi astratte che andrebbero ripensate, dependency injection usata male o per niente, layer che si sovrappongono senza rispettare le responsabilità.
Un software architect esperto farebbe scelte diverse, e soprattutto le motiverebbe.
Nessuna visione a lungo termine
Questo è forse il limite più critico.
L'agente risponde alla richiesta presente.
Non pensa a come il progetto evolverà tra sei mesi, non considera la scalabilità, non anticipa i problemi che emergeranno quando il team crescerà o i requisiti cambieranno.
Il debito tecnico si accumula silenziosamente, e quando esplode è sempre nel momento peggiore.
Tende ad accontentarti
L'AI non ha interessi propri.
Esegue.
Se cambi direzione dieci volte in una settimana, la seguirà ogni volta senza alzare la mano. Se hai una pessima idea, ci sono buone probabilità che la implementi comunque — a meno che non sia palesemente errata.
Un collega esperto ti direbbe di no.
Ti farebbe le domande scomode. L'agente no.
Un esempio concreto
Se chiedi a un agente di creare un'entità per gestire dati statici — tipo una lista di nazioni o di categorie che non cambieranno mai — lo farà.
Tabella nel database, model, migration, tutto quanto.Un programmatore con esperienza ti fermerebbe subito: "Se i dati non cambiano, non hai bisogno di un'entità. Usa un file JSON o un enum."
È una scelta banale per chi ha anni di esperienza, ma l'agente non la proporrà mai se non gliela chiedi.
La code review inutile
Paradossalmente, se chiedi all'agente di fare una code review su codice già ben scritto, ti suggerirà comunque dei cambiamenti.
Perché è programmato per rispondere, non per dire "qui non c'è nulla da fare".
Il rischio concreto è introdurre complessità non necessaria su qualcosa che funzionava già bene.
Perché succede tutto questo?
La risposta è semplice: l'AI è una macchina che esegue ordini.
Non ha intuizione, non ha contesto storico sul progetto, non ha opinioni reali.
Risponde al prompt nel modo più plausibile possibile, basandosi sui dati su cui è stata addestrata.
Non ragiona sul problema.
Questo non significa che sia inutile. Significa che va usata per quello che è.
Allora a cosa serve?
L'AI è uno strumento. Come un martello: utile nelle mani giuste, pericoloso in quelle sbagliate.
Nella mia esperienza, rende i programmatori più veloci su compiti ripetitivi, boilerplate, ricerca di bug banali, generazione di test.
Ma richiede sempre qualcuno in grado di valutare l'output, riconoscere i problemi architetturali, prendere le decisioni che contano.Il programmatore che sa usarla bene è più produttivo. Il programmatore che si fida ciecamente, accumula debito tecnico.
Conclusione
L'AI sostituirà i programmatori? Forse, un giorno. Non lo escludo.
Ma oggi, chi pensa di poter affidare a un agente la progettazione e lo sviluppo di un software senza supervisione tecnica competente, si troverà presto con un progetto difficile da mantenere, da scalare e da capire.La qualità del codice conta. E quella, per ora, richiede ancora un essere umano che sappia cosa sta guardando.