Sześć plików do jednego buga? - Spec Kit pod lupą
"Czekaj, otrzymujesz 6 plików." 🎯 Tyle kosztuje jedna poprawka buga w GitHub Spec Kit, jeśli bierzesz go dosłownie. Bierzemy na warsztat spec-driven development, czyli generowanie kodu z UML-a w nowym wydaniu: agenci AI zamiast generatorów, Markdown zamiast diagramów. Idziemy krok po kroku. Constitution: zasady projektu czy lista życzeń? Clarify to według Szymona "chomąto na człowieka w postaci speckita". Pliki tasków w repo mają wartość "okrągłe zero. Nawet może przepraszam, pomyliłem się ujemna". Łukasz dorzuca swoje: zbiór Markdownów bez hooków i skryptów to nie jest harness dla agentów. ⚠️ Potem robi się gęsto. Łukasz traktuje specyfikacje jak ADR-y i chce "wychłostać agenta za próbę zmiany czegoś w starych specyfikacjach". Szymon ripostuje o projekcie żyjącym 5 lat: "Dosłownie umrzesz od nich." Do tego spór o C4, waterfall jako spychologia i model Fable, który chciał wyciąć 70% skilli. 🤖 Czy specyfikacja jako źródło prawdy to mit, skoro na końcu i tak wygrywa kod? A teraz nie ma co się obijać! 👉 Wpadajcie na naszego Discorda: https://discord.gg/78zPcEaP22 ! 🔥Tam możecie się z nami pokłócić o przyspieszanie SQL-a, podyskutować o naiwnych nadziejach na AI albo po prostu podzielić się swoimi IT-owymi przemyśleniami. Słuchasz Patoarchitektów dzięki PROTOPII – firmie, w której Łukasz i Szymon działają na co dzień, wspierając zespoły IT na każdym etapie: od projektowania, przez wdrożenia i migracje, aż po optymalizację i zabezpieczenia. Oferujemy też mentoring i szkolenia dostosowane do potrzeb każdej firmy, niezależnie od wielkości. Sprawdź nas: 👉 protopia.tech - Nasze sociale i linki - Materiały do odcinka - Pato szkolenia 00:00:00 Intro00:02:01 Geneza i założenia Spec Driven Development oraz przegląd podejść00:06:18 GitHub Spec Kit: instalacja, konstytucja i brak hooków00:09:00 Kroki Specify i Clarify: kontekst zadania i doprecyzowanie00:10:45 Kroki Plan, Tasks i Analyze: planowanie, testy i review00:16:28 Implementacja, warianty workflow i podejście Anthropic00:19:18 Kiedy SDD ma sens: zespół, human in the loop i rozmiar zadania00:23:28 Specyfikacje a dokumentacja: ADR-y, C4, źródła prawdy i harnessy00:28:33 Czy SDD to powrót do Waterfalla i sprzątanie artefaktów00:32:51 Przyszłość specyfikacji przy coraz mądrzejszych modelach00:35:23 Podsumowanie: Spec Kit jako narzędzie do strukturyzacji myślenia00:35:38 Polecane materiały i odcinek o Open Mercato00:36:31 Zakończenie i zaproszenie do komentarzy
Bo to jest takie wypchnięcie nogą, oby było w miarę okej. To nie tak, nie ta opcja. Dobrze. Więc to jest taki tak, to znowu jest krytyk. Tam są jeszcze jakieś checklisty inne, że takie bardzo, bardzo dodatkowe elementy. Żeby to usolidaryzować, żeby było jako i szósty githubowe, żeby z tego zrobić taki trochę flow, potencjalnie na większe zrównolegle. 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? 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.
Nie, pojawiają się już ruchy takie właśnie, żeby właśnie odpalać agentów, którzy będą potem scalali... Rekonsyliowali 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... Prosisz się o halucynacje tam. I jak ci z kodu schalucynuje specyfikację, to potem jesteś wiadomo gdzie, bo już masz schalucynowane specyfikacje. Tak, w tym miejscu tak. Dlatego teraz najgorsze jest to, że w tym miejscu możemy trafić na takie... Kurde, że zaczyna ci tą speckę, której nie trzeba. Dokładnie. Inicjalnie specka, ale potem to będzie opis funkcjonalności. Dokumentacja de facto, trzymająca się na wysokim poziomie typu architektura, typu flowy biznesowe, sens tego, czyli z niegieramów C4, C1, C2, niżej nie schodzimy.
Ty wiesz o tym, że ja zostawię mem, który wrzucam, czyli Agile na sztandarach. I czy to jest Agile? Nie, to Waterfall w Jirze. Nie, to jest spychologia, że ktoś zrobił user story, że chce mieć takiego feature'a i potem była wielka dyskusja. To jest po prostu shit in, shit out, puszczone na pełen flow. Ale poprzednio też nawet w odcinku dyskutowaliśmy, że lepiej, żeby dał ktoś ci link do czata, niż wkleił to do user story. Że to byłby lepszy user story. Co jest w AWS-owym podejściu swoją drogą, że tam komitujemy całą rozmowę do repo i dla mnie to już ma pewien sens. Wiecie, teraz mnie trochę irytuje, teraz będzie marudzenie starego człowieka odnośnie tego, że tak sobie marudzimy, że ole, jejku, jejku, tak wszystko fajnie było i widziałem taki cytat.
Pokazano wszystkie 3 dopasowania. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Rozmowa o Spec Driven Development i jego zastosowaniu w GitHub Spec Kit.
Analiza specyfikacji i jej roli w procesie Spec Driven Development.
Opis narzędzia GitHub Spec Kit i jego zastosowania w praktyce.
Krytyka i propozycje dotyczące narzędzia Spec Kit oraz dyskusja na jego temat.
Podsumowanie dyskusji i refleksje na temat przyszłości Spec Driven Development.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
Intro
Geneza i założenia Spec Driven Development oraz przegląd podejść
GitHub Spec Kit: instalacja, konstytucja i brak hooków
Kroki Specify i Clarify: kontekst zadania i doprecyzowanie
Kroki Plan, Tasks i Analyze: planowanie, testy i review
Implementacja, warianty workflow i podejście Anthropic
Kiedy SDD ma sens: zespół, human in the loop i rozmiar zadania
Specyfikacje a dokumentacja: ADR-y, C4, źródła prawdy i harnessy
Czy SDD to powrót do Waterfalla i sprzątanie artefaktów
Przyszłość specyfikacji przy coraz mądrzejszych modelach
Podsumowanie: Spec Kit jako narzędzie do strukturyzacji myślenia
Polecane materiały i odcinek o Open Mercato
Zakończenie i zaproszenie do komentarzy