Spec-driven development

Co to jest spec-driven development

Specyfikacja to dokument, który mówi, co ma powstać, zanim ktokolwiek zacznie pisać kod. Nie opisuje każdej linijki kodu. Podaje cel, zakres, czyli co należy do pracy, a co nie, oraz warunki, które muszą być spełnione, gdy praca jest skończona.

Praca przebiega w trzech krokach:

• Specyfikacja. Osoba pisze ją sama albo z pomocą agenta, a potem czyta i poprawia, zanim zacznie się realizacja.
• Realizacja. Agent kodujący dostaje cały dokument i pracuje według niego. Gdy czegoś w nim brakuje, powinien zapytać, a nie zgadywać.
• Sprawdzenie. Wynik porównuje się z tym, co zapowiadała specyfikacja. Praca zostaje przyjęta albo wraca do poprawek.

Specyfikacja jest osobnym dokumentem, a nie jedną z wiadomości w rozmowie z agentem. Możesz ją poprawić, dać innej sesji albo innej osobie i po tygodniu sprawdzić, co było ustalone. Gdy zespół zmienia zdanie, zmienia dokument.

Spec-driven development z agentami AI

W agentic coding, gdzie agent AI wykonuje całe zadania w kodzie, specyfikacja jest zadaniem agenta. Krótka prośba na czacie zostawia wiele spraw otwartych, a agent rozstrzyga każdą po swojemu albo zatrzymuje się, żeby Cię zapytać. Specyfikacja rozstrzyga je, zanim praca się zacznie. Dla agenta zwykle zawiera:

• Cel i zakres. Po co jest ta praca, co do niej należy, a co zostaje poza nią, żeby agent nie zrobił za mało ani nie zmieniał niczego przy okazji.
• Kryteria akceptacji. Sprawdzalne stwierdzenia, które muszą być prawdziwe, gdy praca jest skończona. Każde oceniasz jednym słowem, tak albo nie, gdy agent zgłosi pracę.
• Sprawdzenie, które agent uruchamia sam. Testy albo budowanie projektu, które kończą się sukcesem albo błędem, żeby agent mógł sprawdzić swoją pracę, zanim ją zgłosi.

Liczy się też wielkość. Specyfikacja dla agenta powinna opisywać jedną część pracy, którą jedna sesja agenta zrealizuje w całości. Większą pracę, na przykład całą funkcję opisaną w PRD, dzieli się na kilka specyfikacji w jednym epiku i zapisuje między nimi kolejność.

Pracę wykonuje agent, a wynik ocenia osoba: porównuje go ze specyfikacją i przyjmuje albo odsyła do poprawek. Taki sposób pracy, w którym w ważnych punktach decyduje osoba, nazywa się human-in-the-loop. Wpis Jak napisać plan, który agent AI zrealizuje bez zgadywania pokazuje krok po kroku, na przykładzie, jak napisać taką specyfikację.

Spec-driven development w featureloom

W featureloom specyfikacją jest plan: dokument w markdownie na tablicy kanban. Piszesz go sam przyciskiem Nowy plan, od pustego dokumentu, generujesz w aplikacji z wklejonego tekstu albo dokumentu PDF lub Word albo prosisz agenta w konsoli, żeby napisał go z Twojego materiału, na przykład z transkryptu spotkania, który dajesz mu jako plik.

Plan generowany w aplikacji powstaje według szablonu planu projektu, a prompt Planista każe agentowi pisać plany w sekcjach tego szablonu. Wbudowany szablon prosi między innymi o cel, zakres, kroki, kryteria akceptacji i definicję ukończenia. Kryteria akceptacji to sprawdzalne stwierdzenia, które muszą być prawdziwe, gdy praca jest skończona. Szablon dopasujesz do swojego zespołu na ekranie Ustawienia projektu, w zakładce Szablon planu.

Polecenie z planu, na przykład featureloom realizator FAK-14, daje agentowi w jednym wywołaniu prompt z procesem zespołu, cały dokument planu i dokumenty zrealizowanych planów, od których ten plan bezpośrednio zależy. Prompt Realizator, który ma każda nowa organizacja, każe agentowi robić tylko to, co jest w planie, a gdy plan czegoś nie rozstrzyga, pytać, zamiast zgadywać. Pytanie i Twoja odpowiedź trafiają do dokumentu planu.

Na koniec ten sam prompt każe agentowi zgłosić realizację z notą: co zrobił, w czym odszedł od planu i dlaczego, a czego nie zrobił. Ty porównujesz wynik z planem i wybierasz Przyjmuję albo Nie przyjmuję, z powodami albo bez. Werdykt wydaje tylko osoba w aplikacji, a werdykt wysłany z konsoli serwer odrzuca. Po odrzuceniu agent czyta werdykt i wraca do poprawek.

Plan może się zmieniać razem z tym, czego dowiaduje się zespół. Każdy zapis, który zmienia tekst, to nowa wersja, a plan pamięta 100 ostatnich wersji. Całą drogę planu, od tablicy do odbioru, pokazuje strona Jak działa featureloom. Jak ten sposób pracy wygląda z Claude Code, od specyfikacji do przyjętego wyniku, zobaczysz na stronie Spec-driven development z Claude Code.