GitHub Spec Kit versus Kiro versus Claude Code SDD-workflows

Ontwikkelaars die in 2026 Spec-Driven Development-opstellingen vergelijken, vragen zich meestal niet af welk model het slimst is. Ze vragen zich af welke workflow een AI-agent consistent houdt zonder hen te begraven onder bureaucratie.

GitHub Spec Kit, AWS Kiro en aangepaste workflows van Claude Code implementeren allemaal hetzelfde brede concept – vereisten, ontwerp, taken, implementatie, validatie – maar ze maken verschillende afwegingen op het gebied van portabiliteit, integratiediepte en hoeveel proces ze afdwingen.

Als u de concepten eerst wilt begrijpen, lees dan Wat is Spec-Driven Development? en de tool-onafhankelijke handleiding Spec-Driven Development Workflow in het App Architecture-documentatiecluster. Dit vergelijkingsartikel staat in de AI Developer Tools-hub, naast recensies van assistenten en workflowgidsen. Het behandelt de drie opstellingen waar ontwikkelaars het meest over discussiëren op Hacker News en Reddit-achtige fora, plus de lichtere en zwaardere alternatieven die eromheen draaien.

SDD wordt een toolcategorie

Spec-Driven Development is eind 2025 gestopt met zijn bestaan als louter theoretische oefening. Elke grote leverancier van AI-codetools levert nu een versie van specificeren-plannen-implementeren, en een groeiend aantal standalone-tools strijdt om hoeveel structuur ze toevoegen aan die cyclus.

De vergelijking die telt, is niet “welke tool wint”. Het gaat om procesdiepte versus portabiliteit. Kiro is geïntegreerd. Spec Kit is portabel. Claude Code-workflows zijn hackbaar. Slechte specificaties maken elke agent slechter, ongeacht welke wrapper je kiest. Goede specificaties reizen tussen tools.

Hoe SDD-opstellingen te vergelijken

Voordat je een tool kiest, bepaal waar je optimaliseert. Dezelfde feature kan in één opstelling moeiteloos aanvoelen en in een andere bureaucratisch, afhankelijk van teamgrootte, leeftijd van de codebase en hoeveel review je nodig hebt.

Portabiliteit – Kunnen de specificaties bestaan als platte markdown in je repository en werken ze met de agent die je het volgende kwartaal prefereert? Of zijn ze gebonden aan één IDE, één cloud of één proprietaire indeling?

Setup-frictie – Hoe lang duurt het van “ik wil SDD proberen” tot een werkende specificeren-plannen-taken cyclus? CLI-scaffolding, IDE-installatie of het zelf bouwen van slash-commando’s hebben allemaal verschillende activeringsenergie.

Specificatiekwaliteit – Helpt de tool je om precieze vereisten en acceptatiecriteria te schrijven, of genereert hij voornamelijk lange documenten? Structuur is nuttig. Volume niet.

Taakuitvoering – Hoe breekt de tool werk op in reviewbare stukjes? Kunnen taken parallel worden uitgevoerd? Weert het explosies van vijftig taken?

Review-controlepunten – Zijn er natuurlijke menselijke poorten tussen specificeren, plannen, taken en implementeren? SDD zonder review is slechts langzamer vibe coding.

Repository-ankering – Leest de workflow projectconventies, beslisrecords, ADRs, AGENTS.md en bestaande code voordat het begint met plannen? Agents zonder anker opnieuw uitvinden architectuur omdat ze de beoordeelde intentie achter eerdere keuzes nooit zien.

Teamcollaboratie – Kunnen meerdere personen dezelfde specificatie-artifacts reviewen in pull requests? Kun je agents mixen zonder het proces te herschrijven?

Lock-in – Wat verlies je als je over zes maanden van editor, model of cloudleverancier wisselt?

GitHub Spec Kit

GitHub Spec Kit is een open-source CLI-toolkit die een spec-gestuurde cyclus in je repository scaffoldt en de uitvoering overlaat aan welke coderingagent je ook al gebruikt. De specify CLI droppt templates, slash-commando’s en een conventionele mapstructuur. Typische commando’s volgen een constitutie-specificeren-verduidelijken-plannen-taken-implementeren volgorde, met een expliciete verduidelijkingsstap om ambiguïteit op te lossen voordat architectuurbewerk begint.

Het bepalende voordeel van Spec Kit is agent-onafhankelijkheid. De officiële documenten presenteren het als tooling dat werkt met Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex en tientallen andere agents. Je schrijft specificaties één keer in markdown, commit ze als code en wisselt de executor zonder het proces te herschrijven. Dat maakt Spec Kit de standaardaanbeveling voor teams die SDD willen zonder te wedden op één leverancier.

De afwegingen zijn reëel. Spec Kit kan een groot artifactenboom produceren – constitutie, spec, plan, taken, contracten – wat afbetaalt bij multi-sessie features, maar zwaar aanvoelt voor een kleine CLI-aanpassing. Hacker News-threads vergelijken die overhead regelmatig met waterfall-bureaucratie. Spec Kit is ook zwakker als je een volledig geïntegreerde IDE wilt waar specificaties, taken en implementatie in één gecoördineerd oppervlak leven. Het legt proces bovenop je bestaande editor in plaats van deze te vervangen.

Spec Kit past bij teams die al een voorkeur hebben voor een AI-coderingsassistent en een gestandaardiseerd SDD-scaffold erbovenop willen. Het is bijzonder sterk voor greenfield-features, multi-agent shops en iedereen die editor-lock-in weigert.

AWS Kiro

Kiro is AWS’ spec-gestuurde IDE, gebouwd op een VS Code / Code OSS-fork. Waar Spec Kit SDD brengt naar je bestaande stack, gaat Kiro uit van dat SDD een purpose-built omgeving verdient. Een prompt genereert gestructureerde artifacts – typisch requirements.md in EARS-stijl notatie, design.md en een afhankelijkheids-gevolgde tasks.md – voordat agents productcode schrijven.

De begeleide ervaring is het belangrijkste verkoopargument van Kiro. Vereisten, ontwerp en taken zijn eerste-klasse UI-objecten naast je code, geen bestanden die je beheert via een aparte CLI. Kiro levert ook Agent Hooks, gebeurtenis-gestuurde automatiseringen die tests, documentatie of gerelateerde artifacts kunnen updaten wanneer de implementatie verandert. Die bidirectionele lus is iets dat Spec Kit niet standaard biedt – Spec Kit-specificaties blijven statisch totdat een mens ze update.

De kosten zijn integratiediepte ten koste van portabiliteit. Kiro draait binnen zijn editor, gebruikt AWS Bedrock-achterliggende modellen en factureert via een credit-gebaseerd prijsmodel met gelaagde plannen. Enterprise-teams die al op AWS-infrastructuur zitten, vinden dat vaak acceptabel. Solo-ontwikkelaars en multi-editor-teams misschien niet. Kiro heeft ook ruwe randen die typisch zijn voor een nieuwere IDE – extensie-compatibiliteit, workflow-verrassingen en de gebruikelijke vraag “heb ik echt nog een editor nodig?”.

Kiro past bij ontwikkelaars die de meest begeleide SDD-ervaring willen en comfortabel zijn met het aannemen van een spec-native IDE. Het is een sterke optie voor enterprise-teams, AWS-zware omgevingen en iedereen die migreert van Amazon Q Developer en spec-discipline wil zonder de toolchain handmatig te assembleren. Als je vandaag in standaard VS Code leeft en je huidige setup liefhebt, vraagt Kiro om een grotere overstap dan Spec Kit.

Claude Code Custom Commands and Skills

Claude Code levert geen enkele officiële SDD-product zoals Spec Kit of Kiro doen. Als je nieuw bent bij het tool zelf, begin dan met de Claude Code installatie- en configuratiegids voor setup, permissies en lokale backends. Het SDD-patroon zelf leeft in custom commando’s, skills en repo-lokale markdown-templates die ontwikkelaars onderhouden. Anthropic voude oudere .claude/commands/*.md bestanden in het Skills-mechanisme, dus het duurzame patroon is een SKILL.md (of equivalent) die je specificeren-plannen-implementeren checklist definieert, op verzoek geladen.

Deze aanpak is het lichtste en het meest hackbaar. Je kunt een Kiro-stijl driedelige lay-out porteren, Spec Kit-fasen spiegelen met slash-commando’s, of een minimale workflow verzinnen die past bij één repository. Claude Code leest CLAUDE.md voor altijd-aan projectcontext en trekt skills als de taak overeenkomt. Die progressieve onthulling houdt sessies gericht zonder een volledige constitutie op elke prompt te laden.

Het nadeel is discipline. Niets dwingt je door verduidelijkings- of reviewpoorten tenzij je die poorten zelf bouwt. Reddit- en Hacker News-threads over “spec-driven development binnen Claude Code” zijn vol met ontwikkelaars die de skill van iemand anders kopieerden, hem één keer draaiden en terugkeerden naar ongestructureerd prompten toen de skill langzaam voelde. Claude Code SDD werkt wanneer je skills behandelt als code – versiebeheerd, gereviewd en onderhouden – niet als een eenmalige prompt-download.

Voor een serieuze implementatie, lees Claude Skills en SKILL.md voor Ontwikkelaars en codeer je fasen als skills met expliciete review-controlepunten. Claude Code SDD is de juiste keuze als je al in Claude Code leeft, maximale flexibiliteit wilt, en de workflow zelf zult onderhouden.

BMAD, OpenSpec en andere Workflows

Niet elk team wil de Spec Kit artifactenboom of de Kiro IDE. Twee alternatieven komen constant naar voren in 2026-vergelijkingen.

OpenSpec (Fission AI) neemt een wijzigingsgerichte aanpak met minder gegenereerde bestanden dan Spec Kit. Community-benchmarks rapporteren materieel lager tokenverbruik voor vergelijkbare taken, ten koste van minder voorafgaande structuur. OpenSpec wint vaak wanneer je een bestaande codebase aanpast en reviewbare specificaties wilt zonder een planningsfase van 800 regels. Het concurreert met Spec Kit op portabiliteit meer dan met Kiro op IDE-integratie.

BMAD-METHOD (community) duwt in de tegenovergestelde richting – multi-agent, rolgebaseerde workflows die product owner, architect, ontwikkelaar en reviewer persona’s simuleren. BMAD kan krachtig zijn bij grote greenfield-inspanningen waar expliciete rol-scheiding helpt. Het is ook zwaar. Teams rapporteren regelmatig dat de ceremonie pas afbetaalt wanneer coördinatietrauma al acuut is.

Tessl behandelt de spec als de letterlijke bron van gegenereerde code, markeert output als afgeleid en ontmoedigt handmatige bewerkingen. Dat is de sterkste “spec-as-source” houding onder mainstream tools, maar Tessl blijft beta en draagt de hoogste product-lock-in van de groep.

Spec Kitty en andere community-scaffolds zitten tussen OpenSpec en Spec Kit in gewicht. Ze zijn het waard om in de gaten te houden als je templates wilt zonder de volledige GitHub-toolchain aan te nemen.

Het patroon over al hen heen is hetzelfde. Meer proces helpt wanneer ambiguïteit duur is. Meer proces schaadt wanneer feedbacksnelheid belangrijker is dan uitlijning. Match toolgewicht aan taakgrootte, niet aan hype.

Welke SDD-opstelling moet je gebruiken?

Er is geen universele winnaar. De juiste opstelling hangt af van wie je bent, wat je bouwt, en hoeveel structuur je zult onderhouden.

Solo-ontwikkelaar, bestaande codebase, kleine features. Begin met Claude Code skills of OpenSpec. Schrijf een korte vereistenblok, een minimale takenlijst en één review-controlepunt. Installeer geen volledige Spec Kit-boom voor een wijziging van vijftig regels.

Solo-ontwikkelaar, greenfield-feature, meerdere sessies. Spec Kit of een goed onderhouden Claude Code SDD-skill. Je hebt duurzame artifacts nodig meer dan IDE-handholding.

Klein team, gemengde editors. Spec Kit. Platte markdown-specificaties in Git, gereviewd in pull requests, uitgevoerd door welke agent elke ontwikkelaar ook prefereert.

Enterprise-team, AWS-native, compliance-druk. Kiro. Begeleide artifacts, vereisten-traceerbaarheid en hooks die documenten en tests dichter bij de implementatie houden.

Gereguleerde omgeving. Kiro of Spec Kit plus je eigen validatiechecklist – niet alleen Claude Code skills tenzij je compliance-poorten expliciet codeert. Tooling vervangt geen audit-trails. Het maakt ze alleen makkelijker te produceren.

Bestaande codebase, brownfield-wijziging. OpenSpec of een lichtgewicht Claude Code-workflow. Volledige Spec Kit-bureaucratie bij elke bugfix zal voelen als waterfall. Behoud zwaardere structuur voor cross-cutting features.

Greenfield-product, veel agents. Spec Kit. Portabiliteit is belangrijker dan IDE-polish wanneer Copilot, Claude Code en Cursor allemaal dezelfde repo kunnen raken.

Teams die experimenteren met multi-agent orchestratie, moeten ook kijken naar Oh My OpenCode Agents voor patronen op het splitsen van rollen over agents – complementair aan SDD-artifacts, geen vervanging ervoor.

Praktische Beslissingstabel

Wat bepaalt daadwerkelijk succes

Toolkeuze is minder belangrijk dan artifactenkwaliteit. Een Kiro-vereistenbestand met vaag acceptatiecriteria zal dezelfde drift produceren als een slordige Claude Code-prompt. Een Spec Kit-plan dat vijftig redundante taken opsomt, zal voelen als waterfall, ongeacht welke agent het implementeert.

De praktijken die over elke opstelling reizen, zijn saai en effectief. Houd specificaties klein genoeg om in één sitting te reviewen. Schrijf non-goals expliciet. Breek taken op in diffs die een mens kan lezen. Valideer tegen acceptatiecriteria voordat je merge. Update de spec wanneer implementatie een beter pad ontdekt.

Als je nog steeds kiest tussen SDD en ongestructureerd prompten voor een gegeven feature, lees dan Spec-Driven Development vs Vibe Coding. De toolvergelijking in dit artikel doet er pas toe zodra je hebt besloten dat de feature überhaupt een spec verdient.

Slechte specificaties maken elke agent slechter. Goede specificaties reizen tussen tools.

Conclusie

GitHub Spec Kit, Kiro en Claude Code-workflows zijn drie antwoorden op dezelfde vraag – hoe houd je AI-agents uitgelijnd over sessies heen – met verschillende weddenschappen op portabiliteit versus integratie. Spec Kit optimaliseert voor agent-agnostische markdown in je repository. Kiro optimaliseert voor een begeleide spec-native IDE met AWS-achterliggende agents. Claude Code skills optimaliseren voor hackbare, lichtgewicht workflows die alleen slagen wanneer je ze onderhoudt.

Kies de oppervlakkigste setup die toch ambiguïteit verwijdert voor de feature op de hand. Voeg structuur toe wanneer coördinatietrauma verschijnt, niet wanneer een blogpost je vertelt om dat te doen. De ontwikkelaars die waarde halen uit SDD in 2026 zijn niet die met de meest elaborate toolchain. Het zijn diegenen die specificaties schrijven die de moeite waard zijn om te implementeren – en dan laten welke tool ze ook kozen uitvoeren tegen hen.

Nuttige Links

• GitHub Spec Kit documentatie – officiële Spec Kit workflow-referentie
• Martin Fowler over SDD-tools – analyse van Kiro, Spec Kit en Tessl