Eksperyment / Architektura / AI w SDLC

AI napisało kod. Ile z tego działało?

Kod wyglądał na gotowy. Testy pokazały, ile z zaplanowanego procesu dało się wykonać. Ta różnica ma znaczenie, kiedy za wdrożenie odpowiada człowiek.

Sebastian Dąbkowski21 października 2026Analiza + karta do pracy z zespołem

Od wyniku do decyzji

Najpierw pokazuję dane z mojego eksperymentu opisanego na LinkedIn. Następnie proponuję sposób sprawdzenia AI we własnym projekcie. Ta druga część jest materiałem do pracy z zespołem.

Ten sam zakres. Trzy style architektoniczne

Podzieliłem projekt marketplace na 151 user stories. Zadania trafiły do Copilota. Porównałem modularny monolit, N-layer oraz projekt bez narzuconej struktury. Każdy wariant miał ten sam zakres funkcjonalny.

Chciałem sprawdzić, jak struktura wpływa na wynik pracy AI. Sam rozmiar repozytorium nie odpowiadał na to pytanie. Potrzebowałem sprawdzić zachowanie systemu.

Przetestowałem proces, nie liczbę plików

Przygotowałem 40 testów funkcjonalnych obejmujących około 25% przypadków biznesowych. Wyniki poniżej dotyczą tej próby. Nie opisują całego systemu.

Wyniki z artykułu źródłowego
Styl architektoniczny	Zaliczone testy	Maks. złożoność metody*
Modularny monolit	53%	24
N-layer	78%	39
Bez narzuconej struktury	48%	56

* Wartości z analizy NDepend. Złożoność opisuje kod. Nie jest wynikiem testów funkcjonalnych ani miarą wartości biznesowej.

N-layer miał najwyższy odsetek zaliczonych testów. Modularny monolit miał najniższą maksymalną złożoność metody. Wariant bez narzuconej struktury osiągnął odpowiednio 48% oraz 56.

Wybór zależy od tego, co sprawdzamy. Jedna dobra metryka nie zastępuje pozostałych.

Kod integracji to jeszcze nie działająca integracja

W eksperymencie problemy pojawiały się przy logowaniu zewnętrznym, poczcie, płatnościach, routingu oraz migracjach bazy. Część funkcji istniała w kodzie, ale nie dało się ich wykonać. Migracje wymagały ponownego wygenerowania.

Dlatego przy sprawdzaniu własnego projektu proponuję przejść całą drogę użytkownika. Załóż konto. Wykonaj operację. Sprawdź, co zapisało się w bazie. Doprowadź proces do końca w środowisku testowym. Potem sprawdź, co system zrobi po odmowie dostępu albo przerwaniu połączenia.

Jeśli płatność została odrzucona, status zamówienia musi to odzwierciedlać. Samo wywołanie klienta API nie potwierdza poprawnego procesu. Warunek zaliczenia powinien opisywać to, co ma zobaczyć użytkownik oraz to, jaki stan ma pozostać w systemie.

Jak przenieść te wnioski do swojego projektu

Zacząłbym od jednego procesu, za który ktoś płaci albo którego obsługa generuje koszt. Może to być zamówienie, rezerwacja lub obsługa zgłoszenia. Wybierz taki zakres, którego wynik potrafisz ocenić. Dopiero potem porównuj sposób wykonania pracy z AI.

Wartość

Który proces ma działać lepiej?

Zapisz wynik przed zmianą, oczekiwaną poprawę i sposób pomiaru. Samo tempo generowania kodu nie mówi, czy klient osiąga cel.

Granice

Co agent może zmienić?

Wskaż moduł, dozwolone zależności i kontrakt. Dopisz, kiedy agent ma się zatrzymać zamiast samodzielnie rozszerzać zakres.

Weryfikacja

Jak pokażesz, że rozwiązanie działa?

Przygotuj scenariusz biznesowy, przypadek błędny i warunek zaliczenia. Sprawdź też połączenie z systemem zewnętrznym.

Odpowiedzialność

Kto podejmuje decyzję o wdrożeniu?

Nazwij osobę, która sprawdzi wynik. Określ zasady dostępu do danych, wymagane przeglądy i sposób wycofania zmiany.

Zapisz punkt odniesienia

Policz czas potrzebny na wykonanie zmiany razem z przeglądem, testami oraz poprawkami. Zapisz, ile scenariuszy przeszło bez ręcznej naprawy. Przy kolejnej próbie użyj tych samych warunków. Inaczej porównasz różne zadania, a wynik przypiszesz narzędziu.

Sprawdź koszt po wygenerowaniu kodu

Proponuję liczyć koszt modelu, środowiska oraz pracy człowieka. Uwzględnij przygotowanie zadania, sprawdzenie wyniku, poprawki i obsługę błędów. Niski rachunek za API może występować obok wysokiego kosztu doprowadzenia zmiany do działania.

Prosty punkt odniesienia

Koszt zaakceptowanej zmiany = koszt całej próby / liczba zmian, które spełniły uzgodnione kryteria

Porównuj zmiany o podobnym zakresie. Jeśli żadna nie przeszła odbioru, najpierw wyjaśnij przyczynę. Ten wskaźnik nie mierzy przychodu ani zwrotu z inwestycji.

Powiąż wynik z wartością

Krótszy czas pisania kodu jest użyteczny, jeśli prowadzi do poprawy, na której zależy firmie. Sprawdź czas obsługi, liczbę błędnych operacji albo koszt wykonania procesu. Przy zwolnionym czasie policz też, na co zespół faktycznie go przeznaczył. Oszczędzone godziny nie zawsze oznaczają niższy wydatek.

Karta decyzji przed wdrożeniem

Uzupełnij tę kartę przed rozpoczęciem próby. Puste miejsce wskazuje decyzję, którą trzeba jeszcze podjąć. Nie zastępuj go opisem możliwości narzędzia.

Problem i odbiorca: Co dziś nie działa? Kto odczuwa skutek? Skąd wiemy, że warto to zmienić?
Miara oraz punkt odniesienia: Co mierzymy przed zmianą? Jaki wynik uzasadni kolejny krok?
Zakres i ograniczenia: Co agent może zmienić? Jakie dane może otrzymać? Czego nie wolno mu zrobić?
Dowód działania: Który scenariusz biznesowy, przypadek błędny oraz test integracji muszą przejść?
Decyzja i wycofanie: Kto akceptuje wynik? Co wstrzymuje wdrożenie? Jak wrócimy do poprzedniej wersji?

Otwórz kartę do skopiowania

Co z tego porównania wynika, a czego nie sprawdziłem

To eksperyment na jednym projekcie oraz części jego przypadków biznesowych. Nie daje podstaw do ogłoszenia jednego stylu architektonicznego najlepszym dla każdego zespołu. Wyników nie traktuję jako prognozy dla kolejnego modelu, narzędzia lub domeny.

Testy funkcjonalne nie potwierdzają bezpieczeństwa całego systemu. Analiza statyczna nie zastępuje sprawdzenia procesu biznesowego. Do decyzji o wdrożeniu potrzebujemy obu perspektyw oraz oceny konkretnego ryzyka.

Najbardziej użyteczny wniosek jest prosty: opisz ograniczenia, przygotuj sposób sprawdzenia wyniku i policz koszt doprowadzenia zmiany do działania. Dopiero wtedy możesz ocenić, czy AI pomaga w Twoim projekcie.