{dev} forge: OpenSpec, czyli jak nadać Spec-Driven Development realny kształt

Skoro w poprzednim wpisie z cyklu {dev} forge – How software is forged with AI ustaliliśmy, że Spec-Driven Development jest nowoczesnym, AI-powered potomkiem V-Modelu, wzbogaconym o BDD i Specification by Example, to naturalnie pojawia się kolejne pytanie: jak to robić w praktyce?

I tutaj na scenę wchodzi OpenSpec – otwarte, lekkie podejście i zestaw narzędzi, których celem jest uporządkowanie współpracy człowieka z AI coding assistantem wokół specyfikacji. Oficjalny opis projektu mówi wprost, że chodzi o uzgodnienie co budujemy, zanim powstanie kod. To bardzo zdrowy kierunek, szczególnie dziś, gdy modele potrafią generować kod szybko, ale nadal nie czytają w myślach. OpenSpec jest opisywany jako lekki, open-source’owy framework spec-driven dla coding agentów i CLI, bez konieczności używania API keys czy MCP. 

Dlaczego OpenSpec jest ciekawy?

Najbardziej podoba mi się to, że OpenSpec nie próbuje sprzedać kolejnej magicznej obietnicy pod tytułem „AI zrobi software za Ciebie”. Zamiast tego projekt wychodzi od znacznie dojrzalszego założenia: AI jest skuteczne wtedy, gdy ma dobre wejście. A najlepszym wejściem nie jest przypadkowy prompt wrzucony do czatu, tylko sensownie przygotowana specyfikacja.

Twórcy OpenSpec trafnie zauważają, że asystenci kodujący bywają potężni, ale nieprzewidywalni, gdy wymagania żyją wyłącznie w historii rozmowy. OpenSpec dodaje więc lekką warstwę specyfikacji, która porządkuje uzgodnienia przed implementacją. To nie jest tylko techniczny detal. To w praktyce próba zamiany AI z „generatora zgadującego kontekst” w wykonawcę pracującego na bardziej stabilnym kontrakcie. 

OpenSpec jako brakujący pomost między teorią a codziennym developmentem

Wiele rozmów o Spec-Driven Development kończy się na poziomie idei. Mówimy, że warto mieć specyfikację. Że dobrze byłoby powiązać ją z testami. Że AI powinno dostać jasne zasady. I wszystko to jest prawdą. Problem pojawia się wtedy, gdy zespół pyta: dobrze, ale jak dokładnie to wdrożyć do repozytorium i codziennej pracy?

OpenSpec próbuje odpowiedzieć właśnie na to pytanie. Nie buduje zamkniętego ekosystemu ani nie uzależnia całego procesu od jednego vendora. Zamiast tego daje prosty workflow, który można potraktować jako szkic operacyjny dla pracy spec-driven.

Z dokumentacji projektu wynika, że domyślna szybka ścieżka opiera się na trzech krokach: propose → apply → archive. Najpierw proponujemy zmianę, potem ją wdrażamy, a na końcu archiwizujemy i domykamy ślad tej decyzji. To banalnie proste, ale właśnie w tej prostocie tkwi siła.

Jak rozumiem filozofię OpenSpec?

Dla mnie OpenSpec jest interesujące nie dlatego, że „wymyśla specyfikację od nowa”, tylko dlatego, że próbuje ją uczynić operacyjną. To ważna różnica.

Tradycyjnie specyfikacja bywała dokumentem wejściowym do projektu. Potem żyła własnym życiem, a kod i tak skręcał w inną stronę. W bardziej zwinnym świecie często z kolei rezygnowaliśmy z precyzji na rzecz szybkich ustaleń i ticketów, które rozumiały głównie osoby aktualnie siedzące w kontekście. OpenSpec wygląda jak próba znalezienia środka: spec ma być lekki, praktyczny i blisko implementacji, ale jednocześnie wystarczająco formalny, żeby człowiek i AI mogli pracować na tych samych założeniach.

To podejście dobrze wpisuje się w to, jak ja patrzę na ewolucję developmentu. Najpierw mieliśmy cięższe modele procesowe, które dobrze rozumiały wagę weryfikacji. Potem przyszły BDD i Specification by Example, które nauczyły nas mówić o systemie językiem zachowań i przykładów. Teraz dochodzi AI, które wymusza jeszcze większą precyzję, bo każda luka w założeniach bardzo szybko zamienia się w błędną implementację. OpenSpec jest więc dla mnie nie tyle rewolucją, co dobrze nazwanym etapem dojrzewania praktyk inżynierskich.

Co konkretnie wyróżnia OpenSpec?

Na stronie projektu OpenSpec jest przedstawiany jako framework universal, open source, bez API keys i bez MCP. To jest istotne z kilku powodów. Po pierwsze, obniża próg wejścia. Po drugie, pozwala myśleć o nim bardziej jak o metodzie pracy niż o kolejnym płatnym produkcie. Po trzecie, dobrze pasuje do realiów zespołów, które chcą testować podejście spec-driven bez przepisywania całego stacku narzędziowego. 

Repozytorium i changelog pokazują też, że projekt jest aktywnie rozwijany. Na dziś publicznie widoczna wersja pakietu to 1.2.0, a w ostatnich zmianach pojawiały się między innymi profile instalacyjne, możliwość tworzenia kompletnych propozycji zmian w jednym kroku oraz rozszerzenia wsparcia dla kolejnych agentów. Changelog wspomina też o konfigurowalnych schematach workflow w katalogu openspec/schemas/, które można współdzielić przez repozytorium. To akurat bardzo ciekawy trop dla zespołów, które chcą mieć własny, powtarzalny sposób opisywania zmian. 

Dlaczego ten projekt ma sens właśnie teraz?

Bo jesteśmy w bardzo specyficznym momencie rynku. Z jednej strony mamy ogromny entuzjazm wobec AI coding assistants. Z drugiej – coraz więcej zespołów zaczyna widzieć, że samo „kodowanie z prompta” nie skaluje się dobrze w większych inicjatywach.

Na początku wszystko wygląda świetnie. Agent szybko wygeneruje komponent, endpoint, test albo migrację. Potem jednak zaczynają się schody: brak spójności między modułami, różne interpretacje tych samych reguł biznesowych, niespójne nazewnictwo, rozjazdy między dokumentacją a kodem, niejasne decyzje architektoniczne. Innymi słowy: dokładnie te same problemy co dawniej, tylko dostarczane szybciej.

OpenSpec trafia więc w bardzo realną potrzebę: jak sprawić, żeby szybkość AI nie rozwalała jakości i przewidywalności delivery? Odpowiedź brzmi: przez lepsze, bardziej strukturalne uzgadnianie zmian.

OpenSpec a BDD, ADR i dokumentacja architektoniczna

To, co szczególnie warto podkreślić, to fakt, że OpenSpec nie powinien być traktowany jako konkurencja dla innych praktyk inżynierskich. Moim zdaniem największy sens ma wtedy, gdy działa jako warstwa spinająca kilka światów naraz.

Z BDD łączy go myślenie o zachowaniach i o tym, że system trzeba opisać przez oczekiwane rezultaty. Z ADR-ami łączy go potrzeba utrwalenia decyzji, które wpływają na sposób implementacji. Z dokumentacją architektoniczną łączy go to, że specyfikacja nie dotyczy tylko funkcji, ale też granic, zależności i ograniczeń.

W praktyce wyobrażam sobie bardzo sensowny model pracy: biznes i analityk definiują intencję zmiany, BDD doprecyzowuje zachowanie, ADR utrwala decyzje techniczne, a OpenSpec spina to w workflow, który staje się wejściem dla człowieka i AI. W takim układzie spec przestaje być pojedynczym dokumentem. Staje się zestawem powiązanych artefaktów, które razem prowadzą implementację.

Najciekawsza lekcja z OpenSpec: spec jako aktywny artefakt

Jeśli miałbym wyciągnąć z OpenSpec jedną najważniejszą lekcję, to byłaby nią zmiana sposobu myślenia o specyfikacji. Nie jako o obowiązkowym załączniku do projektu. Nie jako o slajdach do governance. Nie jako o „analizie, którą ktoś gdzieś napisał”.

Spec w tym podejściu jest aktywnym artefaktem delivery. Czymś, co ma realny wpływ na to, co zostanie zbudowane i jak będzie weryfikowane. To jest bardzo zdrowe przesunięcie. Szczególnie dla zespołów technicznych, które przez lata często traktowały dokumentację jako przykry obowiązek, bo dokumenty faktycznie nie brały udziału w pracy wytwórczej.

W świecie AI to się zmienia. Dobrze przygotowany spec staje się wejściem dla generatorów kodu, testów, opisów zmian, a czasem nawet dokumentacji. To sprawia, że jego jakość zaczyna mieć bezpośredni wpływ na koszt, szybkość i ryzyko projektu.

Czy OpenSpec rozwiązuje wszystko?

Nie. I to akurat dobra wiadomość, bo narzędzia, które obiecują rozwiązanie wszystkiego, zwykle robią jedną rzecz dobrze: marketing.

OpenSpec nie zwalnia zespołu z myślenia. Nie napisze za nas sensownej domeny. Nie podejmie wszystkich decyzji architektonicznych. Nie zamieni słabego backlogu w świetny produkt. Ale wygląda na bardzo sensowny mechanizm, który może poprawić jakość współpracy między ludźmi, dokumentacją i AI assistantami.

To trochę jak z dobrym szablonem ADR albo dobrze użytym Gherkinem. Sam szablon nie gwarantuje jakości, ale potrafi bardzo pomóc w uporządkowaniu myślenia i ograniczeniu chaosu. OpenSpec wydaje się właśnie takim rodzajem narzędzia – wzmacnia praktykę, jeśli zespół naprawdę chce pracować świadomie.

Gdzie widzę dla niego najlepsze zastosowania?

Największy potencjał widzę w kilku sytuacjach.

Po pierwsze, w zespołach, które już korzystają z AI coding assistants, ale zaczynają odczuwać koszt niejednoznaczności. Po drugie, w projektach z istotną logiką biznesową, gdzie liczą się reguły, wyjątki i traceability. Po trzecie, w środowiskach, gdzie chcemy połączyć specyfikację funkcjonalną, decyzje techniczne i automatyzację jakości bez wchodzenia w zbyt ciężki proces.

Szczególnie dobrze wygląda to dla organizacji, które chcą tworzyć własne standardy pracy z AI. Changelog sugeruje możliwość definiowania własnych schematów workflow, a to oznacza, że OpenSpec może być nie tylko narzędziem do pracy indywidualnej, ale też bazą pod wewnętrzny operating model dla AI-assisted development. 

Moja opinia na dziś

Patrzę na OpenSpec jak na jeden z najciekawszych praktycznych sygnałów, że Spec-Driven Development zaczyna wychodzić poza poziom hasła. Projekt jest spójny z realnym problemem rynku, ma jasną filozofię i nie próbuje udawać, że sama obecność AI zwalnia nas z dyscypliny inżynierskiej.

To, co najbardziej kupuję, to nacisk na uzgadnianie tego, co budujemy przed napisaniem kodu. Brzmi banalnie? Oczywiście. A jednak właśnie ten banał jest dziś nagminnie pomijany, bo wszyscy zachwycili się szybkością generowania implementacji.

Moim zdaniem OpenSpec jest wartościowe nie dlatego, że daje kolejny CLI, ale dlatego, że przypomina o czymś fundamentalnym: software nadal trzeba świadomie projektować, nawet jeśli znaczną część kodu generuje AI.

Podsumowanie

Jeśli poprzedni artykuł z cyklu {dev} forge – How software is forged with AI był próbą pokazania, skąd wzięło się Spec-Driven Development, to ten wpis pokazuje pierwszy konkretny przykład narzędziowego ucieleśnienia tej idei.

OpenSpec to lekki, otwarty framework dla spec-driven development, który porządkuje współpracę z AI coding assistantami wokół specyfikacji, zamiast opierać wszystko na ulotnym kontekście rozmowy. Bazuje na prostym workflow typu propose → apply → archive, jest open source, nie wymaga API keys ani MCP, i aktywnie się rozwija. 

I to właśnie dlatego uważam, że warto go obserwować. Nie jako cudowną receptę na cały software engineering, ale jako bardzo sensowny krok w kierunku bardziej świadomego, przewidywalnego i spec-driven wytwarzania oprogramowania z udziałem AI.

Źródło 
Źródło