L'AI scrive il codice. Ma chi prende le decisioni?

I suoi agenti stanno prendendo decisioni architetturali. C'è qualcuno che le sta mettendo nero su bianco?

Punti chiave

• Il problema degli AI coding tool non è produrre codice. È che, sei mesi dopo, nessuno sa più perché il codice abbia quella forma. Kiro è il tentativo più diretto di risolverlo.
• Lo spec-driven development comporta un overhead. La domanda non è se sia più lento. Lo è. La domanda è se il suo team possa permettersi l'alternativa.
• I rischi sono concreti: spec superficiali, falsa precisione data dalla notazione EARS, ADR che sembrano completi ma non lo sono. Il workflow funziona solo se i review gate vengono trattati come gate veri.

Gli AI coding tool sono diventati bravi a produrre codice. Davvero bravi. Framework multi-agente, assistenti agentici, pipeline autonome: se il problema è "trasformare quest'idea in codice funzionante", le opzioni sono all'altezza. Ma se sviluppa software in team, probabilmente ha già sbattuto contro il muro che si presenta circa due settimane dopo la demo entusiasmante: il codice funziona, nessuno sa perché abbia quella forma e, quando qualcuno chiede perché sia stato adottato un certo approccio, la risposta onesta è "ho lasciato decidere all'agente, e non ne sono del tutto sicuro".

L'ho visto succedere ormai in diversi team. Il problema non è che l'agente abbia fatto scelte sbagliate. È che quasi ogni AI coding tool sul mercato è ottimizzato per l'esecuzione dei task e pochi investono negli artefatti che mantengono coerente nel tempo lo sviluppo software in team.

Kiro di Amazon, lanciato in preview a luglio 2025, è il tentativo più diretto che abbia visto di colmare questo divario. Non è un confronto "Kiro vs. Cursor": per pura velocità sui singoli task, Cursor, Claude Code e i framework multi-agente sono temibili. La vera domanda è se il modello di spec-driven development di Kiro, unito a un workflow di Architecture Decision Record (ADR) configurabile tramite il sistema Steering, dia ai team qualcosa che quegli strumenti non offrono: una traccia condivisa e revisionabile da persone reali di come il software è stato progettato e perché.

Il panorama multi-agente: potente, ma strutturalmente incompleto

L'attuale generazione di framework multi-agente (CrewAI, LangGraph, AutoGen, MetaGPT) è matura. Aziende come DocuSign e PwC fanno girare pipeline multi-agente in produzione su larga scala. La tesi a favore di Kiro ha senso solo se accetta il presupposto che l'alternativa sia già brava a produrre codice.

Vale la pena esaminare MetaGPT direttamente: è meno usato in produzione rispetto a LangGraph o CrewAI, ma è quello che si sovrappone di più a ciò che Kiro promette. Gli dia un requisito di una riga e produrrà artefatti strutturati: PRD, design doc, specifiche di interfaccia, codice di implementazione. Sulla carta copre lo stesso terreno dello spec-driven workflow di Kiro.

La differenza strutturale non riguarda la qualità dell'output. Riguarda chi vede le decisioni e quando.

In MetaGPT gli agenti producono artefatti e li passano all'agente successivo. L'output è completo, ma il processo è opaco: le decisioni prese dall'agente Architect non emergono come record revisionabili. Non c'è un gate di approvazione in cui il suo team legge il design document e segnala un vincolo prima che inizi l'implementazione. Gli artefatti sono output da consumare, non documenti collaborativi da revisionare.

La stessa lacuna esiste trasversalmente nei framework multi-agente. Sono eccellenti motori di esecuzione. Non sono stati progettati per produrre una comprensione condivisa, all'interno del team, del perché il software sia stato costruito in un certo modo. È una scelta di design, non un difetto. Questi framework sono ottimizzati per il completamento dei task. Kiro è ottimizzato per la leggibilità del team nel tempo.

Cosa fa davvero Kiro

Kiro è un fork di VS Code basato su Claude Sonnet su Amazon Bedrock. L'ambiente familiare conta: nessun nuovo IDE da imparare, nessun context switch, e plugin Open VSX, temi e impostazioni esistenti migrano senza attriti. Essendo un IDE general-purpose, Kiro funziona con linguaggi e framework diversi, anche se lo spec-driven workflow si manifesta più naturalmente nello sviluppo backend e full-stack, dove le decisioni architetturali pesano di più.

La differenziazione sta nel workflow che impone.

Spec-Driven Development: prima gli artefatti, poi l'esecuzione

Ogni feature in Kiro inizia con una spec, un insieme di file Markdown strutturati e committati nel repository prima che venga scritta una sola riga di codice. Il processo a tre fasi è deliberato:

Fase 1: Requisiti (requirements.md)

Il primo gate è proprio quello che la maggior parte dei team salta del tutto: requisiti scritti, revisionati e approvati prima che esista qualsiasi codice. Lei descrive ciò che vuole in linguaggio naturale. Kiro non inizia a scrivere codice. Produce invece un documento formale dei requisiti usando la notazione EARS (Easy Approach to Requirements Syntax), un formato che obbliga ogni requisito ad assumere una forma non ambigua e testabile:

WHEN [trigger condition] THE SYSTEM SHALL [observable behavior]

La notazione EARS fa emergere assunzioni che altrimenti resterebbero implicite. Se Kiro genera un criterio di accettazione che lei non aveva in mente, lo intercetta qui, non in fase di code review e non in produzione. I requisiti vengono revisionati e approvati da una persona prima che succeda qualsiasi altra cosa.

Fase 2: Design tecnico (design.md)

È la fase in cui dovrebbero avvenire i veri confronti architetturali, ed è quella in cui la maggior parte degli strumenti AI ha già iniziato a scrivere codice. Con i requisiti approvati, Kiro analizza la codebase esistente e genera un design document: gerarchie di componenti, diagrammi di flusso dati, schemi di database, contratti API, interfacce TypeScript. Il design riflette l'architettura reale del suo progetto.

È il documento che il suo team revisiona prima che venga scritta una sola riga di codice di produzione. Un architetto può obiettare su uno schema. Un senior engineer può segnalare un problema di scalabilità. Un engineer che lavora su una feature parallela può verificare se il nuovo design crea conflitti di integrazione con il suo lavoro. Tutto questo avviene su un artefatto scritto, dentro una pull request.

Fase 3: Task di implementazione (tasks.md)

Solo a questo punto inizia l'implementazione. Kiro genera una lista di task ordinata per dipendenze e mappata sui requisiti: ogni task include unit test e integration test pertinenti e, dove applicabile, stati di caricamento e considerazioni di accessibilità. I task possono essere eseguiti uno alla volta, con approvazione umana esplicita a ogni passaggio, oppure in autonomia in modalità autopilot. I diff del codice e lo storico di esecuzione dell'agente sono visibili a ogni stadio.

I file di spec vivono in .kiro/specs/<feature-name>/ all'interno del repository. Sono committati, versionati e revisionabili nelle pull request, e navigabili tramite la cronologia git. Tutto il team li vede nel momento esatto in cui esistono.

Questa visibilità cambia il modo in cui i senior engineer impiegano il loro tempo. Invece di essere trascinati nell'archeologia di capire cosa sia stato deciso e perché, revisionano un design scritto, contestano ciò che va contestato e approvano prima che il lavoro inizi. Il loro giudizio viene applicato dove ha la massima leva.

La lacuna che gli strumenti multi-agente non colmano: il decision record

È qui che il confronto con i framework multi-agente si fa pungente, ed è qui che la scelta dello strumento ha conseguenze di lungo periodo che in una demo breve non si vedono.

I file di spec di Kiro documentano cosa deve fare il sistema e come è stato progettato per farlo. È già più di quanto trattenga la maggior parte dei workflow AI-assisted. Ma design.md le dirà che è stato scelto PostgreSQL e descriverà lo schema. Non le dirà che DynamoDB è stato valutato e scartato perché i suoi pattern di accesso richiedono filtri multi-colonna che il modello di query di DynamoDB non sa gestire senza una costosa denormalizzazione e percorsi di scrittura duplicati. Non le dirà che l'event sourcing è stato preso in considerazione e accantonato perché il team non ha esperienza operativa con event store e il budget di latenza non avrebbe retto la consistenza eventuale.

Quel contesto — cosa è stato valutato, perché è stato scartato, quali trade-off sono stati accettati — è ciò che cattura un Architecture Decision Record (ADR). Il concetto è stato introdotto da Michael Nygard nel 2011 ed è da allora diventato un caposaldo dell'architettura software sostenibile. La organizzazione ADR su GitHub mantiene una buona panoramica del formato e delle sue varianti, se vuole approfondire.

Gli ADR sono una pratica consolidata. Il GOV.UK Digital Service ne ha pubblicati 39 durante la migrazione AWS, coprendo decisioni che vanno dalla scelta della piattaforma di hosting al consolidamento del database, fino all'architettura DNS. Ognuno è un breve file Markdown: Status, Context, Decision, Consequences. La raccolta è il decision log dell'intera migrazione, versionato insieme all'infrastruttura che descrive.

Il motivo per cui la maggior parte dei team non mantiene gli ADR è la frizione. Produrli compete con la pressione di consegnare, la disciplina si sgretola dopo uno o due sprint e le decisioni effettivamente catturate sono quelle prese in fase di design upfront, non quelle altrettanto importanti che emergono a metà implementazione, quando un vincolo si rivela diverso dalle aspettative.

Kiro elimina questa frizione attraverso due meccanismi:

Generazione automatica di ADR tramite Steering

Il sistema Steering di Kiro permette di committare in .kiro/steering/ istruzioni persistenti che si applicano a ogni interazione dell'agente in tutto il team. Un singolo file di steering rende automatica la generazione degli ADR:

When generating or updating design.md for any spec, also create or update
a decisions/ subdirectory within the spec folder. For each significant
architectural choice — technology selection, data model, integration
pattern, security mechanism — create an ADR file following the naming
convention ADR-NNN-short-title.md.

Each ADR must include: Status, Context, Decision, and Consequences
(positive, negative, risks). Record options considered but not chosen
and the reasons they were rejected.

Una volta committata, l'istruzione si applica a tutto il team. Gli ADR vengono prodotti senza che nessuno debba ricordarsi di produrli.

# ADR-001: Use PostgreSQL over DynamoDB for review storage

## Status
Accepted

## Context
The review system requires complex multi-column filtering (rating, date, product).
DynamoDB's query model requires denormalized duplicates per access pattern,
increasing storage and write complexity by an estimated 3-4x.
The team has existing PostgreSQL operational experience and monitoring tooling.
DynamoDB was the initial default assumption given existing AWS infrastructure.

## Decision
Use PostgreSQL with a normalized schema. Index the columns used in the four
most common filter combinations. Accept the horizontal scaling trade-off.

## Consequences
- Positive: Query logic is significantly simpler; existing tooling applies
- Negative: Horizontal scaling requires more coordination than DynamoDB
- Risk: Revisit if read throughput exceeds 20k RPS at peak; document threshold

Cattura tramite Hook delle decisioni a metà implementazione

Le decisioni prese in fase di design sono quelle facili da catturare. Quelle pericolose avvengono durante l'implementazione: una libreria che si rivela avere un edge case bloccante, una misurazione di performance che cambia il pattern di accesso ai dati. Si risolvono in una conversazione o con una rapida modifica al codice e non vengono mai registrate da nessuna parte.

Un Kiro Hook sulle modifiche a design.md se ne occupa. Quando il design document viene modificato (da un engineer o da Kiro durante l'esecuzione di un task), l'Hook attiva un agente che valuta se la modifica rappresenti una nuova decisione architetturale e, in caso affermativo, redige una bozza di ADR perché il team la revisioni. Spec e decision record restano sincronizzati per tutta l'implementazione, non solo nel momento del design iniziale.

ADR nelle pipeline multi-agente: un approccio complementare

Gli ADR automatizzati non sono prerogativa di Kiro: può aggiungere un agente ADR Writer a una pipeline CrewAI o LangGraph esistente. Ma se l'ADR risultante arrivi al team in forma revisionabile dipende da come ha collegato l'output della pipeline al suo workflow di sviluppo. Kiro integra l'ADR in un workflow in cui il team lo vede, lo revisiona e lo mette in discussione prima che venga scritto codice.

Per i team che già fanno girare pipeline multi-agente, i due approcci coesistono naturalmente: Kiro gestisce design, spec e cattura delle decisioni; la pipeline esistente gestisce task di esecuzione delimitati entro i vincoli stabiliti dalla spec. La spec diventa il contratto tra la fase di design (in cui il team ha supervisione) e la fase di esecuzione (in cui gli agenti operano con maggiore autonomia).

Dove il modello mostra il fianco

Sarei disonesto se non nominassi i punti deboli, perché non sono evidenti finché non si è dentro al lavoro da qualche sprint.

La qualità della spec è limitata da quella del prompt

I documenti di requisiti e design di Kiro sono buoni quanto la descrizione iniziale che gli fornisce. Un prompt vago produce una spec vaga, ma ora è una spec vaga con l'apparenza del rigore, perché formattata in notazione EARS con tanto di criteri di accettazione. È peggio che non avere alcuna spec, perché il team la revisiona, vede la struttura e dà per scontato che il contenuto sia solido.

La mitigazione è culturale, non tecnica: tratti la review della spec come una vera design review, non come un timbro. Se i requisiti sembrano generici o il design non affronta i suoi vincoli specifici, contesti prima di approvare. Tutto il senso del gate di approvazione è che sia un gate, non una formalità.

La notazione EARS può produrre falsa precisione

EARS è bravo a eliminare l'ambiguità nei singoli requisiti. Quello che non fa è garantire la completezza: si possono avere venti requisiti perfettamente non ambigui che, presi insieme, mancano il vero problema difficile. Ho visto Kiro generare requisiti EARS tecnicamente corretti ma operativamente inutili, perché descrivono nel dettaglio l'happy path e ignorano i failure mode che determineranno davvero se il sistema funzioni in produzione.

La soluzione: quando revisiona requirements.md, non si limiti a verificare se ogni requisito sia ben formato. Verifichi se l'insieme dei requisiti copra i casi di fallimento, gli edge case e gli aspetti operativi (monitoring, alerting, rollback) rilevanti per il suo sistema. Se non li copre, li aggiunga prima di approvare.

Gli ADR auto-generati possono essere superficiali

Un file di steering che dice "genera ADR per le scelte architetturali significative" produrrà ADR. Se quegli ADR contengano ragionamenti utili dipende da quanto contesto Kiro ha sui suoi vincoli. Un ADR che dice "abbiamo scelto PostgreSQL perché supporta query relazionali" è tecnicamente corretto e completamente inutile: qualsiasi senior engineer lo sa già. Il valore sta nelle alternative scartate e nelle ragioni specifiche per cui sono state scartate.

Calibri il file di steering perché sia esplicito su cosa vuole catturare. Invece di "registra le scelte significative", provi con "per ogni selezione di tecnologia, documenta almeno due alternative valutate, la ragione tecnica o operativa specifica per cui ciascuna è stata scartata e le condizioni in cui la decisione dovrebbe essere rivista". Più specifica è l'istruzione, più utile l'output.

Lo spec drift è silenzioso per default

Kiro non rileva automaticamente quando l'implementazione diverge dal design. La spec è uno snapshot dell'intento al momento del design. Se un engineer (o un agente in modalità autopilot) apporta una modifica che contraddice il design — un motore di database diverso, un endpoint API aggiuntivo, un modello dati cambiato — i file di spec non si aggiornano da soli.

È risolvibile con gli Hook, come descritto sopra, ma non è il comportamento di default. Se sta adottando Kiro, impostare gli Hook di rilevamento del drift dovrebbe far parte della configurazione iniziale, non qualcosa da aggiungere dopo aver scoperto il problema.

La governance si ferma al confine del design

A dicembre 2025, un agente Kiro ha cancellato un ambiente AWS di produzione live, causando un'interruzione di 13 ore di AWS Cost Explorer in una region cinese (The Register, Feb 2026). Amazon ha attribuito l'incidente al fatto che il ruolo dell'engineer aveva permessi più ampi del previsto. Resoconti indipendenti hanno descritto Kiro come decisore autonomo nel cancellare e ricreare l'ambiente invece di applicare un fix mirato — una distinzione contestata da Amazon.

Entrambe le ricostruzioni portano alla stessa lezione: un team può avere spec revisionate, design approvati e ADR documentati, e subire comunque un fallimento catastrofico perché nessuno ha revisionato cosa sia successo tra il design approvato e il deployment in produzione.

Il modello di governance di Kiro copre la fase di design in modo approfondito. Quello che non copre è il confine di esecuzione: il momento in cui un agente agisce su infrastruttura reale con permessi reali. La modalità autopilot è utile, ma richiede la stessa disciplina di qualsiasi pipeline CI/CD: review del deployment, permessi limitati e una persona nel loop prima che le modifiche raggiungano la produzione. Il workflow di spec rende facile dare per scontato che la governance sia gestita. Non lo è, a meno che il team non estenda quella disciplina oltre il punto in cui termina il workflow di Kiro.

Cosa cambia per il team

Il design avviene in pubblico, non in sessioni private dell'agente

In una pipeline multi-agente la decisione di design viene presa dentro la pipeline. Quando un membro del team la vede, è già implementata oppure committata in un file di output che potrebbe finire o meno in una pull request. Con Kiro, il design document è il primo output committato nel repository, prima che inizi l'implementazione. Il team vede e revisiona il design mentre viene creato, non dopo.

Questo cambia direttamente la code review. Revisionare codice senza una spec significa inferire l'intento dall'implementazione, un'attività lenta e tendente a privilegiare commenti sullo stile rispetto alla sostanza. Revisionare codice rispetto a una spec significa verificare se l'implementazione soddisfi i requisiti dichiarati e se le scelte siano allineate al ragionamento documentato. Le review diventano più rapide e più sostanziali.

Il lavoro parallelo fa emergere prima i conflitti

Le pipeline multi-agente operano tipicamente su un singolo contesto di task. In un team in cui più engineer costruiscono in parallelo, ciascuno con le proprie sessioni di agenti o le proprie pipeline, non c'è un meccanismo per rilevare che due feature stanno facendo assunzioni architetturali in conflitto. Le spec di Kiro, committate prima dell'implementazione, forniscono il punto di riferimento condiviso che rende visibili quei conflitti al momento giusto, prima che venga scritto il codice in conflitto.

La conoscenza sopravvive al cambio di personale

Quando un engineer lascia un team che ha fatto vibe coding o eseguito pipeline di agenti non strutturate, il suo contesto se ne va con lui. L'ho visto succedere abbastanza volte da sapere come va a finire: tre mesi dopo, qualcuno fa reverse engineering di un servizio che nessuno comprende del tutto. Gli ADR e le spec nel modello Kiro sono attaccati al repository, non alle persone. Il ragionamento dietro ogni decisione significativa è lì per chi viene dopo, sia un engineer che entra fra tre mesi sia un team che eredita il sistema fra tre anni.

La domanda scomoda

Ecco la domanda scomoda per i team che fanno girare pipeline multi-agente: la sua pipeline produce codice. Sa perché è stato progettato in quel modo? Lo sa il suo team? Lo sapranno fra sei mesi? Se la risposta a una qualsiasi di queste domande è incerta, sta accumulando knowledge debt che si comporrà nel tempo.

Quel debito ha una traiettoria prevedibile: la velocity degrada, l'onboarding rallenta e alla fine qualcuno propone il rewrite — perché modificare un sistema che nessuno comprende sembra più rischioso che ricominciare da capo.

Kiro non sostituisce il suo tooling multi-agente per l'esecuzione di task delimitati. Fornisce lo strato strutturale (spec, ADR, Hook, artefatti visibili al team e committati prima dell'implementazione) che trasforma l'output AI-generated in software che il suo team può davvero possedere.

La questione dell'overhead

Il workflow di spec aggiunge tempo di pianificazione prima dell'implementazione. Per uno script di breve durata o un task di automazione delimitato, quell'overhead non è giustificato. Alcuni team trovano che l'approccio strutturato di Kiro iper-specifichi problemi semplici e che i gate di approvazione aggiungano una frizione che sembra superflua per modifiche a basso rischio.

Il team di Martin Fowler ha esaminato gli strumenti di spec-driven development (Kiro tra essi) e ha concluso che l'approccio opinionated a workflow unico è probabilmente "non adatto alla maggioranza dei problemi reali di coding". Hanno ragione. Il grosso del lavoro quotidiano di engineering è modifica di sistemi esistenti, bug fix e cambiamenti incrementali: lavoro per cui un ciclo completo di spec crea più frizione che valore. La tesi a favore dello spec-driven development poggia sul sottoinsieme di lavoro in cui si stanno prendendo decisioni architetturali e in cui il costo di sbagliarle è alto. Quel sottoinsieme è più piccolo di quanto questo articolo possa suggerire, ma è dove si verificano gli errori più pesanti.

Kiro offre sia la modalità spec-driven sia la modalità vibe coding nello stesso IDE, e le due coesistono bene: vibe coding per esplorazione e lavoro usa-e-getta, spec per qualsiasi cosa che dovrà essere mantenuta. La domanda più difficile è se i team applichino quel giudizio in modo accurato. Nella mia esperienza, la tentazione è usare il percorso veloce per tutto e raccontarsi che la feature sia più semplice di quanto non sia. Gran parte del knowledge debt nelle codebase è il residuo accumulato di quella decisione, presa molte volte.

Un'euristica pratica: usi la modalità spec quando è vera una qualsiasi di queste condizioni — la feature tocca un modello dati, introduce una nuova integrazione esterna, attraversa un confine di sicurezza o sarà lavorata da più di un engineer. Usi vibe coding per tutto il resto. Il costo di una decisione architetturale sbagliata si compone su ogni sprint successivo; il costo di iper-specificare uno script usa-e-getta è un'ora del suo tempo.

Per i team che introducono la modalità spec per la prima volta, un approccio per fasi riduce le resistenze. Inizi con una nuova feature che soddisfi almeno due delle condizioni euristiche di cui sopra: abbastanza complessità da rendere la spec utile, non così tanta da rendere travolgente la prima esperienza. Conduca la review della spec come una vera riunione di design: assegni a qualcuno il compito di mettere in discussione il documento dei requisiti prima dell'approvazione, non solo di leggerlo. Dopo che la prima feature è stata consegnata, faccia una breve retrospettiva sul fatto che la spec abbia intercettato qualcosa che altrimenti sarebbe emerso più tardi. Quel singolo dato — "abbiamo intercettato il problema dello schema in design review invece che in produzione" — è più persuasivo per un team di engineering scettico di qualsiasi argomentazione di processo.

Conclusione

L'attuale generazione di tooling AI per lo sviluppo ha in larga parte risolto il problema di produrre codice. Gli strumenti sanno trasformare requisiti in linguaggio naturale in implementazioni funzionanti a una velocità che tre anni fa sarebbe sembrata inverosimile.

Quello che la maggior parte di essi non ha risolto è il problema di team: come fa un gruppo di engineer a costruire software insieme, con assistenza AI, in modo da produrre comprensione condivisa anziché output condiviso che nessuno possiede del tutto? Come si risponde a "perché è stato progettato così?" quando il design è avvenuto dentro una sessione dell'agente che nessun altro ha visto?

La risposta di Kiro è strutturale: produrre gli artefatti che rendano rispondibili quelle domande, prima che il codice esista, come parte standard del workflow. I file di spec danno al team visibilità sull'intento di design. Gli ADR, generati tramite un file di steering che lei configura e tenuti aggiornati attraverso gli Hook, danno al team visibilità sul ragionamento dietro le decisioni. Entrambi vivono nel repository e viaggiano attraverso le pull request come qualsiasi altro artefatto di codice.

Per i team che già usano framework multi-agente per task di esecuzione, Kiro non è un rimpiazzo. È lo strato che quegli strumenti non forniscono: un workflow revisionabile e visibile al team, che cattura le decisioni e trasforma il codice AI-generated in software che un team di engineering può mantenere.

Il problema dell'esecuzione è in larga parte risolto. Il problema di team no. È il problema su cui vale la pena lavorare — ed è quello su cui il resto dell'industria del tooling non ha ancora scommesso.