AI w SDLC: co agenci kodujący zmieniają w każdej fazie cyklu

Dlaczego AI w procesie wytwarzania oprogramowania dotyczy całego cyklu

Większość zespołów poznaje agentów kodujących w edytorze i tam też zaczyna się pierwszy pomiar: licencje, sesje, tokeny i zaakceptowane podpowiedzi. Ten obraz przestaje wystarczać, gdy agenci dostarczają całe diffy i pull requesty. Implementacja przyspiesza, a praca piętrzy się przed nią i za nią. Zadania przychodzą niedookreślone, a review, pipeline'y testowe i procesy wydań dostają więcej zmian, niż są w stanie obsłużyć.

Raport DORA 2025 o wytwarzaniu oprogramowania ze wsparciem AI stwierdza, że adopcja AI poprawia teraz przepustowość dostarczania oprogramowania, inaczej niż rok wcześniej, ale nadal zwiększa niestabilność dostarczania. Raport opisuje główną rolę AI jako wzmacniacza, który powiększa istniejące mocne i słabe strony organizacji. Proces review albo wydań, który już wcześniej działał na granicy możliwości, szybciej pokazuje swoje słabości.

AWS patrzy na cały cykl w AI-Driven Development Life Cycle (AI-DLC), opisanym w lipcu 2025. W AI-DLC sztuczna inteligencja tworzy plany, zadaje pytania doprecyzowujące i implementuje dopiero po walidacji przez ludzi, w trzech fazach: Inception, Construction i Operations. Zespół wspólnie weryfikuje propozycje AI na sesjach, które AWS nazywa Mob Elaboration i Mob Construction, plany i artefakty projektowe trafiają do repozytorium projektu, a sprinty ustępują krótszym cyklom nazywanym bolts. Workflowy open source tej metody dodają dziś fazy inicjalizacji i ideacji, działają w kilku agentach kodujących i zatrzymują się w punktach akceptacji przez człowieka.

Nie potrzebujesz nazwanej metody, żeby wprowadzić AI do swojego procesu. Dla każdej fazy zapisz dwie rzeczy: jak praca dzieli się między agentów i ludzi oraz jaki artefakt przechodzi do następnej fazy i kto za niego odpowiada. To właśnie nazywamy AI w SDLC albo agentic SDLC: proces, który już prowadzisz, z tymi decyzjami podjętymi wprost. Oto artefakty przekazania i ich właściciele.

• Specyfikacja (właściciel: osoba pisząca zadanie)
• Plan (właściciel: inżynier odpowiedzialny za zmianę)
• Diff, czyli pull request (właściciel: inżynier, który delegował zadanie)
• Raport z testów (generuje go CI, czyta wskazana osoba)
• Zapis review (właściciel: wskazany recenzent)
• Notatka do wydania (właściciel: osoba odpowiedzialna za wydanie)
• Zapis incydentu i zadania następcze (właściciel: zespół serwisu)

Od zgłoszenia do diffa: planowanie, projektowanie i implementacja

Problemy, które zaczynają się we wczesnych fazach, później drogo kosztują, bo nikt nie zrecenzuje diffa względem wymagań, których nikt nie spisał. Te fazy decydują, czy wynik pracy agenta jest wart czasu recenzenta.

Wymagania i planowanie

Agenci przydają się, zanim ktokolwiek napisze kod. Mogą zestawić zgłoszenie z kodem i jego historią, wypisać moduły, których dotknie zmiana, zadać pytania, które zgłoszenie zostawia otwarte, i naszkicować kryteria akceptacji. O tym, co budować, dla kogo i kiedy praca jest skończona, decydują ludzie. Przekazaniem jest specyfikacja, a każde zadanie warto pociąć tak, żeby dawało jeden diff, który recenzent przeczyta za jednym podejściem.

Projektowanie

Przy wszystkim, co przekracza granicę modułu, poproś agenta o plan przed pierwszą zmianą: pliki do zmiany, interfejsy i struktury danych, kolejność migracji i sposób przetestowania zmiany. Agent może też zbudować prototyp do wyrzucenia, żeby tanio rozstrzygnąć pytanie projektowe. Ludzie zatwierdzają plany, które dotykają publicznych API, modeli danych, granic bezpieczeństwa albo kodu innego zespołu, i odrzucają plany ruszające więcej, niż wymaga zadanie. Zatwierdzony plan zostaje w repozytorium albo w pull requeście, żeby recenzent mógł porównać z nim diff.

Implementacja

Tu agenci wykonują najwięcej pracy i tu harness ma największe znaczenie. Agent pisze zmianę, uruchamia build, lint i testy z czystego checkoutu i poprawia błędy, a niezależne zadania idą równolegle w izolowanych środowiskach. Inżynier, który delegował zadanie, pozostaje jego właścicielem: steruje sesją, restartuje ją, gdy odbiega od briefu, albo przejmuje pracę ręcznie. Pull request mówi, co zostało uruchomione, a czego nie sprawdzono.

Task       PAY-412  Retry failed webhook deliveries
Spec       docs/specs/PAY-412.md, approved by the task writer
Plan       approved in the pull request before the first edit
Agent      tool, model and harness revision
Ran        lint, unit and integration tests: passing
Not run    load test against the provider sandbox
Risk       retries pile up during a long provider outage
Owner      engineer who delegated the task
Reviewer   named person, merges after CI passes

Spec driven developmentHarness engineering

Od diffa do produkcji: testy, review, wydanie i utrzymanie

Dalsze fazy muszą przyjąć wszystko, co dostarczy implementacja. To ich przepustowość, bardziej niż szybkość agenta, decyduje, jak szybko zmiany docierają do użytkowników.

Testy

Agenci szybko piszą testy, co pomaga, ale jest też głównym ryzykiem tej fazy. Test napisany przez tego samego agenta, który napisał kod, dzieli jego rozumienie zadania, łącznie z błędnymi odczytaniami. Uważaj na zaktualizowane snapshoty, poluzowane asercje i pominięte testy, które zmieniają czerwony build w zielony. Agenci dobrze radzą sobie z odtworzeniem zgłoszonego błędu jako nieprzechodzącego testu przed poprawką i z dopisywaniem testów wokół kodu, który zaraz zmienią.

Ludzie decydują, co musi być przetestowane, i trzymają kluczowe testy akceptacyjne poza zasięgiem agenta. Przekazaniem jest raport z testów: wyniki CI przypisane do kryteriów akceptacji oraz wszystko, co sprawdzono ręcznie.

Review

Review zapycha się jako pierwsze, gdy agenci produkują diffy szybciej, niż ludzie są w stanie je czytać. Agent może zrobić pierwsze przejście w świeżym kontekście albo innym modelem, sprawdzić diff względem planu i twoich konwencji i streścić go recenzentowi. Akceptacja zostaje przy wskazanym recenzencie, który odpowiada za to, co trafia do merge'a. Zapis review razem z uwagami zostaje przy pull requeście.

Wydanie

Agenci mogą przygotować szkic notatki do wydania na podstawie zmergowanych pull requestów, sprawdzić, czy migracje i feature flagi zgadzają się z planem, i przygotować zmianę wdrożeniową. O tym, kiedy i dla kogo wydać zmianę oraz czy ją wycofać, decyduje osoba odpowiedzialna za wydanie, w ramach twojego obecnego change managementu. Przekazaniem jest notatka do wydania: co się zmieniło, znane ryzyka i ścieżka wycofania.

Eksploatacja i utrzymanie

W eksploatacji daj agentom najpierw pracę tylko do odczytu, na przykład zestawianie logów, trace'ów i ostatnich wdrożeń podczas incydentu, a poprawki niech proponują jako zwykłe pull requesty. Cykliczne prace utrzymaniowe dobrze pasują do agentów, bo aktualizacje zależności, wycofywanie przestarzałych API i małe migracje są powtarzalne i łatwe do sprawdzenia. Dowodzenie incydentem, zmiany na produkcji i komunikacja z klientami zostają przy ludziach. Zadania następcze z zapisu incydentu wracają do planowania.

Code review z AI

Gotowe workflowy obejmujące kilka faz

Część zespołów sięga po gotowy workflow, zamiast samodzielnie projektować każde przekazanie. Przykładem jest pstack, plugin do Cursora autorstwa Lauren Tan, opublikowany w repozytorium cursor/plugins na licencji MIT. Jego playbooki obejmują powtarzalną pracę inżynierską, od analizy i poprawek błędów po nowe funkcje, refaktoryzację i pracę nad wydajnością, a niektóre prowadzą pull requesty przez CI i komentarze z review aż do merge'a. Kolejne skille każą kilku modelom szukać błędów w diffie, a reguła zapisywana przy konfiguracji przypisuje modele do ról, takich jak kodowanie, ocena i review.

Gotowy workflow ma wbudowane założenie, w którym miejscu wkracza człowiek. Zasady pstack każą agentowi kontynuować pracę odwracalną i pytać przed działaniami nieodwracalnymi, a README pokazuje nocne uruchomienie, które merge'uje cały stos pull requestów. Siostrzany playbook buduje i weryfikuje stos, a review i merge zostawia człowiekowi. To, czy merge do gałęzi, z której idzie wdrożenie, jest odwracalny, rozstrzyga twoja organizacja.

Playbooki instruują agenta i niczego nie wymuszają. Gdy wdrażamy gotowy workflow z zespołem, przypisujemy każdy krok do jego fazy, zatrzymujemy go w twoich punktach akceptacji, a kroki zakładające więcej autonomii, niż daje twoja konfiguracja, dostosowujemy, ograniczamy albo pomijamy. Punkty akceptacji wbudowane w workflowy AI-DLC też pomagają, ale nie zastępują twoich. Punkty akceptacji, które muszą działać, należą do systemów, których agent nie zmieni sam.

• Uprawnienia i poświadczenia agenta, ograniczone do zadania
• Ochrona gałęzi i wymagane review
• Kontrole CI, które blokują merge, gdy nie przechodzą
• Zatwierdzenia wdrożeń na produkcję

Workflowy pstack w twoich repozytoriachpstack w Cursorpstack: kod źródłowy i README

Role, które się zmieniają

Nazwy stanowisk rzadko muszą się zmieniać. Zmienia się to, na co ludzie poświęcają tydzień i za które artefakty odpowiadają.

• Osoby piszące zadania tworzą briefy, które agent wykona bez dopytywania, z kryteriami akceptacji i listą tego, co poza zakresem.
• Inżynierowie, którzy delegują, odpowiadają za każdy diff przekazany agentowi, łącznie z decyzją o restarcie sesji albo przejęciu pracy.
• Recenzenci spędzają więcej czasu na review i potrzebują małych diffów, zatwierdzonego planu i raportu z testów.
• Zespół platformowy odpowiada za harness: instrukcje, polecenia builda i testów, uprawnienia, hooki, domyślne modele i budżety.
• Osoby odpowiedzialne za bezpieczeństwo i wydania decydują, które typy zadań mogą działać bez nadzoru, i zatwierdzają wyjątki.

Wersjonuj harness, zmieniaj go według ustalonego procesu i ogranicz liczbę pull requestów od agentów, które mogą czekać na jednego recenzenta. DORA AI Capabilities Model, uzupełnienie raportu 2025, wymienia wysokiej jakości platformy wewnętrzne wśród siedmiu zdolności, które według badań wzmacniają pozytywny wpływ AI. Harness należy do tej platformy.

Metryki, które nadal mają sens

Metryki DORA dotyczące dostarczania oprogramowania nadal opisują wynik. Change lead time, deployment frequency i failed deployment recovery time mierzą przepustowość, a change fail rate i deployment rework rate niestabilność. DORA stosuje je na poziomie aplikacji lub serwisu, co pasuje do wdrażania agentów: pytanie brzmi, czy serwis jako całość dostarcza lepiej.

Te metryki zmieniają się powoli i reagują na wiele czynników. Dodaj miary bliższe pracy agentów i śledź je według typu zadania.

• Koszt zaakceptowanej zmiany: wydatki na modele i narzędzia dla typu zadania podzielone przez zmiany, które trafiły do merge'a i tam zostały.
• Czas review pull requestu od agenta, od gotowości do review do akceptacji.
• Poprawki: commity, które wkrótce po merge'u naprawiają zmianę agenta.
• Reverty i pull requesty od agentów zamknięte bez merge'a.
• Czas poświęcony na briefy i plany, żeby koszt przed implementacją był widoczny.

Raportuj według zespołu i typu zadania, nigdy według pojedynczych inżynierów. Poprawki błędów, refaktoryzacje i aktualizacje zależności zachowują się inaczej, a średnia z nich ukrywa, gdzie agenci pomagają. DORA ostrzega, że metryki ustawione jako cele zachęcają do ich podkręcania, a oceny indywidualne dodatkowo kosztują zaufanie. Pomiń liczbę linii kodu, odsetek zaakceptowanych podpowiedzi i liczbę pull requestów, bo wszystkie mogą rosnąć bez poprawy dostarczania.

Optymalizacja kosztów LLM

Zasady dla uruchomień bez nadzoru i akceptacji

Ustalaj zasady osobno dla każdego typu zadania. Aktualizacja zależności w dobrze przetestowanym serwisie i migracja schematu w systemie płatności potrzebują innych reguł, nawet przy tym samym narzędziu i modelu. Uruchomienie bez nadzoru ma sens, gdy zadanie da się przekazać na piśmie, zestaw testów uruchamia się sam i nie jest niestabilny, a człowiek recenzuje każdą zmianę przed merge'em. Samo uruchomienie potrzebuje uprawnień ograniczonych do zadania, izolowanego środowiska i wąsko określonych poświadczeń. Wszystko, co zmienia produkcję, dane albo dostępy, wymaga wskazanej osoby zatwierdzającej, a egzekwowanie odbywa się poza agentem.

• Merge do chronionych gałęzi: wskazany recenzent, a egzekwują to ochrona gałęzi i wymagane review.
• Wdrożenia na produkcję i wycofania: osoba odpowiedzialna za wydanie, przez twoje zatwierdzenia wdrożeń.
• Migracje schematu i danych: zespół, do którego należy system, z przetestowaną ścieżką wycofania.
• Nowe narzędzia, modele, serwery MCP lub poświadczenia dla agentów: zespół platformowy i zespół bezpieczeństwa.

Ślad audytowy

Dla każdej zmiany zachowaj brief, zatwierdzony plan, konfigurację agenta (narzędzie, model i rewizję harnessu), raport z testów, zapis review oraz informację, kto zrobił merge. Trzymaj to przy pull requeście, gdzie przetrwa dłużej niż historia sesji w dowolnym narzędziu. Nasza zasada brzmi: agent proponuje, a decydują deterministyczne kontrole i ludzie. Runmill, projekt open source naszego założyciela, działa według niej: o pushach, pull requestach i merge'ach decyduje deterministyczny kod, nigdy agent.

Bezpieczeństwo agentów AIFabryka oprogramowania AI

Wprowadzanie agentic SDLC faza po fazie

Nie potrzebujesz do tego nowego procesu ani reorganizacji. DORA AI Capabilities Model wymienia pracę w małych partiach wśród swoich siedmiu zdolności, a wdrożenie agentów korzysta z tej samej dyscypliny.

1. 1

   Wybierz jedną fazę i jeden typ zadania

   Postaw na pracę z wiarygodnymi testami i małym zasięgiem skutków, na przykład drobne poprawki błędów, pokrycie testami jednego serwisu albo aktualizacje zależności.

2. 2

   Spisz przekazania

   Nazwij artefakt, który agent dostaje, ten, który zwraca, i osobę odpowiedzialną za każdy z nich.

3. 3

   Zmierz punkt wyjścia

   Zapisz metryki DORA dla serwisu oraz czas review, poprawki i koszt dla tego typu zadania, zanim cokolwiek zmienisz.

4. 4

   Uruchom przy niezmienionych kontrolach

   Zostaw review i CI bez zmian i zapisuj narzędzie, model oraz rewizję harnessu dla każdego uruchomienia.

5. 5

   Porównaj i zdecyduj

   Rozszerz zakres na kolejny typ zadania albo sąsiednią fazę, popraw harness albo zakończ. Uruchomienia bez nadzoru przychodzą na końcu.

Jak pomaga Cloudsail

Pracujemy z jednym zespołem naraz, w jego własnych repozytoriach. Jesteśmy niezależni od dostawców i nie płaci nam żaden dostawca modeli ani narzędzi.

• Spisujemy fazy, artefakty przekazania i właścicieli dla jednego typu zadania, a potem rozszerzamy zakres.
• Konfigurujemy harness i punkty akceptacji, wersjonowane i z właścicielem.
• Prowadzimy warsztaty zdalnie albo na miejscu w Niemczech i w Polsce, po angielsku, niemiecku lub polsku, jako sesje zespołowe na twoich repozytoriach i backlogu.
• Mierzymy efekt, odtwarzając zmergowane zmiany względem odłożonych testów, i raportujemy koszt zaakceptowanej zmiany według typu zadania.

Wdrażanie agentów kodującychHarness engineeringEwaluacje na twoich repozytoriach