Otto mesi dopo che Kiro ha raggiunto la disponibilità generale, l'idea duratura si rivela essere la spec, e la parte meno duratura si rivela essere l'IDE. Kiro è stato lanciato come un IDE agentico il cui messaggio era che lavori a livello di specifica e lasci che l'agente implementi. La parte che è rimasta è l'artefatto: una dichiarazione scritta di intento che un umano revisiona prima che il codice esista. La parte che silenziosamente si è persa è l'assunzione che l'editor sia il luogo dove questo accade. Kiro ha lanciato una CLI al GA, ha aggiunto la modalità headless, e il terminale è dove è andato l'utilizzo interessante.

Ho scritto del GA di Kiro alla fine dell'anno scorso in AWS Monthly (Dec '25): The Kiro Era Begins, con più entusiasmo che distanza. Otto mesi sono abbastanza per dire quali parti di quel pezzo hanno retto.

Cosa è stato davvero lanciato

Kiro è entrato in preview a luglio 2025 e ha raggiunto il GA il 17 novembre 2025. Il GA non è stato un rilascio di stabilità, è stato un rilascio di scope: test basati su proprietà che derivano casi di test dai criteri di accettazione di una spec, checkpointing così le modifiche di un agente possono essere annullate, supporto multi-root workspace, piani team gestiti centralmente tramite AWS IAM Identity Center, e Kiro CLI, che ha messo l'agente nel terminale.

Da allora la traiettoria è stata coerente e poco appariscente. Kiro CLI ha ricevuto la modalità headless ad aprile 2026, così l'agente gira nelle pipeline anziché accanto a un umano. Le release CLI di gennaio 2026 riguardavano allowlist e blocklist per quali URL un agente può recuperare, scorciatoie da tastiera per agenti personalizzati, diff migliori. Non è una roadmap che insegue una demo. È uno strumento adattato alla produzione, e la forma dell'adattamento ti dice cosa la gente sta davvero facendo con esso.

La spec era la buona idea

Il vero contributo di Kiro è che ha reso la specifica un file. Requisiti, design, e task, nel repo, versionati, revisionabili, confrontabili. Sembra una cosa piccola accanto a "l'AI scrive il tuo codice" ed è l'unica parte che difenderei senza riserve.

Il motivo è dove sposta la revisione. La codifica agentica non governata produce un diff grande e chiede a un umano di valutarlo dopo il fatto, che è il momento peggiore possibile: il lavoro è finito, l'autore è una macchina senza memoria del proprio ragionamento, e rifiutarlo significa buttare via qualcosa che sembra finito. Revisionare una spec inverte questo. Stai leggendo l'intento, nel punto in cui cambiarlo costa una frase. L'economia del "no, non così" è completamente diversa prima e dopo l'implementazione.

Quella proprietà non ha nulla a che fare con l'AI, ed è proprio per questo che è sopravvissuta. È design review con un ciclo di feedback più corto, e regge indipendentemente dal fatto che chi implementa sia un agente, un contractor, o tu il martedì prossimo.

Dove non ha retto

Tre fallimenti onesti, e tutti erano visibili presto a chiunque lo usasse su lavoro reale.

Le spec vanno alla deriva

Requisiti e design vengono generati in anticipo e non si aggiornano da soli quando l'implementazione rivela che il design era sbagliato. I team riportano esattamente la dinamica che ti aspetteresti: il codice si muove, la spec no, e nel giro di poche settimane la spec è un documento che descrive un sistema che non esiste più. Non è un fallimento dell'AI, è il fallimento più antico della documentazione software, reintrodotto da uno strumento che ha reso il documento economico da produrre e per niente più economico da mantenere. Economico da scrivere e costoso da mantenere vero è la combinazione specifica che genera artefatti obsoleti.

L'overhead non si adatta al lavoro piccolo

La versione schietta, da chi l'ha provato su un piccolo bug fix, è che il workflow della spec è una mazza per una noce. Requisiti, design, e scomposizione dei task per cambiare una regola di validazione è peggio che semplicemente cambiare la regola di validazione. La cerimonia è proporzionale a niente, e la maggior parte del lavoro ingegneristico è piccolo.

La rigidità è reale

Spec-first presuppone che tu sappia cosa vuoi prima di iniziare. Molto software viene scritto da persone che scoprono cosa vogliono scrivendolo. Per il lavoro esplorativo, anticipare la specifica non è disciplina, è un'ipotesi formalizzata in un documento che ora ha un'autorità che non si è guadagnato. La critica secondo cui lo sviluppo spec-driven reimporta dinamiche waterfall non è del tutto ingiusta, ma non è nemmeno del tutto sbagliata, e la differenza dipende da se il tuo team tratta la spec come un contratto o come una bozza.

Quindi per chi è

Il pattern emerso è più stretto del messaggio di marketing e più difendibile. Le spec si guadagnano il loro overhead quando i requisiti sono ambigui, quando le persone coinvolte sono abbastanza distribuite da non poter assumere una comprensione condivisa, o quando la tracciabilità è un obbligo anziché una comodità. In un contesto regolamentato, "ecco la spec revisionata, ecco il diff che la implementa" non è overhead. È l'artefatto di audit che avresti dovuto costruire comunque, prodotto come sottoprodotto.

Per un piccolo team su una codebase ben compresa, l'overhead è per lo più costo. Questa non è una critica a Kiro. È un'affermazione di scoping che il marketing non avrebbe mai potuto fare.

Cosa hanno davvero cambiato gli IDE AI

Ecco l'affermazione retrospettiva, e la tengo con mano leggera.

Il cambiamento non è che l'AI scrive il codice. Quello è successo, è genuinamente utile, ed è ormai abbastanza scontato che discuterne è noioso. Il cambiamento è che l'unità di revisione umana si è spostata a monte, dal diff all'intento. Le spec di Kiro sono un'implementazione. AGENTS.md e i file di steering sono un'altra. Il pattern è lo stesso: gli umani definiscono i vincoli e revisionano l'intento, gli agenti producono le implementazioni, e l'artefatto su cui gli umani discutono smette di essere il codice.

Il secondo cambiamento è che l'IDE si è rivelato non essere il contenitore giusto. La CLI e la modalità headless di Kiro stesso dimostrano il punto meglio di qualsiasi critico. Se un umano non legge ogni modifica mentre arriva, l'editor è un'interfaccia per qualcosa che non ne ha più bisogno, e l'agente appartiene a dove vive il resto della tua automazione. L'IDE era la rampa d'accesso, non la destinazione.

Il punto chiave

Otto mesi dopo il GA, il contributo duraturo di Kiro è la specifica come file revisionabile e versionato, che ha spostato il giudizio umano nel punto in cui è più economico applicarlo. I costi sono reali e specifici: le spec vanno alla deriva perché generarle è economico e mantenerle non lo è, e la cerimonia non si adatta al lavoro piccolo o esplorativo. Usala dove l'ambiguità o la tracciabilità giustificano l'overhead e saltala dove non lo fanno. E nota che l'output più utile dell'IDE agentico è stata una CLI, il che è l'industria che ti dice dove sta andando tutto questo.

Leggi questo dopo

Il lato pipeline dell'esecuzione di agenti in CI, runner, credenziali, e raggio d'esplosione, vive nelle field notes su ercan.cloud. L'hub è su ercanermis.com.