Spec-driven development w 2026 — proces, narzędzia i kiedy się opłaca
Spec-driven development to praca, w której przed dopuszczeniem agenta AI do kodu powstaje przejrzana specyfikacja: co się zmienia, których plików wolno dotknąć i które testy muszą przejść. Agent implementuje według tego kontraktu. Podejście powstało w 2025 roku jako odpowiedź na kod AI dryfujący od intencji.
Dlaczego same prompty przestały wystarczać
Otwarte promptowanie zawodzi w przewidywalny sposób: agent generuje wiarygodnie wyglądający kod, który dryfuje od intencji, wymyśla nieistniejące API i po cichu przepisuje rzeczy, o które nikt nie prosił. W małym projekcie łapie się to czytając diff. Powyżej pewnej skali nikt nie czyta całego diffa — i baza kodu psuje się jedną pewną siebie zmianą na raz.
Spec-driven development to odpowiedź branży, która w 2026 roku przestała być opcjonalna: GitHub, AWS, Anthropic, Cursor i Google mają już własne warianty. Specyfikacja przestała być dokumentacją pisaną po fakcie — jest wejściem, według którego agent wykonuje zmianę, i wzorcem, względem którego sprawdza się wynik.
Proces krok po kroku
- Specyfikacja — zapisz, co się zmienia i po co: zachowanie widoczne dla użytkownika, ograniczenia, rzeczy poza zakresem. To jest teraz właściwa praca inżynierska.
- Plan — agent (lub Ty) wyprowadza plan techniczny: pliki do zmiany, kolejność, ryzyka. Przejrzyj go, zanim powstanie jakikolwiek kod.
- Zadania — podziel plan na małe, niezależnie weryfikowalne kroki zamiast jednego wielkiego wygenerowanego diffa.
- Implementacja — agent wykonuje zadanie po zadaniu, w granicach plików dopuszczonych przez specyfikację.
- Weryfikacja — testy wyprowadzone ze specyfikacji blokują scalenie. Jeśli zestaw nie failuje przy zepsutej funkcji, specyfikacja była za mało konkretna.
Krajobraz narzędzi
Narzędzia różnią się głównie tym, gdzie żyje specyfikacja i ile ceremonii narzucają.
| Narzędzie | Postać | Najlepiej pasuje do |
|---|---|---|
| GitHub Spec Kit | Open-source’owe CLI, ponad 93 tys. gwiazdek, działa z 30+ agentami | Zespołów, które chcą standardu niezależnego od dostawcy |
| AWS Kiro | Pełne IDE sterowane specyfikacją: wymagania, historyjki, pliki sterujące | Organizacji standaryzujących się na jednym środowisku |
| OpenSpec | Proces zmian oparty na propozycjach z jawnymi znacznikami delt | Istniejących baz kodu i audytowanego zarządzania zmianą |
| BMAD | Metodyka i role nakładane na dowolnego agenta | Zespołów, które chcą procesu bez zmiany narzędzi |
| Tryby natywne (Claude Code, Cursor) | Tryb planu lub specyfikacji wbudowany w samego agenta | Solistów i małych zespołów, które już w nich pracują |
Czy ta ceremonia się zwraca?
Pisanie specyfikacji pierwszego dnia wydaje się wolniejsze. Zwrot przychodzi, gdy agent po raz pierwszy wykonuje zmianę w wielu plikach, a testy przechodzą — bo specyfikacja zmusiła do zdefiniowania, co znaczy „przechodzą”. Zespoły, którym kodowanie z AI utrzymało się na produkcji, opisują konsekwentnie te same trzy mechanizmy: specyfikacja na każdą zmianę, testy blokujące pipeline i ludzki przegląd decyzji architektonicznych.
Uczciwy kontrapunkt: dla jednorazowego prototypu specyfikacja to narzut. Umiejętnością jest wiedzieć, w którym trybie się pracuje — i przełączać się świadomie, zamiast pozwalać, by nawyki z prototypowania przeciekły do pracy produkcyjnej.
Specyfikacje działają najlepiej, gdy nie zaczynasz od zera
Specyfikację opisującą, jak ma się zmienić istniejący, działający system, pisze się nieporównanie łatwiej niż taką, która opisuje cały system od podstaw. To cichy argument za budowaniem na open source: fork projektu, który rozwiązuje sąsiedni problem, kurczy specyfikacje do samych delt.
Katalog RepoLoot istnieje dokładnie dla tego pierwszego kroku — 491 projektów opisanych przez to, co robią, co da się na nich zbudować, jaką mają licencję i jak trudne jest pierwsze wdrożenie. Dzięki temu specyfikacja dotyczy Twojej delty, a nie cudzej architektury.
Najczęstsze pytania
- Co to jest spec-driven development?
- Proces, w którym przed napisaniem kodu przez agenta AI powstaje pisemna, przejrzana specyfikacja — zachowanie, zakres, ograniczenia i testy akceptacyjne — a implementacja jest weryfikowana względem niej. Specyfikacja jest wejściem wykonywanym przez agenta, nie dokumentacją pisaną po fakcie.
- Czym spec-driven development różni się od vibe codingu?
- Vibe coding zaczyna od otwartego promptu i ocenia wynik na wyczucie. Spec-driven development przenosi myślenie na początek: specyfikacja określa, co wolno zmienić i co musi przejść przed scaleniem. Podejście powstało właśnie dlatego, że kod z vibe codingu dryfował od intencji w miarę wzrostu projektu.
- Jakie są główne narzędzia spec-driven development w 2026?
- GitHub Spec Kit (open-source’owe CLI współpracujące z ponad 30 agentami), AWS Kiro (IDE sterowane specyfikacją), OpenSpec (propozycje zmian z jawnymi deltami, pod istniejące bazy kodu), BMAD (warstwa metodyki) oraz natywne tryby planowania w Claude Code i Cursorze. Różnią się głównie ceremonią i miejscem, gdzie żyje specyfikacja.
- Czy spec-driven development opłaca się solistom?
- Tak, w lżejszej formie. Nawet półstronicowa specyfikacja z jawnym zakresem plików i listą testów wyłapuje większość dryfu agenta. Pełną ceremonię zostaw na zmiany produkcyjne, a przy jednorazowych prototypach pomijaj ją świadomie, nie z rozpędu.