AI-DLC od AWS po polsku: 3 fazy i co zmienia wobec Scruma
AI-DLC to metodyka AWS z 2025 roku: AI planuje i proponuje, ludzie zatwierdzają. Ma fazy Inception, Construction i Operations. Sprinty zastępuje cyklami liczonymi w godzinach lub dniach.
Dla: CTO, architekci, szefowie zespołów programistycznych, Scrum Masterzy i Product Ownerzy · Stan na 02.11.2026 · Autor: Karol Krawczyk
Czym jest AI-DLC i skąd się wzięło?
AI-DLC, czyli AI-Driven Development Life Cycle, opisał Raja SP, Principal Solutions Architect w AWS, w ośmiostronicowym dokumencie "AI-Driven Development Lifecycle (AI-DLC) Method Definition". Plik PDF powstał w lipcu 2025 roku, a 31 lipca AWS omówił metodykę na blogu DevOps. Wpis odrzuca dwa modele. W AI-assisted programista wykonuje większość pracy intelektualnej, a AI pomaga przy dokumentacji, podpowiadaniu kodu i testach. W AI-autonomous AI generuje całe aplikacje bez ludzi. Oba, według AWS, dawały "suboptimal results", choć wpis nie podaje żadnych pomiarów.
Trzeci model odwraca kierunek rozmowy. Rozmowę prowadzi AI: człowiek podaje cel, a AI rozbija go na zadania, proponuje rozwiązania, pyta o wątpliwości i czeka na decyzję. Autor porównuje to do Google Maps, gdzie użytkownik wskazuje cel, a system prowadzi krok po kroku. Dokument przyznaje też, że dzisiejsze AI nie jest jeszcze wiarygodne w samodzielnym przekładaniu ogólnych intencji na działający kod, i stąd biorą się ludzkie zatwierdzenia na każdym etapie.
Method Definition zawęża zakres AI-DLC do złożonych systemów, budowanych przez wiele zespołów w dużych lub regulowanych organizacjach. Proste aplikacje, które może zbudować osoba bez doświadczenia programistycznego, autor odsyła do narzędzi low-code.
Fazy i pojęcia AI-DLC
Metodyka AI-DLC opiera się na trzech pojęciach (Intent, Unit, Bolt) i trzech fazach (Inception, Construction, Operations). Intent to ogólne określenie celu, biznesowego lub technicznego. Unit to spójny, samodzielny fragment pracy wyprowadzony z intencji, porównywany do subdomeny w Domain-Driven Design albo epika w Scrumie. Bolt to najmniejsza iteracja, w której powstaje Unit lub jego część. Jeden Unit może wymagać kilku Boltów, równolegle albo po kolei.
Inception zamienia intencje w Unity podczas rytuału Mob Elaboration. Zespół siedzi w jednej sali przy wspólnym ekranie, z osobą prowadzącą. AI proponuje podział na historyjki, kryteria akceptacji i Unity, a Product Owner, programiści, QA i inni interesariusze poprawiają to, co jest przesadzone albo niedopracowane. Dokument wymienia sześć wyników tej fazy:
- PRFAQ, czyli opis produktu w formie komunikatu prasowego i pytań z odpowiedziami
- historyjki użytkownika
- wymagania niefunkcjonalne
- opis ryzyk, powiązany z rejestrem ryzyk firmy, jeśli taki istnieje
- kryteria pomiaru odnoszące się do celu biznesowego
- proponowane Bolty
Fazy Construction i Operations w AI-DLC
Faza Construction w AI-DLC prowadzi od Domain Design, czyli modelu logiki biznesowej bez technologii, przez Logical Design z wymaganiami niefunkcjonalnymi i wzorcami architektonicznymi, do kodu i testów. AI zapisuje decyzje w Architecture Decision Records, a programiści je zatwierdzają. W istniejących systemach AI najpierw odtwarza z kodu modele statyczne i dynamiczne, które ludzie sprawdzają przed dalszą pracą. Rytuał Mob Construction znów zbiera zespoły w jednej sali: wymieniają specyfikacje integracji i dostarczają swoje Bolty.
Ludzka kontrola ma tu konkretny cel. Dokument przyrównuje ją do funkcji straty w uczeniu maszynowym: każde zatwierdzenie wyłapuje błąd, zanim ten rozleje się na dalsze etapy, a kod od AI nie staje się sztywny i trudny do zmiany.
Operations obejmuje wdrożenie, observability (wgląd w działanie systemu przez metryki, logi i ślady) oraz utrzymanie. AI analizuje telemetrię, szuka anomalii i proponuje działania z przygotowanych runbooków, ale wykonuje je dopiero po zgodzie programisty. Wszystkie artefakty zostają w repozytorium jako pamięć kontekstu dla kolejnych kroków i są ze sobą powiązane, więc element modelu da się połączyć z konkretną historyjką.
Liczba faz zależy od dokumentu. Method Definition i wpisy AWS z 2025 roku mówią o trzech. Repozytorium awslabs/aidlc-workflows, które wdraża metodykę w narzędziach do kodowania, ma w wersji 2.11.2 z 28 października 2026 pięć faz i 33 etapy: przed Inception doszły Initialization i Ideation, a trzecią fazę nazwano Operation. Domyślny profil Classic pomija Ideation i zostawia Operation jako placeholder, więc instalacja repozytorium nie daje jeszcze automatycznie całego cyklu.
Przykład AI-DLC z Method Definition: silnik rekomendacji
Method Definition, dokument AWS o AI-DLC, prowadzi od początku do końca jeden przypadek: silnik rekomendacji do sprzedaży krzyżowej. Product Owner formułuje ten cel, a AI rozpoznaje nową aplikację i tworzy plan pierwszego poziomu, który zespół poprawia. Podczas Mob Elaboration pyta, kim są główni użytkownicy i jaki wynik biznesowy ma powstać, potem rozpisuje historyjki, wymagania i ryzyka oraz składa je w Unity, takie jak zbieranie danych użytkowników czy wybór algorytmu. Product Owner zauważa, że w pierwszym z nich brakuje ochrony prywatności, i dopisuje wymagania RODO.
W Construction programista przyjmuje propozycję AWS Lambda, ale zmienia magazyn danych na DynamoDB. W Operations AI wykrywa skok opóźnień i proponuje skalowanie, a ludzie zatwierdzają działanie i pilnują wyniku. Dodatek z promptami pokazuje, jak wymusić taki rytm w zwykłym narzędziu: agent zapisuje plan w pliku Markdown z polami do odhaczenia, nie podejmuje sam ważnych decyzji i zaczyna pracę dopiero po akceptacji planu.
Co AI-DLC zmienia wobec Scruma?
AI-DLC zastępuje sprinty Scruma Boltami, a epiki Unitami. Scrum to w wydaniu z 2020 roku lekki framework z trzema odpowiedzialnościami i sprintami trwającymi miesiąc lub krócej. Method Definition twierdzi, że sprint zwykle ma 4 do 6 tygodni, co przekracza limit z samego Scrum Guide, więc jej porównanie zawyża różnicę. Zmiany wyglądają tak:
- Sprint: zastępuje go Bolt, z cyklem budowania i sprawdzania liczonym w godzinach lub dniach. Bolty planuje AI, a zatwierdzają je programiści lub Product Owner.
- Epik: jego odpowiednikiem jest Unit, luźno powiązany z innymi i możliwy do osobnego wdrożenia. Podział proponuje AI.
- Role: Product Owner i programiści zostają, a specjalizacje frontend, backend, DevOps i bezpieczeństwo mają się zbliżać. Dokument w ogóle nie wspomina o Scrum Masterze, pojawia się za to prowadzący Mob Elaboration.
- Daily i retrospektywa: dokument nazywa wiele tradycyjnych rytuałów mniej potrzebnymi, nie mówi jednak, co dokładnie zastępuje retrospektywę.
- Story pointy i velocity: dokument tylko o nie pyta, także o to, czy velocity zastąpić wartością biznesową. Definicji ani sposobu pomiaru nie podaje.
- Techniki projektowe: Scrum zostawia je zespołowi, AI-DLC wbudowuje je w metodykę. Opisany wariant używa DDD, warianty BDD i TDD są zapowiedziane.
Granice AI-DLC: różnice wobec metod zwinnych i kiedy nie pasuje
Method Definition sam sobie przeczy w ocenie, jak bardzo AI-DLC różni się od metod zwinnych, a historyjki użytkownika i rejestr ryzyk zostają. Pierwsza zasada mówi, żeby nie dopasowywać AI do Agile, tylko wymyślić metodę od nowa. Rozdział o wdrażaniu zaczyna się od zdania, że AI-DLC niewiele odbiega od istniejących metod zwinnych. Wniosek tego tekstu, nie AWS: bliżej opisanej treści jest drugie zdanie, bo cykl pozostaje zwinny, a zmieniają się długość iteracji, kolejność rozmowy i to, że pierwszą wersję artefaktów przygotowuje AI.
Obietnice są sformułowane bez danych. Dokument pisze, że Mob Elaboration skraca tygodnie lub miesiące sekwencyjnej pracy do kilku godzin, a praktyk może zacząć stosować metodykę w jeden dzień. Wpis AWS nie podaje benchmarków. Oba zdania to hipoteza do sprawdzenia na własnym projekcie.
Dwie rzeczy mogą przeszkodzić w firmie rozproszonej lub wielochmurowej. Oba rytuały zakładają jedną salę, a zespół zdalny musi sam sprawdzić, czy rozmowa na ekranie daje to samo. Dokument mapuje też komponenty na usługi AWS, choć README repozytorium nazywa metodykę niezależną od dostawcy modeli. Nie zaczynajcie od małego zespołu z prostym produktem, bo taki przypadek leży poza deklarowanym zakresem. Przeciw próbie przemawiają też słabe testy automatyczne: Construction kończy się na nich, a Bolt liczony w godzinach zostawia mało czasu na ręczną regresję. To wniosek tego tekstu, nie zalecenie AWS.
Co zrobić w firmie
- Przeczytajcie Method Definition w oryginale i wypiszcie, które rytuały Scruma zespół chce zachować podczas próby
- Wybierzcie jeden średni Intent w jednym produkcie, z Product Ownerem, programistami i QA dostępnymi przez całą sesję
- Przed startem zapiszcie kryteria pomiaru: czas od celu do wdrożenia, liczbę poprawek po przeglądzie i błędy po wdrożeniu
- Przeprowadźcie Mob Elaboration na tym celu, a Unity i Bolty zatwierdzajcie ręcznie
- Sprawdźcie, czy testy automatyczne obejmują zmieniany obszar, zanim uruchomicie Construction
- Po pilocie porównajcie wyniki z poprzednią podobną pracą i dopiero wtedy decydujcie o rezygnacji z konkretnych rytuałów
Powiązane materiały
Źródła
- AWS, Raja SP: AI-Driven Development Lifecycle (AI-DLC) Method Definition (PDF)
- AWS DevOps Blog: AI-Driven Development Life Cycle: Reimagining Software Engineering
- AWS DevOps Blog: Building with AI-DLC using Amazon Q Developer
- awslabs/aidlc-workflows na GitHubie
- AI-DLC Workflows: Phases and Stages
- AI-DLC Workflows: Workflow Profiles
- The Scrum Guide 2020
Chcesz przełożyć to na swój zespół?
Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.