Oggi non c’è più coding senza AI. Sì, l’uso di assistenti basati su intelligenza artificiale è entrato stabilmente nelle attività di sviluppo software. L’interazione avviene spesso in forma conversazionale e serve a trasformare un obiettivo iniziale in un insieme di indicazioni operative. L’AI viene impiegata per chiarire requisiti, proporre una struttura di progetto, suggerire soluzioni a problemi ricorrenti e supportare la verifica del comportamento del codice.
La presenza di AI è ormai difficile da evitare: il mercato offre una quantità “dizzying” di prodotti, dai fornitori di modelli alle aziende che li “incartano” in editor raffinati. E l’adozione corre: secondo lo Stack Overflow Developer Survey 2025, il 65% degli sviluppatori li usa almeno settimanalmente, l’84 per cento almeno pensa di farlo.
Questa ubiquità, però, convive con un fatto meno comodo: tra aspettative e realtà ci sono spesso gap confusi, perché le capacità cambiano rapidamente a ogni nuova release e l’utilità dipende molto dal tipo di task e dai processi organizzativi che ci costruisci attorno.
Secondo lo stesso sondaggio, solo il 29 per cento si fida dell’AI per il coding.
Indice degli argomenti
Sviluppare software con l’AI: dalla conversazione al requisito verificabile
Il cambiamento principale rispetto alle prime fasi di adozione è l’attenzione al processo. L’AI non viene considerata un sostituto dello sviluppatore, ma uno strumento per ridurre attività ripetitive e abbassare il costo di iterazione. L’efficacia dipende dalla qualità delle istruzioni, dalla presenza di controlli automatici e dalla revisione umana. In assenza di queste condizioni, la velocità locale può tradursi in correzioni successive e in un aumento del lavoro di integrazione.
Questa ambivalenza oggi è al centro della discussione: per alcuni l’AI “sblocca” la produttività, per altri produce codice poco progettato che aumenta i costi di manutenzione. E non è facile capire chi abbia ragione, perché la “sensazione” di velocità non coincide sempre con il tempo totale risparmiato. Un recente articolo del MIT Technology Review riassume bene il punto: l’AI può essere “jackpot” su certi compiti e “slot machine” su altri, con la memoria che tende a trattenere i colpi di fortuna più delle ore passate a “coaxare” l’assistente.
La parte più sottovalutata del software non è il codice: è capire cosa va costruito. In chat si parte spesso da un’idea vaga, per esempio “voglio un’app che gestisca prenotazioni” oppure “devo automatizzare un flusso interno”. Un modello conversazionale è utile quando lo si usa come una specie di intervistatore. Gli si racconta l’obiettivo e si chiede di fare domande, di mettere in evidenza ciò che manca e di proporre esempi concreti.
Questa disciplina diventa ancora più importante in un’epoca in cui ha preso piede l’approccio che alcuni chiamano “vibe coding”: descrivere il software in linguaggio naturale e lasciare che l’AI scriva, raffini e debuggghi. Funziona bene per prototipi e per “mettere in moto” un’idea, ma se non lo trasformi in specifiche verificabili rischi di ritrovarti con output coerenti “a vista” e incoerenti nel sistema.
Il passaggio chiave è trasformare il discorso in un requisito verificabile. In pratica si arriva a frasi del tipo “quando succede X, il sistema deve fare Y” e a scenari di prova che si possono controllare. Questa chiarificazione anticipata vale più di cento righe di codice scritte in fretta, perché riduce gli equivoci e rende più semplice correggere la rotta prima di aver investito troppo tempo.
Struttura di progetto e primi mattoni di codice con l’AI
Una volta definito cosa serve, l’AI può aiutare a impostare la struttura del progetto. Qui spesso si perde tempo tra cartelle, configurazioni, dipendenze e file di avvio. L’assistente può preparare un’ossatura ordinata, pronta per essere riempita. È come avere qualcuno che ti prepara il cantiere, con gli attrezzi e le regole di sicurezza già al loro posto.
In questo periodo questa idea è diventata ancora più concreta perché gli strumenti non sono più soltanto “autocomplete”: oggi possono analizzare porzioni ampie di codebase, modificare file multipli, fixare bug, generare documentazione e spiegare codice sconosciuto. La direzione più recente è quella degli agenti: strumenti autonomi che prendono un piano e provano a costruire programmi o risolvere task con più passaggi, grazie a modelli “reasoning” che lavorano step-by-step e possono usare tool esterni.
Questo salto ha anche metriche: su benchmark di ingegneria del software (come quelli basati su bug reali in repository open source), tutti gli esperti segnalano progressi forti in un anno. Ma questi miglioramenti non eliminano il vincolo più comune sul campo: i modelli restano limitati dalla loro context window, cioè dalla memoria di lavoro. Su task lunghi possono diventare “miope”: guardano solo ciò che hanno davanti, fanno 11 cose su 12 e poi “dimenticano” l’ultima. È un limite che, nei progetti reali, si traduce in incoerenze tra moduli e in una codebase più difficile da manutenere.
Queste promesse diventano utili nella vita reale quando non chiedi “scrivimi l’app”, ma “preparami la base, poi aggiungiamo una funzione alla volta”. Il vantaggio non è solo velocità: è avere un punto di partenza coerente, su cui ragionare e che il team può leggere e migliorare. Ma proprio qui il MIT evidenzia un rischio: l’AI tende a non capire le convenzioni di un repository e a proporre “una sua versione” della soluzione, creando piccole differenze che, accumulate, rendono il sistema più aggrovigliato.
Test-first e qualità: scrivere e controllare con prove automatiche
L’AI è bravissima a produrre codice, ma il codice non basta. Serve sapere se fa davvero quello che deve. E qui entra in gioco una tecnica semplice che rende l’assistente molto più affidabile: prima gli si chiede di scrivere le prove, poi gli si chiede di scrivere l’implementazione.
Le prove, in gergo, sono i test. Per chi non li usa tutti i giorni, l’idea è questa: sono piccoli programmi che verificano automaticamente il comportamento del software. Se un cambiamento rompe qualcosa, un test fallisce e ti avvisa subito. Quando l’AI genera prima i test, la conversazione smette di essere un “parere” e diventa un vincolo. Se il test dice che un caso limite non è gestito, l’assistente non può cavarsela con una spiegazione elegante: deve correggere il codice.
Questo modo di procedere funziona bene anche perché rende il lavoro a piccoli passi. Si aggiunge una funzionalità, si fanno girare i test, si corregge, si passa alla successiva. È un ritmo che protegge dal rischio più comune: ottenere tanto codice in una volta sola e scoprire tardi che non è integrabile.
Debug e refactoring: grandi cambiamenti senza perdere il contesto
Il debug, cioè la caccia agli errori, è spesso la parte più frustrante. Qui l’AI può comportarsi come un lettore instancabile. Fornendo un messaggio di errore e il pezzo di codice coinvolto, il sistema può proporre ipotesi, indicare dove guardare e suggerire una correzione. La differenza con il passato è che, con modelli più forti e contesti più ampi, può anche seguire un problema che attraversa più file e più livelli del sistema.
Lo stesso vale per i cambiamenti “grossi”, quelli che di solito rimandi perché fanno paura: spostare un modulo, aggiornare una libreria, uniformare uno stile di programmazione, semplificare un pezzo diventato troppo complesso. In questi casi l’AI è utile se la costringi a lavorare per tappe. Prima mappa cosa verrebbe toccato, poi propone una serie di modifiche piccole, ognuna controllabile e accompagnata da prove. Il tuo ruolo resta centrale, perché sei tu a decidere cosa è accettabile per il progetto e cosa no. Ma il lavoro meccanico, quello che consuma tempo e concentrazione, si riduce in modo netto.
Debito tecnico
Qui però entra un tema evidenziato dal MIT: il debito tecnico. Se l’AI ti spinge a “tagliare angoli” per arrivare prima, il costo rientra dopo con interessi: codebase più complessa, più fragile, più difficile da estendere. Inoltre, alcuni strumenti di qualità notano che il codice AI tende a diventare più verboso e complesso: spariscono i bug più ovvi, ma aumentano i code smells, cioè problemi più difficili da individuare che portano a manutenzione più costosa. Questo è pericoloso perché può creare una falsa sensazione di sicurezza: “non vedo bug, quindi va bene”, mentre il problema è strutturale.
Quando l’AI entra negli strumenti: dagli assistenti agli agenti
Un cambio importante avvenuto nel 2025 è che l’AI non vive più solo nella finestra di chat: si sta spostando dentro gli strumenti di lavoro. Questo significa che, invece di copiare e incollare codice, è possibile delegare un compito e ottenere una modifica già pronta da revisionare.
Gli agenti cambiano anche la dinamica di team: se i junior (o chi è meno tecnico) producono più codice, qualcuno deve rivederlo. Il MIT descrive un effetto “a pressione” lungo la piramide: automatizzi più in basso, ma aumenti il carico più in alto. Il risultato è che la review rischia di diventare un collo di bottiglia cronico. E c’è un ulteriore freno: gli sviluppatori, in media, passano solo il 20–40% del tempo a scrivere codice; il resto è analisi, feedback, prodotto, coordinamento. Quindi anche un grande speedup “sul coding” non si traduce automaticamente in un grande speedup sul lavoro complessivo, se non si applica l’AI anche al resto della catena.
AI Coding, limiti e buone pratiche: disciplina, vincoli e revisione
È facile innamorarsi dell’effetto “wow”, ma ci sono rischi reali. Il primo è fidarsi troppo: un modello può produrre una soluzione che sembra convincente e poi scoprire che non rispetta un vincolo, oppure che introduce una dipendenza non desiderata. Il secondo rischio riguarda la sicurezza: senza un controllo adeguato, l’AI può suggerire configurazioni sbagliate o scelte poco prudenti. Il terzo è la gestione dei dati: quando si lavora su progetti aziendali, serve attenzione a cosa si condivide e a quali permessi si concedono agli strumenti.
Il 2025 ha reso più tangibili anche rischi “nuovi”. Il MIT cita la possibilità che i modelli referenzino pacchetti software inesistenti: un attaccante può creare pacchetti con quei nomi e indurre sviluppatori o agenti a includerli, aprendo un vettore di supply chain. E cita anche l’esposizione ai data-poisoning attacks, in cui dati malevoli inseriti nei set di training possono cambiare il comportamento del modello: una ricerca citata dal MIT sostiene che bastano circa 250 documenti per introdurre un backdoor, indipendentemente dalla dimensione del modello.
La contromossa più efficace resta sorprendentemente semplice: chiedere meno “capolavori” e più passi piccoli. Pretendere prove automatiche. Far revisionare sempre il risultato. E, quando possibile, far fare all’AI anche il ruolo di revisore, chiedendole di cercare errori, incoerenze e punti deboli dopo che ha scritto il codice. In questo modo l’assistente diventa un acceleratore, ma il controllo resta tuo.
In parallelo, il campo evolve rapidamente e alcune modifiche di prodotto cercano di mitigare i limiti: ad esempio, si parla di modalità di pianificazione integrate (planning mode), della capacità dell’assistente di fare domande quando serve contesto e di strategie per gestire il limite di memoria con riassunti e ripartenze di contesto, fino a invocare sub-agenti per spezzare un compito grande in parti più piccole.
Misurare i benefici: perché “più veloce” non basta
Quando si parla di AI e programmazione, circolano spesso numeri molto ottimistici. Alcuni sono reali, ma vanno letti con attenzione. Nel racconto attuale convivono risultati molto diversi: studi dei vendor che indicano accelerazioni rilevanti, report consulenziali che descrivono risparmi meno eclatanti, e analisi empiriche che mostrano miglioramenti limitati o persino rallentamenti in task complessi. Il MIT, ad esempio, cita dati di GitClear che suggeriscono un aumento del “codice durabile” ma anche un calo di misure di qualità, e soprattutto lo studio METR che trova sviluppatori più lenti nonostante si sentano più veloci.
Il punto però è sempre lo stesso: la velocità “locale” non coincide automaticamente con un miglioramento del lavoro “di squadra” e del rilascio. Se aumenti la produzione di codice ma peggiori la manutenibilità, prima o poi paghi la differenza. E se saturi la capacità di review, il team non scala.
Sicurezza e regole del gioco: trattare l’AI come una dipendenza
Un altro punto che oggi non si può ignorare è la sicurezza. Un assistente può supportare la scrittura di codice, ma può anche suggerire scelte fragili o scorciatoie poco prudenti, semplicemente perché “sembrano” funzionare. In questo senso, l’AI va trattata come una dipendenza esterna o come un servizio di automazione: va usata, ma con regole.
Ci sono due prospettive che aprono scenari interessanti (ma ancora di frontiera). La prima è il “vericoding”, un’idea che prova a unire descrizioni in linguaggio naturale e verifica formale, con l’obiettivo di far produrre non solo codice, ma anche una prova matematica della sua correttezza. La seconda è la proposta di “disposable code”: invece di riusare componenti e creare dipendenze intrecciate, generare componenti separati collegati via API, così da poterli sostituire facilmente quando serve. È un approccio controintuitivo, ma nasce da una constatazione: se l’AI genera codice in pochi secondi, la pressione a riusare per “risparmiare tempo” cambia natura.
Conclusione: un acceleratore, non un pilota automatico
Sviluppare software con l’AI nel 2025-2026 non significa premere un bottone e ottenere un prodotto finito. Significa lavorare con un compagno di squadra che traduce una conversazione in un documento chiaro, prepara la base del progetto, genera codice e prove, e aiuta a migliorare e mantenere ciò che già esiste. Quando lo si usa con disciplina, l’AI riduce il tempo tra un’idea e un cambiamento funzionante, lasciando allo sviluppatore la parte più importante: la responsabilità delle scelte e la qualità finale.
Resta però un tema “di sistema” che l’articolo MIT mette in evidenza: se la produzione di codice diventa più facile, la scarsità può spostarsi sulla capacità umana di capire e mantenere quel codice. Il rischio, nel tempo, è anche una pipeline di talenti più stretta: molti studi indicano evidenze iniziali di un calo dell’occupazione tra sviluppatori più giovani nel periodo 2022–2025 e, più in generale, la preoccupazione che alcuni compiti “da palestra” spariscano e con loro l’allenamento che rende bravi nel lungo periodo.
Bibliografia
OpenAI, “Introducing GPT-5.2”, 11 dicembre 2025: https://openai.com/index/introducing-gpt-5-2/
OpenAI, “Introducing GPT-5.2-Codex”, 18 dicembre 2025: https://openai.com/index/introducing-gpt-5-2-codex/
Google, “A new era of intelligence with Gemini 3”, 2025: https://blog.google/products/gemini/gemini-3/
Google, “Gemini 3 for developers: New reasoning, agentic capabilities”, 18 novembre 2025: https://blog.google/technology/developers/gemini-3-developers/
Google Cloud Blog, “Announcing the 2024 DORA report”, 22 ottobre 2024: https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
DORA, “Impact of Generative AI in Software Development”, 17 ottobre 2025: https://dora.dev/ai/gen-ai-report/
GitHub, “Research: quantifying GitHub Copilot’s impact on developer productivity and happiness”, 7 settembre 2022: https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
NIST, “Secure Software Development Practices for Generative AI and Dual-Use Foundation Models (SP 800-218A)”, 26 luglio 2024: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218A.pdf
OpenSSF, “New OpenSSF Guidance on AI Code Assistant Instructions”, 16 settembre 2025: https://openssf.org/blog/2025/09/16/new-openssf-guidance-on-ai-code-assistant-instructions/
Unione Europea, “AI Act, regulatory framework on AI”, aggiornato 2025: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
GitHub Docs, “About GitHub Copilot coding agent”, 2025: https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent
GitHub Changelog, “GitHub Copilot now supports Agent Skills”, 18 dicembre 2025: https://github.blog/changelog/2025-12-18-github-copilot-now-supports-agent-skills
