#205 Sześć plików do jednego buga? - Spec Kit pod lupą

Szymon Warda: To właściwie to jest powtórka tego, co mieliśmy wiele lat temu, mianowicie jak z UML-a wygenerować sobie kod.

Łukasz Kałużny: Przecież myślenie jest tak bolesną czynnością niekiedy.

Szymon Warda: Dlatego właśnie musimy mieć chomąto na człowieka w postaci Spec Kita. Więc wychodzi nam naturalnie to, o czym właśnie rozmawialiśmy, że Spec jest fajny na starcie, a potem on sam umiera. To nam się to zacznie za chwilę rozjeżdżać i będziemy mieli kilka źródeł prawdy. A jak mamy kilka źródeł prawdy, to finalnie źródłem prawdy będzie kod, który jest autogenerowany. Czyli nie mamy żadnego źródła prawdy. Pytanie, na ile Spec Kit będzie aktualny, ponieważ modele obecnie idą w kierunku tego, żeby się lepiej domyślać o co Ci chodzi. Cześć, słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. No dobra Szymon, to o czym dziś?

Szymon Warda: Spec Driven Development.

Łukasz Kałużny: Dobra, to co, tak powiedziałbym, że, obiecałbym, że przedprzedostatni odcinek o AI-u w najbliższym czasie.

Szymon Warda: Ta, jasne.

Łukasz Kałużny: Ta, jasne. Ale Szymon, wpadłem na pomysł, którym się z Tobą podzieliłem. Dzisiaj porozmawiamy sobie o Spec Driven Development na przykładzie GitHub Spec Kita. Ale…

Szymon Warda: O tym wiedzieliśmy.

Łukasz Kałużny: Za dwa, trzy tygodnie, dwa tygodnie po publikacji tego odcinka mniej więcej zbierzemy opinie i komentarze, które zostawiacie nam na YouTube, Spotify i zrobimy sobie taki odcinek, żeby się do nich odnieść, powiedzieć jakie my mamy poglądy i inne rzeczy. I dzięki, bo niektórzy naprawdę się rozpisywaliście, tam jest parę takich ciekawych rzeczy, w których można przedyskutować. Jest jedno, które mi się spodobało, które Szymon będę musiał wkleić w tym miejscu, to jest to, że za dużo tego, za dużo było u Ciebie AI-owego LSD w pewnych momentach.

Szymon Warda: LSD?

Łukasz Kałużny: Tak, że praca z agentami czasem jest jak branie LSD, ktoś to porównał. I masz nową ksywę “ten z lewej”.

Szymon Warda: Ok, dobrze.

Łukasz Kałużny: Więc tak, trzeba podpisać tutaj Szymonowi dać. Dobra, ale lecąc ze Spec Driven Development, to pojawiło się do tego, bo jak każda rzecz chcemy znaleźć jakąś technikę, framework, podejście, jak używać narzędzia. I odpowiedzią, która rynkowo się pojawi… Ale tak jest zawsze Szymon z narzędziami, zawsze szukamy jakichś wyroczni.

Szymon Warda: Nie koniecznie wyroczni. Chcemy, ktoś chce jakieś opus magnum zrobić, żeby reszta tylko podążała jego pomysłem.

Łukasz Kałużny: Dobra, więc powstało Spec Driven Development, czyli jak ze specyfikacji kodować. Jak tworzyć specyfikację, żeby zlecić agentom delivery? Tak można byłoby to nazwać.

Szymon Warda: I tak, i nie. To jest, bo tak jak to przedstawiłeś, to właściwie to jest powtórka tego, co mieliśmy wiele lat temu, mianowicie jak z UML-a wygenerować sobie kod.

Wstawka: Ale to już było. Znikło gdzieś za nami.

Szymon Warda: Ten sam pomysł przeniesiony na inny grunt z innymi narzędziami.

Łukasz Kałużny: Tak i ja wczoraj na Architekturze 101, którą prowadziłem, zamkniętą dla jednej firmy, miałem rozmowę i największą krzywdą UML-a, to jest diagram klas i diagram bazodanowy w ten sposób przedstawiany.

Szymon Warda: Czyli to jest to, o czym mówiliśmy nawet parę odcinków temu odnośnie tego, że Spec nie do końca ma na tym niższym poziomie sens. Ale do tego sobie spokojnie wrócimy.

Łukasz Kałużny: I dzisiaj bierzemy na warsztat jeden z największych moim zdaniem, czyli GitHub Spec Kit, czyli implementacje Spec Driven od Microsoftu/GitHuba.

Szymon Warda: To samo.

Łukasz Kałużny: To samo. Warto powiedzieć jeszcze o czterech rzeczach. To powiedziałbym o vibe codingowym, chyba najpopularniejszej rzeczy, która swego czasu była, czyli zestawie skilli o nazwie Super Powers.

Szymon Warda: A to o tym mówisz, to już teraz wiem, o którym mówisz.

Łukasz Kałużny: Tak, Szymon nie wiedział, o co chodzi.

Szymon Warda: Nie skojarzyłem po tej nazwie, ale już wiem o co chodzi.

Łukasz Kałużny: Dobra. Kolejną rzeczą, która powstała, to jest Open Spec, czyli niby otwarty właśnie spec framework for building the right thing and building it right. Tak się ładnie określają. Niedawno Anthropic wydał The AI Native SDLC Playbook i jest nastawiony na myślenie. Ale o tym sobie dojdziemy. I ostatni, który już ma trochę czasu, też niedużo, bo jest ten, czasu, bo jest z zeszłego roku tak naprawdę artykuł i podejście, to AI Driven, AI Driven Development Life Cycle od AWS-a.

Szymon Warda: Który jest w ogóle sensowny, jest taki, jest ciekawy pod paroma względami.

Łukasz Kałużny: Dobra, to Szymon, czym tak naprawdę z założenia jest Spec Driven Development?

Szymon Warda: Dobra. Tak, jest dokładnie to samo co był UML. Czyli piszemy sobie specyfikację i wchodzimy do tego samego, że na podstawie tej specyfikacji generujemy sobie kod. Czyli to jest ta sama rozmowa, którą kiedyś mieliśmy odnośnie, nie wiem czy pamiętasz, takie były na konferencjach teksty pod tytułem “co byś wolał Łukasz usunąć albo stracić? Kod czy swoje testy?” No to tu mamy tą samą rozmowę pod tytułem “co byś wolał stracić? Kod czy swoją specyfikację?” Więc idea jest taka, że skoro generujemy już i tak cały kod z pliku markdown, no to po prostu miejmy go zapisanego. I to jest w dużym uproszczeniu. I to jest ten element, który według mnie Spec nie ma większego sensu ani… Sensu, nie ma wartości, tak. Czyli mamy kolejność - specyfikacja, oddajemy to do pisania dla agenta.

Łukasz Kałużny: Tak. Jeżeli popatrzymy, specyfikacja z założenia miała być źródłem prawdy, kod jest jej wynikiem. To jest takie jedno z ważnych. I założenie jest jeszcze inne, które miało być sensowne i to nie zawsze wychodzi, że Spec opisuje co i dlaczego, a wynikiem ma być kod, czyli jak?

Szymon Warda: To samo jak ADR albo user story.

Łukasz Kałużny: Tak. I jedna rzecz, która jest ważna, założenie było koniec z vibe codingiem, czyli zamiast projektu zrób mi X, masz ładny proces i artefakt tego myślenia.

Szymon Warda: Tak, tylko że dobrze wiemy, że załóżmy w Spec Kicie ten cały taki twardy harness, który po prostu uniemożliwia, jest opcjonalny. Więc mając sobie Spec Kita dalej możemy sobie śmiało vibe codingować.

Łukasz Kałużny: Raczej Spec Driven Development.

Szymon Warda: Tak.

Łukasz Kałużny: Tak. Dobra i przejdźmy w takim razie bardzo płynnie, czym jest GitHub Spec Kit? To jest tak naprawdę tool kit…

Szymon Warda: To jest zbiór markdownów.

Łukasz Kałużny: Zbiór markdownów, to chciałem powiedzieć, który idzie nam w zestawie szablonów, komend, skilli, definicji, agentów. I jedyną rzeczą, którą jest przyjemną, jest instalacja, że przez UV instalujemy sobie Specify CLI i możemy zaintegrować to sobie, wrzucić do naszego projektu.

Szymon Warda: I to jest ważne, że to, Spec Kit ląduje w repo i potem on jest nastawiony na to, żeby go tweakować pod swoje potrzeby.

Łukasz Kałużny: Tak. I teraz słuchajcie, przejdźmy sobie przez kroki w Spec Kicie, bo one bardzo dużo Wam wytłumaczą. Od razu Szymon się znęcamy czy tylko przechodzimy?

Szymon Warda: Znęcamy się, bo akurat różnimy się gdzieniegdzie w tych opiniach.

Łukasz Kałużny: To pierwszą komendą, którą i będziemy mówić o fullu, o pełnej instalacji. Czyli zrobiliście sobie specify init project integration na przykład Claude i zaczynamy. Pierwszym skillem, który jest, to jest Spec Kit Constitution, czyli tworzy plik konstytucji. To są zasady projektu, czyli obowiązkowe testy, biblioteki i inne takie elementy, czyli jak wygląda stos i zasady.

Szymon Warda: Tak, zwane inaczej wishlistą, żeby się trochę ponabijać. Ale tak poważnie mówiąc, to pamiętam, że mieliśmy rozmowę, że Ty znowu nie jesteś fanem konstytucji. Ja uważam właśnie, że ona jest jednym z tych bardziej wartościowych, o ile tam to się nie zamieni w wishlistę, czyli: chciałabym mieć duże pokrycie kodu i tak dalej. Takie twarde rzeczy, które mają być przestrzegane po prostu i tyle.

Łukasz Kałużny: Szymon, odeślę też jak to robimy z klientami do Powered by Protopia, bo był taki odcinek, gdzie to opowiadam. Uważam, dlaczego ja mam z tym problem? Ok, założenie jest dobre, bo też robimy to w bardzo podobny sposób, ale to, co robimy na przykład w naszym podejściu firmowym, to jest to, że generujemy skrypty i harness. I to jest bardzo ważna różnica, że na przykład te testy czy pokrycie kodu testami w niektórych miejscach, lintery i inne tego typu zabawki, SonarQube’y, one są wymuszone w configu agenta…

Szymon Warda: Tak.

Łukasz Kałużny: I są w jakiś sposób odpalane i przekazywane agentowi, a nie że ja chciałbym.

Szymon Warda: Ustalmy Łukasz, to są dwie rzeczy generalnie. Jeden, to mówisz, że byś chciał, a drugie to mówisz sprawdzam. Więc to i jedno i drugie jest ważne specify, bardziej konstytucja jest po to ważna, żeby on ze startu szedł w dobrym kierunku, a potem go tam najwyżej (…) doprowadzać.

Łukasz Kałużny: Tak, ale to jest taki mój zarzut do Spec Kita, jeden z największych taki zarzut, jak powiemy, że to jest zbiór markdownów bez żadnych hooków, skryptów i innych rzeczy, które powinny być.

Wstawka: A, podłączyłeś te żyrandole do prądu czy tylko tak powiesiłeś? O kurna, zapomniałem, tylko powiesiłem.

Szymon Warda: Bo one są trudniejsze, nie oszukujmy się, łatwiej jest po prostu povibe’ować z inną. Dobra, specify, czyli inicjalny, jak chcemy cokolwiek w ogóle zrobić. I właściwie tyle. Tam mamy opisać, opisujesz co zrobić, taki user story, można powiedzieć.

Łukasz Kałużny: Tak. To jest, powinieneś dostarczyć jak najwięcej kontekstu: co Ty do diabła chcesz zrobić? I teraz jest rzecz, która mi się nie podoba w tym bardzo mocno, w tych wielu przykładach, bo z założenia te frameworki, tego nie powiedzieliśmy, one powinny być nastawione, że odpalasz jedną sesję i przechodzisz i kończysz. Czyli jest jedna sesja, jedno zadanie na całość. Ale zarzut, który ja mam, one nie pokazują, że powinieneś pomyśleć przy specify. Czyli na przykład: Ty drogi, chciałbym zbudować, to wiem, że już powinno być to w tym miejscu, chciałbym użyć X, Y, Z. Czyli od razu zrobić bardzo dużego braindumpa, a nie tylko prosty user story.

Szymon Warda: No i tu właśnie dochodzimy do clarify, który jest krokiem opcjonalnym, który jest taką próbą, gdzie agent próbuje się Ciebie dopytać, doprecyzować o co w ogóle chodzi. I właśnie tu widzę większą wartość w ogóle z całego Spec Kita, że to nie jest coś, o czym Ty mówisz, że nie jest to opcja, że ja mam pomysł, to po prostu to lecimy w takim razie. Nie, ten właśnie krok dopowiedzenia, czy chcesz zrobić tak, chcesz zrobić inaczej, o co Ci chodzi dokładnie, żeby ten użytkownik się zastanowił: czy na pewno chcesz to zrobić? I z tej pewności możemy dojść do tego, że jednak nie chcę tego robić. Ten cały, narzucenie chomąta, ale myślowego i na człowieka, żeby dowiedzieć się, o co mu właściwie chodzi, żeby to user story, który właśnie z tego specify wynika, żeby ono nie było takim wyrzygiem.

Łukasz Kałużny: Przecież myślenie jest tak bolesną czynnością niekiedy.

Szymon Warda: Dlatego właśnie musimy mieć chomąto na człowieka w postaci Spec Kita.

Łukasz Kałużny: Dobra. I to nam poprawia tę specyfikację. I teraz kolejny zarzut mój, to jest Spec Kit Plan. Plan mode’y w narzędziach są ok. To też powiedzmy sobie wprost, potrafią być ok. Czyli tu wchodzi stack, architektura, kontrakty, struktura danych, kontrakty API. Ok, i to jest commitowane po specyfikacji. To jest kolejny plik, który jest commitowany do repo.

Wstawka: A wiesz dlaczego? Dlatego, że jego słaba psychika już wysłała mu maila do nadciągającej kupy, że spotkanie jest w spodniach.

Szymon Warda: Powinien być, tak.

Łukasz Kałużny: Jak powinien być.

Szymon Warda: No to pamiętam, że mieliśmy rozmowę, że nie jesteś takim fanem tego, ale no dobra, to (…).

Łukasz Kałużny: Raczej nie jestem, wiesz co, mam problem, że to co też zrobiliśmy na firmowym podejściu, że specify i plan jest zmerge’owany w jedną i nazwaliśmy go tutaj researchem całym.

Szymon Warda: Zgodzę się. Znaczy dla mnie to co jest w Spec Kicie, to jest to, że faktycznie specify powinno być bardziej rozbudowane, bo właśnie elementu researchowego, elementu badania, elementu czy aby na pewno i to, co w Google’u było, że a może my byśmy tego nie potrzebowali wcale robić? Tego mi tam trochę brakuje natywnie. Ale dlatego mówię, to jest coś, co trzeba rozbudowywać i tyle.

Łukasz Kałużny: Tak. I teraz następny zarzut, który mam do Spec Kita, na przykład to, co u nas zrobiliśmy, żeby mieć jakąś przewidywalność i to, co podchodzimy Szymon, to w zależności czy w wersji prostej, czy rozbudowanej, ale że dorzucamy sobie określenie testów akceptacji i scenariuszy testowych. Bo one tutaj, okej, tam się dzieją, ale one też nie są jasno wyszczególnione, że: pomóż mi zaplanować testy.

Szymon Warda: I znowu wracamy do tego, że ideowo jest okej. To, co potrzebujemy, to jest chomąto, ale na człowieka, myślowe.

Łukasz Kałużny: Tak, myślowe.

Szymon Warda: Bo to jest dobre właśnie. Bo tak, jak nie doprecyzujemy, możemy powiedzieć, że w konstytucji będzie, że musi mieć pokrycie, musi mieć testy i tak dalej. (…) się tego, Spec Kit nam nie zastąpi naszego procesu wytwarzania i tego wszystkiego, co potrzebujemy zbudować i tyle.

Łukasz Kałużny: Dobra, i teraz specify tasks. I to jest ta rzecz, którą Ty bardzo brzydko określałeś w tym. Czyli że ten skill w Spec Kicie służy do tego, żeby rozbić nasz plan na poszczególne już taski do zlecenia subagentom. Plan rozbity na małe zadania w kolejności i scommitowany do repo. I Tobie…

Łukasz Kałużny: I to scommitowane do repo, wartość tego jest okrągłe zero, nawet może, przepraszam bardzo, pomyliłem się, ujemna. Jaka jest wartość z tego, że będziemy trzymali w repo listę tasków na jakie zostało rozbite? Żadna.

Łukasz Kałużny: Powiem Ci, jak zastanawiałem się, bo my mamy w planie taką task listę dużych zadań. Czyli batche zadań, które można zlecać… W naszym podejściu na przykład doszliśmy do tego, że mamy jakąś listę zadań dużych, które trzeba wykonać, która jest zrobiona tak, że czy można je zbatchować? Od razu upfront, zbatchować i określić scenariusz red green dla danego zadania i czy można zrównoleglić? I to była wartość. Tylko to też znajduje się w planie, bo stwierdziliśmy, że oddzielny taki plik tasks w ogóle nie ma sensu w tym miejscu.

Szymon Warda: Dla mnie rozdzielony ma, bo w tym momencie ten agent, który będzie potem to rozdzielał, ma mniejszy kontekst i nie widzi tego całego pierdolnika.

Łukasz Kałużny: Tak, ale można teraz parę rzeczy się kłócić, ja z tym tasks miałem taki, po co to commitowane jest, jak sobie wejdziesz w historię i w ogóle? To jest po to, żeby jak Ci się coś zwali, to żebyś mógł sobie na innej stacji przywrócić to wszystko do pracy. Wiesz co…

Szymon Warda: To możesz to na brancha wrzucić. Łukasz, tam jest, w Spec Kicie to jest powiedziane jasne, że to jest element ważny i tak dalej, i tak dalej. Chcesz, to miej to na branchu, tak, commituj sobie na brancha, nie ma problemu, tylko finalnie tego nie wrzucaj. Żeby nie było, też podzielenie na taski też ma jedną fajną rzecz, którą wymusza. Wymusza to, że możesz sobie załóżmy gadać z jakimś naprawdę dobrym modelem, a potem taski porozdzielać na modele słabsze, bo z reguły do kodowania to wystarczy, że nie wszyscy będą pisali słabe testy powiedzmy Fablem, bo niekoniecznie jest potrzeba tego robić. Więc ten Spec Kit miejscami ma sens, commitowanie tego i utrzymywanie, może tak, utrzymywanie tego w repo - żaden. To ma negatywny wpływ na całość, bo nam zabija kontekst cały. Potem agent zrobi grepa i dostanie takich tasków 50 plików.

Łukasz Kałużny: Inaczej, i teraz jest problem z tym, że też trzeba naprawdę wysterować AGENTS.md, Claude.md, żeby kurwa nie, przepraszam, nie analizował tego wszystkiego.

Szymon Warda: Dobra, jak ma on nie analizować, to przecież Ty nie będzie tego czytał, no nie oszukujmy się. To po cholerę to tam mamy?

Wstawka: Biorę i udaję, że czytam, ale nie czytam, bo jeszcze mi się zapełni mózg.

Łukasz Kałużny: Więc tutaj jest dużo ciekawej dyskusji, można przechodzić. Następne, to jest Spec Kit Analyze: sprawdź spójność pomiędzy spec plan tasks. Krok opcjonalny.

Szymon Warda: I według mnie dobry, bo widzę, że jak się uśmiechasz i tak go tam szydzisz z niego. Dobry, bo to jest krok, który upewnia się, czy aby na pewno to chciałeś i czy agent Ci nie poleciał w zupełnie innym kierunku. A potrafią, ustalmy, potrafią.

Łukasz Kałużny: Tak, tylko że wiesz co, dlatego ja…

Szymon Warda: To jest krytyk po prostu.

Łukasz Kałużny: Dobra, okej, rozumiem, że jest krytyk, ale zawsze wolałem dlatego posiadać jeden artefakt, który jest wbudowany w kontekście, bo on się mniej rozjeżdża.

Szymon Warda: Ale tu masz analyze po prostu, tu patrz, krytyka, koniec, kropka. Przyda się.

Łukasz Kałużny: Dobra. Szymon, jeżeli krytyka, ja robię trochę inaczej w tym, tak jak, uwaga, preferuję wziąć wrzucić zupełnie inaczej. Uważam, że powinno się, jeżeli już robimy review, to powinien być robione innym modelem.

Szymon Warda: Ale się zgadzam. Mi chodzi o samą ideowo, że po taskach powinien być ktoś, kto stwierdzi czy, to jest taki check ostateczny, czy to nie odpłynął.

Łukasz Kałużny: Tak, czy nie odpłynął.

Szymon Warda: To powinno być innym agentem, jak najbardziej, tak.

Łukasz Kałużny: Dobra, tylko pytanie teraz.. Dobra, przejdźmy, skończmy to i zaraz zadam jedno duże pytanie.

Szymon Warda: Dobrze.

Łukasz Kałużny: Halo, halo! Słuchasz już kwadrans, a nadal nie ma suba i dzwoneczka. Weź to napraw. Teraz jest skill do orkiestracji czyli implement. Ok, tu nie ma co w ogóle, idź pracować, o tak, to nie ma w ogóle w tym. I ostatni, Spec Kit Coverage, porównuje kod z artefaktami, dopisuje to, czego brakuje.

Szymon Warda: No właśnie, dopisuje czy może zmienia specyfikację, czy właściwie co robi? Bo to jest podobne, to jest inaczej nazwany krytyk, nic więcej, który robi sprawdzenie i mówi czego brakuje. Ale to w tym momencie powinniśmy wrócić niemalże na start do specify i dowiedzieć się, co się właściwie zwaliło, a nie dopisywać.

Łukasz Kałużny: Tak.

Szymon Warda: Bo tu jest takie wypchnięcie nogą, oby było w miarę okej. To nie tak, nie ta opcja. Dobrze.

Łukasz Kałużny: Więc to jest taki tak, znowu jest krytyk. Tam są jeszcze jakieś checklisty i inne takie bardzo, bardzo dodatkowe elementy.

Szymon Warda: Żeby to ustrukturyzować, żeby było jako issuesy GitHubowe, żeby z tego zrobić taki trochę flow, potencjalnie nawet większe, większe zrównoleglanie.

Łukasz Kałużny: Tak i teraz są tak, że jak popatrzymy, są wersje proste, czyli po prostu odpal Spec Plan Implement i to jest ten najprostszy workflow, który w tym. I jak popatrzymy, a jeżeli mówimy o pełnym, to jest to, że odpalamy i zaczynamy od inicjalizacji tego constitution, żeby zdefiniować, co jest w ogóle w projekcie, jak on działa. A jeżeli mówimy o bootstrapie brownfieldu, to że bierzemy, odpalamy te constitution i weź mi sprawdź, co ja w ogóle w tym projekcie mam, ale ja już wiem, że jak nowe rzeczy będę robił, to powinieneś tego nie robić i tutaj elementy. Tak można byłoby to nazwać.

Szymon Warda: Jakoś w brownfielda w tym kroku nie wierzę, bo on zrobi grepa po kilku rzeczach i wyciągnie Ci jakieś informacje, niekoniecznie te, które byś chciał ogólnie rzecz biorąc. No ale niech będzie. Dobrze.

Łukasz Kałużny: Tak. I jedna rzecz od Anthropica, którą bym dorzucił, takie fajne wtrącenie, z którym ja się w tym miejscu zgadzam, że te constitution to powinny być najczęściej Claude.md, AGENTS.md. Że nie oddzielny plik, tylko jest to sobie powiedzenie, ewentualnie część oddzielnych plików, ale główne reguły siedzą w głównej specyfikacji.

Szymon Warda: Wiesz co, dla mnie Claude.md jest takim ogólnie informacją co gdzie siedzi, pokrywają się ze sobą, zostawiłbym oddzielone. Ale to jest kłócenie się o nazwę, które jest ważne.

Łukasz Kałużny: Ważne na przykład przy Anthropicu, jak pójdziemy sobie do tego ich podejścia, to ważne, tam oni naciskają właśnie na to, żeby wykorzystywać hooki gdzie się da, przygotować sobie setup, który będzie jakkolwiek deterministycznie odpalany i będzie pomagał weryfikować.

Szymon Warda: Znaczy oczywiście, ponownie Spec Driven Development nie wyklucza, absolutnie nie wyklucza i nie jest zastępstwem dla tego, żeby mieć twarde harnessy, po prostu. Dobrze, Łukaszu, no to teraz tak sobie pogadajmy, kiedy to ma sens, a kiedy nie ma sensu?

Łukasz Kałużny: Znaczy dla mnie jest tak, bardzo dobrze jest to przetestować i… Inaczej, teraz ustalmy, dla mnie on powinien, bo mamy, teraz mam następujące, to też padało w poprzednich odcinkach, się powtórzymy, mam następujące przemyślenie. Po pierwsze, to jest narzędzie, tak jak sobie powiedzieliśmy w poprzednich odcinkach, żeby zwiększyć średnią zespołu.

Szymon Warda: Wyrównać proces myślowy.

Łukasz Kałużny: Tak, wyrównać proces myślowy. I teraz tak, w wielu przypadkach może się okazać, że jeżeli zbudowaliście swój workflow, będzie on tańszy, szybszy, lepszy.

Szymon Warda: Dla Was.

Łukasz Kałużny: Dla Was, w waszym wykonaniu, nie w wykonaniu zespołu. Więc to jest porównanie. I dla mnie to jest bardzo ważne, takie narzędzie myślowe. Wrzucę teraz obrazek z jednego takiego wpisu, bodajże z firmy Affirm, która świetnie u siebie zwizualizowali ich podejście. Kiedy to jest człowiek, kiedy to jest agent i jak to wygląda. Czyli jeżeli popatrzcie, to jest pomyślenie o tym, jak wygląda human in the loop takich rzeczy i kiedy my myślimy. Czyli zobaczcie plan, to jest agent assistant specification i to my musimy to zdumpować, zweryfikować, oddelegujemy researche i inne rzeczy, ale my to krytykujemy i reviewujemy.

Szymon Warda: Czyli agent robi to, co umie robić, czyli mianowicie tworzy, research robi, sprawdza, co tam się działo, jakie są konwencje i tak dalej. To można spokojnie oddelegować.

Łukasz Kałużny: Tak. Następnie agent pisze kod, są od tego verifye, które też są deterministyczne, czego brakuje w Spec Kicie, czyli zrozumienie, że harness to jest twój lokalny CI po prostu. I co trzeba zrobić? Następnie reviewujemy i potem jest delivery, czyli ktoś się współpodpisał i zmerge’ował. I tam jest taka ładna rzecz, sentencja, która idealnie podsumowuje: one task = one agents session = one PR.

Szymon Warda: I ok, to teraz dochodzimy do jednej rzeczy, która…

Łukasz Kałużny: Nie mówimy o subagentach tutaj, tylko, że jest jedna główna sesja.

Szymon Warda: Poczekaj, poczekaj, w takim razie rozmiar zadania i rozmiar projektu, bo to jest problem Spec Kita. Inicjalnie, jak zaczynasz robić feature’y, to jest wszystko super, bo to jest takie mniej więcej, tak jak mówisz, robisz feature po prostu. Spoko. Teraz mamy problem taki, masz, zrobiłeś jakieś większe coś, załóżmy jakiś taki, nie wiem, Epica, trochę, trochę, trochę zaczyna brakować. Teraz idą poprawki bugów. I co teraz zrobić? Bo teraz albo Ty po prostu mówisz mu napraw i on to zrobi. No i to brzmi całkiem okej. Ale w tym momencie Speca nie zaktualizujesz albo tworzysz nowe specify na poprawę buga i do prostego buga, czekaj, otrzymujesz 6 plików.

Łukasz Kałużny: No fucking way! Lokalny plan. I wiesz, dlatego mówię one task = one agent session = one PR. Nie powiedziałem, że odpalasz pełnego Spec Kita, tylko to, żeby ustawić sobie myślenie. I Szymon, do naprawy buga, sorry, shift+tab na plan mode. Zrób mi na przykład, jeżeli masz fajnie zrobione repo, projekt, to zrób mi sesję debugowania. Napisz mi na przykład, jeżeli mamy unit testy, testy integracyjne, napisz mi edge case, żeby odwzorować buga, zreplikować go. Jeżeli udało się go zreplikować napisz fixa, pushnij, zero dodatkowych plików.

Szymon Warda: Dobrze, to teraz wchodzimy w taką prostą opcję. Doskonale wiesz, że takie ładne feature’y, to są na starcie, a potem im dalej tym więcej masz takich bugów, które się przeradzają w zmienne funkcjonalności. Więc wychodzi nam naturalnie to, o czym właśnie rozmawialiśmy, że Spec jest fajny na starcie, a potem on sam umiera, bo się rozjedzie. I potem mamy taką opcję, że realnie mamy, nie wiem, powiedzmy 30 issuesów, które robimy. To 5 to są user stories, 25 to są bugi i nagle de facto my realnie utrzymujemy tego Speca po to, żeby tylko… Na co?

Łukasz Kałużny: Szymon, wiesz, ja patrzę teraz na speci w ten sposób i to jest bardzo ważne, na przykład moje patrzenie na specki, jeżeli one są kombinowane.

Szymon Warda: Dobrze.

Łukasz Kałużny: Że one stanowią, to jest to, nazwałeś to już ADR-ami i że nie powinniśmy, jeżeli potrzebujesz coś zmienić w Specku i agent poprosi, że powinieneś wychłostać agenta za próbę zmiany czegoś w starych specyfikacjach.

Wstawka: Biblia jest otwarta na interpretacje.

Szymon Warda: No nie, nie mów, że są niby idempotentne. No nie są. W tym momencie umrzesz z tych plików.

Łukasz Kałużny: Ale właśnie i to jest pytanie, w którym momencie… Ja bym zadał inaczej pytanie Szymon, że w pewnym momencie będziesz musiał zacząć je kasować.

Szymon Warda: Okej, ale jak je kasujesz, to w tym momencie, jak odchodziliśmy od tego, że kod jest autogenerowany, to w tym momencie tracisz tą wiedzę, a potem jak będziesz miał opcję, że mam kod i nie wiem po co on tam jest w ogóle.

Łukasz Kałużny: Przepraszam, dobra, skasowane to jest źle. Powinniśmy to oznaczyć jako albo wycofane, albo… Inaczej, skasować, powinniśmy zrobić jakąś formę reconciliation, trzeba to dobrać do projektu.

Szymon Warda: No ale w tym momencie dalej biegniemy z projektem i mamy pliki, które tam istnieją, ale może są nieaktualne. No to Łukasz, czyli tworzymy dokumentację, którą wiemy, że za chwilę nam wygaśnie, jest nieaktualna.

Łukasz Kałużny: Dla mnie to jest specyfikacja, że jak powstał dany feature.

Szymon Warda: Nie, jak on kiedyś powstał.

Łukasz Kałużny: Nie, jak powstał, jego znamy genezę i inne takie rzeczy. Idziemy do przodu i iterujemy do przodu. Więc uważam, że najgorszą możliwą rzeczą jest edycja w Specu, w Spec Driven Development, edycja pierwotnej specki, to jest po prostu nowe zadanie.

Szymon Warda: Okej, ale to jeżeli na przykład projekt żyje 3 lata czy 5, to od tych…

Łukasz Kałużny: To właśnie… Inaczej…

Szymon Warda: Plików umrzesz, dosłownie umrzesz od nich.

Łukasz Kałużny: Dlatego trzeba się zastanowić i tego nie znamy odpowiedzi, dlatego ja tak patrzę na Spec Kita w tym względzie i takiej ilości, patrzę na tej zasadzie, że w pewnym momencie będzie trzeba dochodzić do procesu clean upu i nikt o tym głośno nie mówi.

Szymon Warda: Nie, pojawiają się już ruchy takie, żeby właśnie odpalać agentów, którzy będą potem scalali…

Łukasz Kałużny: Reconcilowali dokumentację. My u siebie we flow taką rzecz pewną mamy zrobioną. Tylko teraz jest to problem taki, że wszyscy jesteśmy w momencie zachłyśnięcia.

Szymon Warda: Prosisz się o halucynacje tam. I jak Ci z kodu zhalucynacje specyfikacje, to potem jesteś wiadomo gdzie, bo już masz zhalucynowane specyfikacje.

Łukasz Kałużny: Nie Szymon, tak, w tym miejscu tak. Dlatego teraz, najgorsze jest to, że w tym miejscu możemy trafić na takie kurestwo, że zaczyna Ci tą speckę, której nie trzeba.

Szymon Warda: Dokładnie. Dlatego specka, nie mylić inicjalnie specka, ale potem to powinien być opis funkcjonalności, powinna być dokumentacja trzymająca się na wysokim poziomie typu właśnie architektura, typu flowy biznesowe, sens tego, czyli z diagramów C4: C1, C2, niżej nie schodzimy. Dlatego właśnie…

Łukasz Kałużny: C3 jest ok Szymon akurat w tym. C4 wiemy, że nie, C3 jeszcze może być w opisie.

Szymon Warda: Będziemy się, tu się zgodzimy, że się nie zgadzamy generalnie. Dobrze, to teraz, to jest jedna z moich uwag właśnie, że Spec Kit fajnie wygląda na starcie, potem zaczyna być, zaczynamy się o niego potykać, o własne nogi. Dalej idziemy, powtarzalność tego. W tych dokumentach będzie dużo powtarzalności. Będą rzeczy tu w jednym, w drugim, trzecim. A jak mamy w wielu miejscach źródło prawdy, to nam się to zacznie za chwilę rozjeżdżać i będziemy mieli kilka źródeł prawdy. A jak mamy kilka źródeł prawdy, to finalnie źródłem prawdy będzie kod, który jest autogenerowany. Czyli nie mamy żadnego źródła prawdy.

Łukasz Kałużny: Nie mamy.

Szymon Warda: Spec Kit jest, ta nieuporządkowaność jest straszna. Żeby nie było jestem strasznym fanem tego kroku trzeciego, który właśnie jest ten krok krytyka. To jest świetne chomąto na człowieka i tu jest jego wartość. Ale te bajki, które są, że: a, to będziemy utrzymywali teraz to i będzie wszystko fajnie i tak dalej. Nie, budujemy sobie backlog rzeczy. Sorry, nie ma to żadnego sensu. No to teraz mieliście próbkę naszej rozmowy wewnętrznej.

Łukasz Kałużny: Tak, więc w tym jest Szymon, tak, ja mam totalnie, nie uważam, że to trzeba będzie jakoś zaopiekować po czasie wzrostu, o tak. Nadal…

Szymon Warda: Czyli usunąć.

Łukasz Kałużny: Usunąć. Raczej nie, patrzę, mam na to inne przemyślenia, ale jeszcze nie rzucę. Na razie patrzę w tym. Może inaczej, ja bardzo ciepło wiesz, że patrzę na to, co dzieje się w Open Codzie akurat i na dynamiczne harnessy w Type Script’cie, bo to jest coś. I pomysły, które za tym idą gdzieś też były, pojawiły się pomysły w Claudzie, czyli patrzę co będzie można zrobić, żeby zabronić agentowi dochodzenia do tych elementów.

Szymon Warda: Łukasz, ale tutaj nie ma nawet, nawet nie ma co dyskutować generalnie, bo się zgadzamy z tym w zupełności, że wartość, kierunek, którym będziemy szli, to jest właśnie deterministyczne zabranianie. Bo fuck upy się pojawiają, pojawiają się coraz częściej, jest ich coraz więcej i ryzyko, gdzie wpuszczamy agentów jest też coraz większe. Więc oczywiście, to jest w ogóle super krok, jak najbardziej. Idziemy w to. Jeszcze mieliśmy jedną dyskusję.

Łukasz Kałużny: Którą.

Szymon Warda: Bo jeszcze mieliśmy dyskusję, no właśnie, jakbyś mi nie przerywał, to Ci powiem, bo mieliśmy dyskusję, że Spec Kit to jest powrót do Waterfalla.

Łukasz Kałużny: Ale Ty wiesz o tym, że ja zostawię mem, który wraca, wrzucam, czyli Agile na sztandarach i czy to jest Agile? Nie, to Waterfall w Jira.

Szymon Warda: Nie to jest spychologia, że ktoś zrobił user story na zasadzie chcę mieć takiego feature’a i potem była wielka dyskusja. To jest po prostu shit in, shit out puszczony na pełen flow i tyle.

Łukasz Kałużny: Ale, dobra, poprzednio też nawet w odcinku dyskutowaliśmy, że lepiej żeby dał ktoś Ci link do chata niż wklejał to do user story, że to byłby lepszy user story.

Szymon Warda: Co jest w AWS-owym podejściu swoją drogą, że tam commitujemy całą rozmowę do repo i dla mnie to już ma pewien sens. Teraz mnie trochę irytuje, teraz będzie marudzenie starego człowieka odnośnie tego, że tak sobie marudzimy, że o jejku, jejku, tak wszystko fajnie było. I widziałem taki cytat: software development is fundamentally unknown deterministic process. No serio, to nie jest tak. Development software’u powinien być deterministyczny.

Łukasz Kałużny: Zgodzę się z Tobą… Ale inaczej, Szymon, tylko wszystkie te rzeczy, bo ja, kurde, ja się, przed Agilem ja jeszcze znałem, to ten, dinozaurze mój drogi, stary człowieku krzyczący na chmury, extreme programming.

Szymon Warda: No kto nie znał?

Łukasz Kałużny: Dajcie znać w komentarzach, czy wiecie co to jest, albo na discordzie. Kto z Was wiedział i zna historię zwinności przed zwinnością, czyli extreme programming? W tym miejscu. Więc, Szymon, projektowanie, tak jak powiedziałeś, powinieneś być w stanie zaprojektować… Jak byśmy się teraz kłócili, za co niektóre osoby mnie nienawidzą, tak jak zawsze przyrównuję do tej nieszczęsnej crudej maszyny stanów, gdybyś siadł i zrobił prawdziwą analizę software’u i potrzeb, byłbyś w stanie zaprojektować ją up front, gdyby ludzie chcieli podjąć decyzję. O właśnie, dla mnie Agile to jest po prostu w większości przypadków, rozumiem Agile w rozumieniu buduję nowy produkt, robię ten disrupt i ja się tam zgodzę, że on się znajduje. Ale w bardzo wielu przypadkach, w których projektach wszyscy pracujemy, większość naszych słuchaczy pewnie też, po prostu nikt nie chce się podpisać pod analizą.

Szymon Warda: Albo nikomu się analizy nie chce zrobić, tylko rzucają pomysł i przerzucają to na zasadzie i tak ktoś do mnie wróci. Ustalmy czemu nie robiliśmy pełnej analizy? Bo to było drogie, czasochłonne i tak dalej i każdy potrzebuje dupokrytyki tak naprawdę, a tak to się wystawia tylko analityk. Ale właśnie o to chodzi, że z tymi narzędziami typu specify, typu właśnie krytyka i tak dalej, możemy właśnie mieć tą lepszą dokumentację. I to jest, tam jest ta cała wartość i przestańmy się brandzlować nad tym, że nie wiem, nasz software jest taki niedeterministyczny i że wytwarzamy go i tak dalej. No ludzie, naprawdę nie powinno być tak. Wymaganie powinno się przekładać mniej więcej jeden na jeden na działanie systemu. Koniec.

Łukasz Kałużny: Szymon, jest pewna rzecz, bo tak sobie sprawdziłem w ogóle Spec Kita w tym momencie, jedną rzecz przegapiłem, jak rozmawiamy. To, że plan, task, research i inne rzeczy powinny być przed mergem deletowane nawet.

Szymon Warda: Widziałem takie podejścia w ogóle. Widziałem, widziałem.

Łukasz Kałużny: I żeby w tym i żeby zostawały potem. I w ogóle jest coś, co przegapiłem przygotowując, że jest też wersja Spec Kita - Lean odchudzona jeżeli chodzi o potem kasowanie i inne rzeczy.

Szymon Warda: Super. Sam Spec Kit już sam z siebie się już trochę rozrósł bym powiedział.

Łukasz Kałużny: Więc będą go kastrować.

Szymon Warda: Ma ile? Dwa lata? Półtora roku?

Łukasz Kałużny: Nie, jak to jest.

Szymon Warda: Z rok po minimum, to jest takie… No nieważne już teraz i już go odchudzamy. Budujemy kolejne opus magnum po prostu.

Łukasz Kałużny: Dlatego wiesz co, ja nie wiem, czy masz jeszcze jakieś rzeczy do powiedzenia, czy w tym miejscu…

Szymon Warda: Nie, nie mam. To jest tyle mojego narzekania.

Łukasz Kałużny: Wiesz co, dobra, to narzekając, ja tylko sobie sprawdzam kiedy, muszę się przebić przez wszystkie strony od Spec Kita, bo tych release’ów było dużo, chcę sprawdzić od kiedy tylko.

Szymon Warda: Ale jeszcze jeden komentarz, bo to właśnie mi wyskoczyło w moich notatkach, pytanie na ile Spec Kit będzie aktualny, ponieważ modele obecnie idą w kierunku tego, żeby się lepiej domyślać o co Ci chodzi. I Spec Kit kiedyś, jak te modele były takie trochę bardziej łopatologiczne, miał większy sens. Teraz jak one są naprawdę cwane i naprawdę robią niezłe założenia, nieidealne ale niezłe założenia, to on powoli zaczyna tracić na wartości. I dlatego właśnie te konstytucje i te inne rzeczy mówią dokładnie co my byśmy chcieli.

Łukasz Kałużny: Rok czasu, Spec Kit ma rok.

Szymon Warda: No to niech będzie.

Łukasz Kałużny: Dobra, rok. Wiesz co, inaczej, to jest taki test, który nawet teraz jak nagrywamy, wczoraj wyszedł Opus 5.5.

Szymon Warda: Widziałem.

Łukasz Kałużny: Tak i ja robię taki test, słuchaj Szymon, ostatnio na paru rzeczach, na paru skillach z pytaniem ile możesz, przeanalizuj ile jest Ci niepotrzebne i można wyrzucić.

Szymon Warda: To trzeba regularnie robić.

Łukasz Kałużny: Tak. I chociaż jest teraz ciekawostka, Fable pod tym względem, ze względu na swoją ciężkość, mimo że ten Opus 5.5 tak jak po pierwszym dniu testów jest lepiej niż ze Slopusem 5.

Szymon Warda: Jest lepiej.

Łukasz Kałużny: Jest lepiej. Ale teraz poczekaj, jest tak, że Fable faktycznie chciał mi ściąć w niektórych miejscach 70%, wywalić w ogóle z tego, wywalić i zaproponował w jednym miejscu nawet, że skrypt napisze zamiast tego, bo da się to skryptem robić. Tak jak Opus, na przykład tam Opusy zaczyna to spadać i widać to w ogóle pomiędzy modelami. Fajnie widać jak puszczam sobie subagentów, czyli puść subagenta Fable, Opus i w tym i Sonet i powiedz co usunąć. Sonet nic nie chce usuwać.

Szymon Warda: Bo on tego potrzebuje.

Łukasz Kałużny: Tak. Ta 5.5 teraz już tam powiedziało dość sporo, ale nadal mniej niż Fable. I będzie coś takiego i Anthropic też o tym mówi, jak pójdziemy w jego playbook, który jest.

Szymon Warda: Były wpisy, mówili, że oni sami z siebie pousuwali masę harnessów.

Łukasz Kałużny: Tak, że masę, tak, że… Raczej inaczej, nie, nie harnessów, MDK-ów, MDK-ów.

Szymon Warda: Oni mieszają te pojęcia, że to jest, u nich harness to jest MDK plus te twarde.

Łukasz Kałużny: Tak, to mówią o tych miękkich, mówią o usuwaniu miękkich, nie twardych, o miękkich. Jak przeczytacie sobie tego playbooka, to tam jest właśnie informacja o tym, żeby też przy nowych modelach sprawdzić i sprzątać to.

Szymon Warda: Ma sens jak najbardziej. Łukasz, ale to jest prosty myk. Znowu, porównując do ludzi, junior potrzebuje dużo pokierowania, mid mniej, senior jeszcze mniej architekt to w ogóle zostaw go w spokoju i on Ci wykombinuje lepiej niż…

Łukasz Kałużny: Powinien. To teraz powiedzmy, osoby, które mają hands on i chcą na tym pracować, nie będą narzekały. Zmienią swoje myślenie, będą wypracowywały swój workflow.

Szymon Warda: Podsumowując, Spec Kit spróbujcie, daje fajny sposób myślenia, ustrukturyzuje proces myślowy i proces planowania. A czy użyjecie go do kodowania i czy będziecie trzymali go w repo i te wszystkie inne rzeczy?

Łukasz Kałużny: To są inne rzeczy.

Szymon Warda: Zupełnie inna bajka.

Łukasz Kałużny: Tak, ja też podrzucam do tego Affirma, żeby zobaczyć sobie jak to wygląda. I z naszych rzeczy, które nagrywaliśmy, czyli firmowy podcast, jak i wziąłbym jedna taka rzecz z tym na temat, mieliśmy odcinek na temat Open Mercato. Tam jest przerośnięty harness, więc nie patrzcie na to pod względem co jest w tym repozytorium, ale wyciągnijcie wnioski od Piotrka Karwatki o tym co mówi. Tam dla mnie też było parę rzeczy, które sobie potem z tamtej rozmowy wziąłem i zmieniłem. Jakbym miał powiedzieć jedną rzecz, którą trzeba wyciągnąć z tamtego odcinka, wrzućcie taska i zminimalizujcie konsole i dopiero reviewujcie, jak skończy. Nie wtrącajcie się. To jest bardzo istotna rzecz, która tam jest.

Szymon Warda: Co ja mówiłem - wirtualny desktop.

Łukasz Kałużny: Ja nie lubię virtual desktopów, zostawmy to.

Szymon Warda: Bo ich nie masz.

Łukasz Kałużny: Dobra. To słuchajcie, to teraz pora na pokłócenie się z nami w komentarzach. Zróbcie tam dumpa swoich myśli, a my za jakieś dwa, trzy odcinki wracamy zbierając z całej tej serii AI-owej z ostatnich tygodni, co się działo. Zastanowimy się jeszcze co, bo trzeba jeszcze pomęczyć product management i testy w ogóle z AI-em, bo to są ciekawe rzeczy. Ale to na potem.

Szymon Warda: Pa, pa.

Łukasz Kałużny: Trzymajcie się! Hej!