Wdrożenie AI w SDLC: standard procesu, pomiar i pilot

Nie.

Grupa Pracuj wdrożyła metryki DORA jako narzędzie diagnostyczne, między innymi po to, żeby wiedzieć, gdzie przyspieszenie może być zupełnie niepotrzebne. Opisuje to odcinek 121 podcastu Patoarchitekci.

Rozmówcy nieraz widzieli, jak po zbudowaniu czegoś wewnątrz firmy pojawia się opór organizacyjny. Standard trafia do projektów, które są gotowe go przyjąć i tego chcą. W zespole działa ambasador, który na co dzień reprezentuje ten proces.

Łukasz Kałużny: Nie widać z tego efektów poza kosztami. Trzeba wyciągnąć z tego lekcję, że z AI przechodzimy dokładnie tą samą drogę: zysk będzie widać dopiero po przeprojektowaniu procesu, podejścia i dojrzałości. AI to wzmacniacz: podnosi dojrzałe zespoły i nasila dysfunkcje słabych. Jeżeli przyspieszymy tylko jeden etap, to w którymś miejscu proces się zapcha. Nie będzie też tak, że wdrożycie narzędzie, a reszta zrobi się sama.

Mikołaj Szczerbicki: Cześć! Witajcie w Powered by Protopia. Nazywam się Mikołaj Szczerbicki i dzisiaj jest ze mną w studio Łukasz Kałużny.

Łukasz Kałużny: Cześć.

Mikołaj Szczerbicki: Łukasz, dzisiejszy temat widzimy bardzo często. To jeden z głównych tematów, które podnoszą nasi klienci i organizacje, z którymi współpracujemy. Chodzi o potężny wzmacniacz w postaci AI, który niestety jest podpinany do niemierzonych, nieustandaryzowanych procesów. Dzisiaj chcemy porozmawiać o procesie wytwarzania oprogramowania.

Łukasz Kałużny: Tak. To, co mówisz, słyszymy z rynku, nie tylko od klientów, ale ogólnie przy wymianie doświadczeń. Firmy chcą wrzucić AI, bo mówi się, że jest niesamowite w generowaniu kodu. Niektórzy CEO z zagranicy, ze Stanów, ze świata startupów i Big Techów, mówią nawet, że problem kodu został rozwiązany i AI go rozwiązuje. Ale samo wrzucenie narzędzi, czyli danie komuś popularnego GitHub Copilota, Codexa od OpenAI czy Claude Code od Anthropic, nie pokazuje tak naprawdę żadnego przyspieszenia pracy i nie widać z tego efektów poza kosztami.

Mikołaj Szczerbicki: Tak, ja też miałem ostatnio rozmowy kuluarowe z managementem kilku organizacji i temat brzmiał u wszystkich bardzo podobnie. Wiadomo, diabeł tkwi w szczegółach i w każdej organizacji trzeba indywidualnie podejść do procesów. Ale problem jest ten sam albo firmy są ciągle na etapie zastanawiania się, w których procesach najpierw wdrażać AI i jak mierzyć sukces. Do tego dzisiaj dojdziemy na przykładzie developmentu. Albo przychodzi oddolna inicjatywa developerów i manager mówi: dobrze, korzystajcie, skoro chcesz używać, to pewnie wiesz, czego. I nagle pojawia się, tak jak powiedziałeś, wiele różnych rozwiązań: od aplikacji czatowych wykupionych w nieco droższych, podobno bezpieczniejszych wersjach, po własny interfejs z podpiętym API. Ale dalej jest to totalnie nieustandaryzowane i w którymś momencie organizacja widzi, że nie przynosi to efektu ani żadnego zysku.

Łukasz Kałużny: Tak. W IT mówimy, że mamy software development life cycle, w skrócie SDLC. Po polsku to cykl wytwarzania oprogramowania, czyli standard tego, w jaki sposób wytwarzamy oprogramowanie w firmie.

Mikołaj Szczerbicki: Czyli, i to jest bardzo ważne, to nie jest pisanie kodu, tylko spojrzenie na cały proces.

Łukasz Kałużny: Tak, to cała droga od zebrania potrzeby biznesowej aż do działającego, wdrożonego oprogramowania. To nie jest to samo co pisanie kodu. W zależności od tego, gdzie pójdziemy podyskutować, u tych, którym się udało albo którzy skupili się na pisaniu kodu, usłyszymy, że raporty pokazują przyrosty rzędu 4–5%, czasami mniej. W niektórych bardzo małych organizacjach słyszymy o niebotycznych liczbach, bo nie mają żadnych narzutów organizacyjnych. W małym produkcie, na przykład w małym SaaS-ie, developer jest w stanie w ciągu dnia przetestować i wdrożyć to, co napisał. W dużych organizacjach, z którymi pracujemy, bardzo często nie ma takiej możliwości.

Jeżeli podzielimy cykl wytwarzania oprogramowania na etapy, to mamy zebranie wymagań, tworzenie kodu, testowanie, wdrożenie i na końcu utrzymanie. Jeżeli przyspieszymy tylko jeden etap, to w którymś miejscu proces się zapcha. Dlatego mówimy, że jeżeli chcemy wdrożyć AI w SDLC, czyli wzmocnić ten proces, to standaryzujemy cały proces, a nie tylko pojedyncze narzędzie dla developera.

I ważne: przy obecnym trendzie trzeba się pogodzić z tym, że narzędzia zmieniają się co kwartał i wymyślamy nowe podejścia, bo jako branża dopiero uczymy się, jak to najlepiej wykorzystać. Prawdziwa wartość jest w tym, żeby podejście było powtarzalnym, skalowalnym sposobem pracy dla całej organizacji, a nie tylko dla jednego developera czy jednego zespołu.

Mikołaj Szczerbicki: To, że branża jeszcze się tego uczy, jest szalenie ważne. Naturalne pytania z poziomu zarządu czy wysokiego managementu brzmią właśnie tak: jak mamy mierzyć ten zysk? Na co mamy patrzeć? Dziś ciężko to określić, ale z tego, co wiem, masz pomysł i propozycję, jak to robić. Powiedz mi, jak według Ciebie powinien wyglądać proces wdrożenia AI w SDLC?

Łukasz Kałużny: Zacznijmy od ciekawej rzeczy. Noblista Solow stwierdził w 1987 roku, że komputery widać już wszędzie, ale nigdzie nie widać wzrostu wartości z tych komputerów. Potrzebowaliśmy wtedy około 15 lat, żeby pojawił się zwrot z inwestycji we wprowadzenie komputerów do organizacji. Silnik elektryczny, kiedy pojawiał się w fabrykach, potrzebował około 40 lat. Dlaczego? Bo procesy musiały się dostosować do nowej rzeczy. Trzeba wyciągnąć z tego lekcję, że z AI przechodzimy dokładnie tą samą drogę. Zysk będzie widać dopiero po przeprojektowaniu procesu, podejścia i dojrzałości. Prawdopodobnie ten cykl zwrotu będzie z perspektywy organizacji o wiele szybszy niż przy wprowadzaniu komputerów czy silnika elektrycznego do przemysłu.

Mikołaj Szczerbicki: Poczekaj, Łukasz. Chcesz mi powiedzieć, że trzeba naprawić cały proces, a nie tylko wpiąć agenta po API w jednym miejscu i mieć wszystko zrobione?

Łukasz Kałużny: Tak, trzeba się dostosować. Jeżeli chcemy to kontrolować, musimy to zmierzyć. Chcemy ocenić punkt wyjścia przed udoskonaleniem procesu i po nim. To jest istotne.

Mikołaj Szczerbicki: Przepraszam, że Ci przerwę, ale wydaje mi się, że to wręcz kluczowe. Jeżeli chcemy mieć punkt odniesienia i patrzeć na te same wartości przed i po, to trzeba to zaplanować, zanim rozpoczniemy wdrożenie. Niezależnie od tego, czy chcemy zrobić to od razu w całości, czy etapami, najważniejsze jest, żeby już na samym początku zaplanować, co i w których punktach będziemy mierzyć.

Łukasz Kałużny: Tak. W naszym podejściu punktem wyjścia jest obejrzenie obecnego procesu i potem rozwijanie go ewolucyjnie. Nie zrobimy wszystkiego od razu. To nie będzie rewolucja, tylko ewolucja: zobaczymy, jak dostosować to, co istnieje, żeby współpracowało z tymi narzędziami i żebyśmy uzyskali powtarzalny efekt w skali organizacji, a nie sukces jednego zespołu. Czasami może wystarczy sukces jednego zespołu, tu też nie wolno się zamykać. Ale pytanie brzmi: czy będziemy w stanie potem powielić to w organizacji?

Zanim przejdziemy do tego, co standaryzujemy, powiem jeszcze, jak tego nie robić na początku. To nie są dema na pokaz ani jednorazowe warsztaty. Nie będzie też tak, że wdrożycie narzędzia, a reszta zrobi się sama. Raport DORA z zeszłego, 2025 roku zawierał bardzo ciekawą rzecz: AI to wzmacniacz, podnosi dojrzałe zespoły i nasila dysfunkcje słabych.

Mikołaj Szczerbicki: To jest bardzo dobry cytat.

Łukasz Kałużny: Tak. Słuchaj, Mikołaj, co konkretnie standaryzujemy? Pierwszym elementem jest sprawdzenie, jak wygląda SDLC i jego standard, żeby dowiedzieć się, czy już na papierze nie ma wąskich gardeł i problemów. Czyli jak wygląda CI/CD, jakie są kadencje wydawnicze i czy firma ma to w ogóle ustandaryzowane.

Mikołaj Szczerbicki: Czyli pierwszy krok to assessment stanu AS IS procesu SDLC w organizacji. Dobrze rozumiem?

Łukasz Kałużny: Tak, dokładnie. Nie nazwę tego audytem, to będzie assessment, czyli przegląd, żeby wyciągnąć wnioski. Potem przy standaryzacji procesów stosujemy metodę, którą nazywamy Spec Driven Development. Chodzi o to, żeby to nie był vibe coding, tylko powtarzalne zbieranie wymagań, generowanie z nich specyfikacji, potem tworzenie planu, jak agent będzie pracował i wdrażał daną funkcjonalność, i na koniec realizacja kodu. Bazujemy na otwartych standardach, takich jak GitHub Spec Kit czy OpenSpec, albo tworzymy dedykowaną, lżejszą wersję dostosowaną do organizacji.

Chodzi o to, żeby zrobić jeden spójny standard pracy z agentem w repozytoriach organizacji. Mimo spójności zawsze będą jakieś dostosowania do projektu. Ale ma to być punkt wyjścia, który zespół może ponownie wykorzystać w nowym projekcie albo w projekcie, który zostanie tym objęty.

Kolejne rzeczy to skille, czyli zestawy komend i promptów, które mówią, jak coś zrobić: globalnie w firmie, na przykład „zrób mi review wymagań zgodnie z globalną polityką”, albo w danym projekcie. Jeden z bardzo popularnych skilli, które wdrażamy u klientów, to analiza zgłoszenia błędu na produkcji, żeby skrócić czas znalezienia miejsca, w którym był błąd.

Mikołaj Szczerbicki: Czyli sposób, w jaki proces przebiega w organizacji, musi być dostosowany do AI. Wiemy, że Spec Driven Development jest procesem, który przy korzystaniu z AI sprawdza się dobrze i jest często rekomendowany.

Łukasz Kałużny: Tak. Dalej są elementy takie jak dokumentacja w repozytorium z kodem, która jest czytelna i dla agenta, i dla człowieka, i jest potem aktualizowana. Następnie rzeczy bardzo twarde, techniczne: harnessy i guardraile, czyli całe otoczenie agenta, żeby miał krótką pętlę feedbacku. Tak jak developer wykorzystuje unit testy, tak tu automatyzujemy formatowanie, lintowanie kodu, testowanie, odpowiednie blokady, unit testy czy bramki jakości: w niektórych miejscach pokrycie testami, cognitive complexity albo cognitive load, czyli jak trudno zrozumieć kod i jak bardzo jest złożony. Chodzi o wybór metryk, dzięki którym kod będzie łatwiej usuwalny albo utrzymywalny w przyszłości, i o automatyczne wpięcie ich w proces. W agentach kodujących chodzi o to, żeby dostarczyć konfigurację, dzięki której agent dostaje jak najszybszy feedback i idzie w kierunku, którego sobie życzymy.

Mikołaj Szczerbicki: Czyli każda część procesu jest tworzona tak, żeby maksymalnie wykorzystać możliwości agentów.

Łukasz Kałużny: Tak, dokładnie. Na końcu tego wszystkiego jest dobór narzędzi. Nie mówiłem o nich na początku, bo wiele z tych praktyk łatwo przenieść między modelami i narzędziami. Ogólne podejście można ustandaryzować. Mamy świadomość, że rynek jest zmienny i mody zmieniają się co miesiąc albo co kwartał. Dlatego narzędzia i modele dobieramy pod Wasz stos i pod Wasz compliance, który też jest tu istotny.

Mikołaj Szczerbicki: OK, to podsumujmy trochę, bo poruszyliśmy dwie części tematu: to, że procesy muszą być ustandaryzowane, i to, jak wygląda sam proces. Możesz bardzo krótko wypunktować, co tak naprawdę jest standaryzowane?

Łukasz Kałużny: Tak. Po pierwsze, wdrożenie Spec Driven Development w proces. Za tym idzie standard pracy z agentem, skille i sposób, w jaki układamy w repozytorium wiedzę o danym kodzie źródłowym i produkcie. Potem rzeczy twarde dla agenta, które wybieramy razem z narzędziem, czyli cała pętla zwrotna, która z jednej strony go pilnuje, a z drugiej daje mu feedback, że coś wykonał źle. To cały zestaw techniczny.

Jeżeli rozłożymy to na cały proces SDLC, to przy wymaganiach wchodzi Spec Driven Development. W fazie kodu, testów i review są wszystkie te narzędzia plus Spec Driven Development. Potem są rzeczy, które pomagają w utrzymaniu: czy faktycznie mamy testy integracyjne i unit testy, czy wszystko jest odwzorowane i działa lokalnie oraz w Continuous Integration i Continuous Deployment. To, co standaryzujemy w poszczególnych elementach, rozpina się na cały proces.

Mikołaj Szczerbicki: Dobrze, mamy podsumowane, co będzie standaryzowane i jak. Przejdźmy przez samo wdrożenie. Jak według Ciebie powinien wyglądać proces wdrożenia AI w SDLC, żeby zakończył się sukcesem?

Łukasz Kałużny: Zaczynamy, tak jak powiedziałem, od oceny stanu bieżącego i gotowości. Czyli czy proces jest gotowy na AI, a nie AI na proces. To bardzo ważne: z góry zakładamy, że proces trzeba będzie dostosować do nowego trybu. Oceniamy podejście i higienę: testowalność, częste wdrażanie, a jeśli nie ma takiej potrzeby, to czy wdrażanie oprogramowania jest przynajmniej zautomatyzowane. Oceniamy też wszystko, co jest przed tym, czyli serwery buildu i całe CI/CD.

Mikołaj Szczerbicki: To trochę analogia do człowieka, który często musi przygotować sobie środowisko pracy. Nie zawsze możesz pracować w każdych warunkach. Tu jest to samo: jeżeli AI ma być efektywne, trzeba mu przygotować odpowiednie środowisko pracy.

Łukasz Kałużny: Wracamy do tego, co wraca do nas cyklami, czyli do całego podejścia DevOps i pętli feedbacku, która się przy nim pojawiała. Do tego wracamy i to oceniamy.

Mikołaj Szczerbicki: OK.

Łukasz Kałużny: Następny krok, kiedy już to ocenimy i wiemy mniej więcej, co chcemy zrobić, to wybór zespołu do pilota. To będzie kluczowe: znajdujemy zespół, system, moduł albo aplikację, jedną lub dwie, żeby wystartować. Najlepsze są zespoły, które same zgłoszą się na ochotnika, bo faktycznie chcą to zrobić. Powinno to wymagać zaangażowania całego zespołu.

Mikołaj Szczerbicki: To bardzo ważne. Po pierwsze wiem, że takie zespoły są. Słyszymy o tym od naszych klientów i w rozmowach z różnymi organizacjami: osób zainteresowanych jest naprawdę bardzo dużo. Czyli wybieramy zespół, najlepiej taki, który sam się zgłosi i który potem będzie ewangelizował to rozwiązanie w organizacji. Co jest kolejnym krokiem?

Łukasz Kałużny: Kolejnym krokiem jest określenie stanu przed, czyli mierzenie. Będziemy mówić o mierzeniu, ale nie o KPI. Dlaczego? Bo przy KPI może nastąpić malowanie trawy na zielono, jak przy każdym KPI, i gra pod tytułem „jak spełnić KPI”. Więc mierzymy. To diagnostyka, która pokazuje, gdzie jest wąskie gardło i od czego zacząć, żeby przyspieszyć z głową. To model monitoringu: nie ustawiamy konkretnych celów, tylko patrzymy, jaki efekt faktycznie uzyskamy.

Nie patrzymy też na wskaźniki pozorne, czyli ile tokenów zużyto, ile linii kodu i pull requestów wygenerowano, jaki procent kodu wygenerowało AI. To nie jest produktywność. Nie sprowadzimy wszystkiego do jednej liczby, to będzie ocena wielowymiarowa. W naszym podejściu to trzy poziomy, albo dwa i pół, zależnie od tego, jak policzymy.

Pierwszy to metryki tego, czy dowozimy szybciej i stabilniej, w postaci DORA Metrics. To cztery metryki: jak często wdrażamy zmiany, odsetek nieudanych wdrożeń, czas przywracania po awarii. Drugi element to flow, czyli czas od wejścia prośby o funkcjonalność albo zmianę w aplikacji do chwili, w której oddajemy ją na produkcji. Nie tylko czas generowania kodu, ale metryki od wejścia do dostarczenia.

Mikołaj Szczerbicki: Czyli jakiś fragment tego procesu.

Łukasz Kałużny: Tak naprawdę całość procesu: od chwili, kiedy weszło do nas wymaganie, na przykład nowy ekran albo nowa funkcjonalność w aplikacji, do jej stworzenia i faktycznego dostarczenia wartości. Bo na koniec dnia chcemy dostarczać albo szybciej, albo stabilniej.

A co do stabilności, ostatnia rzecz to jakość. Z klientem ustalamy, jak w jego przypadku zmierzyć liczbę zgłoszonych bugów, może pogorszenie czasu. Chodzi o to, żeby zmierzyć, czy podejście agentowe pogorszyło jakość, polepszyło ją, czy jakość była stabilna, jeśli to dojrzały zespół. To też definiujemy. Mamy więc trzy rzeczy.

Polecam też odcinek naszego drugiego, technicznego podcastu Patoarchitekci. W odcinku 121 Kinga Gaździńska z Grupy Pracuj opowiada, jak wdrożyli DORA Metrics i po co: jako narzędzie diagnostyczne, żeby wiedzieć, jak firma pracuje, gdzie można coś poprawić i przyspieszyć z głową, a gdzie jest to zupełnie niepotrzebne.

Mikołaj Szczerbicki: Serdecznie zapraszamy wszystkich do obejrzenia tego odcinka.

Łukasz Kałużny: Tak. Potem przechodzimy do pilota. Pracujemy z wybranym zespołem albo zespołami na realnym produkcie. Pomagamy w formie mentoringu i konsultacji przez jeden lub dwa cykle wdrożeń na produkcję. Zależnie od tego, czy to sprint i ile trwa, dostosowujemy to tak, żeby przejść i przetestować całą ścieżkę od A do Z.

Mikołaj Szczerbicki: Mam pytanie, bo chciałbym, żeby to wybrzmiało. Dobrze rozumiem, że mówimy o realnych działaniach na produkcji, na produktach klienta, a nie o wymyślonych case'ach testowanych gdzieś z boku?

Łukasz Kałużny: Tak. Chcemy wziąć prawdziwą aplikację, która jest rozwijana i utrzymywana, i przejść w niej cały cykl życia procesu. Dlatego mówimy, że to mogą być jeden lub dwa sprinty po skonfigurowaniu wszystkiego, żeby dojść do tego, że to faktycznie zadziałało. Z takim zespołem wdrażamy całe podejście standaryzacji i wnioski.

Mikołaj Szczerbicki: To mega ważne, żeby testowanie i sprawdzanie odbywało się w takim środowisku, w jakim agent będzie później pracował. Żeby to nie były wymyślone case'y, tylko faktyczna wartość biznesowa dla konkretnego klienta.

Łukasz Kałużny: Tak. Po całości, czyli po standaryzacji w jednym zespole, powinniśmy mieć zebrane wcześniej dane i porównujemy je z wcześniejszym baseline'em: czy coś ruszyło do przodu, czy nie. Trzeba to sobie powiedzieć, bo mogą się zdarzyć takie systemy i aplikacje. Badania pokazują na przykład, że w bardzo dojrzałych zespołach nie było znacznego przyspieszenia. Trzeba mieć tego świadomość.

Mikołaj Szczerbicki: No właśnie. Z jednej strony chcielibyśmy niesamowitych wyników z użycia AI w procesie SDLC. Z drugiej strony wszystkie znaki mówią nam, że im lepiej idzie nam teraz, tym mniejszy będzie przyrost wydajności.

Łukasz Kałużny: Tak. Albo może się okazać, że znajdziemy miejsca do poprawy, które nie zależą od AI, tylko na przykład od procesów akceptacji. Ciekawym przypadkiem jest testowanie w akceptacji. Zespół szybciej naprodukuje, przetestuje po swojej stronie i wypchnie do akceptacji, a kolejka zapcha się na etapie akceptacji, bo ktoś nie będzie nadążał z testowaniem. To bardzo pożądany scenariusz na początku. Wtedy trzeba się zastanowić, jak możemy ten etap przyspieszyć i poprawić. Trzeba mieć tego świadomość.

Mikołaj Szczerbicki: To, co powiedziałeś, jest bardzo ciekawe. Próba wdrożenia AI w proces może pokazać, że tam, gdzie wydawało nam się, że AI pomoże, przyrost nie jest duży, więc może ostatecznie nie zdecydujemy się na AI. Ale i tak znaleźliśmy miejsca w innej części procesu…

Łukasz Kałużny: Do poprawy.

Mikołaj Szczerbicki: Do poprawy. To też jest sukces: coś zmierzyliśmy, sprawdziliśmy i niezależnie od tego, czy AI pojawi się w tym procesie, czy nie, proces został poprawiony.

Łukasz Kałużny: Tak, właśnie. Nawet jeśli próg nie zostanie osiągnięty i nie skalujemy, rekomendujemy diagnozę ograniczeń i być może powrót do fundamentów. Czyli jakie procesy w organizacji to blokują, gdzie są wąskie gardła, które spowodowały niepowodzenie. A może problem leży w tym, jak to skonfigurowaliśmy? Jak wyglądały review, testy i observability w obszarach, których to dotyczyło?

Mikołaj Szczerbicki: Właśnie. Możesz to prosto podsumować? Jesteśmy po ostatnim etapie, w którym robimy porównanie. Na początku wyznaczyliśmy metryki, teraz na końcu je oceniamy. Jakie decyzje podejmujemy w tym momencie?

Łukasz Kałużny: Albo wyciągamy wnioski, wracamy do fundamentów, diagnozujemy i poprawiamy. Albo akceptujemy poprawę i idziemy dalej: to, co się sprawdziło, przelewamy w standardy, szablony i definition of done. Co dalej? Jak rozsiać to po organizacji, jak to wyskalować?

Mikołaj Szczerbicki: To niesamowicie ważne pytanie i pada bardzo często. Nieraz spotkaliśmy się z sytuacją, w której wewnętrznie powstał jakiś proces czy aplikacja, po czym nagle pojawiał się opór organizacyjny.

Łukasz Kałużny: Tak. Pierwsza rzecz: być może nie trzeba rolloutu tego podejścia na całą organizację. Czasami, zależnie od wielkości firmy i krytyczności, wystarczy część organizacji, kilka zespołów developerskich. Aktualizujemy standard i tam, gdzie projekty są gotowe go przyjąć i są chęci, przygotowujemy plan adopcji w organizacji.

Skalujemy na przykład przez ambasadorów. Wybieramy z zespołów osoby, które przeszkolimy i którym pokażemy, jak został onboardowany projekt. Robimy dedykowane warsztaty ambasadorskie, żeby mogli pokazywać to innym. Z drugiej strony dajemy potem merytoryczne wsparcie onboardowanym zespołom w tym, jak powinny z tego korzystać.

Czyli z jednej strony jest ambasador, który pokazuje w swoim zespole, jak to powinno wyglądać, i jest na co dzień przedstawicielem tego procesu. Z drugiej strony są doraźne konsultacje i mentoring, żeby dostosować proces. Trzeba sobie powiedzieć, że standard ma pokazać ogólny kierunek i najważniejsze wytyczne, a każdy projekt i tak będzie potrzebował ostatniego doszlifowania, żeby faktycznie uzyskać wartość. Zawsze trzeba pamiętać, że w zespole będzie jakaś praca, żeby z tego skorzystać.

Mikołaj Szczerbicki: OK, zmierzając pomału do końca: istotna jest standaryzacja. Wymieniłeś najważniejsze elementy standaryzacji, którą trzeba wprowadzić w tym procesie, i opowiedziałeś, jak wygląda sam proces. Ja zapamiętałem przede wszystkim wyznaczenie, co będziemy mierzyć, sprawdzenie punktu początkowego i końcowego oraz znalezienie ewangelistów wewnątrz organizacji: zespołów, które będą bardzo aktywne podczas testowania, a potem mocno zaangażowane w adopcję w organizacji. Łukasz, bardzo Ci dziękuję za dzisiejszą rozmowę. Mam nadzieję, że dla wielu osób będzie ciekawa i że będą wiedzieli, jak podejść do tego tematu. Gorąco zachęcamy, żeby próbować wdrożyć AI w proces SDLC w organizacji.

Łukasz Kałużny: Tak, sami w firmie widzimy w tym bardzo dużą wartość i też mamy to ustandaryzowane.

Mikołaj Szczerbicki: Tak jest. Dziękujemy bardzo i do zobaczenia.

Łukasz Kałużny: Dzięki! Miłego dnia.

Mikołaj Szczerbicki: Cześć!

Łukasz Kałużny: Cześć.