La codifica AI rende il codice sorgente abbondante, ma la verifica resta scarsa
Google News ha portato alla luce un'affermazione netta sull'intelligenza artificiale e sul software: il codice sta diventando write-only e usa e getta. L'espressione coglie un cambiamento reale. Gli agenti di coding possono generare implementazioni più rapidamente di quanto molti team riescano a comprenderle, revisionarle o integrarle in sicurezza.
Il conflitto non è semplicemente tra esseri umani e macchine. È tra velocità di generazione e comprensione organizzativa. L'AI può ridurre il costo di produzione del codice, aumentando al contempo il costo di dimostrare che il sistema risultante resti corretto, sicuro e manutenibile.
Questa distinzione è importante perché le prove più solide non supportano una semplice narrazione secondo cui il codice AI venga rapidamente scartato. Indicano invece un'inversione più profonda. Il codice sorgente sta diventando abbondante, mentre specifiche, giudizio architetturale, verifica e responsabilità restano scarsi.
Cosa ha effettivamente cambiato la storia di Google News
La tesi del codice write-only sposta il dibattito sul coding AI dalla velocità di digitazione al controllo dell'intero sistema software.
Il termine ha guadagnato visibilità grazie a Joseph Ruscio, general partner di Heavybit. Il suo saggio del febbraio 2026, write-only code, descrive un futuro enterprise in cui gli agenti generano così tante implementazioni che gli esseri umani smettono di leggere ogni riga.
“Write-only” non significa che il codice sia letteralmente illeggibile. Significa che leggere ogni riga generata non è più il principale meccanismo di controllo. Le persone esaminano invece specifiche, vincoli, test, architettura e comportamento osservabile.
È un'affermazione più incisiva rispetto al dire che gli sviluppatori useranno un completamento automatico migliore. Un programmatore AI in coppia presuppone comunque che una persona scriva o esamini attentamente l'implementazione. Un agente di coding può ispezionare un repository, modificare più file, eseguire comandi, lanciare test e rivedere il proprio lavoro con un intervento limitato.
L'articolo evidenziato da Google News si inserisce anche in una discussione più ampia già in corso nelle conferenze di ingegneria. Al QCon London 2026, Hannah Foxwell ha sostenuto che revisionare grandi volumi di codice generato non è né piacevole né sostenibile.
La risposta proposta era spostare prima la peer review. I team esaminerebbero la specifica, la strategia di test e l'architettura prima che un agente scriva l'implementazione. La copertura di QCon di InfoQ ha collegato direttamente questa proposta al concetto di write-only code di Ruscio.
L'evento significativo non è quindi un rilascio di prodotto. È l'emergere di un modello operativo coerente per lo sviluppo assistito dall'AI.
In base a tale modello, gli sviluppatori definiscono l'intento e i confini accettabili. Gli agenti traducono tali confini in codice. I sistemi automatizzati testano il risultato, mentre le persone si concentrano sulle decisioni che richiedono contesto di business o giudizio architetturale.
Questo modello cambia l'unità di revisione. Una pull request contenente migliaia di righe generate diventa meno utile come principale confine di fiducia. Gli artefatti importanti diventano il requisito, il modello delle minacce, la suite di test, la policy sulle dipendenze, il piano di deployment e le evidenze a runtime.
Il codice AI usa e getta si colloca all'estremità più aggressiva di questo modello. Un agente potrebbe generare una migrazione temporanea, uno strumento diagnostico, un convertitore di dati, un fixture di test o un prototipo. Il team potrebbe scartare il sorgente dopo che il lavoro immediato è terminato.
Eppure gli effetti raramente scompaiono insieme al file. Uno script di breve durata può comunque modificare un database, esporre un segreto, creare risorse cloud o incorporare un'ipotesi errata nei dati dei clienti. Il sorgente può essere usa e getta, mentre le conseguenze restano durature.
Ecco perché l'inquadramento di Google News merita attenzione. Dà un nome memorabile a un cambiamento reale, ma il nome può anche fuorviare. La questione centrale non è se gli esseri umani leggano ogni riga. È se i team conservino prove e conoscenze sufficienti per governare ciò che quelle righe fanno.
Una generazione più rapida mette sotto pressione le organizzazioni ingegneristiche
L'AI trasforma l'implementazione in un input meno costoso, ma non rende la distribuzione del software altrettanto economica.
I processi ingegneristici tradizionali presuppongono che la generazione del codice sia un vincolo significativo. I team assegnano il lavoro, implementano le modifiche, revisionano le pull request, eseguono i test e portano in produzione le build approvate.
Gli agenti di coding comprimono la fase di implementazione. Non comprimono automaticamente la chiarificazione del prodotto, la revisione di sicurezza, i test di integrazione, la preparazione operativa o il coordinamento organizzativo.
La ricerca DORA di Google Cloud descrive l'AI come un amplificatore. Rafforza le organizzazioni capaci e amplifica le debolezze di quelle in difficoltà. Il rapporto DORA 2025 sostiene che i ritorni dipendano più dal sistema organizzativo circostante che dallo strumento in sé.
Questa conclusione mette subito sotto pressione i leader dell'ingegneria. Se gli agenti producono più modifiche, i revisori affrontano code più lunghe. L'infrastruttura di test riceve più carico. I team di piattaforma devono supportare più esperimenti, ambienti e tentativi di deployment.
Il vecchio collo di bottiglia si sposta anziché scomparire. L'implementazione lascia spazio alla capacità di assorbimento, ossia alla capacità dell'organizzazione di comprendere, integrare, verificare e gestire un flusso crescente di modifiche.
È qui che il codice write-only diventa operativamente significativo. Uno sviluppatore può chiedere a un agente di aggiungere un endpoint, riparare un test, migrare una libreria o creare una piccola applicazione interna. Ogni richiesta può produrre codice plausibile prima che lo sviluppatore abbia esplorato completamente il sistema circostante.
La plausibilità non equivale alla correttezza. Il codice generato può soddisfare il prompt violando però una convenzione non documentata. Può duplicare un servizio esistente, selezionare una dipendenza inadatta, indebolire un controllo di autorizzazione o creare un percorso operativo costoso.
In passato gli esseri umani apprendevano molti di questi vincoli durante l'implementazione della modifica. Incontravano interfacce scomode, leggevano il codice vicino, ponevano domande ai manutentori e scoprivano perché esistevano decisioni precedenti.
Un agente può saltare gran parte di questo processo di apprendimento. Spesso è utile, ma rimuove anche una fonte di comprensione organizzativa. L'implementazione arriva senza garantire che qualcuno abbia assimilato le conoscenze necessarie a mantenerla.
Il peso ricade innanzitutto sugli sviluppatori senior e sui manutentori. Detengono il contesto necessario per distinguere una patch localmente corretta da una sistemicamente dannosa. Quando la generazione accelera, il loro giudizio diventa un servizio condiviso e sempre più scarso.
I team di sicurezza affrontano un problema simile. Il codice AI usa e getta può entrare tramite prototipi, dashboard interni, script di migrazione, utility di supporto e automazioni temporanee. Questi artefatti spesso evitano i controlli applicati alle applicazioni rivolte ai clienti.
Un prototipo può diventare permanente perché i colleghi iniziano a farvi affidamento. Uno script monouso può essere rieseguito mesi dopo. Le credenziali temporanee possono finire nei log. I dati di test possono fuoriuscire in un ambiente live.
La pressione raggiunge anche gli ingegneri junior. Se gli agenti gestiscono l'implementazione ordinaria, gli sviluppatori più nuovi perdono parte del lavoro attraverso il quale un tempo imparavano la struttura della codebase, il debugging e la disciplina di produzione.
I team non possono risolvere il problema vietando l'AI o pretendendo che gli esseri umani ispezionino ogni token generato. Hanno bisogno di percorsi di apprendimento deliberati, responsabilità esplicite e modifiche più piccole e revisionabili.
Un archivio ricercabile delle decisioni architetturali può aiutare a preservare il contesto mancante. I team che costruiscono una knowledge base tecnica possono collegare specifiche, report sugli incidenti e vincoli di progettazione al codice modificato dagli agenti.
La pressione organizzativa è quindi chiara. Gli strumenti di coding AI premiano i team che già possiedono test solidi, confini documentati, interfacce stabili e feedback rapidi. Espongono i team che dipendono da conoscenze non scritte e da revisori eroici.
Il codice write-only inverte il tradizionale contratto di revisione
Il vecchio contratto diceva che gli esseri umani si fidano del codice dopo averlo letto; il contratto emergente dice che si fidano del comportamento dopo averlo vincolato e testato.
Per decenni, manutenibilità ha significato che un altro ingegnere potesse leggere una funzione, comprenderne l'intento e modificarla in sicurezza. Denominazione, struttura, commenti, modularità e documentazione servivano tutti alla comprensione umana.
Il codice write-only mette in discussione l'economia alla base di questo standard. Se un agente può rigenerare un componente a partire da una specifica precisa, preservare ogni dettaglio dell'implementazione può diventare meno prezioso.
Questo non elimina la manutenibilità. Cambia ciò che deve essere mantenuto.
L'asset durevole può essere la specifica anziché l'implementazione corrente. I test possono diventare dichiarazioni eseguibili dell'intento. I contratti di interfaccia possono contare più dell'eleganza interna. Le regole architetturali possono diventare vincoli applicati dalle macchine anziché linee guida in un documento.
Questa inversione ricorda precedenti cambiamenti nell'astrazione software. La maggior parte degli sviluppatori non ispeziona più le istruzioni macchina generate prima di distribuire un'applicazione. Si fida di compilatori, sistemi di tipi, test, sistemi operativi e monitoraggio a runtime.
Il codice generato dall'AI differisce in un aspetto importante. Un compilatore esegue una traduzione delimitata e deterministica. Un agente di coding prende decisioni probabilistiche su progettazione, dipendenze, API e comportamento.
Questa differenza impedisce ai team di trattare un agente come un semplice compilatore. L'agente necessita di un harness, ossia gli strumenti, i permessi, il contesto, i test e i cicli di feedback che ne vincolano il lavoro.
Un buon harness può rifiutare dipendenze vietate, applicare confini tra moduli, limitare l'accesso alla rete, eseguire scanner di sicurezza e richiedere test prima di accettare una modifica. Può inoltre mantenere le modifiche generate abbastanza piccole da consentire una revisione significativa del codice AI.
La revisione stessa deve diventare stratificata. I controlli automatizzati rapidi dovrebbero coprire formattazione, tipi, policy sulle dipendenze, vulnerabilità note, test e regole architetturali. I revisori umani dovrebbero concentrarsi su intento, compromessi, confini delle minacce e modalità di guasto.
Questo non è un permesso per unire una gigantesca patch opaca perché la suite di test è stata superata. I test verificano solo i casi che esprimono. Non possono proteggere ipotesi che nessuno ha identificato.
Le specifiche affrontano lo stesso limite. Un agente può seguire una richiesta dettagliata e costruire comunque il prodotto sbagliato. Il requisito può omettere un'esigenza di accessibilità, una policy di conservazione, una regola regionale o un vincolo operativo.
Il contratto di revisione emergente ha quindi diversi punti di controllo. Le persone approvano ciò che dovrebbe cambiare. Le macchine verificano se i vincoli definiti sono rispettati. La telemetria di produzione rivela se il comportamento risultante corrisponde alla realtà.
Ogni punto copre una diversa classe di errori. Nessuno è sufficiente da solo.
Il cambiamento modifica anche il modo in cui i team dovrebbero valutare la produttività degli sviluppatori. Righe generate, attività completate e pull request aperte misurano l'attività. Non mostrano se gli utenti abbiano ricevuto valore o se il sistema sia diventato più difficile da gestire.
L'analisi successiva di DORA ha rilevato che una maggiore adozione dell'AI era associata sia a un throughput più elevato sia a una maggiore instabilità. La sua discussione sulle tensioni nella delivery AI afferma che il tempo risparmiato durante la creazione viene spesso riallocato all'audit e alla verifica.
Questo risultato spiega perché la programmazione può sembrare più veloce senza rendere la consegna proporzionalmente più rapida. Gli sviluppatori sperimentano il beneficio immediato della generazione. Le organizzazioni ereditano il costo differito dell'integrazione.
La linea di demarcazione pratica non è tra codice scritto a mano e codice generato. È tra cambiamento governato e non governato.
Il codice AI usa e getta governato può essere ragionevole per una trasformazione isolata eseguita in una sandbox. Il codice generato non governato può essere pericoloso anche quando ogni riga sembra convenzionale e rimane nel repository per anni.
Le prove complicano la tesi del codice AI usa e getta
Il codice scritto dall'AI non è automaticamente di breve durata, di bassa qualità o più veloce da produrre in ogni contesto di sviluppo reale.
Un preprint del 2026 di Musfiqur Rahman ed Emad Shihab ha esaminato oltre 200.000 unità di codice in 201 progetti open source. Il loro studio sulla sopravvivenza del codice è giunto a un risultato che contrasta con la narrativa del codice usa e getta.
A livello di riga, il codice scritto dagli agenti ha mostrato un tasso di modifica inferiore di 15,8 punti percentuali e un rischio di modifica inferiore del 16 percento rispetto al codice scritto dagli esseri umani. In altre parole, il codice AI osservato è sopravvissuto più a lungo.
Questo non dimostra che il codice AI fosse migliore. Il codice può rimanere invariato perché funziona, perché nessuno lo usa o perché i manutentori esitano a modificarlo. La longevità da sola non può distinguere tra queste spiegazioni.
Lo studio ha inoltre rilevato un tasso modestamente più elevato di modifiche correttive per il codice scritto dagli agenti, pari al 26,3 percento rispetto al 23 percento del codice umano. La variazione tra i singoli agenti superava la differenza complessiva tra agenti e umani.
Questi risultati suggeriscono che l'etichetta relativa all'origine è troppo grossolana. La scelta del modello, il tipo di attività, la qualità del repository, la supervisione umana e le pratiche organizzative possono contare più del fatto che un'AI abbia prodotto la prima bozza.
Un esperimento separato è giunto a un'altra conclusione scomoda. METR ha reclutato 16 sviluppatori esperti che lavoravano sui propri repository open source maturi. La sperimentazione ha coperto 246 issue reali e ha consentito o vietato casualmente gli strumenti AI.
Gli sviluppatori che utilizzavano strumenti AI dell'inizio del 2025 hanno impiegato il 19 percento di tempo in più per completare le issue assegnate. Il test di produttività ha rilevato anche un sorprendente divario di percezione.
I partecipanti si aspettavano che l'AI li rendesse più veloci del 24 percento prima di completare il lavoro. In seguito, continuavano a ritenere che li avesse accelerati del 20 percento, nonostante il rallentamento misurato.
I ricercatori hanno messo in guardia dal generalizzare il risultato a tutti gli sviluppatori o a tutte le attività. I partecipanti conoscevano bene repository di grandi dimensioni e gli strumenti rappresentavano un periodo specifico in un mercato in rapida evoluzione.
Anche con questi limiti, lo studio mette in luce una debolezza fondamentale nelle affermazioni sul codice AI usa e getta. La generazione rapida non equivale al completamento rapido. Prompting, attesa, verifica, correzione e integrazione possono assorbire il guadagno apparente.
Il sentimento degli sviluppatori rafforza questa cautela. Il sondaggio 2025 di Stack Overflow ha riportato che l'uso dell'AI continuava a crescere mentre la fiducia diminuiva. Solo il 29 percento degli intervistati si fidava dell'accuratezza dell'AI, in calo rispetto a circa il 40 percento nei sondaggi precedenti.
La sua analisi della fiducia degli sviluppatori afferma che oltre l'84 percento degli intervistati utilizzava o pianificava di utilizzare strumenti AI. Adozione e fiducia si stavano muovendo in direzioni opposte.
Questi risultati non invalidano il codice write-only. Chiariscono le condizioni di cui ha bisogno.
In primo luogo, la rigenerazione deve essere davvero più economica della comprensione e della riparazione dell'implementazione attuale. Questo è più plausibile per un piccolo adattatore o una fixture di test che per un registro dei pagamenti.
In secondo luogo, la specifica deve cogliere una parte sufficiente del requisito reale. Un prompt che descrive solo il percorso felice non può sostenere una rigenerazione sicura.
In terzo luogo, l'ambiente deve rilevare comportamenti inaccettabili. Senza test, controlli delle policy, controlli degli accessi e osservabilità in fase di esecuzione, il team non può distinguere una generazione riuscita da un fallimento plausibile.
In quarto luogo, qualcuno deve assumersi la responsabilità del risultato. Un agente non può essere ritenuto responsabile di un'interruzione del servizio, una violazione della privacy o un incidente di sicurezza. La responsabilità umana e organizzativa sopravvive a qualsiasi cambiamento di paternità.
La lettura scettica è quindi importante. “Usa e getta” può diventare una comoda scusa per trascurare la qualità del design e della documentazione. I team possono presumere di poter rigenerare un componente in seguito, per poi scoprire che la sua vera specifica esisteva solo nel comportamento in produzione e nella memoria del personale.
Il codice può essere economico da ricreare, mentre il contesto rimane costoso da recuperare.
Il codice sorgente usa e getta può lasciare effetti durevoli su sicurezza e dati
Eliminare il codice sorgente generato non annulla le azioni che quel codice ha eseguito.
Consideriamo uno sviluppatore che chiede a un agente di creare una migrazione una tantum dei dati dei clienti. Lo script legge un vecchio schema, trasforma i record e li scrive in un nuovo servizio.
Il team può eliminare lo script dopo la migrazione. I record modificati restano. Restano anche eventuali campi corrotti, identificatori esposti, voci di audit incomplete o autorizzazioni involontarie.
Uno script di infrastruttura generato crea lo stesso problema. Può predisporre un bucket di archiviazione pubblico, un service account con privilegi estesi o una credenziale di lunga durata. Rimuovere il file non rimuove necessariamente la risorsa.
Anche le applicazioni interne temporanee hanno l'abitudine di diventare permanenti. Un team commerciale inizia a usare una dashboard generata. Le operazioni dipendono dal suo output. Lo sviluppatore originale passa a un altro progetto.
Ciò che è iniziato come codice AI usa e getta ora supporta un processo aziendale. Potrebbe non avere un responsabile, una policy sulle dipendenze, un piano di backup, una revisione dell'accessibilità o una procedura di gestione degli incidenti.
Questo rischio cresce quando gli agenti ricevono autorizzazioni estese. Un agente di programmazione in grado di eseguire comandi shell, accedere a servizi di rete, interrogare database e pubblicare modifiche ha un impatto molto maggiore di uno strumento di completamento automatico.
Le richieste di autorizzazione offrono una protezione limitata. Le persone si abituano alle approvazioni, soprattutto quando uno strumento genera molte richieste. La difesa più solida è il contenimento deterministico.
Un agente dovrebbe ricevere il minimo accesso a filesystem, rete, credenziali e distribuzione necessario per l'attività. Le azioni ad alto rischio dovrebbero avvenire in ambienti isolati con log chiari e regole di scadenza.
I team dovrebbero inoltre distinguere tra operazioni reversibili e irreversibili. Generare un file locale è di solito reversibile. Inviare un messaggio, eliminare dati di produzione, ruotare un segreto condiviso o modificare un account esterno potrebbe non esserlo.
Il sistema dovrebbe richiedere prove più solide prima di consentire azioni irreversibili. Tali prove potrebbero includere un'esecuzione a secco, l'approvazione umana, un'anteprima delle modifiche, la conferma del backup o la valutazione delle policy.
La revisione del codice AI deve esaminare gli effetti collaterali, non solo lo stile del sorgente. I revisori dovrebbero chiedersi quali dati legge il programma, quali sistemi contatta, quale stato modifica e come l'operazione può essere annullata.
Anche la provenienza è importante. I team devono sapere quale modello o agente ha prodotto una modifica, quale specifica ha ricevuto, quali strumenti ha invocato, quali test sono stati eseguiti e chi ha approvato il risultato.
Questo registro non è una decorazione burocratica. Aiuta gli investigatori a ricostruire i fallimenti quando l'implementazione generata è stata in seguito sostituita o eliminata.
Il rischio della catena di fornitura crea un altro effetto duraturo. Un agente può selezionare una dipendenza in base alla somiglianza del nome o a esempi obsoleti. Quel pacchetto può introdurre vulnerabilità o obblighi di licenza molto tempo dopo la scomparsa del codice iniziale.
I controlli del repository possono bloccare pacchetti sconosciuti, richiedere lockfile, analizzare le licenze e limitare le fonti di installazione. Gli agenti dovrebbero operare all'interno di questi controlli anziché aggirarli per comodità.
L'obiettivo non è conservare per sempre tutto il codice sorgente usa e getta. È preservare le prove necessarie per spiegare e governare gli effetti del sorgente.
Un programma temporaneo può rimanere temporaneo quando il suo ambiente è isolato, i suoi input sono controllati, i suoi output sono convalidati e la sua durata è applicata. Senza queste condizioni, “temporaneo” descrive un'intenzione anziché una proprietà.
Cosa dovrebbero osservare i lettori di Google News
Il futuro write-only sarà deciso dall'economia della verifica, non dalle dimostrazioni di generazione del codice.
Il primo segnale da osservare è se le organizzazioni spostano la revisione a monte. Specifiche, piani di test, modelli di minaccia e vincoli architetturali dovrebbero ricevere maggiore attenzione formale prima che gli agenti inizino l'implementazione.
Le prove di questo cambiamento rafforzerebbero la tesi del codice write-only. I team tratterebbero l'intento come l'artefatto durevole e l'implementazione come un'espressione sostituibile dello stesso.
Se le pull request continuano a crescere mentre le pratiche di revisione restano invariate, la tesi si indebolisce come modello operativo. Descriverebbe il volume di codice senza risolvere il conseguente problema di comprensione.
Il secondo segnale è se le metriche di consegna migliorano insieme alla produttività individuale. Le organizzazioni dovrebbero misurare il lead time, il tasso di fallimento delle modifiche, il tempo di ripristino, i difetti sfuggiti e il carico operativo.
Più codice generato non equivale al successo. Più funzionalità completate con un comportamento stabile in produzione equivalgono al successo.
Il lavoro di DORA suggerisce che l'AI può aumentare il throughput incrementando al tempo stesso l'instabilità. Un miglioramento sostenuto in entrambe le dimensioni mostrerebbe che test, platform engineering e governance stanno recuperando terreno rispetto alla generazione.
Un'instabilità persistente sosterrebbe la conclusione opposta. Significherebbe che le organizzazioni producono implementazioni più velocemente di quanto possano assorbirle in sicurezza.
Il terzo segnale è se gli agenti di programmazione acquisiscono un contenimento più forte e misurabile. Occorre osservare sandboxing predefinito, credenziali limitate, policy leggibili dalle macchine, log completi degli strumenti e approvazione obbligatoria per azioni irreversibili.
Questi controlli renderebbero più sicuro il codice AI usa e getta perché ne limitano gli effetti anche quando gli esseri umani non ispezionano ogni riga. Darebbero inoltre alle imprese una base credibile per delegare attività più ampie.
Un aumento di fughe di dati legate agli agenti, modifiche non autorizzate o applicazioni interne abbandonate metterebbe in luce la debolezza del modello. Mostrerebbe che l'eliminazione ha ridotto la visibilità senza ridurre le conseguenze.
I lettori dovrebbero inoltre evitare di trattare ogni flusso di lavoro di programmazione AI come un'unica categoria. Un test unitario generato, una migrazione di repository e una modifica autonoma in produzione presentano rischi diversi.
Il giusto livello di supervisione dipende dalla sensibilità dei dati, dalla reversibilità, dalla criticità del sistema e dalla fiducia nella verifica. I team hanno bisogno di categorie esplicite anziché di un unico processo di approvazione universale.
Google News ha portato in primo piano un'espressione provocatoria, ma l'espressione dovrebbe iniziare l'analisi anziché concluderla. Il codice può diventare write-only senza diventare irresponsabile. Può diventare sostituibile senza diventare privo di conseguenze.
La sfida pratica consiste nel rendere intenzione, vincoli, test, provenienza e prove operative più durevoli di qualsiasi singola implementazione. I team che raggiungono questo equilibrio possono beneficiare di una generazione più economica senza rinunciare al controllo.
I team che non sono in grado di descrivere questi controlli dovrebbero fermarsi prima di definire il proprio codice usa e getta. Dovrebbero porsi una domanda più difficile: se nessuna persona legge integralmente questa implementazione, quale sistema affidabile intercetterà l'errore prima dei clienti?
