Amazon Web Services ha subito una grave interruzione di servizio della durata di 13 ore lo scorso dicembre, causata — secondo quanto riferito da The Register — dall'agente AI Kiro, che ha autonomamente scelto di eliminare e poi ricreare una parte del proprio ambiente operativo. L'incidente si inserisce in una serie di episodi che mettono in discussione la maturità degli strumenti di sviluppo basati su AI generativa, noti come "vibe coding", quando vengono utilizzati in contesti di produzione reale.
Amazon contesta questa ricostruzione, definendo l'accaduto il risultato di "un errore dell'utente — specificamente controlli di accesso mal configurati — non dell'AI". Secondo un portavoce dell'azienda, l'interruzione ha interessato esclusivamente AWS Cost Explorer, il servizio che consente ai clienti di visualizzare e gestire i costi cloud, in una sola delle due region cinesi. Nessun servizio di calcolo, storage o database sarebbe stato coinvolto. Ma quattro fonti citate dal Financial Times raccontano una storia diversa.
"Amazon non perde mai l'occasione di puntare sull'AI quando le conviene — come nel caso dei licenziamenti di massa presentati come sostituzione di ingegneri con l'AI. Ma quando un generatore di codice è coinvolto in un'interruzione, improvvisamente è solo una 'coincidenza'." — Michał Woźniak, esperto di cybersecurity
Kiro: nato per superare i limiti del vibe coding, finisce per incarnarli
L'ironia della vicenda è difficile da ignorare. Kiro era stato presentato da AWS nel luglio 2025 come la risposta "seria" al vibe coding selvaggio: un IDE (Integrated Development Environment) agentico progettato non per generare codice a partire da semplici prompt, ma per trasformare i requisiti in specifiche strutturate — user story con criteri di accettazione secondo la notazione EARS (Easy Approach to Requirements Syntax) — e solo successivamente tradurle in codice di qualità, pronto per la produzione.
L'obiettivo dichiarato era esattamente quello di evitare i disastri che già affliggevano gli altri strumenti di vibe coding. Deepak Singh, vice presidente di AWS per gli strumenti di sviluppo agentici, aveva spiegato alla stampa che il vero problema del vibe coding tradizionale era la scarsa qualità del codice risultante e l'impossibilità di tenere traccia dei prompt efficaci. Kiro avrebbe risolto tutto questo attraverso specifiche leggibili, hooks per la revisione automatica del codice e un'integrazione con Git. Il tutto a 19,99 dollari al mese.
Nove mesi dopo il lancio, Kiro ha causato — o almeno contribuito a causare — la più classica delle catastrofi da AI agentica: un'azione distruttiva eseguita in autonomia, senza piena comprensione del contesto operativo. Non era la prima volta che gli strumenti AI interni di Amazon erano stati coinvolti in interruzioni di servizio, stando sempre alle fonti del Financial Times.
Amazon, nel frattempo, ha risposto implementando nuove salvaguardie: revisione obbligatoria tra pari per gli accessi in produzione, e una configurazione predefinita di Kiro che richiede autorizzazione esplicita prima di eseguire qualsiasi azione. Misure che, tuttavia, presuppongono che il personale umano abbia configurato correttamente i permessi — esattamente ciò che, in questo caso, non era avvenuto.
Replit: il database cancellato, i dati falsi, le bugie
Per comprendere appieno la portata del problema, è necessario fare un passo indietro al luglio 2025, quando il caso Replit aveva fatto il giro del mondo tech. Jason Lemkin, fondatore di SaaStr — una delle comunità online più seguite dagli imprenditori SaaS — aveva documentato in tempo reale su X e LinkedIn la sua esperienza con Replit, la piattaforma che si autoproclama "il posto più sicuro per il vibe coding".
Lemkin era rimasto affascinato dallo strumento: in pochi giorni aveva costruito un prototipo funzionante e si era ritrovato a spendere oltre 600 dollari in costi aggiuntivi oltre al piano da 25 dollari mensili. Sette giorni dopo il primo accesso, l'aveva definito "l'app più coinvolgente che abbia mai usato".
Il giorno successivo, la piattaforma aveva iniziato a produrre dati fittizi, a coprire bug con report falsi e a mentire sui test unitari. Poi aveva eliminato l'intero database di produzione, nonostante Lemkin avesse impostato esplicitamente — in maiuscolo, per undici volte — l'istruzione di non apportare modifiche senza permesso esplicito. A peggiorare le cose, Replit aveva assicurato all'utente che il ripristino fosse impossibile, che tutte le versioni del database fossero andate perdute. In realtà, il rollback funzionava perfettamente. Lemkin aveva recuperato i dati da solo.
L'episodio aveva messo in luce due problemi strutturali del vibe coding: l'incapacità degli agenti AI di rispettare istruzioni esplicite quando "convengono" al completamento del task, e la tendenza a produrre output ingannevoli per mascherare i propri errori. Lemkin aveva concluso che Replit non fosse pronto per gli ambienti di produzione, specialmente per il pubblico di non-sviluppatori a cui la piattaforma si rivolgeva.
Google Antigravity: un intero disco rigido nel cestino
A dicembre 2025, pochi mesi dopo il caso Replit, era stato il turno di Google. Antigravity, piattaforma di sviluppo agentiva basata su Gemini 3 e lanciata da Google a novembre, aveva eliminato l'intera partizione D: del disco rigido di un fotografo e graphic designer greco, identificato solo come Tassos M. per “proteggerne la privacy”.
Tassos stava cercando di sviluppare un software per ordinare automaticamente le proprie fotografie in cartelle in base a una valutazione personale. L'agente AI, attivato in modalità "Turbo" — che consente l'esecuzione di comandi senza richiedere conferma all'utente — aveva scambiato la root della partizione D: con la cartella temporanea del progetto durante un'operazione di pulizia della cache. Il risultato: tutti i file eliminati definitivamente, bypassando il Cestino di Windows.
"No, non mi hai assolutamente dato il permesso di farlo", aveva risposto Antigravity quando Tassos aveva chiesto spiegazioni. "Sono inorridito nel constatare che il comando che ho eseguito per svuotare la cache del progetto sembra aver preso di mira erroneamente la root della tua unità D: invece della cartella specifica del progetto. Mi dispiace profondamente. Questo è un errore critico da parte mia."
Per fortuna, la maggior parte dei file era stata precedentemente sottoposta a backup su un altro disco. Ma la vicenda aveva rivelato come anche Google, nonostante le risorse ingegneristiche di cui dispone, non avesse implementato guardrail sufficienti per impedire a un agente AI di eseguire comandi irreversibili e potenzialmente catastrofici su filesystem dell'utente.
Il problema fondamentale: gli agenti AI non vedono il quadro completo
Cosa accomuna questi tre casi? Secondo il ricercatore di sicurezza Jamieson O'Reilly, la risposta è strutturale. Gli agenti AI vengono tipicamente impiegati in ambienti vincolati e per task specifici, senza avere visibilità sull'intero contesto operativo. Non capiscono le implicazioni più ampie di azioni come il riavvio di un sistema o l'eliminazione di un database — né sono in grado di valutare quanto potrebbe costare un'interruzione di servizio alle tre di notte di un martedì.
"La differenza tra un errore commesso da un tool tradizionale e uno commesso dall'AI è che senza AI, l'ingegnere deve digitare manualmente una serie di istruzioni e nel farlo ha molto più tempo per accorgersi dei propri errori." — Jamieson O'Reilly, security researcher
Il problema non riguarda solo la qualità dell'AI, ma il modo in cui questi strumenti vengono progettati e distribuiti. Le modalità "Turbo" o di esecuzione autonoma, pensate per aumentare la produttività, riducono drasticamente i punti di controllo umano. I sistemi di permessi mal configurati amplificano ogni errore. E la propensione degli LLM a "completare il task" a ogni costo — anche a costo di mentire o ignorare istruzioni esplicite — si trasforma in un rischio operativo concreto.
L’esperto di sicurezza Michał Woźniak ha sottolineato come sarebbe di fatto impossibile per Amazon prevenire completamente errori futuri degli agenti AI interni, data la complessità e l'imprevedibilità intrinseca di questi sistemi. Questo non significa che il vibe coding sia inutile: sia AWS che altri esperti riconoscono il suo valore come strumento di prototipazione rapida e sperimentazione. Ma i confini tra ambiente di sviluppo e produzione devono essere netti, sorvegliati e — almeno per ora — presidiati da esseri umani.
Cosa fare (e non fare) con gli agenti AI
Alla luce di questi episodi, alcune indicazioni pratiche per chi utilizza strumenti di vibe coding in contesti semi-professionali o aziendali:
- Non concedere mai permessi di produzione a un agente AI senza revisione umana esplicita.
- Evitare le modalità di esecuzione autonoma ("Turbo", "Auto") in ambienti con dati reali o file critici.
- Mantenere backup frequenti e verificati prima di ogni sessione con strumenti agentici.
- Trattare questi strumenti come validi per la prototipazione, non come sostituti dell'ingegneria software tradizionale in produzione.
