--- title: "Zanim ruszy pilotaż, spiszcie, co by go zatrzymało" url: "https://predictes.com/pl/blog/zanim-ruszy-pilotaz-spiszcie-co-by-go-zatrzymalo" description: "Pilotaż kodu pisanego przez agentów bez reguły przerwania nigdy nie upada, tylko się przedłuża. Kryteria poszerzenia i przerwania uzgodnijcie przed pierwszą specyfikacją." --- # Zanim ruszy pilotaż, spiszcie, co by go zatrzymało 12 września 2026·3 min czytania·predictes Większość pilotaży kodu pisanego przez agentów ma datę startu, zakres i pokaz na końcu. Niewiele ma spisaną odpowiedź na pytanie, które najbardziej obchodzi tego, kto za nie płaci: jaki wynik sprawiłby, że przerwiemy? Bez tej odpowiedzi pilotaż nie może się nie udać. Daje wyniki mieszane, jak to pilotaże, a wyniki mieszane czyta się jako powód do przedłużenia. Pół roku później metoda jest w połowie przyjęta w kilku zespołach, nikt nie umie powiedzieć, czy działa, a rozmowa budżetowa dotyczy kosztów utopionych zamiast dowodów. ## Co uzgodnić przed pierwszą specyfikacją Sam pilotaż powinien być krótki i ograniczony: dobrze rozumiany, dobrze przetestowany obszar kodu i dwie–trzy prawdziwe funkcje wyspecyfikowane z precyzją, jakiej wymaga metoda. Rozstrzygającym czyni go to, co uzgodni się przed startem. **Punkt odniesienia.** Ile ten sam rodzaj pracy kosztuje dziś — w czasie kalendarzowym i w pracy inżynierów — od decyzji do działającej zmiany. Nie musi być precyzyjny; musi być uzgodniony. Bez punktu odniesienia każdy wynik wygląda na postęp. **Co będzie mierzone.** Ile trwa napisanie i recenzja specyfikacji. Ile wygenerowanych zmian przechodzi przegląd i ile poprawek wymagają pozostałe. Ile defektów ucieka do późniejszych etapów. Mierzone otwarcie, z porażkami policzonymi, a nie wygładzonymi. **Kryterium poszerzenia.** Wynik, przy którym metodę rozszerza się na większą część kodu, zapisany w kategoriach tych miar. **Kryterium przerwania.** Wynik, przy którym się tego nie robi. Zapisany równie precyzyjnie i traktowany jako uprawniony wynik, a nie powód do wstydu. **Kto rozstrzyga.** Jedna wskazana osoba z uprawnieniem do przerwania, która zgodziła się na kryteria z góry. Nie komitet — komitet zwykle znajdzie powód, żeby przedłużyć. ## Dwa wybory, które wcześnie przesądzają wynik **Obszar.** Najsłabiej rozumiana część kodu gwarantuje przerwanie z niewłaściwego powodu. Banalnie łatwa gwarantuje decyzję o poszerzeniu, która nigdzie indziej się nie utrzyma. Właściwy obszar jest zwyczajny, dobrze przetestowany i reprezentatywny dla pracy, której robicie dużo. **Ludzie.** Pilotaż prowadzony wyłącznie przez najbardziej entuzjastycznego inżyniera mierzy tego inżyniera. Weźcie do niego kogoś sceptycznego. To jego odczytanie wyniku reszta organizacji uzna za wiarygodne. ## Jak czytać wynik Wyniki rzadko wskazują jednoznacznie w jedną stronę, a użyteczna lektura polega na zrozumieniu dlaczego. Większość pracy wykonują dwa pytania: czy specyfikację trudno było napisać i czy wygenerowane zmiany wymagały wielu poprawek? Mało poprawekDużo poprawek Poszerzyć na podobneDziała, ale koszt specyfikacji rozstrzyga, gdzie się opłaca. PoszerzyćDowody wspierają rozszerzenie na większą część kodu. Tu przerwaćTen obszar nie pasuje do metody — i to warto wiedzieć. Zaostrzyć kryteriaSpecyfikacje wyglądają na łatwe, ale są mgliste albo testy są słabe. Trudno spisaćŁatwo spisać Łatwo spisać i mało poprawek — to argument za poszerzeniem. Trudno spisać i dużo poprawek — to argument za przerwaniem w tym obszarze, co mówi coś o obszarze, a niekoniecznie o metodzie. Ciekawe są dwa przypadki mieszane. Specyfikacje łatwe do napisania, a zmiany wymagające wielu poprawek, zwykle znaczą, że kryteria akceptacji były bardziej mgliste, niż wyglądały, albo testy nie sprawdzały tego, co ważne. Specyfikacje trudne, a zmiany czyste, znaczą, że metoda działa tam, gdzie stać Was na wysiłek specyfikowania — i decyzja dotyczy już tylko tego, gdzie. Żadna z czterech ćwiartek nie jest oceną zespołu. Każda jest stwierdzeniem o rodzaju pracy w konkretnym kodzie — a to dokładnie ten poziom, na którym powinna zapaść decyzja budżetowa. ## Dlaczego przerwanie jest dobrym wynikiem Jasne przerwanie po czterech tygodniach jest tanie. Mówi, że w tym rodzaju pracy i w tym kodzie implementacja nie jest Waszym ograniczeniem — albo że najpierw trzeba zbudować pokrycie testami, co zwraca się tak czy inaczej. Pilotaż, który dryfuje w częściowe przyjęcie, kosztuje znacznie więcej, bo koszt rozkłada się na zespoły i kwartały i nigdy nie pojawia się w jednym miejscu. Równie cenna jest jasna decyzja o poszerzeniu, z kryteriami, które za nią stoją. Przy budżecie dużo łatwiej jej bronić niż entuzjazmu, a kolejny zespół wie dokładnie, na co się pisze. ## Czego to wymaga od sponsora Niewiele czasu i jednego niewygodnego zobowiązania: że kryterium przerwania zostanie uszanowane, jeśli zostanie spełnione. Od tego, czy to zobowiązanie jest prawdziwe, zależy większość wartości pilotażu — a zespół, który go prowadzi, będzie wiedział, czy jest. W praktyce oznacza to powiedzenie na głos, już na starcie, że przerwanie jest akceptowalnym wynikiem — i powtórzenie tego, gdy wynik przyjdzie. ## Jak do tego podchodzimy [Rozwój sterowany specyfikacją](https://predictes.com/pl/services/ai-agents-spec-driven-development) jest ułożony dokładnie tak: ograniczony obszar, porządnie napisane specyfikacje, pętla uruchomiona z otwarcie mierzonym poziomem błędów i decyzja — poszerzyć albo przerwać. Lepiej wiedzieć po czterech tygodniach niż po czterech kwartałach. - spec-driven - pilotaże - podejmowanie decyzji - kodowanie z AI ## 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)