Wyobraźmy sobie zadanie dodania kodów rabatowych. Agent zmienia logikę cenową, pisze testy i przygotowuje opis pull requestu. Wszystko jest spójne i zielone. Agent założył jednak, że rabaty można łączyć, choć reguła biznesowa tego zabrania. Implementacja, testy i opis wzajemnie się potwierdzają. Wszystkie są błędne.
AI zwiększa tempo i skalę takiej pomyłki. Duży, wewnętrznie spójny zakres zmian może powstać szybciej niż człowiek odtworzy jego założenia. W analizie jakościowej 1110 odpowiedzi inżynierów Google DORA opisuje ten efekt jako koszt weryfikacji: część czasu zaoszczędzonego podczas tworzenia przechodzi na audyt, przegląd i doprowadzenie rozwiązania do stanu produkcyjnego. Nie jest to uniwersalny pomiar całej branży. Wspólne zalecenia ANSSI i BSI wskazują, że wzrost produktywności wytwarzania wymaga odpowiedniego skalowania QA, AppSec i DevSecOps.
Co oznacza AI-native SDLC?
W tym artykule AI-native SDLC to cykl dostarczania oprogramowania, w którym AI, zwłaszcza agenci programistyczni, stale uczestniczy w pracy nad wymaganiami, kodem, testami, dokumentacją i pipeline’em. Produkt nie musi zawierać modelu AI.
Tematem jest kontrola sposobu wytwarzania oprogramowania z pomocą AI. Produkt zawierający model, pamięć lub autonomiczne działania wymaga dodatkowych ocen jego zachowania, danych i bezpieczeństwa. To osobny zakres, który może występować równolegle.
Gate podejmuje decyzję
Nie każdy mechanizm zwracający wynik negatywny jest gate’em. W procesie jakości pełni określoną funkcję:
| Mechanizm | Funkcja | Przykład |
| Guardrail | ogranicza dozwolone działanie | izolowane środowisko, minimalne uprawnienia |
| Check | sprawdza właściwość i tworzy sygnał | kompilacja, test kontraktowy, skan bezpieczeństwa |
| Monitor | wykrywa odchylenie podczas działania | wskaźnik błędów, telemetria, alert bezpieczeństwa |
| Mechanizm odtworzeniowy | ogranicza skutki problemu | flaga funkcjonalna, automatyczne wycofanie |
| Gate | ocenia dowody względem polityki i autoryzuje zmianę stanu | zgoda na scalenie, wydanie lub zwiększenie ruchu |
Linter dostarcza sygnał. Izolowane środowisko ogranicza zasięg działania. Monitoring pokazuje zachowanie systemu. Gate łączy wskazany przedmiot decyzji, wersję polityki, wymagane dowody oraz uprawnionego właściciela z konkretną reakcją: blokadą, promocją, wycofaniem albo wyjątkiem.
Najpierw ryzyko, potem autonomia
Zespół potrzebuje prostego profilu zmiany. Powinien uwzględniać wpływ na użytkownika i biznes, wrażliwość danych, dostęp do uprzywilejowanych narzędzi, zasięg architektoniczny, odwracalność oraz niepewność wymagań. Znaczenie mają również obowiązki prawne i kontraktowe.
Trzy klasy zwykle wystarczają do rozpoczęcia pracy:
| Klasa | Przykład | Autonomia i dowody |
| Standardowa | lokalna i łatwo odwracalna zmiana | automatyczne sprawdzenia, mały PR, standardowy przegląd |
| Podwyższona | zmiana kontraktu API, zależności lub przetwarzania danych | dodatkowe testy ryzyka, niezależny recenzent, stopniowe wdrożenie |
| Krytyczna | autoryzacja, płatności, migracja danych lub polityka bezpieczeństwa | rozdzielenie obowiązków, przegląd ekspercki, jawna decyzja o ryzyku i plan odtworzenia |
Profil trzeba przeliczyć, gdy agent rozszerza zakres, dodaje zależność, zmienia przepływ danych, uprawnienia albo sposób wdrożenia. NIST SSDF 1.1 opisuje praktyki oparte na ryzyku i rezultatach, które organizacja dostosowuje do swojego kontekstu. Ta sama logika powinna sterować quality gates.
Agent może zaproponować klasę i uzasadnienie. Nie powinien sam obniżać poziomu kontroli. Zmiana podwyższona lub krytyczna wymaga potwierdzenia klasy przez wskazanego właściciela ryzyka albo niezależnego specjalistę.
Gate ocenia konkretny przedmiot
Gate nie ocenia ogólnej jakości projektu. Decyduje o zmianie stanu konkretnego przedmiotu: zadania, sesji agenta, rewizji kodu, zbudowanego artefaktu albo wdrożenia do określonej grupy użytkowników. Bez tego można użyć wyników testów z poprzedniego commita lub danych dotyczących innego obrazu aplikacji.
W modelu, którego używam, kontrakt decyzji odpowiada na sześć pytań:
- Co dokładnie zmienia stan i jaka jest intencja zmiany?
- Jakie szkody, zagrożenia i niepewności obejmuje profil ryzyka?
- Która wersja polityki określa kryteria?
- Które aktualne wyniki dotyczą właśnie tego przedmiotu?
- Jakie decyzje i jakie reakcje wynikają z oceny?
- Kto może zdecydować, jak długo decyzja obowiązuje i co ją unieważnia?
Łączę w ten sposób pięć perspektyw:
- intencję,
- sposób pracy,
- walidację,
- ocenę dowodów,
- kontrolę decyzji.
Jest to model proponowany i używany przeze mnie, a nie standard branżowy.
Co czyni dowód wiarygodnym?
Zielony status informuje, że test przeszedł. Jego wynik wspiera decyzję dopiero, gdy spełnia kilka warunków:
- sprawdza wskazane ryzyko lub wymaganie;
- wskazuje rewizję, konfigurację, środowisko i artefakt;
- pochodzi z zaufanego wykonawcy i zachowuje integralność;
- pozostaje aktualny i nie wystąpiło zdarzenie, które go unieważnia;
- wnosi metodę lub perspektywę niezależną od źródła zmiany.
Niezależność nie zawsze oznacza drugiego człowieka. Test właściwości, kompilator, skan zależności i obserwacja produkcyjna sprawdzają inne cechy. Test może wynikać z reguły biznesowej lub modelu zagrożeń zamiast z bieżącej implementacji. Drugi agent pracujący na tym samym modelu, instrukcji i kontekście może popełnić tę samą pomyłkę.
Praktyczny łańcuch identyfikowalności wygląda tak: wymaganie lub zagrożenie -> sprawdzenie -> wynik i wykonawca -> commit -> artefakt -> wdrożenie. Zmiana któregokolwiek z ogniw może wymagać ponownej oceny dowodów.
Warunki unieważnienia trzeba zapisać w polityce gate’u. Nowy commit, ponowne zbudowanie artefaktu, zmiana konfiguracji, środowiska lub polityki mogą sprawić, że wcześniejszy wynik przestaje opisywać przedmiot decyzji. To samo dotyczy utraty integralności wykonawcy albo zmiany modelu, instrukcji i narzędzi użytych do przygotowania oceny. Zaufane CI powinno zapisać producenta wyniku, czas, konfigurację oraz identyfikator artefaktu. Gate może wtedy odrzucić dowód, który jest zielony, ale dotyczy innego stanu systemu.
Przykład: gate, który zatrzymuje zmianę
Wróćmy do kodów rabatowych. Zmiana otrzymuje klasę podwyższoną, ponieważ wpływa na cenę oraz kontrakt pomiędzy checkoutem a usługą wyliczającą należność. Reguła biznesowa zabrania łączenia promocji. Analiza ryzyka dodaje drugi warunek: kolejność naliczania rabatu i podatku nie może prowadzić do innej ceny końcowej.
Agent przygotowuje implementację i testy podstawowych ścieżek. Oba artefakty dziedziczą jednak założenie, że dwa aktywne kody są dozwolone. Osobny test właściwości powstaje z reguły biznesowej, a nie z kodu. Generuje kombinacje promocji i wykrywa podwójne obniżenie ceny. Wynik pochodzi z kontrolowanego CI i jest związany z dokładnym commitem, dlatego może wejść do pakietu dowodów.
Agent proponuje dostosowanie asercji do implementacji. Chroniona polityka nie pozwala zmienić testu reguły biznesowej bez przeglądu przez właściciela domeny. Gate blokuje scalenie, ponieważ pakiet dowodów wskazuje na naruszenie ryzyka cenowego. Po poprawieniu implementacji ten sam commit przechodzi test reguły, test kontraktowy oraz pozostałe kontrole wymagane dla zmiany podwyższonej.
Skuteczność tego mechanizmu nie wynika z samego użycia kolejnego agenta. Kontrola ma inne źródło, metodę weryfikacji, zaufanego wykonawcę oraz prawo do zatrzymania zmiany. Bez tych elementów dodatkowy test tworzyłby kolejny sygnał, który zespół mógłby zignorować.
Obserwacja projektowa: migracja z .NET 6 do .NET 8
W jednym z projektów wykorzystałem AI do sprawdzenia dokumentacji oraz porównania kodu sprzed migracji z wersją po przejściu z .NET 6 na .NET 8. Celem było odtworzenie oczekiwanego zachowania oraz wskazanie miejsc, w których migracja mogła zmienić działanie systemu.
Na podstawie analizy przygotowaliśmy testy ukierunkowane na wykryte ryzyka oraz reguły quality gate. Agenci AI pomagali zestawić dokumentację, obie wersje kodu i wyniki testów. Wykryliśmy wszystkie znane różnice objęte zdefiniowanymi kryteriami porównania. Powiązanie wyników z konkretną zmianą ograniczyło ryzyko regresji.
Nie był to kontrolowany eksperyment ani dowód na uniwersalną skuteczność AI. Rezultat zależał od jakości dokumentacji, zakresu porównania, doboru testów i zasad podejmowania decyzji. AI przyspieszyło analizę, a jakość wynikała z całego procesu.
Gdzie umieścić kontrole?
Poniższa sekwencja pokazuje miejsca decyzji i zbierania dowodów. Nie oznacza to, że każdy etap potrzebuje osobnego gate’u.
| Etap | Przedmiot | Kontrola lub decyzja |
| 1. Określenie zmiany | zadanie lub specyfikacja | kryteria akceptacji, wymagania niefunkcjonalne, profil ryzyka |
| 2. Autoryzacja wykonawcy | tożsamość i sesja agenta | dozwolone dane, narzędzia, sieć, limity i warunki zatrzymania |
| 3. Szybka informacja zwrotna | lokalna zmiana | kompilacja, testy i reguły strukturalne wywołujące korektę |
| 4. Niezależna weryfikacja | commit lub PR | zaufane CI, testy wynikające z ryzyka, skany i wymagane role |
| 5. Promocja artefaktu | zbudowany artefakt | wyniki powiązane z wersją, pochodzenie artefaktu i plan odtworzenia |
| 6. Wdrożenie i ekspozycja | środowisko lub grupa użytkowników | okres obserwacji, progi promocji, automatyczne wstrzymanie lub wycofanie |
| 7. Operacja i uczenie | usługa i system kontroli | sygnały techniczne, biznesowe i bezpieczeństwa, analiza incydentów, aktualizacja reguł |
Granice agenta obowiązują przez całą sesję. Osobna tożsamość, krótkotrwałe poświadczenia, ograniczony dostęp do danych i narzędzi oraz rejestrowanie działań zmniejszają skalę błędów. OWASP AISVS 1.0 porządkuje te wymagania dla narzędzi i systemów AI. Treść zadania, repozytorium i wyniki narzędzi nadal należy traktować jako potencjalnie niezaufane.
Podczas promocji trzeba potwierdzić, że testy i skany dotyczą dokładnie tego artefaktu. Informacja o pochodzeniu artefaktu, określana jako provenance, pomaga ustalić, gdzie i jak został on zbudowany. SLSA 1.2 opisuje taki dowód. Nie potwierdza on poprawności biznesowej, dlatego pozostaje jednym z elementów pakietu.
Wdrożenie i udostępnienie użytkownikom są dwiema decyzjami. Flaga funkcjonalna lub wdrożenie stopniowe pozwalają obserwować ograniczoną grupę. Gate powinien mieć próg, okres obserwacji i automatyczną reakcję. Bez reakcji monitoring jest tylko źródłem informacji.
Incydent albo poważna regresja powinny zmienić system kontroli. Zespół zachowuje dowody, ustala przyczynę oraz wskazuje kontrolę, która nie zadziałała lub której zabrakło. Wnioski trafiają do wymagań, modelu zagrożeń, testów, polityki gate’u albo monitoringu. Każde działanie ma właściciela i termin. Zamknięcie wymaga wyniku potwierdzającego, że poprawiona kontrola wykrywa klasę błędu i ogranicza ryzyko jego ponowienia. Bez tego etap „operacja i uczenie” kończy się raportem zamiast poprawą procesu.
Wyjątki i odpowiedzialność
Niespełnienie reguły nie powinno znikać pod statusem „warunkowo zaliczone”. Autoryzowany wyjątek zapisuje przedmiot, niespełnioną regułę, pozostałe ryzyko, kontrolę kompensującą, akceptanta, termin wygaśnięcia i właściciela naprawy. Po wygaśnięciu system wymaga ponownej oceny albo blokuje promocję.
Odpowiedzialność dzieli się między kilka osób:
- właściciel domeny potwierdza intencję i dopuszczalny efekt biznesowy;
- właściciel polityki definiuje reguły oraz wymagane dowody;
- niezależny specjalista ocenia zmianę w zakresie swoich kompetencji;
- uprawniona osoba akceptuje udokumentowane ryzyko rezydualne;
- właściciel wydania lub usługi decyduje o promocji i sposobie odtworzenia.
Quality Engineer lub Test Developer może zaprojektować system dowodów i niezależności. Nie staje się przez to właścicielem każdego ryzyka. Agent może zebrać wyniki i wskazać niespójności, ale nie powinien jednocześnie tworzyć zmiany, certyfikować własnych dowodów i zatwierdzać promocji.
Zmienia się też codzienna praca inżyniera jakości. Samo napisanie większej liczby testów nie rozwiązuje problemu wspólnego błędnego założenia. Quality Engineer lub Test Developer ustala, które ryzyka wymagają dowodu, skąd ten dowód ma pochodzić, co go unieważnia oraz kto może podjąć decyzję.
Projektuje także reakcję:
- blokadę,
- ograniczenie ekspozycji,
- wycofanie
- lub autoryzowany wyjątek.
To przesuwa część pracy z implementacji pojedynczych sprawdzeń na projektowanie systemu jakości. Nadal potrzebne są kompetencje techniczne, znajomość produktu i umiejętność tworzenia testów. Dochodzi odpowiedzialność za spójność pomiędzy ryzykiem, środowiskiem wykonania, wynikami i decyzją biznesową.
Jak mierzyć system i uruchomić pilotaż?
Metryki powinny odpowiadać na pytania o rezultat, skuteczność i koszt:
- czy spada liczba poważnych regresji i czas odtworzenia;
- które kontrole wykrywają problemy, a które generują fałszywe alarmy;
- ile trwa decyzja i ile kosztuje weryfikacja;
- jak często używa się wyjątków i czy działania naprawcze są zamykane;
- czy wdrożenia stopniowe zatrzymują błędy przed rozszerzeniem ruchu.
Liczba tokenów, linii kodu, pull requestów lub użycie AI nie mierzy jakości. DORA ostrzega przed miarami aktywności, które łatwo oddzielają się od wartości i rezultatów dostarczania.
Pierwszy pilotaż warto ograniczyć do jednego ważnego przepływu. Zespół wybiera zmianę, przypisuje klasę ryzyka i nazywa przedmioty decyzji. Następnie definiuje pakiet dowodów, role oraz reakcję na wynik negatywny. Gate początkowo działa w trybie obserwacji. Po kalibracji fałszywych alarmów może zacząć blokować.
Po kilku zmianach zespół sprawdza, które kontrole przerwały rzeczywiste błędy, ile kosztowały i czy wyjątki zostały zamknięte. Taki pilotaż daje podstawę do rozszerzenia systemu bez konieczności projektowania całej organizacji od podstaw.
Testing & QA
Zapewnij jakość, wydajność i bezpieczeństwo swojego oprogramowania dzięki naszym usługom testowania i automatyzacji testów.
Oferta Testing&QAPodsumowanie
Quality gate w AI-native SDLC powinien odpowiadać na jedno pytanie: jaki błąd ma przerwać ta kontrola?
Odpowiedź wymaga wskazania przedmiotu decyzji, profilu ryzyka, aktualnych dowodów, warunków ich unieważnienia, wersji polityki, uprawnionego właściciela i reakcji na wynik negatywny. Quality Engineer lub Test Developer projektuje powiązania pomiędzy tymi elementami, a właściciel ryzyka zachowuje odpowiedzialność za decyzję.
Tak zbudowany gate pozwala wykorzystać szybkość agentów bez mylenia większej liczby zmian z wyższą jakością. Zespół może zacząć od jednego przepływu, mierzyć skuteczność kontroli i rozwijać system na podstawie błędów, które rzeczywiście potrafi zatrzymać.
***
Nota autora: Model decyzji, profil ryzyka i mapa miejsc kontroli są praktyczną syntezą proponowaną i używaną przeze mnie. Nie mają statusu standardu branżowego i wymagają dostosowania do kontekstu organizacji.
Zostaw komentarz