L’AI scrive codice, ma la tua infrastruttura può stare al passo?

Stiamo vivendo una delle più strane inversioni nella storia dell’ingegneria del software. Per decenni, l’obiettivo era il determinismo; costruire sistemi che si comportano sempre nello stesso modo. Ora stiamo sovrapponendo agenti AI probabilistici a quella base, generando codice a una scala e velocità allarmanti. E onestamente? La maggior parte della nostra infrastruttura non è stata costruita per questo.

Ho trascorso anni lavorando su strumenti DevOps, co-autore di ricerche e aiutando team di ingegneri a raggiungere le loro prestazioni più elevate. Ciò che sto vedendo ora con lo sviluppo guidato da AI è più di una semplice evoluzione. Sta esponendo ogni crepa nei nostri flussi di lavoro esistenti.

Il problema è già qui

Uno studio del 2025 di GitClear ha scoperto che quasi il 7% dei commit contiene codice generato da AI. La loro analisi precedente di 153 milioni di righe di codice modificato ha rivelato il costo: “code churn” – codice riscritto o cancellato entro due settimane – è raddoppiato entro il 2024 rispetto ai valori di base pre-AI.

Le implicazioni per la sicurezza sono altrettanto drastiche. Un’analisi recente di 80 compiti di codifica curati su più di 100 grandi modelli linguistici ha scoperto che il codice generato da AI introduce vulnerabilità di sicurezza nel 45% dei casi. L’impatto nel mondo reale? Un rapporto su cinque CISO ora segnalano incidenti importanti causati direttamente dal codice generato da AI.

I guadagni di velocità sono reali, ma anche i costi di stabilità.

L’effetto di amplificazione

Una cosa che ho imparato è che l’AI amplifica tutto. Se hai buone pratiche, l’AI le rende migliori e più veloci. Se i tuoi processi sono disordinati, l’AI esacerba quel disordine, anche. Ciò rispecchia un modello che appare anno dopo anno nei rapporti annuali DevOps di DORA: meno variabili portano a migliori risultati. I team di successo standardizzano su meno sistemi operativi, meno linguaggi di programmazione, meno modi di fare le cose. Riducono intenzionalmente la complessità.

Gli agenti AI seguono lo stesso modello. Se gli dai un ambiente coerente in cui Python significa la stessa versione su ogni macchina dello sviluppatore, in cui le dipendenze sono bloccate e tracciate, essi eccellono. Se li costringi a navigare 17 diverse configurazioni, ognuna con differenze sottili, stai bruciando token per capire le peculiarità ambientali invece di risolvere problemi reali.

La paradosso del determinismo

Ciò crea una tensione affascinante. Per anni, la scienza informatica ha perseguito il determinismo come obiettivo finale. Ora stiamo eseguendo carichi di lavoro probabilistici, modelli AI che letteralmente non possono garantire la stessa output due volte, su sistemi progettati per la prevedibilità.

La mia risposta? Mantenere il più possibile della pila deterministica. Se puoi mantenere l’80% della tua infrastruttura a un livello deterministico, i tuoi agenti AI hanno meno variabili da gestire. Non stanno spendendo finestre di contesto su “Perché questa dipendenza non si è installata?” o “Lasciami riprovare questo comando di build”. Stanno concentrati sul lavoro reale che gli chiedi di fare.

Pensaci: quando un agente tenta di compilare qualcosa e i binding nativi falliscono perché ImageMagick non è installato, è una deviazione costosa in termini di token. Se il tuo ambiente già include tutto il necessario (compilatori, librerie, l’intero albero delle dipendenze fino a libc), l’agente funziona. Nessun debug, nessun tentativo ed errore, solo progressi.

Specificazione e convalida sono chiave

Ciò che sta diventando chiaro è che lo sviluppo guidato da AI ci costringe a pensare più duramente a due abilità storicamente sottovalutate: specificazione e convalida. Devi articolare cosa stai costruendo effettivamente e devi avere metodi robusti per verificare che l’abbia fatto.

Ho notato qualcosa di interessante: le persone con background di gestione del prodotto o ingegneria del prodotto sono spesso più efficaci con gli agenti AI in questo momento. Sono già addestrati a pensare in termini di requisiti, criteri di successo e compromessi. Sono a loro agio nel chiedere “Perché hai fatto quella scelta?” e nel regolare in base alla ragione.

La convalida, sapere se la cosa è effettivamente corretta, è sempre stato il problema più difficile dell’ingegneria del software. La QA è stata sottostimata per decenni, eppure è la parte più impegnativa: determinare se il software risolve effettivamente il bisogno dell’utente. L’AI non risolve questo. Se mai, lo rende più critico, perché ora stai convalidando output probabilistici contro requisiti deterministici.

Fiducia, ma verifica (e controlla)

C’è un sentimento che sto iniziando ad abbracciare: dovremmo supporre che il codice generato da AI sia ostile fino a quando non viene provato diversamente. Non perché l’AI sia malizioso, ma perché semplicemente non lo sappiamo. Non possiamo esaminare ogni riga quando gli agenti generano migliaia di righe al giorno.

Ciò significa spostare i punti di controllo. Se non possiamo bloccare tutto al momento dello sviluppo, abbiamo bisogno di controlli più forti al momento dell’esecuzione. Gli operatori, gli SRE, i team di piattaforma, chiunque sia responsabile della produzione, necessitano di una migliore visibilità su cosa sta girando, di un tracciamento completo delle dipendenze e di una chiara provenienza per ogni artefatto.

È qui che la riproducibilità diventa essenziale. Quando puoi provare matematicamente che l’artefatto che hai testato localmente è identico a quello in esecuzione in produzione – stessi input, stessi output, stessa chiusura delle dipendenze – puoi iniziare a prendere decisioni intelligenti. Forse non hai bisogno di eseguire nuovamente i test unitari in CI se li hai già eseguiti localmente e nulla è cambiato. Forse puoi mappare la copertura dei test ai cambiamenti del codice e saltare le suite di test non pertinenti.

Cosa viene dopo

Siamo a un punto di svolta. I team che già avevano buone pratiche stanno vedendo enormi guadagni di produttività con l’AI. I team che stavano lottando ora stanno lottando più velocemente.

L’infrastruttura che alimenta lo sviluppo guidato da AI deve essere costruita per la riproducibilità fin dall’inizio. Non aggiunta successivamente con strumenti di scansione e audit, ma incorporata nel modo in cui gli sviluppatori lavorano fin dal primo giorno. Quando il tuo ambiente di sviluppo è identico su Mac e Linux, quando ogni dipendenza è tracciata e bloccata, quando hai una completa provenienza per ogni artefatto, gli agenti AI diventano moltiplicatori di forza invece di generatori di caos.

Ecco il mio più grande consiglio per i team che cercano di avere successo nell’era dell’AI:

• Standardizza senza pietà. Meno variabili corrispondono a prestazioni più elevate. Blocca la tua pila tecnologica, applica ambienti coerenti su tutte le piattaforme ed elimina la deriva della configurazione prima che l’AI la amplifichi. Se le incompatibilità di versione di Python causano problemi ora, causeranno problemi 10 volte più grandi quando l’AI genererà codice su larga scala.

• Incorpora la convalida nel tuo flusso di lavoro, non alla fine. Con l’AI che genera codice più velocemente di quanto gli esseri umani possano revisionarlo, non puoi affidarti solo alla revisione manuale del codice. Implementa test automatizzati che convalidano non solo che il codice funzioni, ma che soddisfi effettivamente il requisito. Fai della tua pipeline CI/CD la tua rete di sicurezza, con forti cancelli al momento dell’esecuzione per i deploy in produzione.

• Investi nella riproducibilità come infrastruttura. Tratta la coerenza dell’ambiente come una preoccupazione di infrastruttura di prima classe. Quando puoi provare matematicamente che il tuo ambiente locale, l’ambiente CI e l’ambiente di produzione sono identici, elimini una intera classe di problemi “funziona sulla mia macchina”. Questa base deterministica è ciò che ti consente di sovrapporre in modo sicuro carichi di lavoro AI probabilistici.

La domanda non è se l’AI scriverà la maggior parte del nostro codice. Già lo fa per molti team. La domanda è se la nostra infrastruttura può stare al passo.