Spec-Driven Development: GitHub Spec Kit i OpenSpec w Praktyce

Witamy bardzo serdecznie w serii Data Zen AI Podcast. Przygotowaliśmy dzisiaj dla naszych słuchaczy kolejną wnikliwą analizę. Cześć, witam wszystkich. Temat mamy dzisiaj naprawdę mocny, bo dotyka samych fundamentów tego, jak pracujemy. Dokładnie. Chciałabym zacząć od takiego dość prowokacyjnego pytania. A co jeśli to już wcale nie kod jest najważniejszy w pracy programisty, a jedynym, powiedzmy, ostatecznym źródłem prawdy staje się nagle specyfikacja? No to jest wywrotowa myśl, wiesz, zwłaszcza dla inżynierów. Właśnie. I żeby to dobrze zrozumieć, zrobimy dzisiaj taki głęboki przegląd najnowszych materiałów. Co tam mamy na stole? Mamy sporo ciekawych rzeczy. Opieramy się na przemyśleniach takich branżowych wyjadaczy jak Adios Mani czy Kent Beck.

Do tego analizujemy dokumentację narzędzi, konkretnie GitHub Spec Kit i OpenSpec. No i zaglądamy na blogi inżynieryjne zespołów takich jak xCapit czy teksty Allegorazy. Jasne. No i oczywiście nie mogło zabraknąć najświeższych publikacji naukowych z Archive o inżynierii oprogramowania w erze AI. Super zestawienie. A cel naszej dzisiejszej dyskusji jest dość prosty, w sensie chcemy zrozumieć, czym jest to całe Spec-Driven Development, w skrócie SDD, jak to się ma do tradycyjnego cyklu życia oprogramowania i do tego chaosu, który teraz obserwujemy, tak zwanego vibe coding. O tak, vibe coding to jest teraz bardzo modne hasło. No i przede wszystkim, kiedy wdrażanie tego całego SDD ma sens?

To może zacznijmy od początku. Co to jest ten vibe coding? Wiesz co, to jest to, co pewnie większość z nas robi na co dzień, z czatami AI. Otwierasz clouda albo copilota, wrzucasz luźny prompt typu napisz mi logowanie przez Google i tak zwanym fuksem liczysz na cud. No i czasami działa. Czasami działa, ale często system zmyśla biblioteki, których w ogóle nie ma albo niszczy architekturę gdzieś trzy pliki dalej, bo nie widzi szerszego kontekstu. To jest pisanie na wyczucie, na vibe. To znaczy, w tradycyjnym modelu, w takim tradycyjnym SDLC, kod to był ten absolutny król, prawda? Tak. Kod był na piedestale. Mieliśmy te gigantyczne, nudne dokumenty na Confluence, które de facto szły do kosza w momencie napisania pierwszej linijki kodu.

Jak coś nie działało, łataliśmy kod. A to nowe podejście, to Spec-Driven Development, to jest jakby całkowite odwrócenie ról. Zgadza się. Tutaj specyfikacje stają się, wiesz, plikami wykonywalnymi. Kod służy specyfikacji, a nie na odwrót. To AI pisze kod na podstawie bardzo ścisłych reguł. Czekaj, bo Ali Raza użył tutaj świetnego porównania. To jest tak, jakbyś nie powiedział wykonawcy na budowie, wiesz, masz tu cegły, zbuduj mi jakiś dom i jakoś to ogarniesz. No to by się zawaliło. Dokładnie, tylko wręczasz mu precyzyjne, cyfrowe plany architektoniczne. Ale tu od razu muszę o coś zapytać, bo skoro wrzucimy sztucznej inteligencji, powiedzmy 10 stron gęstych zasad, to czy ona tego po prostu nie zignoruje?

I tu dotykasz sedna problemu, o którym pisze Ady Osmani. Naukowcy nazywają to klątwą instrukcji. Im więcej wrzucisz do jednego promptu, tym szybciej model głupieje. Aha, czyli ma taką swoją ograniczoną pojemność uwagi. Tak, modele LLM skupiają się na początku i na końcu, a ten środek, te wszystkie biznesowe niuanse po prostu wyparowują. Dlatego wcale nie chodzi o to, żeby wrzucić AI gigantyczny dokument w formacie Worda. SDD to wymuszenie struktury i dzielenie pracy na małe, odizolowane kroki. Jasne. I skoro już wiemy, że ta struktura jest nam absolutnie niezbędna, żeby w ogóle zapanować nad tym modelem, to weźmy na tapetę konkretne narzędzia.

Mamy GitHub Spec Kit z jednej strony i OpenSpec Kit z drugiej. Zgadza się, to są dwa różne światy w sumie. Zacznijmy od Spec Kita. Z tego co czytałam, to jest taki bardzo rygorystyczny framework oparty na wierszu poleceń, prawda? Tak, on wręcz prowadzi agenta AI, na przykład takiego Cloud Code jak zarączkę. Nie ma tam miejsca na samowolkę. Masz cztery sztywne fazy odpalane specjalnymi komendami. No właśnie, najpierw jest komenda specify, czyli takie zdefiniowanie co i dlaczego budujemy. Wiesz, z perspektywy użytkownika, potem jest planowanie techniczne, to chyba plan? Tak, spec-hit plan. Tutaj model wybiera stos technologiczny. O, a potem moja ulubiona część, faza zadań z PetKit Tasks.

Agent rozbija ten wielki plan na malutkie, izolowane zadania. To jest takie test-driven development, ale dla AI. Dokładnie, a na końcu dopiero wjeżdża implement, czyli samo kodowanie i weryfikacja kodu krok po kroku. Ale wiesz, co jest w dokumentacji Spec-Kita absolutnie kluczowe? Ta faza zerowa. Właśnie. Konstytucja projektu. To jest coś niesamowitego. Tworzysz plik spec-kit.constitution, w którym określasz absolutnie niezmienny DNA architektury i zasady. Agent w każdej fazie musi się do tego odnosić. No tak, czyli takie zasady, których nie wolno mu złamać pod żadnym pozorem. Ale powiedzmy sobie szczerze, to brzmi jak rozwiązanie idealne dla projektów typu Greenfield, czyli jak budujemy coś od zera, prawda?

Tak, w korporacjach, gdzie masz rygor i audyty, to jest bajka. No właśnie, a co jeśli wchodzimy do projektu, który ma już 10 lat? Mamy, wiesz, starego, dobrego monolita. Tu Spec Kit chyba polegnie. I tu na białym koniu wjeżdża OpenSpec. On proponuje dużo lżejszą formę, taką elastyczną alternatywy. Zamiast budować wielką konstytucję, OpenSpec opiera się na tak zwanym ciągłym uzgadnianiu. Czyli jak to działa w praktyce? Możesz tam mechanizm Change Proposal. Zanim AI dotknie kodu, najpierw czyta to, co jest, generuje z tego specyfikację obecnego stanu, a potem ty proponujesz zmianę. Rozmawiacie o tym z agentem, on to planuje, wdraża i na końcu archiwizuje ten nowy wycinak do głównej specyfikacji. Aha, czyli on tak naprawdę świetnie sobie radzi z istniejącymi systemami, z tak zwanym brownfield.

Zależy od branży. Deepak Piskala fajnie to opisał w swoim artykule. Rozrysował takie trzy poziomy rygoru. Ten pierwszy, najluźniejszy, to spec-first. To chyba takie podejście, które stosuje większość z nas. Znaczy, używasz specyfikacji tylko na początku, żeby AI wygenerowało startowy kod. Tak. Dostajesz ten pierwszy zarys i tyle. AI zrobiło swoje, a potem kod znowu przejmuje stery, a specyfikacja ląduje w wirtualnym koszu. A ten drugi poziom? Drugi poziom jest znacznie ciekawszy. To Spec Anchored. Tu specyfikacja żyje razem z kodem. Są dosłownie zakotwiczone. Aha, czyli jeśli zmienię coś w kodzie, to muszę zaktualizować specyfikację? I na odwrót.

Dokładnie tak. No ale żeby nie było tak kolorowo, wiesz, entuzjasti agile wcale nie piją z zachwitu. Martin Fowler czy Kent Beck, oni mają tu sporo do powiedzenia. O tak, Kent Beck, twórca Extreme Programming, on uderza w sam rdzeń tego pomysłu. Dla niego założenie, że da się napisać pełną idealną specyfikację z góry, to jest wręcz absurd. No bo proces pisania kodu jest formą uczenia się, tak? Dokładnie. Beck mówi, że to właśnie kiedy próbujesz zaimplementować rozwiązanie, odkrywasz, że założenia biznesowe były błędne. AI powinno nam pomagać przyspieszać te iteracje, przyspieszać sprzężenie zwrotne. A my, pakując się w SSD, trochę zmuszamy się do powrotu do ery metodyki waterfall, gdzie robiliśmy dokumentację przez pół roku.

Właśnie, a z tym wiążą się konkretne pułapki podczas wdrażania. Jest takie zjawisko jak over-specification. To widać, kiedy deweloperzy zamiast pisać w specyfikacji, co chcą osiągnąć, zaczynają pisać rozwlekły pseudokod. O, to jest plaga. Tłumaczą modelowi jak ma działać, instrukcja po instrukcji. To całkowicie mija się z celem, bo przecież AI ma samo dobrać optymalne rozwiązanie, a my je w ten sposób blokujemy. Zgadza się. Kolejne zagrożenie to tzw. specification rot, czyli po prostu gnicie specyfikacji. No tak, jeśli nie połączymy tego z ciągłą integracją, z automatycznymi testami. To specyfikacje znowu zaczną dryfować. Zrobisz małą poprawkę na produkcji, w kodzie, zapomnisz zaktualizować specyfikacji, no i po systemie.

Ale wiesz co mnie najbardziej przeraża? Takie fałszywe poczucie bezpieczeństwa. Bo AI wygeneruje Ci piękny, perfekcyjny pod kątem składni kod. Do całkowicie błędnej, głupiej specyfikacji biznesowej. To jest świetny punkt i to nas prowadzi do chyba najważniejszej myśli z najnowszych badań z Archive. Przez lata martwiliśmy się jak wygenerować kod. Dzisiaj kod stał się tanim, darmowym towarem. Generowanie już nie jest problemem. Nowym, absolutnie krytycznym, wąskim gardłem jest dzisiaj weryfikacja. Weryfikacja. Tak. Utrzymanie systemów zależy dzisiaj w 100% od procesów, które zbudujemy wokół sztucznej inteligencji, a nie od wielkości samego modelu LLM. To w sumie drastycznie zmienia rolę samego człowieka, prawda?

W jednym z artykułów, w tym od xCapit, fajnie to podsumowano. Nie powinniśmy zlecać sztucznej inteligencji logiki i krytycznych decyzji biznesowych. Zdecydowanie nie. Bo agent AI wyłapie Ci każdy możliwy kod błędu, napisze piękne testy, ale w sytuacji krytycznej to tylko żywy człowiek może podjąć decyzję, czy system powinien zastosować podejście fail open czy fail closed. Dokładnie. Czy w trakcie awarii pozwalamy na kontynuowanie operacji z ryzykiem błędu, czy tniemy wszystko zamykając system? AI nie weźmie odpowiedzialności za biznes. Ty jako człowiek stajesz się raczej weryfikatorem logiki, takim dyrygentem, a nie klepaczem kodu. Skoro nasza rola zmienia się aż tak bardzo, to czas może na małe podsumowanie dla naszych słuchaczy.

Czy w tej całej nowoczesnej ery AI my znów potrzebujemy wracać do specyfikacji? Wychodzi na to, że tak, ale już nie w formie martwych dokumentów na dysku, tylko jako żyjących, wykonywalnych kontraktów. Czyli to całe Spec-Driven Development wcale nie zastępuje kodowania, tylko je jakoś sensownie strukturyzuje i chroni nas przed halucynacjami tych modeli, tak? Nie dodajemy sobie biurokracji, tylko w końcu organizujemy wiedzę, która i tak zawsze musiała być w głowach zespołu. W punkt. To jest porządkowanie chaosu, w który sami się wpędziliśmy przez luźne prompty. Ale zostawmy na sam koniec taką jedną, bardzo prowokacyjną myśl. Bo jeśli naprawdę osiągniemy ten docelowy pojąg Spec-Source w zwykłych, codziennych aplikacjach...

No, to by była rewolucja. Jeśli przestaniemy w ogóle czytać wygenerowany kod, bo on będzie tańszy niż prąd potrzebny na jego wyświetlenie, to czy za dekadę my, ludzie, będziemy jeszcze w stanie zdebugować system, w którym różne agenty AI zaczną negocjować ze sobą jakieś sprzeczne specyfikacje w locie? O rany! To jest wizja jak z matrica. Maszyny ustalające między sobą kontrakty. Prawda. I z tą właśnie wizją dzisiaj Państwa zostawiamy. Bardzo dziękuję za wspólną analizę. Ja również dziękuję. To była świetna rozmowa. Zdecydowanie. Zapraszamy do zapoznania się z pełnym artykułem i źródłami, o których dzisiaj rozmawialiśmy pod adresem https://datazen.top-podcast-ai-25 Gorąco polecamy.

A jeśli podobała się Państwu nasza dzisiejsza analiza, to bardzo prosimy o kliknięcie przycisku z serduszkiem na stronie artykułu. To jest dla twórców naprawdę niesamowicie ważny feedback. No i zachęcamy do subskrybowania Data Zen AI Podcast, żeby nie przegapić kolejnych tak wnikliwych eksploracji w świecie AI. Do usłyszenia. Trzymajcie się. Do usłyszenia.