GitHub Spec Kit vs Kiro vs flussi di lavoro SDD di Claude Code

Gli sviluppatori che confrontano le configurazioni di Sviluppo Guidato dalle Specifiche (Spec-Driven Development) nel 2026 di solito non si chiedono quale modello sia il più intelligente. Si chiedono quale flusso di lavoro manterrà allineato un agente AI senza seppellirli in burocrazia.

GitHub Spec Kit, AWS Kiro e i flussi di lavoro personalizzati di Claude Code implementano tutti la stessa idea generale – requisiti, design, task, implementazione, validazione – ma scambiano portabilità, profondità di integrazione e la quantità di processo che impongono.

Se hai bisogno prima dei concetti, leggi Cos’è lo Sviluppo Guidato dalle Specifiche? e la guida neutrale rispetto agli strumenti Flusso di Lavoro dello Sviluppo Guidato dalle Specifiche nel cluster di documentazione Architettura delle App. Questo confronto si trova nell’hub Strumenti per Sviluppatori AI insieme a recensioni degli assistenti e guide ai flussi di lavoro.

SDD Sta Diventando una Categoria di Strumenti

Lo Sviluppo Guidato dalle Specifiche ha smesso di essere un esercizio sulla carta in qualche momento a fine 2025. Ogni grande vendor di coding AI ora fornisce qualche versione di specifica-pianifica-implementazione, e un elenco crescente di strumenti autonomi compete su quanta struttura aggiungono attorno a quel ciclo.

Il confronto che conta non è “quale strumento vince”. È profondità del processo rispetto alla portabilità. Kiro è integrato. Spec Kit è portabile. I flussi di lavoro di Claude Code sono modificabili. Specifiche scadenti rendono ogni agente peggiore indipendentemente da quale wrapper si scelga. Specifiche buone viaggiano tra gli strumenti.

Come Confrontare le Configurazioni SDD

Prima di scegliere uno strumento, definisci cosa stai ottimizzando. La stessa funzionalità può sembrare agevole in un setup e burocratica in un altro a seconda della dimensione del team, dell’età del codice e di quanta revisione serve.

Portabilità – Le specifiche possono vivere come markdown semplice nel tuo repository e funzionare con l’agente che preferisci il prossimo trimestre? O sono legate a un unico IDE, a un’unica cloud o a un formato proprietario?

Attrito di setup – Quanto tempo ci vuole da “voglio provare SDD” a un ciclo funzionante di specifica-pianifica-task? Scaffolding CLI, installazione IDE o creazione dei propri comandi slash hanno tutti diversa energia di attivazione.

Qualità delle specifiche – Lo strumento ti aiuta a scrivere requisiti e criteri di accettazione precisi, o genera principalmente documenti lunghi? La struttura è utile. Il volume non lo è.

Esecuzione dei task – Come lo strumento spezza il lavoro in slice revisionabili? I task possono essere eseguiti in parallelo? Resiste a esplosioni di task a cinquant’elementi?

Checkpoint di revisione – Ci sono gate umani naturali tra specifica, pianifica, task e implementazione? SDD senza revisione è solo vibe coding più lento.

Ancoraggio al repository – Il flusso di lavoro legge le convenzioni del progetto, record delle decisioni, ADR, AGENTS.md e il codice esistente prima della pianificazione? Gli agenti senza ancoraggio reinventano l’architettura perché non vedono mai l’intento revisionato dietro le scelte precedenti.

Collaborazione di team – Più persone possono revisionare gli stessi artefatti di specifica nelle pull request? Si possono mescolare agenti senza riscrivere il processo?

Lock-in – Cosa perdi se cambi editor, modelli o vendor cloud tra sei mesi?

GitHub Spec Kit

GitHub Spec Kit è un toolkit CLI open source che crea uno scaffolding per un ciclo guidato dalle specifiche nel tuo repository e passa l’esecuzione a qualsiasi agente di coding tu stia già usando. La CLI specify deposita template, comandi slash e una struttura di cartelle convenzionale. I comandi tipici seguono una sequenza costituzione-specifica-clarifica-pianifica-task-implementa, con un esplicito passo di chiarimento per risolvere l’ambiguità prima che inizi il lavoro architetturale.

Il vantaggio distintivo di Spec Kit è l’indipendenza dall’agente. La documentazione ufficiale lo posiziona come tooling che funziona con Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex e decine di altri agenti. Scrivi le specifiche una volta in markdown, le commit come codice, e cambi l’esecutore senza riscrivere il processo. Questo rende Spec Kit la raccomandazione predefinita per i team che vogliono SDD senza puntare su un singolo vendor.

I compromessi sono reali. Spec Kit può produrre un grande albero di artefatti – costituzione, specifica, piano, task, contratti – che si ripaga su funzionalità multi-sessione ma sembra pesante per una piccola modifica CLI. I thread su Hacker News confrontano regolarmente quel sovraccarico con la cerimonia waterfall. Spec Kit è anche più debole se vuoi un IDE completamente integrato dove specifiche, task e implementazione vivono in una superficie guidata unica. Aggiunge processo sopra il tuo editor esistente invece di sostituirlo.

Spec Kit si adatta a team che hanno già un assistente di coding AI preferito e vogliono uno scaffolding SDD standardizzato sopra. È particolarmente forte per funzionalità greenfield, ambienti multi-agente e chiunque rifiuti il lock-in dell’editor.

AWS Kiro

Kiro è l’IDE guidato dalle specifiche di AWS, costruito su un fork di VS Code / Code OSS. Dove Spec Kit porta SDD al tuo stack esistente, Kiro assume che SDD meriti un ambiente costruito appositamente. Un prompt genera artefatti strutturati – tipicamente requirements.md in notazione di stile EARS, design.md e un tasks.md sequenziato per dipendenze – prima che gli agenti scrivano codice di produzione.

L’esperienza guidata è il principale punto di vendita di Kiro. Requisiti, design e task sono oggetti UI di prima classe accanto al tuo codice, non file che gestisci attraverso una CLI separata. Kiro fornisce anche Agent Hooks, automazioni guidate da eventi che possono aggiornare test, documenti o artefatti correlati quando l’implementazione cambia. Quel ciclo bidirezionale è qualcosa che Spec Kit non fornisce di default – le specifiche di Spec Kit restano statiche finché un umano non le aggiorna.

I costi sono la profondità di integrazione scambiata con la portabilità. Kiro gira dentro il suo editor, usa modelli supportati da AWS Bedrock e fattura attraverso un modello di pricing basato su crediti con piani a livelli. I team enterprise già su infrastruttura AWS spesso lo trovano accettabile. Gli sviluppatori singoli e i team multi-editor forse no. Kiro ha anche spigoli vivi tipici di un IDE più recente – compatibilità delle estensioni, sorprese nel flusso di lavoro e la solita domanda “ho davvero bisogno di un altro editor?”.

Kiro si adatta a sviluppatori che vogliono l’esperienza SDD più guidata e sono a loro agio adottando un IDE nativo per le specifiche. È un’opzione forte per team enterprise, ambienti pesanti su AWS e chiunque migri da Amazon Q Developer volendo disciplina sulle specifiche senza assemblare la toolchain manualmente. Se oggi vivi in VS Code standard e ami il tuo setup attuale, Kiro richiede un cambio più grande di quanto faccia Spec Kit.

Comandi e Skills Personalizzati di Claude Code

Claude Code non fornisce un unico prodotto SDD ufficiale come fanno Spec Kit o Kiro. Se sei nuovo allo strumento stesso, inizia con la guida all’installazione e configurazione di Claude Code} per setup, permessi e backend locali. Il pattern SDD stesso vive nei comandi personalizzati, nelle skills e nei template markdown a livello di repository mantenuti dagli sviluppatori. Anthropic ha assorbito i vecchi file .claude/commands/*.md nel meccanismo Skills, quindi il pattern duraturo è un SKILL.md (o equivalente) che definisce la tua checklist specifica-pianifica-implementa, caricato su richiesta.

Questo approccio è il più leggero e il più modificabile. Puoi portare un layout a tre file di stile Kiro, riflettere le fasi di Spec Kit con comandi slash, o inventare un flusso di lavoro minimo che si adatti a un repository. Claude Code legge CLAUDE.md per il contesto del progetto sempre attivo e estrae skills quando il task corrisponde. Quel disclosure progressivo mantiene le sessioni focalizzate senza caricare un’intera costituzione a ogni prompt.

Il lato negativo è la disciplina. Niente ti forza attraverso i gate di chiarimento o revisione a meno che tu non li costruisca tu stesso. I thread su Reddit e Hacker News su “sviluppo guidato dalle specifiche dentro Claude Code” sono pieni di sviluppatori che hanno copiato la skill di qualcun altro, l’hanno eseguita una volta e sono tornati al prompting non strutturato quando la skill sembrava lenta. SDD con Claude Code funziona quando tratti le skills come codice – versionate, revisionate e mantenute – non come un download di prompt one-time.

Per un’implementazione seria, leggi Claude Skills e SKILL.md per Sviluppatori} e codifica le tue fasi come skills con checkpoint di revisione espliciti. SDD con Claude Code è la scelta giusta quando vivi già in Claude Code, vuoi massima flessibilità e manterrai tu stesso il flusso di lavoro. Per il passo di gate di revisione in particolare, i subagent di Claude Code possono eseguire un passaggio di revisione indipendente, con contesto isolato, sul codice generato prima che tu mergi un task – un sostituto leggero per il ruolo di verifica che gli Agent Hooks di Kiro forniscono nativamente.

Superpowers: Una Versione Imballata dello Stack di Skill Fai-da-Te

Se assemblare manualmente quello stack di skill sembra esattamente il problema di disciplina di cui avverte la tabella sopra, Superpowers} merita un’occhiata. È un pacchetto di skills open source – brainstorming, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review e un pugno di skills di supporto – distribuito come plugin installabile invece di qualcosa che scrivi da zero. Mira direttamente alla limitazione “la qualità dipende interamente dalla disciplina dell’autore”: le skills si attivano automaticamente e sono intese come flusso di lavoro obbligatorio, non come suggerimenti opzionali che l’agente può saltare.

Il flusso di lavoro che impone mappa strettamente sul ciclo a cinque fasi coperto in Flusso di Lavoro dello Sviluppo Guidato dalle Specifiche dai Requisiti al Codice}: il brainstorming rifinisce un’idea vaga in un documento di design revisionato, writing-plans lo spezza in piccoli task verificabili, subagent-driven-development dispaccia un nuovo subagent per task con una revisione a due stadi, e test-driven-development impone un rigoroso red-green-refactor prima che qualcosa sia considerato fatto. Quest’ultima parte è più rigorosa di quanto la maggior parte delle skills SDD di Claude Code si prenda la briga di essere – Superpowers elimina esplicitamente il codice scritto prima che esistesse un test fallente per esso.

A differenza di una skill a livello di repository che scrivi tu stesso, Superpowers non è solo per Claude Code. Fornisce manifesti di plugin per Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid e diversi altri agenti, quindi la stessa metodologia ti segue attraverso gli harness invece di vivere in una singola cartella .claude/skills/. Questo lo rende un punto di mezzo tra assemblare la tua skill di Claude Code e adottare uno strumento più pesante, specifico per IDE come Kiro: ottieni un ciclo opinione e imposto senza rinunciare al tuo editor o impegnarti su un formato di specifica di un singolo vendor.

Superpowers si adatta a sviluppatori che amano l’approccio skills di Claude Code in principio ma continuano a scivolare verso il prompting non strutturato perché nulla impone i gate di revisione. È un adattamento più debole se hai già una skill SDD specifica del progetto calibrata sul tuo stack – in quel caso stai scambiando una piccola quantità di personalizzazione per una quantità maggiore di cerimonia imposta.

BMAD, OpenSpec e Altri Flussi di Lavoro

Non tutti i team vogliono l’albero di artefatti di Spec Kit o l’IDE di Kiro. Due alternative appaiono costantemente nei confronti del 2026.

OpenSpec (Fission AI) adotta un approccio centrato sui cambiamenti con meno file generati rispetto a Spec Kit. I benchmark della community riportano un uso dei token materialmente inferiore per task comparabili, al costo di meno struttura preventiva. OpenSpec tende a vincere quando stai modificando un codice esistente e vuoi specifiche revisionabili senza una fase di pianificazione di 800 righe. Compete con Spec Kit sulla portabilità più che con Kiro sull’integrazione IDE.

BMAD-METHOD (community) spinge nella direzione opposta – flussi di lavoro multi-agente, basati sui ruoli, che simulano le persone del product owner, architetto, sviluppatore e revisore. BMAD può essere potente su grandi sforzi greenfield dove la separazione esplicita dei ruoli aiuta. È anche pesante. I team riportano frequentemente che la cerimonia si ripaga solo quando il dolore di coordinazione è già acuto.

Tessl tratta la specifica come la letterale sorgente del codice generato, marcando l’output come derivato e scoraggiando le modifiche a mano. Questa è la posizione più forte “specifica come sorgente” tra gli strumenti mainstream, ma Tessl rimane in beta e porta il lock-in di prodotto più alto del gruppo.

Spec Kitty e altri scaffolding della community stanno tra OpenSpec e Spec Kit in termini di peso. Vale la pena tenerli d’occhio se vuoi template senza adottare l’intera toolchain di GitHub.

Il pattern attraverso tutti loro è lo stesso. Più processo aiuta quando l’ambiguità è costosa. Più processo danneggia quando la velocità del feedback conta più dell’allineamento. Abbina il peso dello strumento alla dimensione del task, non all’hype.

Quale Setup SDD Dovresti Usare?

Non c’è un vincitore universale. Il setup giusto dipende da chi sei, cosa stai costruendo e quanta struttura manterrai effettivamente.

Sviluppatore singolo, codice esistente, funzionalità piccole. Inizia con skills di Claude Code o OpenSpec. Scrivi un breve blocco di requisiti, un elenco di task minimo e un checkpoint di revisione. Non installare un albero completo di Spec Kit per un cambiamento di cinquanta righe.

Vuoi l’approccio skills di Claude Code ma continui a saltare i tuoi gate di revisione. Installa Superpowers invece di scrivere una skill custom da zero. Rinunci ad alcune regolazioni specifiche del progetto in cambio di un ciclo imposto brainstorm-plan-implement-review che non dipende dalla tua disciplina di quel giorno.

Sviluppatore singolo, funzionalità greenfield, più sessioni. Spec Kit o una skill SDD di Claude Code ben mantenuta. Hai bisogno di artefatti duraturi più che di mano-piegata dell’IDE.

Piccolo team, editor misti. Spec Kit. Specifiche markdown semplici in Git, revisionate nelle pull request, eseguite da qualsiasi agente che ogni sviluppatore preferisce.

Team enterprise, AWS-native, pressione di conformità. Kiro. Artefatti guidati, tracciabilità dei requisiti e hook che mantengono documenti e test più vicini all’implementazione.

Ambiente regolamentato. Kiro o Spec Kit più la tua checklist di validazione – non solo skills di Claude Code a meno che tu non codifichi esplicitamente i gate di conformità. Il tooling non sostituisce le tracce di audit. Le rende solo più facili da produrre.

Codice esistente, cambiamento brownfield. OpenSpec o un flusso di lavoro leggero di Claude Code. La cerimonia completa di Spec Kit su ogni bugfix sembrerà waterfall. Riserva la struttura più pesante per funzionalità trasversali.

Prodotto greenfield, molti agenti. Spec Kit. La portabilità conta più della rifinitura dell’IDE quando Copilot, Claude Code e Cursor possono tutti toccare lo stesso repository.

I team che sperimentano con l’orchestrazione multi-agente dovrebbero anche guardare Oh My OpenCode Agents} per pattern sulla divisione dei ruoli tra agenti – complementare agli artefatti SDD, non un sostituto per essi.

Tabella Decisionale Pratica

Cosa Determina Realmente il Successo

La scelta dello strumento conta meno della qualità degli artefatti. Un file di requisiti di Kiro con criteri di accettazione vaghi produrrà lo stesso drift di un prompt disordinato di Claude Code. Un piano di Spec Kit che elenca cinquanta task ridondanti sembrerà waterfall indipendentemente da quale agente lo implementi.

Le pratiche che viaggiano attraverso ogni setup sono noiose ed efficaci. Mantieni le specifiche abbastanza piccole da essere revisionate in una sola seduta. Scrivi i non-obiettivi esplicitamente. Spezza i task in diff che un umano può leggere. Convalida contro i criteri di accettazione prima del merge. Aggiorna la specifica quando l’implementazione scopre un percorso migliore.

Se stai ancora scegliendo tra SDD e prompting non strutturato per una data funzionalità, leggi Sviluppo Guidato dalle Specifiche vs Vibe Coding} . Il confronto degli strumenti in questo articolo conta solo una volta che hai deciso che la funzionalità merita una specifica.

Specifiche scadenti rendono ogni agente peggiore. Specifiche buone viaggiano tra gli strumenti.

Conclusione

GitHub Spec Kit, Kiro e i flussi di lavoro di Claude Code sono tre risposte alla stessa domanda – come mantieni gli agenti AI allineati tra sessioni – con scommesse diverse sulla portabilità rispetto all’integrazione. Spec Kit ottimizza per markdown agnostico rispetto all’agente nel tuo repository. Kiro ottimizza per un IDE nativo per le specifiche guidato con agenti supportati da AWS. Le skills di Claude Code ottimizzano per flussi di lavoro modificabili e leggeri che hanno successo solo quando li mantieni tu.

Scegli il setup più superficiale che rimuova comunque l’ambiguità per la funzionalità in questione. Aggiungi struttura quando appare il dolore di coordinazione, non quando un post di blog te lo dice. Gli sviluppatori che ottengono valore da SDD nel 2026 non sono quelli con la toolchain più elaborata. Sono quelli che scrivono specifiche degne di essere implementate – e poi lasciano che qualsiasi strumento abbiano scelto esegua contro di esse.

Link Utili

• Documentazione di GitHub Spec Kit – riferimento ufficiale al flusso di lavoro di Spec Kit
• Superpowers Quickstart: Installazione, Flusso di Lavoro e Prova} – pacchetto di skills open source che impone una metodologia brainstorm-to-TDD attraverso Claude Code, Cursor, Codex e altri agenti
• Martin Fowler sugli strumenti SDD – analisi di Kiro, Spec Kit e Tessl