Claude Code i Spec Kit: specyfikacja przed pisaniem kodu

Co stało się z vibe codingiem w maju 2026 roku?#

Rok później, 4 lutego 2026 roku, opublikował wątek podsumowujący:

Podczas wystąpienia na Sequoia Ascent 2026 ujął to jeszcze precyzyjniej: „Vibe coding podnosi dolny próg — zwiększa to, co każdy może zrobić w oprogramowaniu. Agentic engineering pozwala zachować górny próg — poprzeczkę jakości profesjonalnego wytwarzania oprogramowania”. Na tej samej scenie rzucił zdanie, które weszło do branżowego słownika: „Vibe coding nie daje ci prawa do wprowadzania luk w zabezpieczeniach. Nadal odpowiadasz za swoje oprogramowanie, tak jak wcześniej”.

Dwie rzeczy wydarzyły się równolegle. We wrześniu 2025 roku GitHub opublikował narzędzie Spec Kit — w ciągu 8 miesięcy zebrało ono 107 000 gwiazdek. W lutym 2026 roku AWS opublikowało szczegółowe studium przypadku dotyczące odkrywania leków, informując o „95% logiki biznesowej wygenerowanej na podstawie specyfikacji i oszczędności ponad 80 godzin”.

Pod koniec maja 2026 roku w anglojęzycznej przestrzeni informacyjnej ukształtował się konsensus: vibe coding jako metoda pracy to poziom początkujący. Kolejny etap to Spec-Driven Development. Ten poradnik wyjaśnia, jak zainstalować i zastosować to podejście.

Czym są Spec Kit i Spec-Driven Development?#

Główna idea tej metodologii została ujęta w jednym zdaniu w oficjalnej dokumentacji GitHuba:

W praktyce przebiega to w 4 fazach (Spec Kit dodaje jeszcze jedną, fazę zerową — constitution, opisaną poniżej):

1. Specify — napisz w języku naturalnym specyfikację tego, czego chcesz. CO należy zrobić i DLACZEGO. Nie JAK.
2. Plan — agent na podstawie specyfikacji przygotowuje plan techniczny: jakich technologii użyć, jaka ma być architektura i jakie komponenty są potrzebne.
3. Tasks — agent dzieli plan na konkretne, możliwe do zweryfikowania zadania i określa zależności.
4. Implement — agent (lub jego subagenci) realizuje zadania i pisze kod.

Po fazie Implement aktualna wersja Spec Kit ma etap weryfikacji o nazwie Converge: agent porównuje gotowy kod ze specyfikacją, planem i zadaniami, a następnie dodaje do tasks.md wszystko, co zostało pominięte. Powtarzaj Implement i Converge, aż Converge odpowie „Converged”.

Każda faza to osobny plik Markdown w repozytorium. W Claude Code każda faza jest osobnym poleceniem slash: /speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, a sprawdzenie to /speckit-converge. Dokumentacja Spec Kit zapisuje te same polecenia z kropką (/speckit.specify), ale w Claude Code Spec Kit instaluje je jako umiejętności i wywołuje się je łącznikiem. Jeśli coś pójdzie nie tak na którymś etapie, edytuj plik Markdown i uruchom następną fazę ponownie.

Spec Kit to konkretna implementacja SDD. W maju 2026 roku obsługiwał już ponad 30 integracji z różnymi agentami AI. W obrębie jednego repozytorium Spec Kit działa tak samo z Claude Code, Cursor, GitHub Copilot, Codex CLI, Windsurf, Qwen, Tabnine, Amazon Q, Gemini, Goose i kilkunastoma innymi narzędziami.

Po zakończeniu pracy repozytorium zawiera więc nie tylko kod, ale także jego specyfikację, plan i zadania. Po miesiącu możesz wrócić do projektu, przeczytać spec.md i zrozumieć, co zrobiono i dlaczego. To już nie „vibe coding, w którym zapomniano, że istnieje kod” — to pamięć robocza projektu.

Po co to komuś, kto stosuje vibe coding i nie pisze kodu?#

Spec Kit formalizuje planowanie w oddzielnych krokach za pomocą 4 poleceń slash. Logika jest taka sama: oddzielić „przemyślenie sprawy” od „implementacji”, tak aby odbywały się w różnych oknach kontekstu. Każdy etap zaczyna się w czystym kontekście, którego nie zaśmieciła poprzednia faza.

Trzy konkretne korzyści dla osoby stosującej vibe coding:

• Przewidywalność. Kiedy mówisz agentowi „utwórz formularz rejestracji z potwierdzeniem e-mail”, samodzielnie zgaduje 10 szczegółów — i w trzech z nich myli się co do twoich oczekiwań. Gdy masz spec.md z User Stories, Acceptance Scenarios i znacznikami [NEEDS CLARIFICATION] w każdym niepewnym miejscu, nie ma czego zgadywać.
• Pamięć projektu. Po miesiącu nie będziesz pamiętać, o czym rozmawiałeś z agentem na czacie. Ale pliki spec.md, plan.md i tasks.md będą w repozytorium, w folderze specs/###-feature/ obok kodu. Pokażą nie tylko, co zrobiono, ale też dlaczego.
• Skalowanie. W przypadku funkcji obejmującej 1-2 pliki różnica jest ledwo zauważalna. Przy funkcji obejmującej 20 plików i 5 encji danych różnica polega na tym, czy po 4 godzinach „przepisujesz wszystko od nowa”, czy „wszystko trafiło do głównej gałęzi”. AWS Kiro wykazało, że w projekcie TargetID 95% logiki biznesowej można zautomatyzować na podstawie specyfikacji.

Główne złudzenie vibe codingu polega na tym, że na początku wydaje się szybszy. Pół godziny i jest prototyp. Ale po tygodniu prototyp się psuje i łatwiej go wyrzucić. Spec-Driven Development zajmuje na początku nieco więcej czasu (godzinę zamiast pół godziny), ale tydzień później nadal pracujesz w tym samym repozytorium.

Jak zainstalować Spec Kit w Claude Code (4 kroki)#

Krok 1. Zainstaluj uv. Wystarczy zrobić to raz; uv pozostanie w systemie.

# macOS / Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Sprawdź, czy uv zostało zainstalowane:

uv --version

Krok 2. Zainstaluj Spec Kit. Jedno polecenie:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Sprawdź:

specify --version

Krok 3. Zainicjuj repozytorium. Przejdź do folderu projektu (lub utwórz nowy) i uruchom:

specify init --here --integration claude

Flaga --integration claude wybiera bezpośrednio Claude Code. Bez niej Spec Kit poprosi o wybranie agenta z interaktywnej listy, a także może zapytać o typ skryptu (w macOS i Linux pozostaw sh). Jeśli folder nie jest pusty, Spec Kit ostrzeże, że połączy swoje pliki z istniejącymi: najpierw zatwierdź swoją pracę, a następnie powtórz polecenie z flagą --force.

Następnie w repozytorium pojawi się:

.specify/
  memory/
    constitution.md        # zasady projektu, uzupełniane przez /speckit-constitution
  scripts/
  templates/
    spec-template.md
    plan-template.md
    tasks-template.md
.claude/
  skills/
    speckit-constitution/SKILL.md
    speckit-specify/SKILL.md
    speckit-clarify/SKILL.md
    speckit-plan/SKILL.md
    speckit-checklist/SKILL.md
    speckit-tasks/SKILL.md
    speckit-analyze/SKILL.md
    speckit-implement/SKILL.md
    speckit-converge/SKILL.md
    speckit-taskstoissues/SKILL.md

Krok 4. Otwórz Claude Code i sprawdź polecenia slash. Uruchom w tym samym folderze:

claude

W sesji wpisz /speckit — w podpowiedziach powinny pojawić się polecenia speckit-*. Jeśli się nie pojawią, uruchom ponownie Claude Code, aby ponownie odczytał .claude/skills/. Jeśli w katalogu głównym projektu masz już plik CLAUDE.md, Spec Kit go nie ruszy — działa obok niego, w .specify/memory/constitution.md.

Spec Kit działa też bez Claude Code (obsługuje ponad 30 agentów), ale ten poradnik opisuje konfigurację konkretnie z Claude. Jeśli chcesz od razu zainstalować dwa narzędzia, zobacz osobne poradniki na temat konfiguracji CLAUDE.md i Plan Mode w Claude Code.

Spec Kit jest pierwszym elementem składowym „umowy o pracę agenta”. Pełna konfiguracja obejmuje trzy elementy: klon AI (twoja metodologia w postaci Skills i subagentów), Second Brain (struktura business/, do której agent wraca za każdym razem) oraz inżynierię kontekstu (Spec Kit, Plan Mode, /compact). To trzy filary niezbędne, by AI nie halucynowało.

Jak napisać pierwszą specyfikację (Specify)#

W Claude Code wpisz:

/speckit-specify

Następnie agent poprosi o opis funkcji. Na tym etapie używaj prostego języka, bez żargonu technicznego:

Chcę dodać formularz rejestracji do mojej aplikacji. Użytkownik wpisuje adres e-mail
i hasło, otrzymuje wiadomość z potwierdzeniem i po potwierdzeniu
trafia na pulpit. Potwierdzenie wygasa po 48 godzinach. Jeśli e-mail
nadal nie jest potwierdzony, usuń konto w ciągu 5 minut po tym terminie;
nigdy nie usuwaj potwierdzonego konta.

W tym przykładzie doprecyzowano tolerancję usunięcia do 5 minut po terminie 48 godzin. Dla rzeczywistego produktu potwierdź ją przed Plan; dokładny termin 48 godzin wymaga projektu i testów egzekwujących silniejszy warunek. Agent przygotuje specs/001-registration/spec.md. Otwórz go, aby zobaczyć strukturę podobną do tej:

# Feature Specification: User Registration

**Feature Branch**: `001-registration`
**Created**: 2026-05-31
**Status**: Draft
**Input**: User Description: "I want a registration form..."

## User Scenarios & Testing *(mandatory)*

### Primary User Story
As a new user, I want to register an account with email confirmation,
so that I can access the dashboard with a verified identity.

### Acceptance Scenarios
1. **Given** I am on the registration page,
   **When** I submit valid email and password,
   **Then** I receive a confirmation email within 1 minute.
2. **Given** I clicked the confirmation link within 48 hours,
   **When** I land on the dashboard,
   **Then** I see my email confirmed in profile.
3. **Given** I have not confirmed at the 48-hour deadline,
   **When** cleanup runs within the next 5 minutes,
   **Then** my account is deleted and email is freed for re-registration.
4. **Given** my account is just under 48 hours old or already confirmed,
   **When** cleanup runs,
   **Then** the account is not deleted.

## Requirements *(mandatory)*

### Functional Requirements
- **FR-001**: System MUST accept registration via [NEEDS CLARIFICATION:
  email/password only, or also SSO/OAuth?]
- **FR-002**: System MUST send confirmation email within 60 seconds
- **FR-003**: Confirmation MUST expire at 48 hours; the system MUST
  delete still-unconfirmed accounts no later than 5 minutes after that
  deadline and MUST NOT delete confirmed accounts
- **FR-004**: System MUST log all registration attempts for [NEEDS
  CLARIFICATION: how long do we retain logs - 30 days, 90 days, forever?]

### Key Entities
- User: email, password_hash, email_verified_at, created_at, deleted_at
- ConfirmationToken: token, user_id, expires_at, used_at

## Success Criteria *(mandatory)*
- **SC-001**: 95% of confirmation emails delivered within 60 seconds (p95)
- **SC-002**: 0 accidental deletions of confirmed accounts
- **SC-004**: No deletion before 48 hours; every eligible unconfirmed
  account is deleted by age 48 hours 5 minutes under the tested workload
- **SC-003**: Registration completion rate > 60% (from form open to dashboard)

Zwróć uwagę na znaczniki [NEEDS CLARIFICATION: ...]. Spec Kit celowo wstawia je wszędzie tam, gdzie agent nie uzyskał jednoznacznej odpowiedzi z twojego tekstu. Zanim przejdziesz do fazy Plan, musisz samodzielnie odpowiedzieć na te pytania w spec.md albo uruchomić /speckit-clarify. Agent omówi z tobą niejasne kwestie i zada pytania w dialogu.

W Spec Kit wbudowane polecenie /speckit-clarify zastępuje wypowiedziane „zadawaj mi pytania”. Efekt jest ten sam: nie przechodzisz do Plan, dopóki w spec.md nie pozostaną żadne znaczniki [NEEDS CLARIFICATION].

W spec.md nie powinno być technologii. Nie wspominaj o React, Postgres, Prisma ani Redis. Specyfikacja opisuje, co system robi z perspektywy użytkownika i firmy. Stos technologiczny pojawia się w następnej fazie.

Co Claude robi w fazie Plan?#

Gdy spec.md jest gotowy, uruchom:

/speckit-plan

Opcjonalnie możesz przekazać wskazówki dotyczące technologii bezpośrednio w poleceniu:

/speckit-plan Next.js App Router, Prisma, PostgreSQL, Resend for email

Claude odczytuje trzy źródła: twój spec.md, plik CLAUDE.md (lub memory/constitution.md) oraz istniejący kod w repozytorium. Wynikiem jest plan.md o strukturze mniej więcej takiej:

# Implementation Plan: User Registration

## Technical Context
- Framework: Next.js 14 App Router
- Database: PostgreSQL via Prisma
- Email: Resend (single transport)
- Validation: Zod schema in shared lib
- Auth: NextAuth.js with credentials provider

## Architecture Decisions

### 1. Token storage
Tokens stored in DB (table ConfirmationToken), not in JWT.
Reason: need server-side revoke on email re-register.

### 2. Email delivery
Async via cron `/api/cron/send-confirmation` triggered immediately
after registration. Retries handled by Resend.

### 3. Auto-delete cron
Run `/api/cron/cleanup-unconfirmed` every minute. Delete rows only where
created_at <= NOW() - INTERVAL '48 hours' AND email_verified_at IS NULL.
The clarified example allows at most 5 minutes of deletion delay.
Verify scheduler lag and completion time against that bound; report
a missed bound as a failure, not a successful daily cleanup.

## Data Model
See data-model.md

## API Contracts
See contracts/
- POST /api/auth/register
- POST /api/auth/confirm
- GET /api/auth/resend-confirmation

## Implementation Phases
1. Database migration (Prisma schema + migration file)
2. API routes (3 endpoints)
3. UI: registration form + confirmation success page
4. Cron jobs (send + cleanup)
5. Email template
6. Integration tests

data-model.md będzie opisywać encje i ich relacje. Folder contracts/ będzie zawierał szablony kontraktów API (albo YAML OpenAPI, albo typy żądań i odpowiedzi TypeScript). To nie jest kod — to założenia, które Claude później przełoży na rzeczywiste trasy.

Główna zaleta fazy Plan to czysty kontekst. Claude nie próbuje jednocześnie pamiętać specyfikacji i implementacji. Najpierw wszystko analizuje, zapisuje decyzje w pliku, a dopiero potem przechodzi dalej.

Następne jest opcjonalne polecenie /speckit-analyze. Uruchamia się je po fazie Tasks i przed Implement: analizuje zestaw spec.md + plan.md + tasks.md w poszukiwaniu sprzeczności oraz sprawdza, czy plan i zadania pokrywają wszystkie wymagania specyfikacji. Nie edytuje plików, tylko generuje raport. To formalne sprawdzenie poprawności przed implementacją.

Jak podzielić pracę na zadania (Tasks)#

Gdy masz już spec.md i plan.md, uruchom:

/speckit-tasks

Claude rozwija plan w plik tasks.md:

# Tasks: User Registration

## Phase 1: Database (no dependencies)
- [ ] T-001: Add User model to prisma/schema.prisma (parallel-safe)
- [ ] T-002: Add ConfirmationToken model to prisma/schema.prisma (after T-001)
- [ ] T-003: Generate migration `add-user-registration` (after T-002)

## Phase 2: API contracts (no dependencies)
- [ ] T-004: Create Zod schemas in shared/validation/auth.ts
- [ ] T-005: Define TypeScript types in shared/types/auth.ts (after T-004)

## Phase 3: Routes (depends on Phase 1+2)
- [ ] T-006: Implement POST /api/auth/register
- [ ] T-007: Implement POST /api/auth/confirm
- [ ] T-008: Implement GET /api/auth/resend-confirmation

## Phase 4: UI (parallel with Phase 3)
- [ ] T-009: Build /register page with form
- [ ] T-010: Build /register/confirm/[token] page
- [ ] T-011: Build /register/success page

## Phase 5: Cron + integration (depends on Phase 3+4)
- [ ] T-012: Cron /api/cron/send-confirmation
- [ ] T-013: Cron /api/cron/cleanup-unconfirmed
- [ ] T-014: Email template registration-confirmation.tsx
- [ ] T-015: Integration tests (Playwright), including cleanup just
  before 48h, exactly at 48h, deletion by 48h 5m, delayed-job failure,
  and protection of confirmed accounts

## Notes
- T-001, T-004, T-009-T-011 are parallel-safe (different files)
- T-002 conflicts with T-001 (same file: schema.prisma) - run sequentially
- T-006 needs T-003 (migration applied) and T-005 (types)

Zwróć uwagę na oznaczenia parallel-safe i after T-NNN. Tworzą one graf zależności, który później pozwala uruchamiać kilka faz równolegle. Cała metoda przyspieszania pracy przez Spec Kit opiera się na tym mechanizmie: część zadań można powierzyć pięciu różnym sesjom Claude Code jednocześnie, a inne muszą być ściśle sekwencyjne.

Spec Kit robi to automatycznie za pomocą jednego polecenia, od razu po instalacji.

Opcjonalne polecenie /speckit-taskstoissues bierze tasks.md i tworzy z jego listy GitHub Issues, z których każdy zawiera odnośnik do spec.md. Przydaje się to w pracy zespołowej albo do śledzenia postępów w GitHub Projects.

Jak wdrożyć rozwiązanie z użyciem subagentów (Implement)#

/speckit-implement

Claude zaczyna od pierwszego zadania w tasks.md. Każde zadanie przechodzi krótki cykl: odczytaj odpowiednie pliki, przygotuj diff, uruchom testy, zaznacz [x]. W razie potrzeby automatycznie uruchamiani są subagenci: osobny do przeglądu kodu, osobny do uruchomienia lintera i osobny do sprawdzenia regresji.

Osobno, o zasadach:

W Spec Kit ten cykl jest sformalizowany. Masz spec.md jako źródło prawdy, plan.md z decyzjami technicznymi i tasks.md w formie listy kontrolnej. Jeśli Claude zboczy z kursu na którymkolwiek etapie, wracasz do specyfikacji i mówisz: „To nie pasuje do FR-003; zrób ponownie”. Nie musisz tworzyć długich promptów w rodzaju „pamiętaj, o czym rozmawialiśmy...” — cała historia jest w plikach.

Jeśli masz skonfigurowane Dynamic Workflows w Opus 4.8, możesz w pełni zautomatyzować działanie Spec Kit: jedno polecenie /speckit-implement, a Claude równolegle realizuje zadania, łączy wyniki i je sprawdza. Limit wynosi 1000 subagentów naraz. W przypadku większości funkcji wystarczy 10-30.

Gdy wszystkie pola [x] są zaznaczone, a kontrola w następnej sekcji zwraca „Converged”, sprawdź PR (lub serię PR-ów, jeśli zadań jest dużo) i go scal. Artefakty — spec.md, plan.md, tasks.md — pozostają w repozytorium jako dokumentacja funkcji. Rok później nie będziesz musiał odtwarzać logiki na podstawie kodu.

Jak sprawdzić, czy agent niczego nie pominął (Converge)#

/speckit-converge

Najpierw agent podsumowuje ustalenia, przypisując im poziomy ważności, a następnie przedstawia jeden z dwóch wyników. „Converged” oznacza, że nie ma braków, plik tasks.md nie zmienił się ani o bajt i można przejść do przeglądu. „Tasks appended” oznacza, że wykryto braki, dodano je do sekcji Convergence w tasks.md, a agent informuje, ile ich jest.

Converge nie edytuje ani nie usuwa kodu; zapisuje wyłącznie nowe zadania w tasks.md. Możesz więc uruchomić je bez obaw, ale dopiero po tym, jak /speckit-implement zrealizuje bieżącą zawartość tasks.md. Każdy kolejny przebieg wykrywa coraz mniej braków.

Czym Spec Kit różni się od CLAUDE.md i Plan Mode?#

Porównajmy je pod kątem 5 cech:

W terminologii Spec Kit jest to .specify/memory/constitution.md. Podczas inicjalizacji Spec Kit może wykorzystać istniejący plik CLAUDE.md jako podstawę constitution albo utworzyć obok niego osobny plik. Zwykle zostawiam CLAUDE.md jako globalną „umowę” (stos, słownik, protokół wdrażania), a constitution Spec Kit wykorzystuję do zasad właściwych dla danego cyklu pracy — na przykład „wszystkie formularze są walidowane przez Zod; bez ręcznych sprawdzeń”.

Powiązanie z Plan Mode jest prostsze. Plan Mode to szybki tryb „zaplanuj przed napisaniem kodu” w ramach jednej sesji. Sprawdza się przy małych zmianach (naprawie błędu, refaktoryzacji funkcji). W przypadku dużej funkcji Plan Mode przegrywa, bo okno kontekstu jednej sesji jest za małe na plan liczący 3000 wierszy — wyjaśniam to bezpośrednio podczas transmisji na żywo:

Spec Kit to konkretne narzędzie do inżynierii kontekstu. Przenosi „obrus architektury” z czatu do plików. Spec.md pozostaje w repozytorium, a każda nowa sesja Claude ponownie go odczytuje — nie musisz powtarzać tych samych informacji.

Konfiguracja dużego projektu:

1. CLAUDE.md — stos, słownik i rzeczy, których nie należy robić. Plik znajduje się w katalogu głównym.
2. .specify/memory/constitution.md w Spec Kit — zasady dotyczące tego cyklu pracy.
3. specs/001-feature-A/spec.md, plan.md, tasks.md — pierwsza funkcja.
4. specs/002-feature-B/spec.md, plan.md, tasks.md — druga funkcja.
5. Do codziennej pracy używaj /speckit-implement (dla gotowych zadań) albo /plan (do szybkiego sprawdzenia przed zmianą).

Które przypadki zastosowania sprawdzają się w praktyce?#

Konkretne przypadki:

• AWS Kiro — agent do odkrywania leków. W artykule na blogu AWS Industries z 18 lutego 2026 roku zespół opisuje projekt TargetID. Trzech programistów, trzy tygodnie, agent do odkrywania leków. Dane podane w artykule: Kiro wygenerowało ponad 95% kodu logiki biznesowej, oszczędzając ponad 80 godzin pracy programistycznej. Ponadto: „dokumentacja README napisana przez Kiro pozwoliła zaoszczędzić szacunkowo 8 godzin” i „zmniejszyła liczbę iteracyjnych cykli prompt-poprawka o 40%”.
• Rackspace Technology. W tym samym artykule AWS firma Rackspace informuje: „zrealizowaliśmy 52 tygodnie szacowanej pracy w zaledwie 3 tygodnie”, „wzrost wydajności o 90%”. To już nie jest mała funkcja — to pełny projekt korporacyjny.
• Rozwój GitHub Spec Kit. Według stanu na 31 maja 2026 roku repozytorium miało 107 000 gwiazdek.

Dla czytelnika oznacza to, że to podejście nie jest teorią: poważne zespoły już stosują je w środowisku produkcyjnym.

Kiedy Spec Kit NIE jest odpowiedni?#

Nie nadaje się nr 1 — drobne poprawki. Jeśli zadanie polega na „zmianie nazwy zmiennej”, „poprawieniu literówki w tekście” albo „dodaniu logu”, przejście przez Specify → Plan → Tasks zajmie więcej czasu niż sama edycja. Przy drobnych poprawkach szybszy jest Plan Mode albo po prostu bezpośrednie polecenie w Claude Code.

Nie nadaje się nr 2 — eksperymenty na żywo. Gdy jeszcze nie wiesz, czego chcesz, i musisz „poklikać” w interfejsie albo szybko złożyć prototyp, by zobaczyć, „czy zaskoczy”, specyfikacja nie ma sensu. Wartość tkwi właśnie w improwizacji. Na poziomie „zabawy pomysłem” działa właśnie vibe, a nie specyfikacja.

Nie nadaje się nr 3 — starszy kod ze złożonym stanem. Rzeczywistość zmienia się szybciej niż specyfikacje. Jako przykład można podać rozliczanie subskrypcji: zespół opisał cykle rozliczeniowe i zasady podatkowe, a tydzień później dział finansowy poprosił o europejski VAT — specyfikacja zdezaktualizowała się jeszcze przed wydaniem. Gdy logika biznesowa szybko się zmienia, utrzymywanie specyfikacji staje się obciążeniem.

Dodatkowym ryzykiem jest fałszywe poczucie kontroli. Artykuł Martina Fowlera analizuje ten problem: struktury są eleganckie, ale agenci często ignorują instrukcje albo, przeciwnie, zbyt dosłownie stosują szablony. Wynikiem jest kod poprawny strukturalnie, ale niedopasowany do konkretnego repozytorium — specyfikacja nie gwarantuje, że agent zrozumiał ją zgodnie z twoją intencją.

W kwietniu 2026 roku analitycy branżowi ostrzegali przed modelem kaskadowym: pisanie obszernej specyfikacji przed kodowaniem to droga, która już raz doprowadziła branżę do porażki, w czasach 200-stronicowych wymagań. Od tamtej pory inżynierowie podchodzą do tego sposobu pracy ostrożnie i słusznie.

Co z tym zrobić? Proponuję prostą zasadę: wielkość funkcji w stosunku do czasu potrzebnego na napisanie specyfikacji. Jeśli implementacja funkcji zajmie mniej niż 2 godziny, nie pisz specyfikacji — szybszy będzie Plan Mode. Jeśli funkcja zajmie tydzień, zdecydowanie użyj Spec Kit; oszczędność czasu pięciokrotnie zwróci godzinę poświęconą na specyfikację. Między 2 godzinami a tygodniem zdecyduj samodzielnie. Ja osobiście piszę specyfikację nawet dla funkcji zajmujących pół dnia, bo artefakt w repozytorium jest wart więcej niż 30 zaoszczędzonych minut.

Co dalej: jak zintegrować Spec Kit z projektem?#

Konkretny plan na następne 7 dni:

• Dzień 1. Zainstaluj uv i Spec Kit (5-10 minut). Sprawdź, czy w Claude Code pojawiły się polecenia /speckit-*. Nie próbuj stosować ich w istniejącym projekcie — zacznij od nowego.
• Dzień 2. Wybierz prawdziwą funkcję, którą planujesz zbudować. Uruchom /speckit-specify z opisem w swobodnej formie. Otwórz spec.md, przeczytaj go i odpowiedz na każde pytanie oznaczone [NEEDS CLARIFICATION]. Nie przechodź zbyt szybko do Plan.
• Dzień 3. Uruchom /speckit-plan, podając wskazówki dotyczące stosu technologicznego. Przeczytaj plan.md, a zwłaszcza sekcję Architecture Decisions. Jeśli coś ci nie odpowiada, popraw plik ręcznie.
• Dzień 4-5. Uruchom /speckit-tasks, następnie /speckit-analyze, aby ponownie sprawdzić zestaw specyfikacji, planu i zadań, a potem /speckit-implement. Obserwuj, jak Claude zaznacza [x] w tasks.md. Może gdzieś utknąć — to normalne. Wróć do spec.md, doprecyzuj wymaganie i ponownie uruchom /speckit-implement z konkretnym zadaniem. Gdy zadania będą zamknięte, uruchom /speckit-converge i powtarzaj sekwencję Implement i Converge, aż otrzymasz odpowiedź „Converged”.
• Dzień 6-7. Sprawdź PR (lub serię PR-ów). Scal go. Przeczytaj spec.md i plan.md — będą dokumentacją funkcji na nadchodzący rok.

Co warto czytać równolegle:

• Jak skonfigurować CLAUDE.md w 2026 roku — podstawa constitution w Spec Kit.
• Plan Mode w Claude Code — szybka alternatywa dla małych zadań.
• Inżynieria kontekstu w 2026 roku — dlaczego Spec Kit w ogóle działa.
• Skills, Subagents, MCP czy Plugins — co dodać do Spec Kit, aby dopasować go do swojego sposobu pracy.
• Dynamic Workflows w Claude Code — jak uruchomić wielu subagentów naraz na etapie Implement.

Pełny cykl pracy z kontekstem: klon AI + Second Brain + inżynieria kontekstu.

Więcej materiałów znajdziesz na Ailoot.