Blog

W R-Technologies coraz częściej dowozimy pierwszą działającą wersję w kilka dni — nie miesięcy. Spec-Driven Development i praca z AI sprawiają, że zmiana w kodzie jest tania. Klient widzi efekt wcześnie: jeszcze nie doskonały, ale już konkretny. Od tego momentu projekt przestaje być „budowaniem w ciemno” i staje się dopracowywaniem działającego prototypu.

Dlaczego sprint tygodniowy lub dwutygodniowy traci sens? Bo pętla feedbacku nie nadąża za tempem implementacji. Gdy AI potrafi przygotować kolejną wersję w godzinach, czekanie do końca sprintu oznacza przestój decyzyjny. Wąskim gardłem nie jest już pisanie kodu. Wąskim gardłem są decyzje: co zostawiamy, co poprawiamy, co odkładamy. Dlatego naturalnym rytmem stają się krótkie spotkania co 2–3 dni.

To inny temat niż sam Spec-Driven Development. SDD porządkuje intencję i kryteria jakości — o tym piszemy osobno. Ten artykuł dotyczy modelu współpracy: jak szybko pokazać wartość i jak klient musi się do tego przygotować organizacyjnie.

Od czego zacząć? Od krótkiej specyfikacji startowej: problem biznesowy, użytkownik, zakres pierwszej wersji oraz kryteria „wystarczająco dobre na feedback”. Potem budujemy prototyp, pokazujemy go szybko i dopiero na żywym systemie doprecyzowujemy produkt. To nie jest skrócony waterfall. To zmiana kolejności: najpierw coś, na czym można kliknąć, potem decyzje o jakości i priorytetach.

Jak wygląda cykl co 2–3 dni w praktyce? Poniedziałek: przegląd prototypu i lista poprawek. We wtorek aktualizujemy specyfikację i wdrażamy zmiany. W środę lub czwartek znów oglądamy efekt razem z klientem. Intensywność zastępuje długie fazy planowania. Zespół nie czeka na domknięcie dużego backlogu — domyka konkretne luki w działającym produkcie.

Co zyskuje klient? Postęp widać w dniach, nie w kwartałach. Szybciej weryfikujecie, czy kierunek ma sens biznesowy. Mniej płacicie za funkcje, które po pierwszym demo i tak byście odrzucili. Dopracowywanie dzieje się na żywym prototypie, więc rozmowa dotyczy tego, co już działa — a nie wyobrażeń o systemie.

Co musi zapewnić klient? Osobę odpowiedzialną za kontakt i zatwierdzanie zmian na bieżąco, w praktyce co 2–3 dni. Bez niej tempo AI niewiele daje: zespół czeka, a koszt przesuwa się z implementacji na przestój decyzyjny. Product Owner staje się rolą kluczową i musi być dyspozycyjny. Nie powinien prowadzić zbyt wielu projektów równolegle — w tym modelu liczy się intensywność, nie liczba otwartych inicjatyw.

Checklista gotowości przed startem: (1) Product Owner z mandatem do decyzji, (2) dostępność na krótkie sync’e co 2–3 dni, (3) zgoda na pierwszy niedoskonały prototyp w kilka dni, (4) jasne kryteria akceptacji kolejnych iteracji, (5) jedna priorytetowa ścieżka produktu zamiast wielu równoległych „pilnych” wątków, (6) szybka ścieżka feedbacku od użytkowników biznesowych. Jeśli któregoś punktu brakuje, najpierw uporządkujcie organizację — dopiero potem przyspieszajcie dostarczanie.

Czy AI zastępuje Product Ownera? Nie. AI przyspiesza budowę i zmiany; Product Owner nadal decyduje o wartości, zakresie i akceptacji. Bez dyspozycyjnego PO projekt tylko szybciej dojdzie do złych decyzji.

Czy sprinty Agile są już zbędne? Jako jedyny rytm feedbacku — zwykle tak, są za wolne. Nadal możecie planować kamienie milowe. Codzienna współpraca powinna jednak opierać się o krótsze przeglądy: co 2–3 dni.

Ile trwa pierwszy prototyp? Przy jasnej intencji i dobrej specyfikacji startowej pierwszy widoczny prototyp to często kwestia kilku dni, nie tygodni. Nie będzie wersją produkcyjną „na zawsze”. Ma być na tyle konkretny, by ocenić kierunek.

Co, jeśli Product Owner prowadzi kilka projektów naraz? To największe ryzyko opóźnień w modelu intensywnych iteracji. Lepiej mniej projektów i pełna dyspozycyjność niż wiele inicjatyw czekających na decyzje.

Czy to tylko dla nowych produktów? Nie. Ten sam rytm sprawdza się przy modernizacji i nowych funkcjach: szybki prototyp zmiany, przegląd z biznesem, dopracowanie — zamiast długiego wdrożenia typu big bang.

Tempo dostarczania ogranicza dziś rzadziej technologia, a częściej dostępność decyzji. AI i Spec-Driven Development skracają drogę od pomysłu do działającego prototypu — pod warunkiem intensywnej współpracy i dyspozycyjnego Product Ownera po stronie klienta.

W ostatnich latach zmieniło się podstawowe założenie pracy nad oprogramowaniem. Coraz większa część kodu nie jest już ręcznie pisana przez programistów, tylko generowana, poprawiana i testowana przez modele LLM oraz agentów AI. Anthropic opisuje ten trend bardzo konkretnie: według danych firmy, w maju 2026 ponad 80% kodu mergowanego do ich codebase'u było autorstwa Claude'a, a typowy inżynier mergował wielokrotnie więcej kodu niż wcześniej. Źródło: https://www.anthropic.com/institute/recursive-self-improvement

To ma głęboki sens biznesowy. Dobre modele potrafią pisać kod szybciej, taniej i coraz częściej na poziomie jakości porównywalnym z człowiekiem. Jeżeli wykonanie implementacji staje się tanie, głównym ograniczeniem projektu przestaje być samo pisanie kodu. Ograniczeniem staje się decyzja: co właściwie budujemy, dlaczego tak, jakie kompromisy akceptujemy i jak rozpoznamy, że efekt jest poprawny.

Dlatego przyszłość należy do Spec-Driven Development. Specyfikacja nie jest dokumentem dla formalności. To kontrakt opisujący założenia biznesowe, architekturę, granice systemu, scenariusze użytkowników, kryteria akceptacji i decyzje, których agent AI nie powinien zgadywać. Im lepiej zapisana jest intencja projektu, tym mniejsze ryzyko, że model zbuduje coś efektownego, ale niezgodnego z prawdziwymi potrzebami firmy.

Najczęstsze błędy agentów AI nie wynikają z tego, że nie potrafią napisać funkcji, testu czy migracji bazy danych. Wynikają z błędnie podjętych decyzji, bo agent nie zna pełnego kontekstu: historii produktu, ograniczeń compliance, modelu sprzedaży, długu technologicznego albo niepisanych zasad zespołu. Specyfikacja jest sposobem na przeniesienie tego kontekstu z głów ludzi do procesu, który mogą rozumieć i wykonywać agenci.

Wokół tego podejścia powstaje już cały ekosystem narzędzi. BMAD pomaga zamieniać wymagania produktowe na uporządkowany proces pracy z agentami. OpenSpec porządkuje zmiany przez proposal, design, tasks i specyfikacje zachowania systemu. GitHub rozwija własne podejście do spec-driven development, w którym specyfikacja staje się punktem startu dla implementacji, przeglądu i iteracji.

Ten sam kierunek dotyczy weryfikacji. Pisanie kodu przez AI bez AI-review szybko tworzy nowe wąskie gardło: człowiek nie nadąża z czytaniem wszystkiego, co agenci potrafią wygenerować. Coraz większa część przeglądu kodu, testowania, analizy bezpieczeństwa i oceny zgodności ze specyfikacją powinna więc również trafiać do agentów AI. Człowiek nadal ocenia efekt końcowy i bierze odpowiedzialność za decyzje, ale manualny review każdej linijki przestaje być skalowalnym modelem pracy.

W praktyce oznacza to zmianę roli zespołów technologicznych. Najcenniejszą kompetencją nie będzie samo wpisywanie kodu, tylko umiejętność definiowania dobrych problemów, pisania jasnych specyfikacji, ustawiania kryteriów jakości i budowania pętli weryfikacji. Firmy, które nauczą się pracować w ten sposób, będą dowozić szybciej i z mniejszym kosztem. Firmy, które zostaną przy nieformalnym przekazywaniu wymagań, będą produkować coraz więcej kodu, ale niekoniecznie coraz więcej wartości.

Wiele firm zaczyna od zakupu licencji na model językowy, zanim zdefiniuje problem biznesowy. Skuteczne wdrożenie GenAI zaczyna się od procesów, w których tekst, dokumenty lub decyzje powtarzają się setki razy dziennie.

Pierwszy etap to audyt: wskaż 3–5 zadań, które zajmują zespołowi najwięcej czasu i mają mierzalny efekt (czas obsługi, koszt, jakość). Dopiero potem dobieramy architekturę — asystent wewnętrzny, agent z dostępem do systemów, automatyzacja dokumentów.

Pilotaż powinien trwać 4–8 tygodni i kończyć się jasnym KPI: np. skrócenie czasu odpowiedzi na zapytania klientów o 40%. Po pilotażu skalujemy to, co działa — bez budowania „platformy AI” od razu.

Projekty GenAI dotykają danych wrażliwych: umów, maili, raportów finansowych. Bez polityki danych i kontroli dostępu każdy chatbot staje się potencjalnym wyciekiem.

Minimum dla firmy średniej wielkości: izolacja środowiska (VPC lub prywatny endpoint), logowanie zapytań, role użytkowników oraz zakaz wysyłania danych osobowych do publicznych API bez anonimizacji.

W R-Technologies projektujemy wdrożenia tak, aby dane nie opuszczały uzgodnionej infrastruktury — Azure OpenAI, GCP Vertex lub modele on-premise, w zależności od wymagań compliance branży.