Co to znaczy w praktyce
Vibe coding działa, dopóki z rozwiązania korzystacie tylko wy. Kiedy dołączają kolejne osoby, zaczyna brakować tego, czego w nim nigdy nie było: dokładnej umowy, co to ma właściwie robić.
Rozwój spec-driven spisuje tę umowę, zanim cokolwiek powstanie:
- Problem statement: jaki problem pracownika albo klienta rozwiązujemy.
- Wymagania użytkownika: czego ludzie od tego potrzebują.
- Kryteria akceptacji: po czym poznamy, że jest gotowe.
- Specyfikacja techniczna: jak ma to być zbudowane.
- Plan wdrożenia i testy.
Jako przykłady roboczych narzędzi używamy na szkoleniach BMAD i GitHub Spec Kit.
Kiedy to ma sens
Wtedy, gdy nad rozwiązaniem pracuje więcej osób, gdy ma zachowywać się za każdym razem tak samo, gdy potrzebujecie testów albo gdy przejmuje je ktoś inny niż ten, kto je zbudował.
Dziewięć pytań przed budowaniem
Zanim na szkoleniu ktokolwiek napisze pierwszy prompt, jego grupa odpowiada na dziewięć pytań. To te same pytania, które powinien zadać sobie każdy zamawiający:
- Jaki problem pracownika albo klienta rozwiązujemy?
- Kogo ten problem dotyczy?
- Co osiągnęłoby użyteczne rozwiązanie?
- Czy AI pomaga tylko zbudować rozwiązanie, czy gotowa aplikacja też z niej korzysta?
- Jakie dane wyraźnie podniosłyby wartość rozwiązania?
- Gdzie aplikacja powinna działać?
- Czy to osobiste narzędzie, aplikacja wewnętrzna czy produkt dla klienta?
- Jakiego poziomu bezpieczeństwa, testowania i własności to wymaga?
- Po czym poznamy, że prototyp jest użyteczny?
Większość nieudanych projektów AI wykłada się na tym, że ktoś nie zadał sobie pytania czwartego albo dziewiątego.