W tym odcinku opowiadam o tym jakie są zalety i zagrożenia stosowania nowoczesnych narzędzi AI w kontekście rozwoju systemów legacy.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek 64. Stosowanie AI, a praca z systemami legacy - przemyślenia i wnioski. Znowu przytrafiła się taka przerwa, no nie da się ukryć bardzo intensywny teraz czas, można powiedzieć zanim przejdziemy do meritum informatycznego, no to każdy chyba widzi jak zniżkują kursy walut w odniesieniu do złotówki, co sprawia, że można być obłożonym robotą, ciekawą robotą, fajnymi projektami, ale no niestety trzeba włożyć znacznie więcej pracy, żeby pewne wskaźniki kondycji firmy były na odpowiednim poziomie. No i tak też się dzieje, ale z drugiej strony jakby tu mam na myśli to, że osobiście zaangażowałem się w pewne firmowe zawodowe działania, natomiast z drugiej strony, właśnie dzięki temu, z perspektywy podcastu, chociaż może mam mniej na niego czasu, to mam też trochę ciekawych przemyśleń, którymi między innymi dzisiaj właśnie się podzielę, bo ostatnio opowiadałem o vibe-codingu w takim bardziej ogólnym tego pojęcia znaczeniu.

Dla przypomnienia oczywiście zachęcam do poprzedniego odcinka, natomiast dla przypomnienia vibe-coding, czyli generowanie w zasadzie całych aplikacji bądź ich części za pomocą narzędzi, edytorów opartych o duże modele językowe. Natomiast poprzednio miały miejsce takie bardziej ogólne rozważania, natomiast dzisiaj chciałem się skupić na pewnych konkretach w kontekście zwłaszcza systemów legacy, bo obecnie jako firma mocno w tym działamy. W Makimo sam również jestem uczestnikiem, z różnym natężeniem, ale w kilku projektach. I praca z systemami legacy ma swoją specyfikę i ona zwłaszcza wychodzi właśnie w przypadku AI i mam nadzieję, że to, czym będę chciał się dzisiaj podzielić okaże się interesujące.

No dobrze, ale może najpierw powiedzmy sobie, co to jest to oprogramowanie legacy w ramach przypomnienia. Chodzi o oprogramowanie, które... Mówiąc krótko istnieje ale nie jest tworzona od zera. Czasami mówi się o oprogramowaniu przestarzałym, czasami o odziedziczonym, no to tak tłumacząc bezpośrednio, natomiast brakuje takiego tłumaczenia bardzo precyzyjnego, dobrego może ktoś jakiś zna to proszę o sygnał w komentarzach.

Natomiast generalnie chodzi o sytuację, w której aby rozwiązać dany problem, nie tworzymy oprogramowania od zera, tylko zajmujemy się już istniejącymi systemami, już istniejącą infrastrukturą, no i oczywiście im jest ona starsza, bardziej skomplikowana, tym ten efekt legacy staje się bardziej istotny.

Jednym z bardziej oczywistych zastosowań AI jest oczywiście wszelkiego rodzaju wykrywanie pewnych powtarzających się wzorców, takie automatyzacje, które nazwałbym rozszerzonym znajdź i zamień, czyli sytuacje w których chcemy zastąpić fragmenty kodu, ale nie wprost jeden. Jakiś tekst, jedną nazwę inną, tylko takie sytuacje w których mamy pewne bardziej zaawansowane wzorce tekstowe.

No to są takie sytuacje w których faktycznie AI się dobrze sprawdza, a jednocześnie można powiedzieć, że takie ręczne robótki wykonywane własnoręcznie, ludzkimi rękoma, są narażone na duże ryzyko błędu. W związku z tym to jest myślę takie bardzo fajne zastosowanie. Natomiast jednocześnie trzeba mieć też na względzie, co jest wydaje mi się taką kluczową kwestią, że aby uzyskać dobry efekt generowania kodu, może niekoniecznie tylko do zmian, ale w ogóle generowania kodu na bazie rozwiązania legacy, to wypadałoby podzielić się z nim, z modelem żeby on znał kontekst. No a to oczywiście jest pewne ryzyko, nawet jeżeli pracujemy w jakimś tam prywatnym kontekście, nie dzielimy się tym kodem. Korzystamy z takich ustawień modelu które pozwalają na niedzielenie się przesłanymi promptami czy przesłanym kontekstem, to jednak zawsze jest to pewne ryzyko. Można oczywiście w takiej sytuacji zastosować modele działające lokalnie ale to oczywiście wymaga pewnego sprzętu, pewnego też przygotowania, na ogół zajmuje też więcej czasu.

No i nagle może się okazać że wcale stosowanie AI tak na siłę nie ma za dużo sensu. Także tutaj kwestie... Z jednej strony takiej automatyzacji bardzo prostych zadań to jest super, z drugiej strony coś, o czym chciałbym przestrzec w ogóle w kwestii pracy z narzędziami AI w kontekście systemów legacy, czyli właśnie to, czy jesteśmy gotowi podzielić się kontekstem, podzielić się na przykład całym kodem źródłowym. Całym to, nawet jak to wypowiadałem, to wydało mi się to bardzo jednak jeszcze abstrakcyjne, może niezbyt mądre, ale na przykład fragmentem takiego oprogramowania. Jeżeli na przykład podzielimy się jednym plikiem który chcemy usprawnić. To może być to sensowne, jeżeli akurat tam nie jest jakaś specyficzna logika biznesowa, która stanowi kluczową wartość intelektualną naszej bądź klienta organizacji.

No dobrze, idąc dalej, jeżeli już korzystamy z tego AI, no to Możemy liczyć na to, że przy podejmowaniu decyzji brane będą pod uwagę, zwłaszcza w tym wariancie chmurowym, całe lata doświadczenia dekady wręcz w niektórych przypadkach doświadczenia. Nie jesteśmy ograniczeni tylko doświadczeniem bądź umiejętnością wyszukiwania informacji przez programistów ale faktycznie jest Potężny potencjał, śmiesznie to się zgrało natomiast taka jest prawda, mamy możliwości które z jednej strony może być trudno pod względem których może być trudno dorównać człowiekowi.

Z drugiej strony ryzykujemy to, że te dane mogą być w bardzo nietypowych formatach danych w nietypowej strukturze i nasz model językowy może zwyczajnie sobie z nimi nie poradzić. Model językowy, czy ogólnie agent, też mówiąc szerzej. Możemy mieć sytuację w której po prostu te podpowiedzi, te sugestie, które otrzymamy związane np. z rozwiązaniem jakichś problemów, czy dodaniem nowych funkcji w oprogramowaniu legacy będą po prostu złe, bo model źle rozpozna wiedzę która była zawarta gdzieś tam w jego czeluściach.

Kolejnym punktem jest no właśnie, to co myślę jest takim świętym gralem wszystkich menedżerów kierowników zarządców, czyli kwestia oszczędności. To jest temat, z którym mierzymy się już teraz z naszymi klientami, mierzymy się też sami z sobą jak to w tym wszystkim, jeśli chodzi o oszczędności, jak to z tym wszystkim jest? No bo tak, jak korzystamy chociażby z oprogramowania takiego jak Cursor połączonego z modelem LLM, albo na przykład korzystamy z Cloud Code, gdzie też już mamy nie tylko generowanie kodu, ale całego agenta który jest w stanie wykonywać różne zadania związane z tworzeniem projektu no to wydaje się, że to w zasadzie jest potężna automatyzacja z definicji. No bo przecież to nie człowiek siedzi i klepie w tą klawiaturę, nie testuje, nie traci czasu. Tylko mamy automat. No niby tak, tylko problem polega na tym, że po pierwsze temu automatowi ktoś musi dalej te polecenia wydawać i to naprawdę... Póki nie chcemy czegoś bardzo ogólnego i bardzo takiego powtarzalnego, na przykład wygenerujmy schemat aplikacji mobilnej z jakimiś podstawowymi elementami, a w systemach klasy legacy właśnie mamy do czynienia z sytuacją odwrotną, czyli bardzo duży kontekst, bardzo dużo istniejącego kodu komponentów, a czasami te polecenia te prośby są wręcz bardzo niewielkie.

No i teraz sformułowanie poleceń może zająć bardzo dużo czasu. Wykonanie tych poleceń to też nie jest kwestia ułamka sekundy. To są często polecenia wykonywane całymi minutami. Jest też koszt, oczywiście on stosunkowo mniejszy, ale jednak niepomijalny. Koszt działania takiego agenta w tle takiego modelu. I tutaj jak się to wszystko posumuje, a jeszcze jest oczywiście ryzyko że przecież taki agent w żadnym razie od razu nam prawidłowo skomplikowanych problemów nie rozwiąże. To znaczy, może się zdarzy, ale rozwiązywanie dość zaawansowanych problemów, tak z mojego doświadczenia, nie dzieje się z reguły natychmiast. Często jest to kwestia jeszcze doprecyzowania na przykład... Nie tyle przepisania promptu od zera, co jednak doprecyzowania, docyzelowania można powiedzieć, pewnych szczegółów.

Bo inaczej kończymy w sytuacji, w której na przykład model nam coś wygeneruje, ale i tak potem taki programista musi to udoskonalić. Co z drugiej strony może też jest jakimś wyjściem. Także o ile właśnie ten vibe-coding dużo zyskuje przy tworzeniu nowych rozwiązań, zwłaszcza wtedy, kiedy chcemy coś szybko sprototypować i ta jakość rozwiązania nie jest aż taka istotna, ale liczy się szybki efekt, tak przy pracy z systemami legacy jest to w pewnym sensie odwrócone, więc nic dziwnego, że to zastosowanie AI do legacy może być problematyczne.

No oczywiście jest też niezwykle istotna kwestia bezpieczeństwa, bo z jednej strony to w zasadzie tak naprawdę nie tylko AI, ale nawet bardziej złożone tradycyjne rozwiązania są w stanie bardzo dobrze radzić sobie z wykrywaniem pewnych podatności w kodzie. Oczywiście takie proste rzeczy, nawet jak śledzenie wersji komponentów z których korzystamy w systemie i wskazywanie że są jakieś zagrożenia komponentowe, tutaj taka automatyzacja postaci właśnie AI-owej jakiegoś modelu który agenta w zasadzie z modelem w tle, który regularnie analizuje, co dzieje się w oprogramowaniu to jest oczywiście świetna rzecz. Natomiast z drugiej strony, jeżeli mówimy już stricte o generowaniu kodu, to pamiętajmy że ten kod nawet jeżeli działa, może mieć w sobie podatności. To jest ogromne ryzyko bo o ile na przykład, zwłaszcza jeżeli tutaj mówimy o sytuacji w której do takiego korzystania z AI w kontekście legacy siada ktoś niezbyt doświadczony z strony programistycznej. No i okej trzeba coś zrobić, trzeba... Dodać jakąś funkcję, no to dodajemy, ona może nie działać na początku, ale wiemy przynajmniej że okej nie działa, to nie działa, trzeba dalej pracować, w końcu dochodzimy do momentu że działa. Mamy ten feedback, tą informację zwrotną i wiemy że musimy działać musimy pracować nad tym fragmentem systemu dopóki nie zostanie skończony, dopóki nie będzie działać. O tyle w przypadku bezpieczeństwa te luki często pojawiają się w bardzo subtelnych miejscach które trudno jest samemu sprawdzić, zwłaszcza jak nie ma się głębokiej wiedzy. No nie bez kozery pod kątem bezpieczeństwa często w dużych jakichś strategicznych projektach są zatrudniane osobne firmy które zajmują się na przykład pentestami, testami penetracyjnymi czyli weryfikacją tego, czy na pewno wszystko jest dobrze zabezpieczone.

Oczywiście na przykład są firmy, które po prostu testują oprogramowanie, ale jednak często kiedy zamawia się o oprogramowanie gdzieś tam w firmie takiej typu softwarehouse, no to testy takie funkcjonalne czy pod kątem wydajności, to jest coś co wchodzi w standardowy zakres usług, ale te testy bezpieczeństwa jako taka dodatkowa warstwa często są zlecane na zewnątrz, bo nie jest takie łatwe znalezienie luk we własnym software'ze.

No i tak na koniec... Niejako spinając te różne argumenty, te różne kwestie z mojego doświadczenia praca z systemami legacy to jest często bardzo dużo szukania, bardzo dużo analizy, poznanie bardzo szerokiego kontekstu, aby tak naprawdę na końcu wprowadzić bardzo nieduże zmiany w kodzie. Zwłaszcza jak na przykład jeśli chodzi o poprawienie jakichś błędów, czy jakąś taką drobną modyfikację logiki biznesowej.

To cieszę się w takich sytuacjach, że klienci nie płacą nam od linijki kodu, bo taka sumaryczna zmiana efekt pracy kilku godzin na przykład to potrafi być 5-10 linijek kodu i wydaje się, że no... Co to za robota? Ale często samo napisanie nawet tego kodu to jest dosłownie parę paręnaście minut. Natomiast znalezienie i upewnienie się, że ta zmiana będzie funkcjonowała tak, jak o to nas klient poprosił, czyli znalezienie kontekstu wypracowanie tego, co właściwie ma być zmodyfikowane, przetestowanie też potem, co w przypadku jakichś skomplikowanych integracji wcale nie jest takie oczywiste. To wszystko sprawia, że... De facto jakby ten uzysk który byśmy mieli z modelu językowego wcale nie jest taki duży. I tu oczywiście ja powiem tak, bardzo chętnie posłucham czy poczytam jakieś kontrprzykłady, bo jestem przekonany że w wielu przypadkach model językowy może zadziałać słusznie i może zrobić to szybciej niż człowiek.

Natomiast tu jakby wchodzi w grę jednak ten kontekst. Zarówno ten kontekst o którym mówiłem, czyli kontekst wprost kodu, znajomość po prostu struktury projektu, znajomość tego, jak jest zbudowany cały system. Żeby to oczywiście przekazać nie ma tutaj zbyt dużego formalnego problemu, ale może być problem natury czysto takiej, no powiedzmy prawnej, tak, czy chcemy się dzielić tym kodem z modelem.

Ale to już chodzi o kontekst biznesowy, który nie zawsze może w bardzo łatwy jasny sposób wynikać z kodu. To, że wiemy o co chodzi w projekcie, to, że wiemy na czym zależy klientowi. I nawet, co często się też okazuje, może być tak, że mimo że formalnie rzecz biorąc wprowadzenie tego, o co nas klient poprosił to byłoby na przykład kilka, kilkanaście linijek wygenerowanych przez model bez większego problemu to prawdziwe rozwiązanie problemu klienta wyjdzie daleko poza wygenerowanie takiej małej zmiany w kodzie i może się okazać, że na przykład jest to kwestia dorobienia zupełnie nowej funkcji, ale to już wynika z naszej interakcji takiej czysto ludzkiej a nie maszynowej.

No, na dzisiaj to już wszystko, mam nadzieję że w przyszłości, no ja te słowa nagrywałem na początku lipca, więc troszeczkę teraz powinno być więcej czasu, jak to zwykle u mnie w wakacje, no tak przede mną jeszcze dwa dni egzaminów dyplomowych, ale potem już do września spokój także mam nadzieję, że troszkę też częściej teraz będę miał okazję publikować odcinki.

No a na teraz to już wszystko. Dziękuję bardzo za uwagę. Kłaniam się nisko i do usłyszenia.