Amazon Perde 6.3 Milioni di Ordini per Codice AI: Ora Serve la Double Review
Due outage in una settimana, 6.3 milioni di ordini persi in 6 ore. Amazon impone double code review e reset di sicurezza su 335 sistemi. Cosa è successo.
Alessandro Saiani
Human in the Loop
6.3 milioni di ordini. Sei ore. Un calo del 99% dei volumi nei marketplace nordamericani di Amazon. Non un test di carico andato male — un sabato di marzo 2026 su uno degli e-commerce più grandi del pianeta.
La causa? Codice andato in produzione con "Gen-AI assisted changes", secondo un briefing interno. La risposta di Amazon? Un reset di sicurezza di 90 giorni su 335 sistemi critici, double code review obbligatoria per tutti — compresi gli ingegneri senior — e un meeting di emergenza chiamato "deep dive".
È la storia di come il codice AI è passato da problema teorico a 6.3 milioni di ordini evaporati.
Due Incidenti in Quattro Giorni
La cronologia è questa.
2 marzo 2026: primo incidente. 120.000 ordini persi, 1.6 milioni di errori registrati sui servizi web. Grave, ma gestibile. Un outage come tanti nella storia di un'infrastruttura enorme come quella di Amazon.
5 marzo 2026: secondo incidente. Molto più grave. Il volume di ordini nei marketplace nordamericani crolla del 99%. In sei ore, Amazon perde circa 6.3 milioni di ordini. Non un rallentamento, non un degradamento parziale — un collasso quasi totale della capacità di processare acquisti.
Il 10 marzo Amazon convoca un meeting interno di emergenza, un "deep dive" per capire cosa è successo e come evitare che si ripeta.
La Risposta: 90 Giorni di Reset
Il piano che esce dal deep dive è aggressivo. Amazon lancia un reset di sicurezza di 90 giorni che copre circa 335 sistemi critici. Non è un audit — è una ristrutturazione dei processi di deployment.
Le nuove regole:
- Double code review obbligatoria prima di ogni deploy, anche per ingegneri senior. Nessuna eccezione
- Processo formale di documentazione e approvazione per ogni modifica in produzione
- Controlli automatizzati più rigorosi nella pipeline di deployment
- Revisione completa dei sistemi identificati come critici
Il messaggio è chiaro: non basta più che un senior dica "ho controllato, va bene". Serve un secondo paio di occhi. Sempre.
"Errori Umani, Non Errori AI"
Qui la cosa si fa interessante. Secondo quanto riportato, un briefing interno parla esplicitamente di un "trend of incidents" con "high blast radius" associati a "Gen-AI assisted changes".
La correlazione è nel documento. Ma la posizione ufficiale di Amazon è diversa: si tratta di errori umani, non errori AI.
La narrativa è familiare. L'avevamo già vista con l'outage di AWS Cost Explorer causato da Kiro a dicembre 2025, quando Amazon aveva detto la stessa cosa: "È stato l'umano a configurare male i permessi, non l'AI a prendere la decisione sbagliata."
Tecnicamente, potrebbe essere vero in entrambi i casi. Un ingegnere che accetta un suggerimento AI senza verificarlo sta commettendo un errore umano. Ma è un errore che non sarebbe esistito senza l'AI. Se il codice problematico è stato generato da un assistente AI e un umano lo ha approvato senza capirlo, di chi è la colpa?
La risposta onesta è: di entrambi. Ma chiamarlo solo "errore umano" oscura il problema reale — e il problema reale è il processo.
Il Verification Gap in Azione
Quello che è successo ad Amazon ha un nome nel nostro mondo: verification gap. È la distanza tra la velocità con cui l'AI genera codice e la velocità con cui un umano riesce a verificarlo.
L'AI ti produce una modifica in 30 secondi. La review accurata di quella modifica ne richiede 15 minuti. In un contesto di pressione su delivery e deployment, la tentazione è accettare più velocemente di quanto dovresti. Moltiplica per centinaia di ingegneri e migliaia di deploy al giorno, e hai la ricetta per un "trend of incidents".
Ne abbiamo parlato in modo approfondito nell'analisi sull'agentic engineering: il passaggio dal vibe coding a una disciplina ingegneristica richiede esattamente questo — processi di verifica che tengano il passo con la velocità di generazione.
Amazon, a modo suo, sta arrivando alla stessa conclusione. La double code review non è altro che un'ammissione: un singolo punto di verifica non basta più quando il codice viene generato (o assistito) dall'AI.
335 Sistemi, Un Numero che Parla
Il numero 335 merita attenzione. Non è il totale dei sistemi Amazon — è il sottoinsieme identificato come critico nel reset di sicurezza. Significa che Amazon ha mappato i sistemi dove un deployment sbagliato può avere "high blast radius" e sta applicando controlli differenziati.
È un approccio pragmatico. Non puoi mettere double review su ogni singolo commit di ogni singolo microservizio in un'organizzazione delle dimensioni di Amazon. Ma puoi identificare i 335 sistemi dove un errore costa 6.3 milioni di ordini e blindare quelli.
Per chi lavora in organizzazioni più piccole, il principio è lo stesso: non tutti i sistemi hanno lo stesso blast radius. La tua pipeline di pagamento non è il tuo blog interno. Trattali diversamente.
Cosa Significa per Chi Sviluppa
Tre cose concrete da portarsi a casa.
La double review sta diventando standard. Se Amazon — un'azienda che ha costruito la sua cultura engineering sulla velocità di deployment — decide che serve un secondo reviewer obbligatorio, è un segnale forte. Non è burocrazia: è il costo della velocità AI senza verifica.
"Errore umano" è la scusa comoda. Quando un'azienda dice che l'AI non c'entra ma contemporaneamente ristruttura 335 sistemi e impone double review dopo incidenti legati a "Gen-AI assisted changes", i fatti parlano più delle dichiarazioni ufficiali.
Il blast radius è il metro. Non serve blindare tutto. Serve sapere cosa blindare. Amazon ha perso 6.3 milioni di ordini perché il codice problematico è finito in un sistema ad alto impatto. Se quel codice fosse finito in un servizio secondario, sarebbe stato un ticket Jira, non una notizia.
Il codice AI non è il problema. Il codice AI non verificato in sistemi ad alto impatto è il problema. Amazon l'ha imparato nel modo più costoso possibile.
Fonti: