--- title: "Zanim kupicie rozwój sterowany specyfikacją, posortujcie backlog" url: "https://predictes.com/pl/blog/zanim-kupicie-rozwoj-sterowany-specyfikacja-posortujcie-backlog" description: "Przy rozwoju sterowanym specyfikacją część pracy staje się dużo tańsza, a część wolniejsza. To, która przeważa w Waszym backlogu, rozstrzyga o uzasadnieniu biznesowym." --- # Zanim kupicie rozwój sterowany specyfikacją, posortujcie backlog 14 maja 2026·3 min czytania·predictes Oferta kodu pisanego przez agentów zwykle sprowadza się do jednej liczby: o ile szybciej będzie powstawać oprogramowanie. To odpowiedź w złym kształcie. Rozwój sterowany specyfikacją jedną pracę czyni znacznie tańszą, a inną wolniejszą, a uzasadnienie biznesowe zależy prawie wyłącznie od tego, jaka jest proporcja w Waszym backlogu. Tę proporcję da się oszacować, zanim ktokolwiek cokolwiek kupi — i potrafią to zrobić ludzie, którzy już tę pracę znają. ## Gdzie metoda zmienia rachunek Gdy agenci wytwarzają implementację ze specyfikacji, koszt zmiany przesuwa się z pisania kodu na precyzyjne określenie, co ten kod ma robić. Taka zamiana jest świetnym interesem, gdy określić jest łatwo, a napisać pracochłonnie — i kiepskim w sytuacji odwrotnej. Dla osoby trzymającej budżet zmienia to samo pytanie. Nie brzmi ono już: czy metoda w ogóle działa. Brzmi: do jakiej części naszej pracy pasuje i czego reszta tej pracy potrzebuje najpierw. **Podobna praca w dużych ilościach.** Integracje, adaptery, migracje danych, warstwa CRUD wewnętrznego systemu. Wzorzec jest znany, kryteria akceptacji da się zapisać, a większość dotychczasowego kosztu to pisanie i sprawdzanie. Tu metoda się zwraca. **Kod dobrze pokryty testami.** Generowana zmiana jest dokładnie tak bezpieczna, jak testy, które ją oceniają. Obszar z dobrym pokryciem przyjmie generowany kod; obszar bez pokrycia przyjmie zobowiązanie. **Stabilna intencja.** Praca, przy której zamawiający wiedzą, czego chcą, zanim to powstanie. Specyfikacja napisana raz i raz zrecenzowana jest tania. Przepisywana po każdym pokazie już nie. ## Gdzie go nie zmienia **Praca eksploracyjna.** Badania, prototypy, nowy pomysł produktowy. Specyfikacja istnieje dopiero po eksperymencie, więc pisanie jej najpierw jest pisaniem fikcji. **Naprawdę nowy projekt.** Gdy trudną częścią jest decyzja o architekturze, precyzyjną specyfikację pisze się trudniej niż kod, a metoda dokłada krok, zamiast go usuwać. **Kod, którego nikt nie rozumie.** Obszary zastane, bez testów i bez właściciela. Start w takim miejscu to najpewniejszy sposób, żeby dojść do wniosku, że metoda nie działa — podczas gdy w rzeczywistości zawiódł wybór obszaru. BadaniaKod bez testówZmiana architekturyNowe funkcjeMigracje danychIntegracje i adaptery Metoda spowalniaMetoda się opłaca Położenie to reguła kciuka. O tym, gdzie naprawdę leży każda pozycja, rozstrzyga Wasz backlog. ## Posortujcie backlog, zanim kupicie Użyteczne ćwiczenie zajmuje popołudnie. Weźcie pracę dowiezioną w ostatnich dwóch kwartałach albo zaplanowaną na dwa kolejne i rozłóżcie każdą pozycję na trzy stosy: dało się ją precyzyjnie wyspecyfikować przed budową; nie dało się; generowanie nie byłoby bezpieczne, bo nie było testów. Proporcje między stosami są uzasadnieniem biznesowym. Backlog zdominowany przez pierwszy stos to mocny kandydat. Zdominowany przez drugi oznacza, że ograniczeniem jest jasność tego, co ma powstać, a tego żadna metoda pisania kodu nie naprawi. Zdominowany przez trzeci oznacza, że pierwszą inwestycją jest pokrycie testami — które zwraca się z agentami albo bez nich. Ćwiczenie mówi też, kto powinien siedzieć przy stole. Uczciwie posortować stos potrafią inżynierowie i liderzy, którzy tę pracę wykonali, a nie ci, którzy ją planowali. ## Jak wygląda dobry wynik Nie jako jednakowe przyspieszenie. Dobry wynik to czytelna mapa: te obszary i te rodzaje pracy idą przez specyfikacje i agentów, te zostają tak, jak są, a ten najpierw potrzebuje testów. Zespoły pracujące w pierwszej grupie spędzają mniej czasu na implementacji, a więcej na specyfikacji i przeglądzie, a czas od decyzji o zmianie do jej działania skraca się właśnie w tych obszarach. Gdzie indziej niewiele się zmienia — i to w porządku, bo nigdy nie miało się zmienić. Taka mapa ma też wartość sama w sobie. Mówi zarządowi, gdzie pieniądze na metodę pracują, a gdzie lepiej wydać je na testy albo na doprecyzowanie tego, co ma powstać. ## Na co uważać w ofercie Dostawca obiecujący jednakowe przyspieszenie całej Waszej pracy nie przyjrzał się tej pracy. Uczciwa odpowiedź różni się między obszarami, a wiedza, który obszar jest którym, to większość tego, za co płacicie. Równie ostrożnie podejdźcie do pilotażu proponowanego w najtrudniejszej części kodu, „żeby sprawdzić metodę w skali”. Coś sprawdzi — zwykle nie to, co trzeba — a wniosek zostanie wyciągnięty o metodzie, a nie o wyborze. ## Jak do tego podchodzimy [Rozwój sterowany specyfikacją](https://predictes.com/pl/services/ai-agents-spec-driven-development) zaczynamy w ograniczonym, dobrze rozumianym i dobrze przetestowanym obszarze, od dwóch–trzech prawdziwych funkcji wyspecyfikowanych porządnie i otwarcie mierzonego poziomu błędów. Jeśli liczby nie pozwalają poszerzać, to uprawniony wynik — i lepiej znać go po czterech tygodniach niż po czterech kwartałach. - spec-driven - kodowanie z AI - uzasadnienie biznesowe - backlog ## 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)