TL;DR
Poprawianie promptu w kółko, aż coś zadziała, ma wadę: model sam uzupełnia niedopowiedzenia i ważne założenia zapadają bez Twojej akceptacji. Spec Driven Development odwraca kolejność. Najpierw powstaje specyfikacja jako źródło prawdy, a dopiero potem kod. Proces składa się z konstytucji projektu (konwencje, standardy bezpieczeństwa), specyfikacji, planu technicznego, listy zadań i dopiero na końcu implementacji.
Autor pokazuje to na przykładzie newslettera z kodem zniżkowym 10%. Scenariusze, takie jak duplikaty adresów e-mail czy jednorazowość kodu, opisane z góry stają się potem checklistą testów. W praktyce pomaga GitHub Spec Kit, który zamiast zgadywać, oznacza luki znacznikiem [NEEDS CLARIFICATION]. Jest też uczciwa uwaga, kiedy to się nie opłaca, więc zajrzyj, gdzie autor stawia granicę.
Zamiast w kółko poprawiać prompt, aż „jakoś zadziała” – najpierw decyzje, potem kod. Czyli o Spec Driven Development, zanim sam się za nie zabiorę…
Czytaj cały wpis u źródła
