Fino a poco tempo fa, un programmatore che usava l’AI inseriva una domanda in un chatbot, copiava il frammento di codice generato e lo incollava nel progetto. Oggi questo modello di lavoro assomiglia sempre più a qualcosa di completamente diverso.
Il programmatore può assegnare un compito a un agente, dargli accesso al repository, permettergli di analizzare il codice esistente, eseguire i test, modificare più file, correggere bug e poi preparare la modifica per la revisione. L’essere umano non sparisce dal processo. Cambia però il punto in cui il suo lavoro ha il maggior valore.
Secondo lo studio JetBrains Developer Ecosystem Survey 2026, che ha coinvolto oltre 15 mila programmatori professionisti da tutto il mondo, nel periodo maggio-luglio 2026 ben il 90% degli intervistati ha usato AI coding agents al lavoro almeno una volta alla settimana, e il 68% lo faceva ogni giorno.
Non si tratta più di un esperimento di pochi entusiasti. Si tratta di un cambiamento del modello di lavoro.
L’AI non è più solo un “assistente per il codice”
Vale la pena distinguere due cose.
L’assistente AI aiuta il programmatore.
L’AI coding agent esegue un compito.
È una differenza apparentemente piccola, ma dal punto di vista dell’organizzazione del lavoro è enorme.
L’assistente può proporre una funzione, spiegare un errore, generare un frammento SQL oppure scrivere un test. Tuttavia l’essere umano continua a svolgere la maggior parte delle operazioni.
L’agente può ricevere un comando molto più generale:
“Aggiungi la possibilità di filtrare gli ordini per stato. Verifica l’architettura esistente. Implementa backend e frontend. Aggiungi i test. Esegui la test suite e correggi gli errori.”
E inizia a lavorare.
Esamina la struttura del progetto. Cerca i file pertinenti. Analizza le dipendenze. Modifica il codice. Esegue i test. Riceve un messaggio di errore. Cerca di risolverlo. Riesegue i test.
Non è più un autocomplete sotto steroidi.
È un esecutore di compiti che opera all’interno dell’ambiente di sviluppo.
Ed è qui che inizia il vero cambiamento del ruolo del programmatore
Se l’AI può generare centinaia di righe di codice in pochi decine di secondi, il valore del programmatore non può più essere misurato solo dal numero di righe scritte.
Cominciano a contare altre competenze.
Il programmatore sa definire bene il problema?
Capisce l’architettura del sistema?
Sa quali informazioni dare all’agente?
Sa valutare se la soluzione si adatta davvero al sistema esistente?
Sa progettare i test?
Si accorge che l’agente ha risolto il problema localmente, ma ne ha creato uno tre livelli più in alto?
Sa quando fermare l’agente?
Questo significa uno spostamento del peso del lavoro.
Meno: “Scriviamo questo codice da zero.”
Più: “Progettiamo la soluzione, definiamo i vincoli, passiamo il contesto giusto, verifichiamo il risultato e decidiamo se può essere distribuito.”
Il programmatore inizia a somigliare al leader di un piccolo team
Immaginiamo un progetto in cui lavorano diversi agenti.
Uno analizza il codice esistente.
Un altro prepara il backend.
Un terzo lavora sull’interfaccia.
Un quarto genera i test.
Un quinto analizza la sicurezza.
L’essere umano può coordinarne il lavoro, trasmettere il contesto e prendere decisioni.
Sembra un team di sviluppo?
In un certo senso sì.
La differenza è che i “dipendenti” non sono esseri umani.
Ed è proprio per questo che emerge una nuova competenza: la gestione dello sviluppo agentico.
Qui non si tratta di gestire persone, calendario o budget. Si tratta di gestire il flusso di lavoro eseguito dai sistemi AI.
Il programmatore deve saper scomporre un problema grande in attività, definire le dipendenze, trasmettere il contesto adeguato e creare un meccanismo di controllo dei risultati.
Questo è molto più vicino al lavoro di un architetto che alla classica riscrittura del codice.
Oggi lo strumento più importante del programmatore può essere il contesto
L’agente è bravo quanto le buone informazioni che riceve.
Si può dire: “Aggiungi il login degli utenti.”
E si può dire: “Aggiungi il login degli utenti. Il sistema usa l’attuale meccanismo OAuth. Non modificare la struttura della tabella degli utenti. Le sessioni vengono conservate lato server. Non introdurre nuove librerie senza una giustificazione. Mantieni la compatibilità con l’app mobile. Aggiungi i test per login, logout, sessione scaduta e token non valido.”
Il secondo comando non è semplicemente più lungo.
È una specifica migliore.
L’agente riceve vincoli, contesto aziendale e tecnico, e criteri di accettazione.
Proprio per questo, nel mondo degli agenti, diventa sempre più importante la capacità di lavorare con il contesto. Il programmatore non dice solo all’AI, cosa fare. Deve anche dire, in quale ambiente farlo, cosa non si può cambiare e come capiremo che il compito è stato eseguito correttamente.
L’errore più grande? Confondere la velocità di generazione con la velocità di creazione del software
È molto importante.
L’agente può generare una funzione in 30 secondi.
Non significa che la funzione sia pronta per la produzione dopo 30 secondi.
Il codice va capito. Testato. Integrato. Verificato dal punto di vista della sicurezza. Controllata la performance. Verificata la conformità all’architettura. Analizzato l’impatto sugli altri elementi del sistema.
L’AI può accorciare drasticamente la fase di produzione del codice, ma non elimina il bisogno di ingegneria.
Anzi.
Più è facile generare codice, più è facile generare anche codice sbagliato.
E il problema inizia quando l’essere umano non è più in grado di capire ciò che ha approvato.
Per questo l’essere umano rimane ancora nel ciclo
I dati di Stack Overflow dell’aprile 2026 mostrano un quadro molto interessante. L’uso degli agenti al lavoro è salito al 59%, ma il 63% dei tecnologi intervistati dichiarava di consentire raramente o mai agli agenti di agire in modo completamente autonomo. Il 60% degli intervistati blocca agli agenti la possibilità di eseguire modifiche non approvate nei sistemi.
Questo mostra una cosa importante.
Il mercato non si sta semplicemente muovendo verso: “L’AI fa tutto, l’essere umano guarda soltanto.”
Molto più realistico è il modello: “L’AI svolge sempre più lavoro, ma l’essere umano controlla ancora direzione, vincoli e risultato.”
È una differenza fondamentale.
Il programmatore non deve scrivere manualmente ogni funzione. Deve però sapere perché una certa funzione è stata creata, come funziona e se dovrebbe far parte del sistema.
Il nuovo programmatore dovrà essere bravo in diversi mondi contemporaneamente
Le competenze programmatiche classiche restano comunque importanti.
La conoscenza di linguaggi di programmazione, database, architettura, protocolli, sicurezza, testing e infrastruttura non scompare solo perché il codice può essere generato dall’AI.
Anzi.
Se qualcuno non comprende il sistema, difficilmente riuscirà a valutare se la soluzione generata sia buona.
A questo si aggiungono però nuove competenze.
Il programmatore deve capire i limiti dei modelli. Deve saper preparare il contesto. Deve sapere come suddividere i compiti tra gli agenti. Deve saper progettare il processo di verifica. Deve capire i costi delle chiamate, i permessi degli agenti, l’accesso ai dati e il rischio di eseguire operazioni automatiche.
E soprattutto deve imparare a dire all’AI non solo: „fai”.
Ma anche: „fai in questo modo, perché...”.
Questo può cambiare anche il modo in cui si costruiscono i team IT
Per anni, scalare un team di sviluppo ha significato aggiungere persone.
Più funzionalità? - Più programmatori.
Progetto più grande? - Team più grande.
Più clienti? - Più persone.
L’agentic development può cambiare questa relazione.
Ciò non significa automaticamente che un programmatore sostituirà dieci altri. Sarebbe un’ipotesi troppo semplice.
Può però significare che un programmatore esperto sarà in grado di supervisionare un ambito di lavoro molto più ampio svolto automaticamente.
In pratica, significa spostare il collo di bottiglia.
Oggi il limite può essere il numero di persone in grado di scrivere codice.
Domani il limite può essere il numero di persone in grado di progettare bene, delegare e verificare il lavoro svolto dall’AI.
E il junior?
Qui la situazione diventa particolarmente interessante.
L’AI può generare molto rapidamente una soluzione che in passato un junior avrebbe scritto in diverse ore.
Ma il junior potrebbe non sapere se la soluzione sia corretta.
Questo crea un paradosso.
L’AI può accelerare l’apprendimento della programmazione, perché permette di sperimentare più velocemente, fare domande e analizzare soluzioni.
Allo stesso tempo può rendere più difficile sviluppare una comprensione fondamentale del sistema, se il giovane programmatore accetta codice già pronto senza cercare di capirne il funzionamento.
Per questo il futuro dei junior non deve necessariamente significare: „l’AI gli porterà via il lavoro”.
Può significare qualcosa di più pratico: Un junior che sa solo scrivere codice avrà molta più difficoltà. Un junior che sa comprendere il codice, testare soluzioni, analizzare problemi e lavorare con gli agenti costruirà un profilo di competenze completamente diverso.
È la differenza tra un operatore dello strumento e un ingegnere.
L’errore più costoso lo commette ancora l’essere umano
Un agente può generare codice errato.
Ma la decisione di andare in produzione può ancora prenderla un essere umano.
Ed è proprio per questo che la responsabilità del software non passa magicamente all’AI.
Se un agente crea una funzione che funziona correttamente in uno scenario di test, ma viola le regole di business, il problema non è che l’AI „non ha capito l’azienda”.
Il problema è il processo che ha permesso a quella modifica di andare oltre.
Questo porta a un cambiamento molto importante nel modo di pensare alla qualità.
Non basta più chiedersi: „Il programmatore ha scritto buon codice?”
Sempre più spesso bisogna chiedersi: „Il team ha creato un buon processo di creazione del codice con l’aiuto dell’AI?”
È una domanda molto più ampia.
L’agente non sostituisce l’architetto. Aumenta l’importanza dell’architettura
Più codice può essere creato automaticamente, maggiore è l’importanza della struttura del sistema.
Un’architettura ben progettata permette all’agente di lavorare entro confini definiti.
Un’applicazione progettata male può invece far sì che l’agente aggiri i problemi invece di risolverli.
Per questo architettura, documentazione, test, standard di codifica, CI/CD, monitoraggio e controllo degli accessi diventano non meno importanti, ma potenzialmente ancora più importanti.
L’AI può accelerare il lavoro in un ambiente ben preparato.
Non riparerà automaticamente tutto il caos organizzativo e architettonico.
Può però ampliarlo molto rapidamente.
Il futuro non appartiene al programmatore che scrive più codice
Questa è probabilmente la conclusione più importante di tutto il cambiamento.
Per molto tempo la programmazione è stata associata alla scrittura del codice.
Ora il codice sta diventando sempre più economico e veloce da produrre.
Questo sposta il valore più in alto.
Verso la comprensione del problema.
La progettazione della soluzione.
Il prendere decisioni.
Il controllo qualità.
L’architettura.
La sicurezza.
L’integrazione.
La comprensione del business.
E l’uso sapiente degli agenti.
Il programmatore del futuro potrebbe passare meno tempo alla tastiera, ma non per questo avrà meno lavoro.
Il suo lavoro potrebbe semplicemente apparire diverso.
Invece di scrivere ogni funzione a mano, progetterà il modo in cui le funzioni vengono create.
Invece di correggere ogni errore da solo, costruirà un processo che permetta agli agenti di trovare e correggere gli errori.
Invece di essere l’unico esecutore, diventerà la persona che definisce la direzione del lavoro di diversi esecutori digitali.
E forse proprio per questo la domanda più importante del futuro non sarà: „L’AI sa programmare?”
Ma: „Sappiamo costruire software in modo che l’AI possa lavorare velocemente e l’essere umano sappia ancora cosa sta succedendo?”
Perché nel mondo degli agenti il vantaggio più grande non sarà il semplice possesso dell’AI.
Sarà la capacità di controllarla.
