GitHub Spec Kit contro Kiro e i workflow SDD di Claude Code

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

GitHub Spec Kit, AWS Kiro e i flussi di lavoro personalizzati di Claude Code implementano tutti la stessa idea di fondo – requisiti, progettazione, task, implementazione, validazione – ma bilanciano portabilità, profondità di integrazione e quanta parte del processo impongono.

Se hai bisogno prima dei concetti, leggi Cos’è lo Sviluppo Guidato da Specifiche? e la guida neutra agli strumenti del Flusso di Lavoro di Sviluppo Guidato da Specifiche nel cluster di documentazione Architettura delle App. Questo confronto si trova nell’hub Strumenti per Sviluppatori AI accanto alle recensioni degli assistenti e alle guide sui flussi di lavoro.

SDD Sta Diventando una Categoria di Strumenti

Lo Sviluppo Guidato da Specifiche ha smesso di essere un esercizio cartaceo a un certo punto a fine 2025. Ogni grande fornitore di coding AI ora rilascia una qualche versione di specifica-pianificazione-implementazione, e un elenco crescente di strumenti indipendenti compete su quanta struttura aggiungono attorno a quel ciclo.

Il confronto che conta non è “quale strumento vince”. È profondità di processo versus portabilità. Kiro è integrato. Spec Kit è portabile. I flussi di lavoro di Claude Code sono modificabili. Specifiche scritte male rendono ogni agente peggiore indipendentemente dal wrapper scelto. Specifiche ben scritte 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 una configurazione e burocratica in un’altra, a seconda della dimensione del team, dell’età della codebase e di quanta revisione ti serve.

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

Attrito di configurazione – Quanto tempo passa da “voglio provare SDD” a un ciclo di lavoro specifico-pianifica-task funzionante? Scaffolding CLI, installazione IDE o creazione dei propri slash command hanno tutti energie di attivazione diverse.

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

Esecuzione dei task – Come lo strumento divide il lavoro in fette revisionabili? I task possono girare in parallelo? Resiste alle esplosioni di cinquant’elementi nei task?

Punti di controllo di revisione – Ci sono gate umani naturali tra specifica, pianificazione, task e implementazione? SDD senza revisione è solo coding “vibe” più lento.

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

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

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

GitHub Spec Kit

GitHub Spec Kit è un toolkit CLI open source che schelettrica un ciclo di sviluppo guidato da specifiche nel tuo repository e affida l’esecuzione a qualunque agente di coding tu usi già. La CLI specify deposita template, slash command e una struttura di cartelle convenzionale. I comandi tipici seguono una sequenza costituzione-specifica-chiarifica-pianifica-task-implementa, con un passo esplicito di chiarificazione per risolvere l’ambiguità prima che inizi il lavoro di architettura.

Il vantaggio distintivo di Spec Kit è l’indipendenza dagli agenti. I documenti ufficiali lo posizionano come tooling che funziona con Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex e dozzine di altri agenti. Scrivi le specifiche una volta in markdown, le commit ti come codice e cambi l’esecutore senza riscrivere il processo. Questo rende Spec Kit il consiglio predefinito per i team che vogliono SDD senza scommettere su un singolo fornitore.

I compromessi sono reali. Spec Kit può produrre un grande albero di artefatti – costituzione, specifica, piano, task, contratti – che ha senso su funzionalità multi-sessione ma si sente pesante per una piccola modifica CLI. I thread su Hacker News confrontano regolarmente quel sovraccarico con le cerimonie waterfall. Spec Kit è anche più debole se vuoi un IDE completamente integrato dove specifiche, task e implementazione vivono in una superficie guidata unica. Invecchia il 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 scaffold SDD standardizzato sopra. È particolarmente forte per funzionalità greenfield, aziende multi-agente e chi rifiuta il lock-in dell’editor.

AWS Kiro

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

L’esperienza guidata è il punto di vendita principale di Kiro. Requisiti, progettazione e task sono oggetti UI di prima classe accanto al tuo codice, non file che gestisci tramite una CLI separata. Kiro rilascia anche Agent Hooks, automazioni guidate dagli 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 integration scambiata con la portabilità. Kiro gira dentro il suo editor, usa modelli basati su AWS Bedrock e fattura tramite un modello di prezzi a crediti con piani a livelli. I team enterprise già su infrastruttura AWS spesso trovano ciò accettabile. Sviluppatori singoli e team multi-editor forse no. Kiro ha anche i soliti angoli grezzi tipici di un IDE più nuovo – compatibilità delle estensioni, sorprese nel flusso di lavoro e la solita domanda “mi serve davvero 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 specifiche. È un’opzione forte per team enterprise, ambienti pesati su AWS e chi migra da Amazon Q Developer e vuole disciplina di specifica senza assemblare manualmente la toolchain. Se oggi vivi in VS Code standard e ami il tuo setup attuale, Kiro chiede un cambio più grande di quanto faccia Spec Kit.

Comandi Personalizzati e Skills di Claude Code

Claude Code non rilascia un singolo prodotto SDD ufficiale nel modo in cui fanno Spec Kit o Kiro. Se sei nuovo allo strumento stesso, inizia con la guida per installazione e configurazione di Claude Code} per setup, permessi e backend locali. Lo schema SDD stesso vive nei comandi personalizzati, nelle skills e nei template markdown repo-local che gli sviluppatori mantengono. Anthropic ha inglobato i vecchi file .claude/commands/*.md nel meccanismo Skills, quindi lo schema durevole è un SKILL.md (o equivalente) che definisce la tua checklist specifica-pianifica-implementa, caricata su richiesta.

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

Lo svantaggio è la disciplina. Niente ti costringe attraverso i gate di chiarificazione o revisione a meno che tu non li costruisci tu stesso. I thread su Reddit e Hacker News su “sviluppo guidato da 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 di Claude Code funziona quando trattavi le skills come codice – versionate, revisionate e mantenute – non come un download one-time di prompt.

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

Superpowers: Una Versione Pacchettata dello Stack di Skill Fai-da-Tè

Se creare 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, stesura piani, sviluppo guidato da subagenti, sviluppo guidato da test, richiesta di revisione del codice 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 scattano automaticamente e sono intese come flusso di lavoro obbligatorio, non suggerimenti opzionali che l’agente può saltare.

Il flusso di lavoro che impone mappava da vicino il ciclo a cinque fasi coperto nel Flusso di Lavoro di Sviluppo Guidato da Specifiche dai requisiti al codice} : il brainstorming raffina un’idea vaga in un documento di progetto revisionato, writing-plans lo spezza in piccoli task verificabili, subagent-driven-development dispaccia un nuovo subagente per task con una revisione in due fasi, e test-driven-development impone un rigoroso rosso-verde-refactor prima che qualcosa sia considerato fatto. Quell’ultima parte è più rigida di quanto la maggior parte delle skills SDD di Claude Code si preoccupi di essere – Superpowers elimina esplicitamente il codice scritto prima che esistesse un test fallente per esso.

A differenza di una skill repo-local che scrivi tu, Superpowers non è solo per Claude Code. Rilascia 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 tra gli impiazzamenti invece di vivere in una cartella .claude/skills/. Questo lo rende un punto di mezzo tra scrivere la tua skill di Claude Code e adottare uno strumento più pesante, specifico dell’IDE, come Kiro: ottieni un ciclo opinato e imposto senza rinunciare al tuo editor o impegnarti nel formato di specifica di un singolo fornitore.

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

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 sul cambio con meno file generati di Spec Kit. I benchmark della community riportano un uso dei token materialmente inferiore per task comparabili, al costo di meno struttura iniziale. OpenSpec tende a vincere quando stai modificando una codebase esistente e vuoi specifiche revisionabili senza una fase di pianificazione da 800 righe. Compete con Spec Kit sulla portabilità più che con Kiro sull’integrazione dell’IDE. Vedi il quickstart OpenSpec} per i passi di installazione, il ciclo esplora-proponi-applica-archivia e gli errori che appaiono più spesso su Reddit.

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

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

Spec Kitty e altri scaffold della community stanno tra OpenSpec e Spec Kit in peso. Sono degni di attenzione se vuoi template senza adottare la piena toolchain GitHub.

Lo schema attraverso tutti loro è lo stesso. Più processo aiuta quando l’ambiguità è costosa. Più processo fa male 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. Lo setup giusto dipende da chi sei, cosa stai costruendo e quanta struttura manterrai realmente.

Sviluppatore singolo, codebase esistente, piccole funzionalità. Inizia con le skills di Claude Code o OpenSpec. Scrivi un blocco di requisiti corto, una lista di task minima e un punto di controllo di revisione. Non installare un albero completo di Spec Kit per un cambio di cinquanta righe.

Vuoi l’approccio delle skills di Claude Code ma continui a saltare i tuoi gate di revisione. Installa Superpowers invece di scrivere una skill personalizzata da zero. Rinunci ad alcune regolazioni specifiche del progetto in cambio di un ciclo brainstorming-pianifica-implementa-revisiona imposto che non dipende dalla tua disciplina del giorno.

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

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

Team enterprise, AWS-native, pressione di compliance. 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 compliance. Lo strumento non sostituisce le tracce di audit. Le rende solo più facili da produrre.

Codebase esistente, cambio brownfield. OpenSpec o un flusso di lavoro leggero di Claude Code. Le cerimonie complete di Spec Kit su ogni bugfix sembreranno waterfall. Riserva la struttura più pesante per funzionalità trasversali.

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

I team che sperimentano l’orchestrazione multi-agente dovrebbero guardare anche Oh My OpenCode Agents} per pattern sulla divisione dei ruoli tra agenti – complementare agli artefatti SDD, non una sostituzione. Se il tuo team esegue un agente terminal-first invece di uno integrato all’IDE, la guida pratica CLI di OpenCode mostra la versione più leggera, a livello di prompt, della stessa disciplina pianifica-prima-di-implementare – utile quando un albero completo di Spec Kit è più cerimonia di quanto il task giustifichi.

Tabella di Decisione 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 cinquant’attività ridondanti sembrerà waterfall indipendentemente da quale agente lo implementa.

Le pratiche che viaggiano attraverso ogni setup sono noiose ed efficaci. Mantieni le specifiche abbastanza piccole da poterle revisionare in una sola seduta. Scrivi esplicitamente i non-obiettivi. Spezza i task in diff che un umano può leggere. Validare 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 da Specifiche vs Vibe Coding. Il confronto degli strumenti in questo articolo conta solo dopo che hai deciso che la funzionalità merita una specifica nel modo più assoluto.

Specifiche scritte male rendono ogni agente peggiore. Specifiche ben scritte 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 allineati gli agenti AI tra sessioni – con scommesse diverse sulla portabilità versus l’integrazione. Spec Kit ottimizza per markdown agnostico agli agenti nel tuo repository. Kiro ottimizza per un IDE nativo per specifiche guidato con agenti basati su AWS. Le skills di Claude Code ottimizzano per flussi di lavoro modificabili e leggeri che hanno successo solo quando li mantieni.

Scegli lo setup più superficiale che ancora rimuova 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 qualunque strumento abbiano scelto esegua contro di esse.

Link Utili

• Documentazione GitHub Spec Kit – riferimento ufficiale del flusso di lavoro Spec Kit
• Quickstart Superpowers: Installazione, Flusso di lavoro e Prova} – pacchetto di skills open source che impone una metodologia da brainstorming a TDD tra Claude Code, Cursor, Codex e altri agenti
• Martin Fowler sugli strumenti SDD – analisi di Kiro, Spec Kit e Tessl