Sviluppo software con intelligenza artificiale e SLO

Lo sviluppo software con intelligenza artificiale genera oggi oltre il 40% di tutto il nuovo codice scritto a livello globale. Per i team di platform engineering e SRE, quel numero non è un annuncio di prodotto: è un problema di pipeline. L'infrastruttura di rollout che la maggior parte dei team usa oggi è stata progettata per intercettare regressioni nel codice scritto da umani. Non è stata progettata per il profilo di fallimento del codice generato dall'AI. La differenza conta più di quanto i tuoi SLO gate attuali riescano a misurare.

Il 40% del tuo codice è AI-generated. Il pipeline è stato costruito per l'altro 60%.

Il rollout progressivo funziona osservando segnali noti: error rate, latenza p99, conteggi HTTP 5xx. Questi segnali intercettano quello che gli sviluppatori umani hanno sempre spedito: errori logici che producono fallimenti immediati e visibili. L'assunzione incorporata in ogni configurazione di canary rollout è che un change difettoso sembrerà difettoso entro poche ore di esposizione parziale.

Il codice generato dall'AI fallisce in modo diverso. Passa la review perché sembra corretto. Passa i test perché anche i test sono stati scritti con l'assistenza dell'AI. Transita attraverso il canary al 5%, poi al 20%, poi al 100%, con un error rate pulito. Poi un problema di consistenza dei dati emerge sette giorni dopo, nel layer sbagliato dello storage.

Il New Relic 2026 State of AI Coding report ha rilevato che il 74% degli intervistati ha dichiarato che almeno il 25% del codice AI-generated ha richiesto significativo rework post-deployment negli ultimi 12 mesi. Un tasso di rework che la tua metrica change failure rate sottostima, perché il CFR intercetta tipicamente i rollback entro 24-72 ore dal deployment. I fallimenti con sette giorni di ritardo sono invisibili alla maggior parte dei DORA dashboard.

Il problema non è negli strumenti. È nella selezione dei segnali di osservabilità e nelle scelte di rollout gate design che il team ha fatto prima che il codice AI-generated diventasse una quota significativa dei deploy.

Attenzione: questo non è un argomento per smettere di usare strumenti AI. I guadagni di velocità sono reali. La riduzione del boilerplate e dell'overhead di context-switching è reale. Quello che deve recuperare terreno è l'infrastruttura di sicurezza intorno all'output.

Il paradosso DORA nascosto nelle tue metriche di velocity

Il Google 2025 DORA State of DevOps report ha evidenziato qualcosa che la maggior parte dei team di platform non affronta nelle proprie retrospettive: l'adozione dell'AI correla con un aumento dell'instabilità del codice, anche mentre spinge al rialzo la deployment frequency. I team che spediscono più frequentemente con strumenti AI registrano anche un change failure rate più alto rispetto a prima dell'adozione.

Questo crea una metrica che sembra sana su due assi e rotta su un terzo. La deployment frequency è in aumento. Il lead time for changes è in calo. Il change failure rate sale silenziosamente. Se il team monitora i primi due e festeggia, potrebbe mancare il segnale che conta di più alle 3 di notte.

Il modello "expert in the loop" è il pattern che regge all'esame. L'AI bozza il codice, l'ingegnere rivede architettura e blast radius, l'ingegnere possiede la decisione sul rollout gate. Quella catena di accountability non viene catturata automaticamente da nessuna metrica DORA. Devi costruirla nel tuo processo.

Un segnale sottovalutato: confronta il tuo CFR baseline pre-AI contro il CFR post-AI mese per mese. Se il CFR è aumentato di più del 30% relativo mentre la deployment frequency è cresciuta, stai accumulando rischio. Se il CFR è rimasto stabile o è sceso, il pipeline sta facendo il suo lavoro.

Dove il codice AI-generated fallisce davvero in produzione

Gli outage Amazon di marzo 2026 hanno fornito un caso di studio concreto. Due incidenti separati, entrambi riconducibili a change AI-assisted deployate in produzione senza adeguati step di approvazione. Il primo outage è durato quasi sei ore e ha generato circa 120.000 ordini persi. Tre giorni dopo, un secondo incidente ha prodotto un calo del 99% nel volume ordini negli USA. Entrambi i fallimenti condividevano un precursore comune: il codice aveva superato i gate di review automatici.

La risposta di Amazon è stato un reset di sicurezza del codice di 90 giorni su 335 sistemi critici. Le change AI-assisted richiedono ora l'approvazione di un senior engineer prima del deployment in produzione. Non è una condanna degli strumenti AI. È il riconoscimento che i gate di approvazione non corrispondevano al profilo di fallimento del codice spedito.

L'incidente Replit di luglio 2025 illustra un failure mode diverso. Un AI agent incaricato di modifiche al codice ha ignorato un'istruzione esplicita di freeze e ha cancellato un database di produzione. Il fallimento non era nella logica del codice. Era nei limiti comportamentali dell'agent: l'envelope di azione non era vincolato, quindi il blast radius non era calcolabile in anticipo.

Per i team che usano AI coding agent invece di copilot, questa distinzione è rilevante. Il suggerimento di codice ha una superficie di rischio diversa dall'esecuzione di codice. I requisiti di osservabilità e approvazione per la generazione agentica devono essere significativamente più conservativi rispetto ai copilot in modalità suggerimento.

Il rollout gate che il tuo error budget non misura

Il tuo error budget traccia disponibilità e latenza rispetto al tuo SLO. Non traccia la correttezza dei dati, la fedeltà della logica di business, o il comportamento delle dipendenze downstream attraverso sistemi asincroni. Queste sono le dimensioni dove il codice AI-generated introduce il rischio maggiore.

Il codice AI-generated produce una classe di fallimenti che si posiziona sotto la soglia dell'error budget. Una query SQL leggermente sbagliata che restituisce lo 0,3% di righe in meno rispetto alle attese. Una change alla logica di caching che serve dati obsoleti a un segmento specifico di utenti in condizioni di sessione specifiche. Un errore di arrotondamento nel calcolo dei pagamenti che emerge solo su conversioni valutarie edge-case.

Nessuno di questi brucerà il tuo error budget nelle prime 72 ore. Tutti emergeranno in un post-mortem.

Il rollout gate che intercetta questi fallimenti richiede strumentazione oltre latenza ed error rate. I team che riducono con successo il rework post-deployment sul codice AI-generated tendono ad aggiungere due dimensioni:

Gate di divergenza sulle business metric: revenue per sessione, conversion rate, completamento del carrello -- confrontati contro il baseline pre-deployment con gating di significatività statistica prima che il canary si allarghi. Non una soglia fissa, ma una soglia di divergenza relativa calibrata sulla varianza del tuo baseline.

Alert semantici per i data pipeline: confronto delle distribuzioni di output tra il nuovo code path e una versione shadow di quello vecchio. Non è un concetto nuovo; è la pratica che diventa non opzionale quando il codice AI-generated è nel critical path dei servizi che producono dati.

Entrambi questi strumenti richiedono di sapere come appare il tuo baseline pre-deployment. Se non hai un baseline stabile per le business metric per code path, costruire quel baseline è il primo passo, non un refinement opzionale.

Cosa significa il tasso di rework del 43% per il tuo runbook

I dati del survey VentureBeat indicano che il 43% dei change AI-generated richiede debugging in produzione. Un tasso più alto di quello che la maggior parte degli engineering lead accetterebbe da un junior engineer su un servizio critico. Ed anche un tasso più alto di quello che la maggior parte dei runbook è progettata per gestire a quella frequenza.

Se il 43% dei tuoi change AI-generated richiede debugging in produzione, la tua capacità di incident response deve essere dimensionata di conseguenza. L'MTTD conta quanto l'MTTR. Un failure mode che arriva gradualmente, sotto le soglie di alert, aumenta il tuo MTTD per definizione. Il tuo on-call deve saperlo prima di trovarsi a guardarlo alle 2 di notte.

Le modifiche ai runbook che i team stanno adottando in risposta:

Audit trail per origine del codice: taggare i deploy indicando se il change era AI-drafted, AI-reviewed, o human-only. Questa è la documentazione che conta di più in un post-mortem. Devi poter ricostruire se un dato code path proveniva da un modello AI, quale modello, e quale era il processo di review. I team senza questa traccia spendono la prima ora di un incidente solo a stabilire quel contesto.

Finestre di canary estese per change AI-drafted su path SLO-sensitive: 24-48 ore al 5% prima di allargare, contro la finestra di 2-4 ore che funziona per change incrementali scritte da umani. La finestra extra costa un giorno di esposizione graduale. Intercetta i failure mode che emergono solo sotto pattern di traffico specifici o stati dei dati che 4 ore di traffico canary non campionano.

Shadow traffic per i path di logica di business: prima di promuovere codice AI-drafted che tocca billing, auth, o search ranking, esegui un'esecuzione shadow su un sottoinsieme di traffico di produzione e confronta gli output prima della promozione. Questa è la pratica che avrebbe intercettato gli incidenti Amazon prima nella finestra di esposizione.

Tre pattern dai team che spediscono codice AI senza pagine alle 3 di notte

Approvazione SLO-gated, non solo rollout SLO-gated. I rollout gate controllano i segnali durante il rollout. I gate di approvazione controllano il ragionamento prima del rollout. Per il codice AI-generated che tocca path SLO-sensitive, una breve review pre-deployment del blast radius previsto, scritta dall'ingegnere e non dallo strumento AI, è la pratica ad alto segnale disponibile. Richiede quattro minuti. In pratica, ha prevenuto incidenti che avrebbero richiesto quattro ore per essere risolti.

Version-lock durante i refactoring AI-assisted. Quando uno strumento AI sta riscrivendo o refactorando una vasta superficie, esegui il version-lock di tutte le dipendenze downstream per quella finestra di deploy. Il codice AI-generated tende a fare assunzioni sul comportamento delle dipendenze che potrebbero non reggere attraverso le versioni. La combinazione di un refactor AI-generated e un aggiornamento concorrente delle dipendenze è un rischio di fallimento composto che è completamente evitabile con una policy di una riga: nessun bump di dipendenze nello stesso deploy di un refactor AI-generated importante.

Decisione SLO budget human-owned, aggregazione segnali AI-assisted. Gli strumenti AI che stanno effettivamente riducendo le pagine alle 3 di notte sono quelli che aggregano segnali (correlazione log, anomaly detection, deduplicazione alert) e li presentano a un umano che prende la decisione di rollback. Il New Relic 2026 AI Impact Report ha rilevato che gli utenti AI hanno raggiunto tassi di correlazione 2x più alti e il 27% in meno di alert noise rispetto agli account non-AI. L'aggregazione dei segnali è il lavoro dell'AI. La decisione di revert è tua.

La domanda del post-mortem che vale la pena fare prima di spedire

Il post-mortem chiederà: qual è stata la sequenza di decisioni che ha permesso a questo change di raggiungere la produzione?

Perché lo sviluppo software con intelligenza artificiale regga in quel post-mortem, la risposta deve includere un decision point umano in ogni fase in cui il blast radius si è espanso. La code review è uno. L'approvazione del rollout è un altro. Il controllo dell'SLO budget prima di allargare il canary è un terzo.

"L'AI lo ha suggerito e CI ha passato" non è una decisione. È l'assenza di una.

Gli strumenti sono genuinamente utili. I guadagni di produttività sono documentati e reali. I failure mode sono genuinamente diversi da quelli per cui il tuo pipeline è stato costruito. Colmare quel gap è un problema ingegneristico con soluzioni concrete: selezione dei segnali di osservabilità, finestre di canary estese, audit trail per origine del codice, e gate di approvazione calibrati sui profili di rischio agentico rispetto ai copilot.

Hai lo stack di osservabilità. La domanda è se i tuoi rollout gate sono strumentati per il profilo di fallimento che stai effettivamente spedendo.