GitHub Spec Kit, Kiro i Claude Code: porównanie procesów SDD

Programiści porównujący wdrożenia Spec-Driven Development (SDD) w 2026 roku zwykle nie pytają, który model jest najbystrzejszy. Pytają, który przepływ pracy utrzyma agenta AI na właściwych torach, nie obciążając ich nadmierną biurokracją.

GitHub Spec Kit, AWS Kiro i niestandardowe przepływy pracy Claude Code implementują tę samą szeroką ideę — wymagania, projektowanie, zadania, implementacja, walidacja — ale różnią się przenośnością, głębią integracji i tym, jak bardzo wymuszają określony proces.

Jeśli potrzebujesz najpierw zrozumieć koncepcje, przeczytaj artykuł Czym jest Spec-Driven Development? oraz neutralne narzędziem przewodnik Przepływ pracy Spec-Driven Development w klastrze dokumentacji Architektura Aplikacji. To porównanie znajduje się w hubie Narzędzia developerskie AI obok recenzji asystentów i przewodników po przepływach pracy.

SDD staje się kategorią narzędzi

Spec-Driven Development przestał być ćwiczeniem papierowym gdzieś pod koniec 2025 roku. Każdy duży dostawca narzędzi do kodowania z wykorzystaniem AI oferuje teraz jakąś wersję cyklu: zdefiniowanie, zaplanowanie, implementacja, a rosnąca lista niezależnych narzędzi konkurować ze sobą o to, ile struktury dodają wokół tego pętli.

Porównanie, które ma znaczenie, to nie „które narzędzie wygrywa”. To głębokość procesu w stosunku do przenośności. Kiro jest zintegrowany. Spec Kit jest przenośny. Przepływy pracy Claude Code są podatne na modyfikacje (hackowalne). Złe specyfikacje czynią każdego agenta gorszym, niezależnie od wybranego opakowania. Dobre specyfikacje przetrwają na różnych narzędziach.

Jak porównywać konfiguracje SDD

Zanim wybierzesz narzędzie, określ, czym optymalizujesz. Ta sama funkcja może wydawać się bezwysiłkowa w jednej konfiguracji i biurokratyczna w innej, w zależności od rozmiaru zespołu, wieku bazy kodu i tego, ile przeglądu potrzebujesz.

Przenośność – Czy specyfikacje mogą żyć jako zwykły Markdown w Twoim repozytorium i działać z agentem, którego wybierzesz w następnym kwartale? Czy są powiązane z jednym IDE, jedną chmurą lub jednym niestandardowym formatem?

Tarcie przy konfiguracji – Ile czasu potrzeba od „chcę wypróbować SDD” do działającej pętli: specyfikacja-plan-zadania? Szkielet CLI, instalacja IDE lub tworzenie własnych komend z ukośnikiem mają różną energię aktywacji.

Jakość specyfikacji – Czy narzędzie pomaga napisać precyzyjne wymagania i kryteria akceptacji, czy też głównie generuje długie dokumenty? Struktura jest przydatna. Objętość nie.

Wykonywanie zadań – Jak narzędzie dzieli pracę na przeglądane fragmenty? Czy zadania mogą być wykonywane równolegle? Czy opiera się eksplozjom pięćdziesięcio-punktowych list zadań?

Punkty kontrolne przeglądu – Czy są naturalne bramki ludzkie między fazami: specyfikacja, plan, zadania, implementacja? SDD bez przeglądu to po prostu wolniejsze „vibe coding” (kodowanie na wyczuwanie).

Zaakotowanie w repozytorium – Czy przepływ pracy czyta konwencje projektu, rejestry decyzji, ADR-y, AGENTS.md i istniejący kod przed planowaniem? Agenci bez zakotowania ponownie wymyślają architekturę, ponieważ nigdy nie widzą zweryfikowanej intencji stojącej za poprzednimi wyborami.

Współpraca zespołu – Czy wiele osób może przeglądać te same artefakty specyfikacji w pull requestach? Czy można mieszać agentów bez przepisywania procesu?

Lock-in (zapięcie) – Co tracisz, jeśli zmienisz edytor, model lub dostawcę chmury za sześć miesięcy?

GitHub Spec Kit

GitHub Spec Kit to open-source’owy zestaw narzędzi CLI, który buduje szkielet pętli SDD w Twoim repozytorium i przekazuje wykonanie dowolnemu agentowi kodowania, którego już używasz. CLI specify dodaje szablony, komendy z ukośnikiem i konwencjonalny układ folderów. Typowe komendy遵循ują sekwencję: konstytucja-spekifikacja-klarowanie-plan-zadania-implementacja, z jawnym krokiem klarowania w celu rozwiązania niejasności, zanim rozpocznie się praca nad architekturą.

Definiującą przewagą Spec Kit jest niezależność od agenta. Oficjalna dokumentacja pozycjonuje go jako narzędzie, które działa z Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex i dziesiątkami innych agentów. Piszesz specyfikacje raz w Markdown, commitujesz je jak kod i wymieniasz wykonawcę bez przepisywania procesu. To czyni Spec Kit domyślną rekomendacją dla zespołów, które chcą SDD bez stawiania wszystkiego na jednego dostawcę.

Kompromisy są realne. Spec Kit może wygenerować duże drzewo artefaktów — konstytucja, specyfikacja, plan, zadania, kontrakty — co zwraca się przy funkcjach wielosesyjnych, ale może wydawać się ciężkie przy małej poprawce CLI. Wątki na Hacker News regularnie porównują to obciążenie z biurokracją waterfalla. Spec Kit jest też słabszy, jeśli chcesz w pełni zintegrowanego IDE, gdzie specyfikacje, zadania i implementacja żyją na jednej przewodzonej powierzchni. Nakłada proces na Twój istniejący edytor, zamiast go zastępować.

Spec Kit pasuje do zespołów, które mają już preferowanego asystenta AI do kodowania i chcą standaryzowanego szkieletu SDD na wierzchu. Szczególnie silny jest przy funkcjach greenfield, firmach z wielu agentów i dla każdego, kto odrzuca zapięcie (lock-in) w edytorze.

AWS Kiro

Kiro to spec-driven IDE od AWS, zbudowane na forku VS Code / Code OSS. Tam gdzie Spec Kit przynosi SDD do Twojego istniejącego stosu, Kiro zakłada, że SDD zasługuje na dedykowane środowisko. Prompt generuje ustrukturyzowane artefakty — typowo requirements.md w notacji EARS, design.md i sekwencjonowane zależnościami tasks.md — zanim agenci zaczną pisać kod produkcyjny.

Doświadczanie z przewodnikiem jest głównym atutem Kiro. Wymagania, projektowanie i zadania są obiektami pierwszorzędowymi w interfejsie UI obok Twojego kodu, a nie plikami, które zarządzasz przez osobny CLI. Kiro oferuje również Agent Hooks (Haczyki Agentów), automaty zorientowane na zdarzenia, które mogą aktualizować testy, dokumentację lub powiązane artefakty, gdy zmienia się implementacja. Ta dwukierunkowa pętla jest czymś, czego Spec Kit nie oferuje „z pudełka” — specyfikacje Spec Kit pozostają statyczne, dopóki człowiek ich nie zaktualizuje.

Koszt to głębia integracji w zamian za przenośność. Kiro działa wewnątrz swojego edytora, używa modeli wspieranych przez AWS Bedrock i rozlicza się za pomocą modelu cenowego opartego na kredytach, z planami warstwowymi. Drużyny enterprise już korzystające z infrastruktury AWS często uznają to za akceptowalne. Deweloperzy indywidualni i zespoły wieloedycyjne mogą tego nie zrobić. Kiro ma też ostre brzegi typowe dla młodszych IDE — kompatybilność rozszerzeń, niespodzianki w przepływie pracy i zwykłe pytanie „czy naprawdę potrzebuję kolejnego edytora?”.

Kiro pasuje do deweloperów, którzy chcą najbardziej przewodzonego doświadczenia SDD i są gotowi na przyjęcie spec-native IDE. Jest to silna opcja dla zespołów enterprise, środowisk intensywnie korzystających z AWS oraz dla każdego, kto migruje z Amazon Q Developer i chce dyscypliny specyfikacji bez ręcznego składania łańcucha narzędzi. Jeśli żyjesz obecnie w standardowym VS Code i kochasz swój obecny setup, Kiro wymaga większego przełączenia niż Spec Kit.

Claude Code: Customowe Komendy i Skilli

Claude Code nie oferuje jednego oficjalnego produktu SDD w sposób, w jaki robią to Spec Kit lub Kiro. Jeśli jesteś nowicjusem w tym narzędziu, zacznij od przewodnika instalacyjnego i konfiguracyjnego Claude Code dla ustawień, uprawnień i lokalnych backendów. Sam wzorzec SDD żyje w niestandardowych komendach, skillach i lokalnych dla repozytorium szablonach Markdown, które utrzymują deweloperzy. Anthropic włączył starsze pliki .claude/commands/*.md do mechanizmu Skills, więc trwałym wzorcem jest SKILL.md (lub równoważnik) definiujący Twoją checklistę: specyfikacja-plan-implementacja, ładowaną na żądanie.

To podejście jest najlżejsze i najbardziej podatne na modyfikacje. Możesz przenieść trójplikową strukturę w stylu Kiro, odwzorować fazy Spec Kit za pomocą komend z ukośnikiem lub wymyślić minimalny przepływ pracy pasujący do jednego repozytorium. Claude Code czyta CLAUDE.md dla kontekstu projektu zawsze aktywnego i pobiera skille, gdy zadanie pasuje. Ten progresywny ujawnianie (progressive disclosure) utrzymuje sesje skupione bez ładowania pełnej konstytucji przy każdym prompcie.

Słabą stroną jest dyscyplina. Nic nie zmusza Cię do przejścia przez bramki klarowania lub przeglądu, chyba że zbudujesz te bramki samodzielnie. Wątki na Reddit i Hacker News dotyczące „spec-driven development wewnątrz Claude Code” są pełne deweloperów, którzy skopiowali skill kogoś innego, uruchomili go raz i wrócili do nieskorygowanych promptów, gdy skill wydawał się wolny. SDD w Claude Code działa, gdy traktujesz skille jak kod — wersjonowane, recenzowane i utrzymywane — a nie jak jednorazowy pobór promptu.

Dla poważnej implementacji, przeczytaj Claude Skills i SKILL.md dla deweloperów i zakoduj swoje fazy jako skille z jawnymi punktami kontrolnymi przeglądu. SDD w Claude Code to właściwy wybór, gdy już żyjesz w Claude Code, chcesz maksymalnej elastyczności i będziesz samodzielnie utrzymywać przepływ pracy. Konkretnie dla kroku bramki przeglądu, subagenty Claude Code mogą wykonać niezależną przejście przeglądu w izolowanym kontekście na wygenerowanym kodzie, zanim scalisz zadanie — lekki zamiennik roli weryfikacyjnej, którą Agent Hooks Kiro zapewniają natywnie.

Superpowers: Pakietowa wersja DIY Stack Skilli

Jeśli ręczne tworzenie tego stosu skilli brzmi dokładnie jak problem dyscypliny, o którym ostrzega tabela powyżej, Superpowers zasługują na uwagę. To open-source’owy pakiet skilli — burza mózgów, pisanie planów, rozwój napędzany subagentami, programowanie napędzane testami (TDD), żądanie przeglądu kodu i kilka wspierających skilli — dystrybuowany jako instalowalny plugin, a nie coś, co piszesz od zera. Celuje bezpośrednio w ograniczenie „jakość zależy całkowicie od dyscypliny autora”: skille wyzwalają się automatycznie i mają być obowiązkowym przepływem pracy, a nie opcjonalnymi sugestiami, które agent może pominąć.

Wymuszany przez niego przepływ pracy mapuje się ściśle na pięciofazową pętlę omówioną w Przepływ pracy Spec-Driven Development od wymagań do kodu: burza mógów dopracowuje wstępną ideę do przejrzanego dokumentu projektowego, pisanie planów dzieli ją na małe weryfikowalne zadania, rozwój napędzany subagentami wysyła nowego subagenta dla każdego zadania z dwustopniowym przeglądem, a programowanie napędzane testami wymusza rygorystyczne czerwone-zielone-refaktorowanie, zanim cokolwiek zostanie uznane za zakończone. Ta ostatnia część jest surowsza niż większość skilli SDD w Claude Code — Superpowers jawnie usuwa kod napisany przed istnieniem testu, który by go nie przechodził.

W przeciwieństwie do lokalnego dla repozytorium skilla, który piszesz samodzielnie, Superpowers nie jest tylko dla Claude Code. Dostarcza manifesty pluginów dla Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid i kilku innych agentów, więc ta sama metodologia podąża za Tobą między środowiskami, zamiast żyć w jednym folderze .claude/skills/. To czyni go środkiem drogi między tworzeniem własnego skilla w Claude Code a przyjęciem cięższego, specyficznego dla IDE narzędzia jak Kiro: otrzymujesz zdefiniowane stanowiskiem, wymuszoną pętlę, nie rezygnując ze swojego edytora ani nie zobowiązując się do formatu specyfikacji jednego dostawcy.

Superpowers pasuje do deweloperów, którzy lubią podejście Claude Code skills w teorii, ale ciągle wracają do nieskorygowanych promptów, ponieważ nic nie wymusza bramek przeglądu. Jest słabszym dopasowaniem, jeśli masz już specyficzny dla projektu SDD skill dostrojony do Twojego stosu — w takim przypadku wymieniasz niewielką ilość personalizacji na większą ilość wymuszonej ceremonii.

BMAD, OpenSpec i inne przepływy pracy

Nie każdy zespół chce drzewa artefaktów Spec Kit ani IDE Kiro. Dwa alternatywy pojawiają się stale w porównaniach z 2026 roku.

OpenSpec (Fission AI) podejmuje podejście skoncentrowane na zmianach z mniejszą liczbą generowanych plików niż Spec Kit. Społecznościowe benchmarki raportują znacznie niższe zużycie tokenów dla porównywalnych zadań, kosztem mniejszej struktury wstępnej. OpenSpec zwykle wygrywa, gdy modyfikujesz istniejącą bazę kodu i chcesz przeglądane specyfikacje bez 800-wierszowej fazy planowania. Konkurować z Spec Kit bardziej pod kątem przenośności niż z Kiro pod kątem integracji IDE. Zobacz OpenSpec quickstart dla kroków instalacji, pętli: eksploracja-propozycja-aplikacja-archiwizacja, oraz pułapek, które pojawiają się najczęściej na Reddicie.

BMAD-METHOD (społeczność) idzie w przeciwnym kierunku — wieloagentowe, oparte na rolach przepływy pracy, które symulują postacie product ownera, architekta, dewelopera i recenzenta. BMAD może być potężny przy dużych wysiłkach greenfield, gdzie jawna separacja ról pomaga. Jest też ciężki. Zespoły często raportują, że ceremonia zwraca się tylko wtedy, gdy ból koordynacji jest już ostry.

Tessl traktuje specyfikację jako dosłowne źródło generowanego kodu, oznaczając output jako pochodny i zniechęcając do ręcznych edycji. To najsilniejsze stanowisko „specyfikacji jako źródła” wśród mainstreamowych narzędzi, ale Tessl pozostaje w wersji beta i niesie najwyższy poziom zapięcia produktowego w grupie.

Spec Kitty i inne społeczne szkielety zajmują pozycję między OpenSpec a Spec Kit pod względem wagi. Warto je obserwować, jeśli chcesz szablonów, nie przyjmując pełnego łańcucha narzędzi GitHub.

Wzorzec we wszystkich z nich jest taki sam. Więcej procesu pomaga, gdy niejasność jest droga. Więcej procesu szkodzi, gdy szybkość informacji zwrotnej ma większe znaczenie niż zgranie. Dopasuj wagę narzędzia do rozmiaru zadania, nie do hype’u.

Którą konfigurację SDD powinieneś użyć?

Nie ma uniwersalnego zwycięzcy. Właściwa konfiguracja zależy od tego, kim jesteś, co budujesz i ile struktury faktycznie utrzymasz.

Deweloper indywidualny, istniejąca baza kodu, małe funkcje. Zacznij od skilli Claude Code lub OpenSpec. Napisz krótki blok wymagań, minimalną listę zadań i jeden punkt kontrolny przeglądu. Nie instaluj pełnego drzewa Spec Kit dla pięćdziesięcio-wierszowej zmiany.

Chcesz podejścia Claude Code skills, ale cały czas pomijasz własne bramki przeglądu. Zainstaluj Superpowers zamiast pisać customowy skill od zera. Oddajesz trochę strojenia specyficznego dla projektu w zamian za wymuszony przepływ: burza mózgów-plan-implementacja-przegląd, który nie zależy od Twojej dyscypliny tego dnia.

Deweloper indywidualny, funkcja greenfield, wiele sesji. Spec Kit lub dobrze utrzymywany skill SDD w Claude Code. Potrzebujesz trwałych artefaktów bardziej niż prowadzenia za rękę przez IDE.

Mały zespół, mieszane edytory. Spec Kit. Zwykłe specyfikacje Markdown w Git, recenzowane w pull requestach, wykonywane przez dowolnego agenta, którego preferuje każdy deweloper.

Zespół enterprise, native AWS, presja zgodności. Kiro. Przewodzone artefakty, śledzalność wymagań i haczyki (hooks), które utrzymują dokumentację i testy bliżej implementacji.

Środowisko regulowane. Kiro lub Spec Kit plus własna checklistą walidacyjna — nie tylko skille Claude Code, chyba że jawnie zakodujesz bramki zgodności. Narzędzia nie zastępują śladów audytowych. Tylko ułatwiają ich wytworzenie.

Istniejąca baza kodu, zmiana brownfield. OpenSpec lub lekki przepływ pracy Claude Code. Pełna ceremonia Spec Kit dla każdej poprawki buga będzie się czuła jak waterfall. Zrezerwuj cięższą strukturę dla funkcji poprzecznych (cross-cutting).

Produkt greenfield, wielu agentów. Spec Kit. Przenośność ma większe znaczenie niż wykończenie IDE, gdy Copilot, Claude Code i Cursor mogą dotykać tego samego repozytorium.

Zespoły eksperymentujące z orkiestracją wielu agentów powinny też przyjrzeć się Oh My OpenCode Agents dla wzorców dzielenia ról między agentami — komplementarne do artefaktów SDD, a nie ich zamiennik. Jeśli Twój zespół uruchamia agenta pierwszego wyboru terminalowego, a nie zintegrowanego z IDE, praktyczny przewodnik po OpenCode CLI pokazuje lżejszą, prompt-level wersję tej samej dyscypliny planowania przed implementacją — przydatne, gdy pełne drzewo Spec Kit to więcej ceremonii, niż wymaga zadanie.

Praktyczna Tabela Decyzyjna

Co faktycznie determinuje sukces

Wybór narzędzia ma mniejsze znaczenie niż jakość artefaktów. Plik wymagań w Kiro z niejasnymi kryteriami akceptacji wyprodukuje ten sam dryf, co niedbały prompt Claude Code. Plan Spec Kit, który wymienia pięćdziesiąt redundantnych zadań, będzie się czuł jak waterfall, niezależnie od tego, który agent go implementuje.

Praktyki, które przetrwają w każdej konfiguracji, są nudne i skuteczne. Utrzymuj specyfikacje wystarczająco małe, aby można było je przejrzeć w jednej sesji. Pisz o niecelowościach (non-goals) jawnie. Dzieli zadania na diff’y, które człowiek może przeczytać. Waliduj względem kryteriów akceptacji przed scaleniem. Aktualizuj specyfikację, gdy implementacja odkryje lepszą ścieżkę.

Jeśli nadal wybierasz między SDD a nieskorygowanymi promptami dla danej funkcji, przeczytaj Spec-Driven Development vs Vibe Coding. Porównanie narzędzi w tym artykule ma znaczenie dopiero po tym, jak zdecydujesz, że funkcja w ogóle zasługuje na specyfikację.

Złe specyfikacje czynią każdego agenta gorszym. Dobre specyfikacje przetrwają na różnych narzędziach.

Podsumowanie

GitHub Spec Kit, Kiro i przepływy pracy Claude Code to trzy odpowiedzi na to samo pytanie — jak utrzymać agentów AI na właściwych torach między sesjami — z różnymi postawieniami na przenośność versus integracja. Spec Kit optymalizuje się dla nieagentowego Markdowna w Twoim repozytorium. Kiro optymalizuje się dla przewodzonego, spec-native IDE z agentami wspieranymi przez AWS. Skille Claude Code optymalizują się dla hackowalnych, lekkich przepływów pracy, które udają się tylko wtedy, gdy je utrzymujesz.

Wybierz najlżejszą konfigurację, która nadal usuwa niejasności dla funkcji na danym etapie. Dodaj strukturę, gdy pojawi się ból koordynacji, a nie gdy blog post Ci o tym powie. Deweloperzy, którzy czerpią wartość z SDD w 2026 roku, to nie ci, którzy mają najbardziej elaborowany łańcuch narzędzi. To ci, którzy piszą specyfikacje warte implementacji — a następnie pozwalają wybranemu narzędziu egzekwować je.

Przydatne linki

• Dokumentacja GitHub Spec Kit – oficjalna referencja do przepływu pracy Spec Kit
• Superpowers Quickstart: Instalacja, przepływ pracy i wypróbowanie – open-source’owy pakiet skilli wymuszający metodologię od burzy mózgów do TDD między Claude Code, Cursor, Codex a innymi agentami
• Martin Fowler o narzędziach SDD – analiza Kiro, Spec Kit i Tessl