--- title: "Rozwój sterowany specyfikacją nie kupi Wam mniejszego zespołu" url: "https://predictes.com/pl/blog/rozwoj-sterowany-specyfikacja-nie-kupi-wam-mniejszego-zespolu" description: "Uzasadnienie budżetowe kodu pisanego przez agentów bywa uzasadnieniem kadrowym. Naprawdę zmienia się to, na co idzie czas inżynierów i których umiejętności brakuje." --- # Rozwój sterowany specyfikacją nie kupi Wam mniejszego zespołu 13 lipca 2026·3 min czytania·predictes Gdy kod pisany przez agentów trafia na rozmowę budżetową, często przychodzi jako argument kadrowy. Skoro implementację wytwarzają agenci — brzmi rozumowanie — ta sama mapa drogowa wymaga mniej inżynierów. To zrozumiała nadzieja, a planowanie wokół niej to jeden z droższych błędów, jakie można w tym obszarze popełnić. Rozwój sterowany specyfikacją przesuwa to, na co idzie czas inżynierów. Nie usuwa potrzeby tego czasu, a dostawca obiecujący inaczej sprzedaje coś innego niż tę metodę. ## Gdzie ten czas idzie zamiast tego Gdy implementacja tanieje, trzy czynności, dotąd wciskane między okresy pisania kodu, stają się właściwą pracą. **Specyfikowanie.** Zapisanie intencji, ograniczeń, kryteriów akceptacji i tego, co jest poza zakresem — na tyle precyzyjnie, żeby kompetentny agent albo nowy inżynier zbudował z tego to samo. Większość zespołów szybko odkrywa, że ich dotychczasowe zgłoszenia nie były nawet blisko tego poziomu, a domknięcie tej luki wymaga czasu najbardziej doświadczonych osób. **Niezależne testowanie.** Testy akceptacyjne wyprowadzone ze specyfikacji, a nie z wygenerowanego kodu, bo testy pisane z implementacji po prostu ją potwierdzają. Ktoś musi odpowiadać za tę niezależność. **Przegląd.** Najpierw specyfikacja, potem wygenerowana zmiana czytana względem niej — w zmianach dość małych, żeby przejrzeć je porządnie. Zdolność przeglądu staje się ograniczeniem, pod które wymiaruje się cały potok. Nadzieja kadrowa - –Mniej inżynierów przy tej samej mapie drogowej - –Szybkość mierzona ilością wygenerowanego kodu - –Przegląd jako formalność - –Narzędzie zainstalowane przez dostawcę Co naprawdę się zmienia - →Czas inżynierów przechodzi na specyfikowanie, testy i przegląd - →Szybkość mierzona od decyzji do działającej zmiany - →Zdolność przeglądu jako ograniczenie, pod które wymiaruje się potok - →Metoda, którą prowadzi Wasz własny zespół ## Kogo zaczyna brakować W tej metodzie najbardziej liczą się ludzie, którzy potrafią precyzyjnie powiedzieć, co system ma robić, i rozpoznać, kiedy wygenerowany kod robi coś subtelnie innego. Zwykle są to doświadczeni inżynierowie ze znajomością dziedziny — ci, bez których organizacja najtrudniej się obywa. Warto wiedzieć, kim są, zanim porozmawiacie z jakimkolwiek dostawcą, bo to ci sami ludzie będą musieli oddać swój czas pilotażowi. Realistyczne uzasadnienie biznesowe nie brzmi więc: mniej ludzi przy tym samym wyniku. Brzmi: więcej dowiezionych zmian od ludzi, których już macie, w tych rodzajach pracy, do których metoda pasuje — przy czym najbardziej doświadczeni inżynierowie spędzają więcej czasu na rozstrzyganiu i sprawdzaniu, a mniej na pisaniu. To skromniejsza obietnica niż redukcja etatów. Za to taka, która rok później nadal się broni. ## Ile kosztują pierwsze miesiące Metoda ma krzywą uczenia się i warto ją uczciwie zabudżetować. Pierwsze specyfikacje powstają dłużej, niż powstałby kod, bo zespół uczy się, co znaczy „precyzyjnie” w jego własnej dziedzinie. Przegląd na początku wydaje się wolniejszy, bo recenzenci czytają intencję, zanim przeczytają diff. Spodziewajcie się, że pierwsze tygodnie będą wyglądać na spowolnienie, i oceniajcie metodę po kolejnych tygodniach — w tych rodzajach pracy, dla których ją wybrano. Plan obiecujący oszczędności od pierwszego sprintu odczyta ten początkowy dołek jako porażkę. ## Odpowiedzialność się nie przesuwa Za zmianę odpowiada inżynier, który ją zrecenzował i scalił — dokładnie jak wcześniej. To nie formalność. To powód, dla którego przeglądu nie wolno rozluźnić, gdy rośnie przepustowość generowania, i powód, dla którego plan traktujący przegląd jak narzut do przycięcia prędzej czy później wypuści coś, czego nikt nie rozstrzygnął. Dla osoby trzymającej budżet ma to praktyczną konsekwencję: praktyka przeglądu jest częścią tego, co kupujecie, i powinna być widoczna w planie, z przydzielonym czasem. Inżynierowie, którzy scalają najwięcej generowanego kodu, niosą też największą odpowiedzialność, a ich czas na przegląd trzeba chronić, a nie ściskać. ## Jak rozpoznać rozsądną propozycję Rozsądna propozycja mówi, od jakiego rodzaju pracy zacznie. Opisuje, co stanie się z czasem inżynierów, a nie z ich liczbą, traktuje zdolność przeglądu jako ograniczenie i zostawia metodę Waszemu zespołowi, a nie dostawcy. Propozycja, w której pozycja oszczędności to głównie wynagrodzenia, przyjęła wniosek, zanim zaczęła liczyć. Zanim przeczytacie jakąkolwiek propozycję, warto zadać własnym liderom technicznym trzy pytania. Kto z naszych ludzi już dziś potrafi napisać specyfikację, z której ktoś inny by zbudował? Kto dobrze robi przegląd i ile wolnego czasu ma na to w tygodniu? Gdzie nasze testy są na tyle dobre, żeby zaufać generowanemu kodowi? Odpowiedzi mówią, jak szybko da się wprowadzić metodę, i są warte więcej niż jakikolwiek benchmark przyniesiony przez dostawcę. ## Jak do tego podchodzimy [Rozwój sterowany specyfikacją](https://predictes.com/pl/services/ai-agents-spec-driven-development) ustawiamy w Waszych repozytoriach i CI, z Waszymi inżynierami prowadzącymi metodę i nazwanymi trybami porażki. Zwykle trwa to cztery do ośmiu tygodni, a potem jest jedno spotkanie, gdy zespół już z metodą pożyje. Gdybyśmy rok później nadal prowadzili Wasz potok, znaczyłoby to, że ustawiliśmy go źle. - spec-driven - zespoły inżynierskie - uzasadnienie biznesowe - odpowiedzialność ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)