Spec-Driven Development: programowanie oparte na specyfikacji

Spec-Driven Development, w skrócie SDD, to podejście, w którym specyfikacja jest głównym nośnikiem intencji projektu. Zanim agent AI zmieni kod, powstaje dokument opisujący problem użytkownika, zakres, ograniczenia, scenariusze oraz kryteria akceptacji. Kolejne artefakty rozwijają tę samą decyzję: projekt techniczny wyjaśnia sposób realizacji, a lista zadań rozbija pracę na weryfikowalne kroki. Kod nie przestaje być ważny, ale nie jest już jedynym miejscem, w którym trzeba odgadywać, co miało powstać.

W pracy z AI SDD odpowiada na typowy problem prompt-first: wymagania żyją w rozmowie, potem znikają w historii czatu, a agent wypełnia luki własnymi założeniami. To bywa wystarczające dla małej, odwracalnej poprawki. Przy stronie sprzedażowej, automatyzacji leadów albo funkcji w produkcie jeden niejasny skrót może jednak zmienić zachowanie formularza, dane lub koszt procesu. Specyfikacja daje agentowi kontekst, który można przeczytać, poprawić i zatwierdzić przed wykonaniem. Daje też człowiekowi punkt odniesienia podczas review.

Dobra specyfikacja nie musi być korporacyjnym dokumentem. Dla solopreneurki może mieć jedną stronę i odpowiedzieć na sześć pytań: dla kogo jest zmiana, jaki problem rozwiązuje, co dokładnie ma się wydarzyć, czego nie wolno zmieniać, po czym uznamy wynik za poprawny oraz jak go sprawdzimy. Kryteria powinny być obserwowalne. Zamiast „formularz ma działać lepiej”, zapisz: „po wysłaniu poprawnego adresu użytkownik widzi komunikat sukcesu, zapis idzie przez wskazane API, a błąd dostaje czytelną informację”. Takie zdania są użyteczne dla biznesu, testów i agenta.

Typowy przepływ SDD wygląda tak: specyfikacja, plan, zadania, implementacja i walidacja. Spec Kit opisuje tę sekwencję jako Spec → Plan → Tasks → Implement. Narzędzia różnią się nazwami plików, lecz sens jest podobny. Kiro tworzy osobno wymagania z historyjkami i kryteriami akceptacji, dokument projektu oraz listę śledzonych zadań. Nie trzeba instalować konkretnego frameworka, aby pracować tą metodą. Ważne, żeby artefakty były zapisane razem z projektem i żeby każde następne polecenie odwoływało się do nich, a nie tylko do pamięci bieżącej rozmowy.

Przykład: chcesz dodać na stronie konsultacji kwalifikację zapytań przed rezerwacją. W specyfikacji opisujesz odbiorcę, pytania, dane przekazywane dalej, reguły odrzucenia, ochronę danych i kryteria akceptacji. Plan wskazuje komponent formularza, endpoint, walidację oraz testy. Zadania oddzielają copy, implementację i sprawdzenie produkcyjnego przepływu. Agent może teraz zaproponować kod, ale nie powinien sam wybierać pytania o dane wrażliwe, zmieniać ceny usługi ani wysyłać wiadomości. SDD zamienia ogólne „zrób lejek” w kontrolowany zakres pracy.

Specyfikacja powinna wskazywać granice, nie tylko funkcje. Dodaj zależności, istniejące źródło prawdy, wymagania prawne, zachowania błędów, elementy poza zakresem i sposób wycofania zmiany. Jeśli zadanie dotyczy automatyzacji, opisz też zdarzenie startowe, dane wejściowe, uprawnienia, działanie końcowe i punkt akceptacji człowieka. Po implementacji porównaj wynik z każdym kryterium, uruchom testy oraz sprawdź realny scenariusz. Sam komunikat agenta, że „gotowe”, nie jest walidacją.

SDD nie gwarantuje dobrego produktu i nie zastępuje rozmowy z klientem, projektowania ani testów. Źle napisany dokument może jedynie utrwalić zły pomysł, a zbyt szczegółowa specyfikacja dla drobnej zmiany spowolni pracę. Dobieraj ciężar procesu do ryzyka. Jednoliniowa poprawka tekstu zwykle nie potrzebuje pełnego planu. Zmiana płatności, routingu, danych klientów lub automatyzacji sprzedaży już tak. Największa wartość SDD nie polega na większej liczbie plików, lecz na tym, że intencja zostaje jawna, sprawdzalna i przenośna między ludźmi oraz agentami.