Il primo salto lo abbiamo visto qualche anno fa, quando l’editor ha iniziato a completare la riga che stavamo scrivendo. Il secondo è arrivato più silenziosamente: oggi lo stesso strumento non aspetta più il cursore. Legge l’intero repository, apre i file che gli servono, esegue i test, corregge quello che ha rotto e propone una modifica completa. Nel 2026 la domanda non è più se l’AI sappia scrivere codice, ma quanta parte del ciclo di sviluppo abbia senso delegarle.
Cosa distingue un agente da un autocompletamento
Un assistente classico lavora su una finestra ristretta: vede il file aperto, forse qualche file vicino, e propone la continuazione più probabile. Un agente di codice lavora invece a cicli: riceve un obiettivo scritto in linguaggio naturale, esplora il progetto per capire dove intervenire, modifica più file, lancia i comandi di build o di test, legge gli errori e riprova finché il risultato non è coerente.
La differenza non è la qualità del codice generato riga per riga — su quello i due strumenti si somigliano più di quanto si creda. È l’autonomia: l’agente prende decisioni intermedie che nessuno rivede, e arriva davanti allo sviluppatore con un risultato già formato, non con un suggerimento da accettare o rifiutare.
Dove funziona meglio oggi
- Migrazioni e refactoring meccanici. Cambiare una API deprecata in ottanta file, uniformare uno stile, spostare una cartella aggiornando tutti gli import: compiti noiosi, ripetitivi e soprattutto verificabili, perché i test esistenti dicono subito se qualcosa si è rotto.
- Codice di contorno. Test di regressione, script di build, configurazioni, gestione degli errori: parti necessarie ma poco creative, dove il costo di scriverle a mano è alto e il rischio di sbagliare è contenuto.
- Esplorazione di un progetto sconosciuto. Chiedere dove viene gestita una certa funzionalità in una codebase di cui non sai nulla è spesso più veloce che cercarla a mano, e la risposta è verificabile in pochi secondi.
- Prima bozza di una funzionalità isolata. Non l’architettura, ma il pezzo circoscritto con input e output chiari, da rileggere e correggere invece che scrivere da zero.
Dove invece conviene ancora fare da soli
Le scelte che l’agente non può prendere al posto tuo sono quelle in cui il contesto sta fuori dal codice: perché quella struttura dati è fatta in quel modo, quale vincolo di prodotto ha portato a quel compromesso, quale parte del sistema è fragile perché nessuno l’ha più toccata da due anni. Un agente ottimizza per far passare i test; non sa quali test mancano.
Vale anche per la sicurezza: il codice generato tende a essere plausibile e a compilare, il che è esattamente ciò che rende difficile notare una gestione dei permessi sbagliata o un dato sensibile registrato nei log per errore.
I problemi ancora aperti
- Il collo di bottiglia si sposta sulla revisione. Se generare una modifica costa pochi minuti, la parte lenta diventa leggerla. Un team che accetta più codice di quanto riesca a rivedere accumula debito tecnico più in fretta di prima, non più lentamente.
- La comprensione superficiale del progetto. L’agente ricostruisce il contesto ogni volta dai file che apre: se una convenzione importante è scritta solo nella testa del team, verrà ignorata sistematicamente.
- Permessi ed esecuzione. Un agente che può eseguire comandi può anche cancellare file, riscrivere la cronologia di git o pubblicare qualcosa per sbaglio. Il perimetro in cui lavora conta quanto la qualità del modello.
- Dipendenze introdotte con leggerezza. Aggiungere una libreria è la soluzione più rapida a molti problemi, e un agente la propone volentieri: la superficie di attacco del progetto cresce senza che nessuno abbia deciso davvero di farla crescere.
Suggerimento: prima di dare a un agente compiti su un progetto reale, assicurati che i test si possano lanciare con un solo comando e che documentino il comportamento atteso, non solo la copertura. È il modo più economico per trasformare l’autonomia dell’agente da rischio in vantaggio: se sbaglia, lo scopri tu prima della revisione.
Cosa aspettarsi da qui in avanti
Il mestiere non sparisce, ma il baricentro si sposta: meno tempo a scrivere le parti prevedibili, più tempo a decidere cosa deve essere costruito, a rivedere, a mantenere il contesto che il modello non ha. Chi lavora con questi strumenti ogni giorno se ne accorge presto — la competenza che diventa rara non è saper produrre codice, ma saper riconoscere in fretta quello che sembra corretto e non lo è.