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

Słuchajcie Paterietów. Prowadzą Szymon Wardę i Łukasz Kałużny. No dobra Szymon, to o czym dziś? Spec Driven Development! Dobra, to co? Tak powiedziałbym, że, obiecałbym, że przed przedostatni odcinek AI w najbliższym czasie. Tak jasne. Tak jasne. Ale Szymon, wpadłem na pomysł, z którym się Tobą nie podzieliłem. Dzisiaj porozmawiamy sobie o Spec Driven Development na przykładzie GitHub Spec Kita. O tym wiedzieliśmy. 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 inaczej i dzięki, bo niektórzy naprawdę się rozpisywaliście.

To jest tak naprawdę toolkit, To jest zbiór markdownów. Zbiór markdownów, to chciałem powiedzieć, który idzie nam w zestawie szablonów, comment, skilli, definicji agentów. I jedyną rzeczą, którą jest przyjemną, jest instalacja, że przez UV instalujemy w sprawie SpecifyKli i możemy zaintegrować to sobie, wrzucić do naszego projektu. I to jest to ważne, że to Spec Kit ląduje w repo i potem on jest nastawiony na to, żeby go tweakować pod swoje potrzeby. 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? Znęcamy się, bo akurat uruchomimy się gdzieniegdzie w tych opiniach.

To pierwszą komendą, którą... I będziemy mówić o fullu, o pełnej instalacji. Czyli zrobiliście sobie tam specify init project, integration np. cloud. I zaczynamy pierwszym skillem, który jest, to jest Spec Kits Constitution, czyli tworzy plik konstytucji, to są zasady projektu, czyli obowiązkowe testy, biblioteki, inne takie elementy, czyli jak wygląda stos i zasady. Tak, zwane inaczej wishlistą, żeby się trochę ponabijać. Nie, ale tak poważnie mówiąc, to pamiętaj, że mieliśmy rozmowę, że ty znowu nie jesteś fanem Konstytucji. Ja uważam, że ona jest jedną z tych bardziej wartościowych, o ile tam właśnie 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. Wiesz co, Szymon, odeśle też jak to robimy z klientami do Powered by Potopia, bo był taki odcinek, gdzie to opowiadam.

Uważam, dlaczego ja mam z tym problem. Okej, założenie jest dobre, bo też robimy to w bardzo podobny sposób, ale to, co robimy np. w naszym podejściu firmowym, to jest to, że generujemy skrypty i harness. I to jest bardzo ważna różnica, że np. te testy, czy pokrycie kodu, testami w niektórych miejscach, lintery, inne tego typu zabawki, Sonar Cuby, one są wymuszone w konfigu agenta. I są w jakiś sposób odpalane i przekazywane agentowi, a nie, że ja chciałbym. Ustalmy. Są dwie rzeczy generalnie. Jeden to mówisz, że byś chciał, a drugie to mówisz, że sprawdzam. Więc to jedno i drugie jest ważne. Specify... Znaczy patrz, instrukcja jest po to ważna, żeby on ze startu szedł w dobrym kierunku, a potem go tam najwyżej...

To jest taki mój zarzut do Spec Kita, jeden z największych takich zarzutów, że to jest zbiór markdownów bez żadnych hooków, skryptów i innych rzeczy, które powinny być. No bo one są trudniejsze, nie szukamy się, łatwiej jest sobie powibować. Specify. Czyli inicjalnie jak chcemy cokolwiek w ogóle zrobić. I właściwie tyle. Tam mamy opisać, opisujesz co zrobić. Takie już jest to, można powiedzieć. 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 tej 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 np. ty drogi, chciałbym zbudować to, wiem, że już powinno być to w tym miejscu, chciałbym użyć XYZ. Czyli od razu zrobić bardzo dużego brain dumpa, a nie tylko prosty user story. No i tu właśnie dochodzimy do Clarify, który jest krokiem opcjonalnym, który jest takim... Próbą, gdzie agent próbuje się ciebie dopytać, doprecyzować, o co w ogóle chodzi. I ja właśnie tu widzę większą wartość w ogóle z całego Spec Kita, że to nie jest to, o czym ty mówisz, że nie jest to opcja, że ja mam takiego, mam pomysł, to po prostu to lecimy w takim razie. Nie. Ten właśnie krok do pytania, czy chcesz zrobić tak, czy chcesz zrobić inaczej, o co ci chodzi, dokładnie, żeby ten człowiek o niej 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 homonta, ale myślowego i na człowieka. Żeby dowiedzieć się, o co mu właściwie chodzi. Żeby to user story, które właśnie z tego Specify wynika, żeby ono nie było takim wyrzygiem. Przecież myślenie jest tak bolesną czynnością niekiedy. Dlatego właśnie musimy mieć homonto na człowieka w postaci Spec Kita. Dobra. I to nam poprawia tę specyfikację. I teraz kolejny zarzut mój, to jest Spec Kit plan. Plan mody w narzędziach są okej. To też, powiedzmy sobie wprost, potrafią być okej. Czyli tu wchodzi stack, architektura, kontrakty, struktura danych, kontrakty API. Okej. I to jest komitowane po specyfikacji, to jest kolejny plik, który jest komitowany do repo.

Powinien być. Tak, powinien być. No to pamiętam, że mieliśmy rozmowę, że nie jestem takim fanem tego, ale no dobra. Raczej nie jestem, wiesz co, mam problem, że to co też zrobiliśmy w tym firmowym podejściu, że Specify i plan jest zmerge'owane w jedną i nazywaliśmy go tutaj researchem całym. Zgodzę się. Dla mnie to, co jest w Spec Kicie, to jest to, że faktycznie Specify powinno być bardziej rozbudowane. Właśnie ten elementu researchowego, elementu badania, elementu czy aby na pewno i to, co swego razu w Google było, że a może my byśmy tego nie potrzebowali? Chcemy to robić? No nie? Tego mi nam trochę brakuje natywnie, ale dlatego mówię, to jest coś, co trzeba rozbudowywać i tyle. 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 jest 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, ok, tam się dzieją, ale one też nie są jasno wyszczególnione, że pomóż mi zaplanować testy. Znaczy i znowu, wracamy do tego, że ideowo jest ok, to co potrzebujemy to jest homonto, ale na człowieka. Myślowe, bo to jest dobre właśnie. Bo tak, jak nie doprecyzujemy, ok, możemy powiedzieć, że w konstytucji właśnie będzie, że musimy mieć pokrycie, musimy mieć test i tak dalej. Rozumiem, że tego Spec Kit tam nie zastąpi naszego procesu wytwarzania, tego wszystkiego, co potrzebujemy zbudować. I tyle. Dobra. I teraz Specify Tasks. I to jest ta rzecz, którą ty bardzo brzydko się 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.

Ale się zgadzam, mi chodzi o samą ideowo, że po taskach powinien być ktoś, kto stwierdzi, czy to jest taki czek ostateczny, czy to nie odpłynął. Tak, czy nie odpłynął, tylko kurde... Dobra, tylko pytanie teraz... Dobra, przejdźmy, skończmy to i zaraz zadam jedno duże pytanie. Dobrze. Teraz jest ta skill do orkiestracji, czyli implement. Okej, 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 artyfaktami. Dopisuje to, czego brakuje. No właśnie, dopisuje, czy może zmieniać specyfikację, czy właściwie co robi. Bo to jest podobne, to jest inaczej nazywany 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ć.

Teraz mamy problem taki, możesz zrobić, żebyś miał jakieś większe coś, tylko żebyś miał jakieś takie, nie wiem, epika, Trochę zaczyna brakować. Teraz inną. Poprawki bugów. I co teraz zrobić? Bo teraz albo po prostu mówisz mu napraw i on to zrobi, no i to brzmi całkiem okej, ale w tym momencie Spec Kit specjalnie zaktualizujesz, albo tworzysz nowe specify na poprawę buga i do prostego buga, czekaj, otrzymujesz sześć plików. 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-tap na plan mode. Zrób mi na przykład, jeżeli masz fajnie zrobione repo, projekt, to zrób mi sesję debugowania.

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 one się tam zgodzą, że 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ą. Albo nikomu się na nic nie chce zrobić, tylko rzucają pomysł i przerzucają to na zadzień i tak coś do mnie wróci. I ustalmy, czemu nie robiliśmy pełnej analizy, bo to było drogie, czasochłonne i tak dalej, no i prawie nie Każdy potrzebuje dupu krytyki tak naprawdę, a tak to się wystawia tylko analityk. Ale właśnie tak chodzi, że z tymi właśnie narzędziami typu specify, typu właśnie krytyka i tak dalej, możemy właśnie mieć tą lepszą dokumentację.