--- title: "Jeśli kod piszą agenci, recenzowaną rzeczą staje się specyfikacja" url: "https://predictes.com/pl/services/ai-agents-spec-driven-development" description: "Budowa oprogramowania, w której wykonywalna specyfikacja steruje agentami piszącymi kod: recenzowana intencja, generowana implementacja i testy odpowiadające specyfikacji." --- # Jeśli kod piszą agenci, recenzowaną rzeczą staje się specyfikacja Gdy implementacja staje się tania i szybka, wąskie gardło się przesuwa. Przestaje nim być pisanie, a zaczyna dokładna wiedza, o co się poprosiło. Rozwój sterowany specyfikacją traktuje specyfikację jako artefakt główny — wersjonowany, recenzowany, wykonywalny przez testy — a implementację pozwala wyprodukować agentom. - **Specyfikacje na tyle precyzyjne, żeby z nich budować.** Napisane tak, że kompetentny agent albo nowy inżynier wyprodukuje z nich to samo. - **Przegląd tam, gdzie zapadają decyzje.** Inżynierowie recenzujący intencję i kryteria akceptacji, a nie przeglądający pobieżnie wielkie wygenerowane diffy — bo to tam przegląd naprawdę się załamuje. - **Testy wyprowadzone ze specyfikacji.** Kryteria akceptacji wyrażone jako wykonywalne testy, żeby specyfikacja była sprawdzalna, a nie aspiracyjna. - **Potok, który prowadzi Wasz zespół.** Ustawiony w Waszych repozytoriach i CI, z zabezpieczeniami i bramkami przeglądu czyniącymi generowany kod bezpiecznym do scalenia. [Porozmawiajmy o tym](https://predictes.com/pl/contact) ## Co przekazujemy - ### Format specyfikacji Struktura działająca w Waszej dziedzinie: intencja, ograniczenia, kryteria akceptacji i to, co jawnie poza zakresem. Dość krótka, żeby ją przeczytać, i dość precyzyjna, żeby z niej zbudować. - ### Potok agentowy Generowanie, uruchamianie testów, iteracja i moment, w którym pyta się człowieka. Skonfigurowany w Waszym CI, a nie jako usługa prowadzona przez kogoś innego. - ### Zabezpieczenia Limity wielkości generowanych zmian, obszary kodu wyłączone, obowiązkowe ścieżki przeglądu przez człowieka i automatyczne odrzucanie wszystkiego, czego nie da się powiązać ze specyfikacją. - ### Strategia testów Testy akceptacyjne ze specyfikacji, testy własnościowe tam, gdzie pasują, i zestaw ewaluacyjny dla komponentów AI. Testy pisane niezależnie od implementacji, inaczej całość jest kołowa. - ### Praktyka przeglądu Czego recenzent naprawdę szuka w generowanym kodzie i jak utrzymać zdolność przeglądu jako wiążące ograniczenie — bo jeśli nim nie jest, gromadzi się kod niedoprzeglądany. - ### Uzdolnienie zespołu Wasi inżynierowie prowadzący tę metodę, z nazwanymi trybami porażki. To praktyka pracy, a nie narzędzie do zainstalowania. ## Jak to przebiega 1. 01 ### Wybrać ograniczony obszar Dobrze rozumianą część kodu z dobrym pokryciem testami. Zaczynanie od obszaru najsłabiej rozumianego to sposób, w jaki zespoły dochodzą do wniosku, że metoda nie działa. 2. 02 ### Napisać specyfikacje porządnie Dwie albo trzy prawdziwe funkcje wyspecyfikowane z wymaganą precyzją. Większość zespołów odkrywa tutaj, że ich dotychczasowe zgłoszenia nie były nawet blisko specyfikacji. 3. 03 ### Uruchomić pętlę Generuj, testuj, recenzuj, iteruj — z otwarcie mierzonym poziomem błędów, żeby metodę oceniać na dowodach. 4. 04 ### Poszerzyć albo przerwać Rozszerzyć na większą część kodu, jeśli liczby na to pozwalają. Jeśli nie, to uprawniony wynik i lepiej wiedzieć go po czterech tygodniach niż po czterech kwartałach. ## Dobre dopasowanie, gdy - Zespół już używa asystentów kodujących doraźnie, z niespójnymi wynikami. - Dobrze pokryty kod, w którym ograniczeniem jest specyfikacja, a nie pisanie. - Duże ilości podobnej pracy: integracje, adaptery, migracje, warstwa CRUD. - Chcecie, żeby metoda należała do Waszego zespołu, a nie do dostawcy. ## To nie ta usługa, gdy - Małe albo żadne pokrycie testami. Generowany kod bez testów to nieweryfikowalne zobowiązanie — najpierw pokrycie. - Praca badawcza i eksploracyjna, gdzie specyfikacja powstaje dopiero po eksperymencie. - Oczekujecie, że to usunie potrzebę inżynierów. Przesuwa to, na co idzie ich czas; nie usuwa ich — a dostawca obiecujący inaczej sprzedaje co innego. ## Najczęstsze pytania Czy to naprawdę przyspiesza wytwarzanie? Dla właściwego rodzaju pracy istotnie — implementacja przestaje być ograniczeniem. Dla pracy słabo wyspecyfikowanej albo naprawdę nowatorskiej bywa wolniej, bo napisanie precyzyjnej specyfikacji jest trudniejsze niż napisanie kodu. Wiedza, który to przypadek, jest większością wartości. Jak zapobiegacie problemowi ilości? Ograniczając wielkość generowanych zmian, wymagając powiązania każdej zmiany ze specyfikacją i traktując zdolność przeglądu jako ograniczenie, pod które wymiarujemy potok. Zespoły mierzące szybkość generowania i ignorujące szybkość przeglądu gromadzą dług, który przychodzi naraz. Kto odpowiada za generowany kod? Inżynier, który go zrecenzował i scalił, dokładnie jak przy każdej innej zmianie. To nie formalność — to powód, dla którego przeglądu nie wolno rozluźnić, niezależnie od przepustowości generowania. Jacy agenci i jakie modele? Takie, które sprawdzają się na Waszym kodzie, trzymane jako wymienialne. Liczy się metoda; narzędzia w tym obszarze zmieniają się co kilka miesięcy, a cokolwiek zbudowanego wokół jednego dostawcy trzeba będzie przebudować. Czy możecie to ustawić i odejść? Taki jest zamiar. Zwykle cztery do ośmiu tygodni na zbudowanie praktyki z Waszym zespołem, a potem jedno spotkanie po tym, jak z nią pożyją. Jeśli rok później nadal prowadzimy Wasz potok, ustawiliśmy go źle. ## Czytaj dalej - [ ### Gdy kod piszą agenci, wąskim gardłem staje się przegląd Generowanie przyspieszyło dziesięciokrotnie, a przegląd nie. Zespoły mierzące tylko pierwszą połowę gromadzą niedoprzeglądany kod, a dług przychodzi naraz. ](https://predictes.com/pl/blog/gdy-kod-pisza-agenci-waskim-gardlem-jest-przeglad) ## Pozostałe usługi - [ ### Strategia AI Które decyzje warto zmienić, ile każda kosztuje i co miałoby się mierzalnie zmienić. Łącznie z tymi, w których odpowiedzią nie jest AI. Czytaj artykuł](https://predictes.com/pl/services/ai-strategy) - [ ### Transformacja AI Część po strategii: kolejność dopasowana do realnej zdolności, zmiana sposobu pracy i adopcja jako czyjeś zadanie, a nie nadzieja. Czytaj artykuł](https://predictes.com/pl/services/ai-transformation) - [ ### Inżynieria agentów AI Agenci, którzy wykonują pracę, a nie odpowiadają na pytania — z granicami, narzędziami, bramkami zatwierdzania i rejestrem decyzji, który przetrwa pierwszy incydent. Czytaj artykuł](https://predictes.com/pl/services/ai-agents-engineering)