AI SDLC to kompletny cykl wytwarzania oprogramowania, w którym wyspecjalizowane agenty AI prowadzą pracę przez dziewięć etapów — a każde przejście między etapami wymaga dowodu, nie deklaracji. Jeden proces dla wielu domen, pełna ścieżka audytu w Jira i GitHub, człowiek jako właściciel wszystkich decyzji strategicznych.
Agenty AI piszące kod bez procesu produkują szybko — i nieprzewidywalnie. AI SDLC rozdziela dwie władze: merytoryczną (kto tworzy treść etapu) i przepływu (kto przesuwa pracę dalej). Żadna rola nie trzyma obu naraz.
Inicjatywa biznesowa, pakiet domenowy i drobna poprawka przechodzą te same etapy. Typ pracy zmienia produkt etapu — nigdy sam proces. Zero wyjątków, zero bocznych furtek do „Done”.
Domena odpowiada na pytanie gdzie praca trafia i kto decyduje. Proces odpowiada na pytanie co dzieje się dalej. Żadna domena nie dostaje własnego cyklu życia.
Zmiana statusu to czysta mechanika: odpala się dopiero, gdy istnieje dowód bramki. Skrypt przejścia weryfikuje dowód — nigdy go nie tworzy. Decyzja merytoryczna zapada wcześniej, u właściwej roli.
To nie jest tylko nasza obserwacja. Raport DORA 2025 (Google Cloud, ~5000 respondentów) pokazuje, że adopcja AI koreluje już dodatnio z przepustowością dostarczania — ale nadal ujemnie z jego stabilnością. Kod powstaje szybciej, a zmiany psują się częściej. DORA nazywa AI wzmacniaczem: podbija i mocne strony organizacji, i jej słabości. Wnioski samego DORA wskazują na małe partie zmian, automatyczne testy i szybkie pętle informacji zwrotnej jako przeciwwagę. Rozdział władz opisany niżej to nasza odpowiedź na tę diagnozę — nie jest to rekomendacja DORA. Pełne liczby i źródła są na stronie Wyniki.
Kliknij etap, aby zobaczyć jego kontrakt: kto odpowiada, co powstaje i jaki dowód otwiera przejście dalej.
Każdy etap kończy się jedną linią dowodu w formacie maszynowym, publikowaną w Jira przez odpowiedzialną rolę — i tylko przez nią. Dowód jest przypięty do dokładnej rewizji kodu (40-znakowy SHA commita): werdykt dotyczy tego, co naprawdę zostanie wdrożone, a nie „mniej więcej tej wersji”.
System działa w trybie fail-closed: dowód brakujący, niejednoznaczny, zdublowany albo przypięty do innej rewizji — to odmowa przejścia z maszynowym pakietem odmowy. Nie ma „przepchnięcia” statusu: skrypt przejścia sprawdza dowód na żywo w Jira, za każdym razem.
Gdy kod się zmieni po wydaniu werdyktu, wszystkie dowody tracą ważność razem i etap weryfikacji wykonuje się ponownie na nowej rewizji. To zamyka klasyczną lukę „przetestowaliśmy, potem ktoś dopchnął commit”.
| Etap | Rola odpowiedzialna | Dowód bramki | Przejście odpala |
|---|---|---|---|
| Analiza | Agent Analityk | ANALYSIS GATE: PASS | Dyrektor |
| Architektura | Agent Architekt | ARCHITECTURE GATE: PASS | Dyrektor |
| Planowanie implementacji | Agent Planista (solution architect) | IMPLEMENTATION PLANNING GATE: PASS | Dyrektor |
| Development | Routowany agent deweloperski | DEVELOPMENT GATE: PASS | Dyrektor |
| Weryfikacja (QA) | Agent QA | VERIFICATION GATE: PASS | Agent QA |
| Release / Zamknięcie | Agent Release | RELEASE GATE: PASS | Agent Release |
| Learning | Właściciel Procesu | LEARNING GATE: PASS | Właściciel Procesu |
Gdy zmiana ma istotę architektoniczną albo dotyka powierzchni bezpieczeństwa (uwierzytelnianie, dane między-tenantowe, sekrety, nowe zależności…), etap Weryfikacji wymaga dodatkowych werdyktów specjalistów — wszystkich przypiętych do tej samej rewizji. QA odmawia PASS, dopóki komplet nie istnieje. W razie wątpliwości klasyfikacja przechyla się w stronę „wymagane”. To gotowy materiał dowodowy pod audyt SOC 2 / ISO 27001.
Gdy bramka odmawia, praca nie „spada na developera domyślnie”. Wraca do najwcześniejszego etapu, którego zaakceptowany kontrakt okazał się błędny: wadliwe wymaganie — do Analizy, wadliwy projekt — do Architektury, wadliwa implementacja — do Developmentu. Późniejsza rola nigdy nie naprawia po cichu cudzego kontraktu.
Rola agenta to nie „prompt ogólny” — to utrwalony, wersjonowany skill z kontraktem wejścia i wyjścia, uprawnieniami ograniczonymi do zadania oraz zakazem wychodzenia poza przydzielony zakres. Role dzielą się na dwie rozłączne klasy.
Właściciel wszystkich domen. Decyduje o zakresie, priorytecie, ryzyku i akceptacji rezultatu. Jedyne źródło decyzji strategicznych.
Tymczasowy, na czas jednej inicjatywy. Koordynuje sekwencję i zależności między domenami; nie wykonuje pracy merytorycznej.
Stały, na jedną domenę. Prowadzi kolejkę domeny, odpala przejścia na podstawie dowodów, deleguje całą treść do ról merytorycznych.
Strażnik spójności: ocenia zdrowie domeny względem jej strategii i granic. Rekomenduje korekty — nie prowadzi kolejki i nie zmienia zakresu.
Zamienia potrzebę w zaakceptowany zakres: wymagania, testowalne kryteria akceptacji, wycena, ryzyka.
Decyzje architektoniczne (ADR), model zagrożeń, granice systemu — albo jawne, uzasadnione „N/A”. Architektura jest odwiedzana zawsze.
Pakiet implementacyjny: jednostki pracy, ścieżki docelowe, dobór specjalisty per jednostka, współbieżność, komendy weryfikacji.
Specjalizacje: backend, frontend, testy przeglądarkowe, DevOps. Deterministyczny routing po ścieżkach plików; jeden odpowiada za scalony rezultat.
Jedyny autor werdyktu weryfikacji i jedyna rola odpalająca przejście z QA. Konsumuje werdykty specjalistów, sam ich nie wydaje.
Skany SAST/SCA, walidacja modelu zagrożeń, werdykt bezpieczeństwa. Dowód dla QA — nie władza nad statusem.
Mechaniczne wykonanie: merge wyłącznie przez deterministyczną bramkę merge, weryfikacja działania po wdrożeniu, sprzątanie.
Prowadzi etap Learning: retrospektywa każdej dostawy, wnioski zamieniane w usprawnienia procesu z przypisanym właścicielem.
Twarda granica: Dyrektor nigdy nie tworzy treści merytorycznej — analizy, architektury, kodu ani werdyktu. Rola merytoryczna nigdy nie zmienia statusu w Jira. Dzięki temu żaden pojedynczy agent nie może jednocześnie „zrobić i zatwierdzić” — ta sama zasada, na której opiera się rozdział obowiązków w audycie finansowym.
Inicjatywa biznesowa przechodzi własną analizę i architekturę cross-domain, po czym rozpada się na Pakiety Domenowe (DWP) — trwałe jednostki dostarczania, z których każda należy do dokładnie jednej domeny i przechodzi pełny cykl życia we własnym tempie. Praca czysto domenowa (dług, utrzymanie, drobne zmiany) wchodzi do kolejki domeny bezpośrednio — bez sztucznej inicjatywy. Domena to obszar własności biznesowej, nie warstwa techniczna: interfejs, API i baza danych jednej zmiany należą do tej samej domeny.
Proces jest niezależny od narzędzi — Jira materializuje stan, nie definiuje go. Każdy etap, dowód bramki, werdykt i decyzja operatora ląduje jako trwały, podpisany rolą zapis na zgłoszeniu. Poniżej — realny przebieg jednego zgłoszenia, krok po kroku.
Statusy zmienia wyłącznie skrypt przejścia, który na żywo weryfikuje dowód bramki w Jira. Człowiek i agent widzą ten sam stan; nikt nie „przeciąga karteczki” ręcznie.
Kto aktualnie pracuje, zapisuje etykieta roszczenia (claim) — metadana własności, nie dodatkowy status. Zero fikcyjnych stanów „czeka na przekazanie”.
Kod dostarczają wyłącznie pull requesty z izolowanych gałęzi. Scalenie wykonuje deterministyczna bramka merge po komplecie dowodów — żaden agent nie scala „ręcznie”.
Agenty wykonują pracę i dowodzą jej jakości — ale akceptacja rezultatu należy do Operatora. Zgłoszenie nie osiągnie „Done”, dopóki na etapie Learning nie istnieje zapisana akceptacja człowieka. Zakres, priorytet, ryzyko i granice domen to decyzje zarezerwowane dla ludzi; agent, który je odkrywa, eskaluje — nigdy nie decyduje sam.
Etap Learning domyka pętlę: każda dostawa kończy się retrospektywą, a wykryta wada procesu zostaje naprawiona albo staje się osobnym zadaniem z właścicielem. Proces, który sam się mierzy i sam się poprawia — to różnica między „używamy AI” a „mamy system, który z każdym tygodniem dostarcza lepiej”.
Ten proces nie jest koncepcją na slajdach. Działa produkcyjnie: prowadzi realne dostawy — w tym produkt bezpieczeństwa budowany do standardów audytowych — z realnymi bramkami i realną historią dowodową. Chętnie przeprowadzimy Państwa zespół przez pełny cykl na wybranym przez Was przykładzie. Samo wdrożenie też prowadzimy jak proces: trzy fazy z twardymi warunkami wyjścia, w których „no-go" jest legalnym wynikiem i kończy się raportem, nie sankcją — a retrospektywy dotyczą procesu, nigdy ludzi.