AI w wytwarzaniu oprogramowania. Nie czekać, ale wiedzieć „po co?”

Jeśli oprogramowanie będzie powstawać w kilka dni, a najtrudniejszym pytaniem okaże się: „po co nam właściwie to rozwiązanie?” – mówi Jan Maria Kowalski, współzałożyciel inicjatywy Liderzy IT i współorganizator cyklu spotkań dla menedżmentu o implementacji AI a także członek Rady Programowej Klubu CxO. Rozmawiamy przed konferencją „Budowa oprogramowania w erze AI”, która odbędzie się 4 listopada i której partnerem medialnym jest redakcja Smart Tech RE:view.

Czy firmy powinny wstrzymać wdrażanie sztucznej inteligencji do czasu stworzenia ram bezpieczeństwa i zarządzania danymi? Jak zintegrować agentów AI z systemami, które same mają już wbudowaną sztuczną inteligencję?

Dwa tory zamiast czekania

Czy wdrażanie sztucznej inteligencji powinno poczekać na solidne ramy bezpieczeństwa i uporządkowanie zarządzania danymi? A tym samym cały program transformacji powinien zostać wstrzymany do czasu ich wprowadzenia?

Bliskie jest mi podejście dwutorowe, hybrydowe. Z jednej strony budujemy fundamenty, czyli strategię i zasady zarządzania (governance), tak aby w organizacji sztuczna inteligencja była wdrażana bezpiecznie i odpowiedzialnie. Z drugiej strony nie możemy czekać, aż opracujemy politykę bezpieczeństwa, wybierzemy narzędzia i platformy, podpiszemy umowy z dostawcami, zapewnimy obserwowalność systemów (observability) i zrobimy wiele innych rzeczy. Biznes na to nie poczeka.

Sam stosowałem takie podejście i widzę je w różnych firmach. Nazywaliśmy je eksploracyjnym, „oddolnym”. Szukaliśmy okazji, czyli miejsc w procesach, które da się zautomatyzować – na przykład streszczanie notatek ze spotkań, wstępne sortowanie zgłoszeń do helpdesku czy przygotowywanie szkiców dokumentacji – i po prostu to robiliśmy. Wiąże się to z pewnym ryzykiem, ale na tyle niewielkim, że można nad nim zapanować, jeśli wybiera się procesy i zadania niekrytyczne, bez większego wpływu na klienta. Zacznijmy od środka, od narzędzi dla pracowników. Testujmy najpierw na sobie, a dopiero potem udostępniajmy efekty klientom, zbierając po drodze doświadczenia. Uczmy się.

 Jestem więc zwolennikiem modelu dwutorowego. Z jednej strony budujemy platformę, która pozwoli nam się skalować w przyszłości, i standaryzujemy sposób realizacji projektów. Nie budujemy pięciu osobnych chatbotów, tylko docelowo mamy jedno rozwiązanie, które potrafimy udostępniać różnym klientom czy zespołom. Zanim jednak do tego dojdziemy, dajmy sobie szansę na eksperymenty, naukę i popełnianie błędów w projektach bez większego wpływu na klienta, tak aby ewentualne wpadki nas nie bolały.

Pamiętam, że ten podział, a właściwie próba pogodzenia dwóch podejść, był jednym z pierwszych dużych tematów w społeczności, którą współtworzycie. Minęło półtora roku. Czy taka hybryda się sprawdza? Rozwój jest przecież niezwykle dynamiczny: narzędzia programistyczne AI stale się zmieniają.

Myślę, że tak. Narzędzia rzeczywiście szybko się zmieniają i starzeją. Dlatego warto już teraz podejmować decyzje, eksperymentować i testować, a za trzy czy sześć miesięcy dokonać innego wyboru, zamiast czekać na platformę, która ma być naszym fundamentem. Taka platforma również szybko się zestarzeje. Zanim ją wybierzemy i uruchomimy, na rynku pojawią się nowe modele, biblioteki i gotowe produkty, więc trzeba będzie ją przebudowywać.

Jednocześnie widzę w organizacjach, z którymi współpracuję, i słyszę od praktyków na naszych konferencjach, że w firmach powstają zespoły i projekty, które chcą wprowadzać AI na własną rękę, po swojemu. Brakuje synergii. Zespół odpowiedzialny za reklamacje chce mieć własnego bota albo narzędzie do ich automatyzacji. Zespół od kredytów hipotecznych i innych dyspozycji klientów buduje podobne rozwiązanie, tyle że może na zupełnie innej technologii, ucząc się przy okazji wszystkiego od zera. Za chwilę trzeci zespół zaczyna własny projekt, a firma płaci kilka razy za tę samą naukę.

Jeszcze półtora roku temu powiedziałbym: niech różne zespoły testują, próbują i uczą się. Dziś te narzędzia są jednak na tyle dojrzałe i sprawdzone, że warto już dokonywać wyborów. Jeśli firma korzysta z oferty dużego dostawcy, a pracownicy mogą w jego narzędziu budować własne chatboty, to nie szukajmy innych technologii ani nie twórzmy wszystkiego we własnym zakresie. Uznajmy to rozwiązanie za nasz standard. Wtedy łatwo udostępnić je pracownikom, zapewnić szkolenia, pokazać, jak je budować, i dzielić się wiedzą – na przykład w ramach wewnętrznej społeczności, w której zespoły wymieniają się gotowymi wzorcami.

Dobrym przykładem jest analityka rozmów z klientami. Wszędzie tam, gdzie działa telefoniczna obsługa klienta, można zastosować technologię zamieniającą mowę na tekst. Wiele zespołów próbuje uruchamiać takie projekty samodzielnie, a można po prostu powiedzieć: to jest nasza technologia do analizy mowy, korzystajcie z niej – w contact center, przy obsłudze reklamacji i wszędzie tam, gdzie przyjmujemy zlecenia telefonicznie. Dzięki niej można na przykład wychwytywać powody reklamacji, sprawdzać zgodność rozmowy z procedurą czy wyłapywać rozmowy wymagające szybkiej reakcji. Podobnie jest z dokumentami: jeśli chcecie analizować treść umowy kredytowej albo maila od klienta, mamy już do tego gotowe narzędzie. Nie chodzi więc koniecznie o jedną kompleksową platformę AI. Pojawiają się raczej rozwiązania domenowe, obszarowe, na których warto się oprzeć. Rośnie potrzeba takiej standaryzacji, takiej platformizacji.

Benchmarki bez znaczenia, ważna jest domena

Czy na rynku powstają już swego rodzaju macierze lub rekomendacje, na przykład że ekosystem jednego dostawcy lepiej sprawdza się w danej domenie biznesowej, ale musi się „dogadać” z narzędziami innego dostawcy, który jest w czymś wyspecjalizowany? A może taką klasyfikację każda firma musi budować sama?

Myślę, że specjalizacja modeli to raczej domena inżynierów, którzy doktoryzują się z benchmarków: który model o ile punktów procentowych wyprzedził inny. Za dwa tygodnie ta sytuacja się odwróci. Moim zdaniem nie ma to w ogóle znaczenia dla biznesu i organizacji. Te technologie są po prostu porównywalne, a nawet jeśli dziś jeden model jest lepszy od drugiego, wkrótce będzie już nieco gorszy.

Specjalizacja następuje natomiast w domenach biznesowych. Zauważył to również Gartner: mówi się o embedded AI, czyli sztucznej inteligencji osadzanej w systemach, z których firma już korzysta. Weźmy firmę, która używa systemu CRM od zewnętrznego dostawcy: jeszcze dwa lata temu nie było w nim AI, a dziś dostawca już o to zadbał i oferuje na przykład podsumowanie historii kontaktów z klientem czy propozycję odpowiedzi na maila. Klient nie musi się zastanawiać, jak wprowadzić AI do obsługi klienta, bo dostawca mówi: mam gotowe rozwiązanie, nie musisz się tym zajmować. Podobnie jest w systemach contact center, gdzie dostawcy uznają za oczywiste, że potrzebna jest transkrypcja rozmowy, notatka po rozmowie z klientem, a może nawet podpowiedzi na żywo, co odpowiedzieć na trudne pytanie. Specjalizacja dotyczy więc poszczególnych domen: systemów CRM, contact center i tym podobnych.

A platformy do budowy agentów?

Firmy nie mają jeszcze do końca przemyślanej koncepcji budowy takich platform. Mówi się: ten agent będzie umiał wszystko – rozpoznawać mowę, analizować dokumenty, tworzyć materiały marketingowe na stronę, cokolwiek. Postawisz platformę dla agentów i nie musisz już myśleć o systemach CRM, ERP czy HR. Tymczasem każdy z dostawców tych systemów ma już własnego agenta i mówi: skorzystaj z niego, bo jest zintegrowany, nie musisz niczego dokupować, tylko podniesiemy subskrypcję.

Z kolei pojawili się dostawcy platform agentowych. Powstała konkurencja i klienci zastanawiają się, którą platformę wybrać oraz jak ją w ogóle uruchomić. To będzie największe wyzwanie: jak połączyć takiego agenta lub taką platformę z systemami CRM, ERP, HR i innymi, które, jak sobie powiedzieliśmy, mają już własną sztuczną inteligencję. Po co mi więc jeszcze ten agent?

Wydaje mi się, że to dziś prawdziwa zagadka dla decydentów: szefów działów AI, dyrektorów IT, architektów. Mają poważny ból głowy, bo muszą to wszystko ze sobą zintegrować, a jednocześnie biznes naciska: nie mamy jeszcze agentów, musimy je mieć. Agenci mają autonomicznie obsługiwać reklamacje, przyjmować wnioski kredytowe, wypłacać transze, odpowiadać na maile od klientów, czyli przejąć część pracy od zespołów ludzkich. Moim zdaniem od strony architektury nie jest do końca przemyślane, jak włączyć ich we własny ekosystem narzędzi i systemów IT.

Kod to już nie sensacja

Wasze konferencje cechuje wybieranie aktualnych wyzwań w implementacji AI. Ostatnia dotyczyła roli analityka i architekta. Czy wnioski z tego cyklu pokrywają się z tym, o czym mówimy?

W ramach naszych konferencji dotykaliśmy nie tyle procesów biznesowych, takich jak obsługa klienta, reklamacje czy sprzedaż produktów, ile procesów wewnętrznych, w szczególności budowy oprogramowania. Firmy coraz chętniej dzielą się doświadczeniami, jak wykorzystać agenta w codziennej pracy analityka, architekta, programisty czy testera, czyli w procesie nie biznesowym, lecz technologicznym.

Pojawiły się dobre praktyki łączenia agenta z ekosystemem narzędzi do budowy oprogramowania. Bywa to nawet łatwiejsze niż integracja z systemem HR czy ERP. Analitycy i architekci pracują w narzędziach takich jak Enterprise Architect, czyli repozytorium, w którym tworzy się architekturę, diagramy i komponenty, a także w wiki, w SharePoincie czy w Wordzie, gdzie znajdują się dokumentacja projektowa i specyfikacja wymagań. Platformy do budowy agentów wspierających analityka czy architekta można w dość prosty sposób podłączyć do repozytorium dokumentów oraz do narzędzia, w którym zgromadzona jest cała wiedza o architekturze systemów. Agent może wtedy na przykład przygotować wstępny diagram komponentów na podstawie specyfikacji albo sprawdzić, czy nowe wymagania pasują do istniejącej architektury.

Czy kodowanie z AI, wykorzystanie agentów w programowaniu to jeszcze temat „sexy”?

Staje się normą. W ciągu półtora czy dwóch lat tak się to upowszechniło, że nikt już nie zastanawia się, czy i jak wprowadzić agenta do programowania. Można użyć Claude Code, Codeksa czy GitHub Copilota, podłączyć go do repozytorium kodu źródłowego i środowiska testowego, tak aby po zbudowaniu aplikacji automatycznie ją przetestować, wdrożyć na tym środowisku i oddać użytkownikom do sprawdzenia. W tym obszarze wiele się zmieniło i jest dużo dobrych przykładów oraz praktyk.

Natomiast nadal nie do końca wiadomo, jak skutecznie wykorzystać agentów w biznesie i połączyć ich z działającymi aplikacjami.

Konferencja 4 listopada: cały proces, nie tylko kod

Najbliższa konferencja, 4 listopada, ma traktować całościowo proces dostarczania oprogramowania. Skoro zmieniliśmy cykle wytwarzania i czas przestał być głównym ograniczeniem, pojawiają się na pewno inne. Jaki jest pomysł na to wydarzenie?

Po konferencji z początku października, na której dyskutowaliśmy o wykorzystaniu sztucznej inteligencji w pracy analityka i architekta, zauważyliśmy, że warto zorganizować wydarzenie poświęcone całemu cyklowi wytwarzania oprogramowania: od analizy, przez projektowanie systemu, programowanie i testowanie, po wdrażanie, a także zarządzanie zespołami. Stąd ścieżka menedżerska, w której poruszymy kwestię wpływu sztucznej inteligencji na tworzenie zespołów, struktury organizacyjne, role i odpowiedzialności.

Nie chodzi o to, że analitycy, programiści i specjaliści DevOps będą dzięki AI pracować szybciej. Uważam, że będą pracować inaczej. Część zadań oddadzą agentom lub modelom, a role biznesu i technologii będą się do siebie zbliżać. Analityk biznesowy wyposażony w agenta będzie mógł pewne rzeczy przetestować, zaprototypować i opracować bez konsultacji ze stroną technologiczną – na przykład samodzielnie przygotować działający prototyp procesu czy ekranu i pokazać go użytkownikom. Z kolei programista, jeśli większość pracy przy kodzie odda agentowi, będzie musiał nauczyć się biznesu, zrozumieć domenę, wejść trochę w buty analityka i częściej rozmawiać z końcowym użytkownikiem: jakie ma potrzeby, co trzeba zbudować, jakie funkcje ma mieć aplikacja. Potem zakoduje to agent. Widzimy, że role się zmieniają, i dlatego chcemy spojrzeć na cały proces wytwarzania oprogramowania kompleksowo.

A czy w tym redefiniowanym procesie jest miejsce do zastosowania bardziej kreatywnych – generatywnych funkcji AI?

Mówisz o odkrywaniu potrzeb, czyli product discovery. Sztuczna inteligencja pozwala dziś szybko przeprowadzić analizę rynku i porównać ofertę z konkurencją.

Zdecydowanie – to wchodzi w zakres naszej konferencji. Możemy działać proaktywnie i nie czekać, aż biznes zaproponuje, że chciałby na przykład mieć w aplikacji mobilnej funkcję zakupu biletów do kina. Agent może sprawdzić, co wdrożyła konkurencja – nie tylko na rynku lokalnym, ale też na świecie – wychwycić trendy, ocenić, jak inni rozwiązali płatność, wybór miejsc czy program lojalnościowy, i coś nam podpowiedzieć. Wchodzimy więc na sam początek procesu wytwarzania oprogramowania, bo zarówno w discovery, jak i w prototypowaniu takie narzędzia znajdują duże zastosowanie.

Czy taki agent od razu weryfikowałby swoje pomysły, czyli oceniał, jak mieszczą się one w obecnej architekturze informatycznej, aplikacyjnej, a przede wszystkim biznesowej? Co mogłyby zastąpić albo scalić, jakie są argumenty za i przeciw?

Tak, bo pomyślałem sobie, że to może faktycznie rozbudzić apetyty ludzi z biznesu na rozwiązania, które z różnych przyczyn okażą się potem trudne do dostarczenia w danej organizacji. Mogłoby to wymagać znacznie większych zmian w firmie.

Takie narzędzie powinno więc samo ocenić realność projektu na podstawie tego, co wie o organizacji.

Dokładnie tak.

Jak będzie wyglądać konferencja od strony organizacyjnej i jak duża jest skala wydarzenia?

Konferencja trwa od 9 do 16 w dwóch strumieniach, między którymi można się swobodnie przełączać, wybierając interesujące tematy. Po wydarzeniu uczestnicy dostaną link do nagrań i prezentacji, żeby w ciągu kilku dni w spokoju obejrzeć to, co im umknęło, lub wrócić do wybranych treści.

Pierwszy strumień, bardziej technologiczny, będzie miejscem, w którym praktycy i eksperci podzielą się doświadczeniami z użycia AI w codziennej pracy: analitycy, architekci, programiści i testerzy pokażą, jak robią to już dziś i co im to daje.

Drugi strumień będzie bardziej menedżerski i organizacyjny. Chcemy w nim porozmawiać o tym, jak sztuczna inteligencja wpływa na zespoły, role i odpowiedzialności. Planujemy debatę w gronie dyrektorów IT odpowiedzialnych za rozwój technologii. Ponieważ światy technologii i biznesu tak się do siebie zbliżają, zaprosimy do niej także przedstawicieli biznesu. Dzięki AI zasiadają oni przy jednym stole i trochę na nowo definiują swoje role oraz to, czego mogą oczekiwać od drugiej strony.

Każde wystąpienie trwa około 25 minut i pokazuje konkretny przypadek wdrożenia w firmie prelegenta, a potem jest pięć minut na pytania i dyskusję. Zawsze zachęcamy uczestników do zadawania pytań i staramy się, żeby pochodziły one właśnie od nich. Tym razem konferencja nie odbywa się na żywo, więc zamiast pytań z sali pojawią się pytania z czatu.

Poprzednia konferencja, poświęcona analitykom i architektom w erze AI, przyciągnęła ponad 4000 uczestników. Spodziewamy się nie mniejszej frekwencji.

Przepisać miliony linii kodu w kilka dni

Jakie szykujecie hity? Dziś na przykład duże wrażenie w świecie wytwarzania oprogramowania pojawiają się doniesienia, że ktoś odtworzył i przepisał cały pakiet graficzny jednego z dostawców. Następna rzecz to pewnie przepisanie jakiegoś CRM-a czy innego systemu. Czy takie tematy znajdą swoje miejsce na konferencji?

Udział zapowiada jeden z prelegentów, reprezentujący firmę produktową. Pokaże, jak jego zespół w kilka dni przepisał całe rozwiązanie z jednej technologii na drugą, czyli kilka milionów linii kodu, oczywiście z wykorzystaniem agentów AI.

Nie wyobrażam sobie, jak taki kod można potem utrzymywać „po ludzku”, wprowadzać do niego poprawki i go wdrażać. Prawdopodobnie jest to już niemożliwe. Wchodzimy w model AI first: sztuczna inteligencja będzie dla nas kodować, a nawet drobne zmiany oddamy właśnie jej, bo my nie będziemy wiedzieć, w którym pliku i w której linii je wprowadzić.

Będzie też prelekcja kolegi, który uwrażliwia na kwestie bezpieczeństwa rozwiązań. Wykorzystuje on narzędzia AI do skanowania kodu, napisanego zarówno przez człowieka, jak i przez inną sztuczną inteligencję, aby wykryć luki i podatności.

Poruszymy także temat całego procesu. Skróciliśmy etap programowania, ale niekoniecznie cały cykl wytwarzania oprogramowania, bo składa się on jeszcze z analizy, projektowania, testowania i wdrażania. Jeden z prelegentów pokaże praktyczny przykład: co z tego, że czas programowania skrócił się z kilku miesięcy do kilku dni, skoro potem i tak czekamy kolejne miesiące na testy, akceptacje i wdrożenie na produkcję.

Eksperci, prelegenci i liderzy zaczynają więc mówić, że AI trzeba umieć wykorzystać nie tylko w kodowaniu, lecz także w pozostałych etapach: przy analizie i specyfikacji wymagań, w testowaniu oraz w automatyzacji wdrożeń aplikacji na kolejnych środowiskach.

Po co, skoro wszystko się da?

Ostatnia sprawa: jaki jest pomysł na kolejną konferencję?

Cały czas rozmawiamy o tym także między sobą, z Andrzejem (prof. Andrzejem Sobczakiem – red.): na ile jesteśmy gotowi zorganizować pracę tak, żeby to sztuczna inteligencja była w centrum, a człowiek tylko coś dopowiadał, gdy agent o coś dopyta albo się pomyli. Chodzi o odwrócenie ról.

Do tej pory AI działała jako asystent pracownika. Kierunek zmian jest taki, że staje się autonomicznym agentem, który w pełni realizuje zadania, a człowieka prosi o pomoc dopiero wtedy, gdy wykracza poza swoje kompetencje, dochodzi do ściany albo potrzebuje rozstrzygnięcia konfliktu – na przykład gdy dwa wymagania wzajemnie się wykluczają.

Szczerze mówiąc, jeszcze nie widzę takiego modelu AI first w biznesie. Widzę go natomiast w programowaniu i wytwarzaniu oprogramowania.

Czyli kodu nikt nie będzie utrzymywał. Ciekawe, czy ta technologia z „golema” zmieni się w prawdziwego partnera, czy wręcz przeciwnie: golem po prostu urośnie.

A może to będzie większa szansa dla analityków, użytkowników, dla nas wszystkich, żebyśmy lepiej zastanowili się, czego potrzebujemy. Zbudowanie aplikacji, systemu czy narzędzia nie będzie już problemem: powstanie w ciągu kilku godzin lub dni.

Wyzwaniem będzie przemyślenie, czego tak naprawdę nam trzeba, i na tym powinniśmy skupić uwagę. Ile razy biznes słyszał, że czegoś nie da się zrobić? Teraz się da. Pytanie brzmi: po co?