To jest 258. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak radzić sobie z legacy code przy pomocy Gen AI.

Sponsorem tego odcinka jest Capgemini.

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/258. Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka Osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz lub poprzez podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka.

Odpalamy!

 

Cześć!

Mój dzisiejszy gość to software architekt w Capgemini. Wcześniej pracował w IT w bankach w Genui, Amsterdamie i Pradze. Zajmuje się tworzeniem Enterprise Risk Platforms dla banków inwestycyjnych oraz rozwiązań opartych na Generative AI. W wolnym czasie koduje open source na GitHubie. Moim i Waszym gościem jest Adam Witkowski.

Cześć, Adam, bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztof, mi też bardzo miło.

 

Cieszę się bardzo. Dzisiaj z Adamem będziemy rozmawiać o generatywnej sztucznej inteligencji i wsparciu w programowaniu, a w szczególności z pracą z legacy code, jaką to właśnie pomoc możemy z tego miejsca uzyskać. Będzie to swego rodzaju wprowadzenie do tematu.

A więcej oraz możliwość spotkania się z Adamem na żywo będzie już niedługo, bo 17 października 2024 roku we Wrocławiu w Hard Rock Cafe w ramach kolejnego już Tech Talka od Camp Gemini. Oczywiście wszystkie szczegóły znajdziecie w linku w notatce do tego odcinka.

Dobrze, Adam, to myślę, że chciałbym Cię zapytać, tak jak każdego mojego gościa na początku, czy słuchasz podcastów, jeśli tak, to być może masz jakieś ciekawe rekomendacje.

 

Tak, słucham tak zwanych, ja to nazywam mędrcami, czyli jeden mędrzec nazywa się Scott Aaronson, to jest facet, który pracuje w OpenAI i zajmuje się bezpieczeństwem AI, ale też stworzeniem systemu, który pozwoli nam odróżnić, czy jakiś tekst stworzyła maszyna, czy człowiek, czyli bardzo ciekawe tematy. Drugi mędrzec się nazywa Allen Holub i on zajmuje się bardziej agilem, architekturą, oprogramowaniem obiektowym i ma takie dosyć kontrowersyjne poglądy, bardzo odbiegające od mainstreamu i dlatego bardzo ciekawe. Tak że głównie tych dwóch panów słucham.

 

Super, dzięki za te rekomendacje. Na początku chciałbym Cię zapytać, z czym Ci się kojarzy tzw. kod zastany, czy ten legacy code. Generalnie budzi on raczej mieszane uczucia w kierunku negatywnych, ale jestem ciekawy, co Ty o tym myślisz.

 

Tak, generalnie mi się wydaje, przynajmniej z mojego doświadczenia, że wszystkie uczucia związane z legacy są negatywne, czyli programiści nie lubią i nie chcą i uciekają od legacy z kilku powodów.

Głównie dlatego, że legacy jest oparte o stare rozwiązania, czyli tam jest praktycznie zawsze stary stos technologiczny. To oznacza, że programista, który chce się zawsze uczyć najnowszych rzeczy, jest zmuszony do pracowania nad czymś, co ma 10-15 lat, nikt nie jest chętny.

Bardzo często te rozwiązania oparte na legacy są nieczytelne. Jeśli wierzyć ostatnim badaniom, które mówią, że programiści spędzają 10 razy więcej czasu na czytaniu niż na pisaniu, w sumie prawdopodobnie powinniśmy przerobić naszą definicję programisty, to już nie jest ktoś, kto pisze, tylko ktoś, kto dużo czyta, czasami może coś napisze, a jak pracuje nad legacy, to pewnie nie 10 razy, tylko 30 razy więcej czyta, niż pisze. I to nas prowadzi do kolejnego problemu, że taki kod legacy jest bardzo często nieczytelny. Czyli programiści przychodzą, patrzą: Boże, kto to napisał? Ja nie wiem, co to znaczy. Oczywiście te rzeczy są nieprzetestowane.

Czyli Problem numer dwa to jest taki, że robimy jakąś zmianę, wszystko wydaje się okej, potem pięć dni później coś wybucha, w jakimś miejscu to nam się wydawało kompletnie niepołączonym z tym miejscu, w którym ta zmiana była, prawda? Musimy wyrzucić naszego fixa, czyli mamy oryginalny problem, plus np. pięć dni złych danych. No i to jest klasyka, mógłbym mówić dalej, ale to jest klasyka problemów legacy, wszyscy je znają.

Te aplikacje legacy prawie nigdy nie trafiają do PowerPointów. O tym się nie za bardzo mówi. Ludzie nie za bardzo potrafią to ugryźć, ale płacą za to. Czyli płacą za to na kilka sposobów. Oczywiście te systemy kosztują miliardy dolarów w skali roku. Oczywiście podejrzewam, że tak połowa, jak najwięcej programistów musi nad nimi pracować, a ta liczba rośnie i nikt nie chce się tym chwalić oczywiście. Taka jest sytuacja mniej więcej z legacy w IT teraz.

Bardzo często te rozwiązania oparte na legacy są nieczytelne. Jeśli wierzyć ostatnim badaniom, które mówią, że programiści spędzają 10 razy więcej czasu na czytaniu niż na pisaniu, w sumie prawdopodobnie powinniśmy przerobić naszą definicję programisty, to już nie jest ktoś, kto pisze, tylko ktoś, kto dużo czyta, czasami może coś napisze, a jak pracuje nad legacy, to pewnie nie 10 razy, tylko 30 razy więcej czyta, niż pisze. I to nas prowadzi do kolejnego problemu, że taki kod legacy jest bardzo często nieczytelny. Czyli programiści przychodzą, patrzą: Boże, kto to napisał? Ja nie wiem, co to znaczy. Oczywiście te rzeczy są nieprzetestowane.

 

I każdy chciałby tworzyć tylko te systemy typu greenfield, czyli od początku sobie układać, dobierać klocki takie, jakie obecnie są najbardziej chodliwe, to wydaje się, że jest najlepsze rozwiązanie dla każdego, tymczasem tak jak powiedziałaś, tych systemów, które działają już latami, wymagają utrzymania, może jakiegoś rozszerzania, pewnie jest relatywnie dużo więcej. Myślę sobie, że podobnie jest właśnie z wykorzystaniem AI w programowaniu.

W takim powszechnym mniemaniu to pewnie wygląda w ten sposób, że wyobrażamy sobie, że po prostu AI będzie pisało za nas kod, no względnie powiedzmy, tłumaczyło pomiędzy dwoma różnymi językami programowania, będzie tworzyło nowe feature’y. Chciałbym Cię zapytać, czy w tym obszarze takich zadań utrzymaniowych związanych właśnie z legacy code również jesteśmy w stanie Gen AI jakoś sensownie wykorzystać?

 

Tak, jak najbardziej. Czyli ja bym wszędzie wrzucał maszynę tam, gdzie człowiek się męczy. Czyli np. klasycznie mamy jakiś projekt Javowy dla jakiegoś banku, który ma 500 klas i 5% z nich ma testy. I to jest klasyka, to jest bardzo częste. I teraz można by było tych junior developerów tam wrzucić i niech oni dwa lata piszą testy, ale to się praktycznie nigdy nie dzieje, nikt tak nie robi. Czyli te systemy pozostają nieotestowane, a mogą być biznesowo krytyczne.

Czyli to, co dla człowieka byłoby zbyt ciężkie, nudne, powtarzalne itd., to właśnie można dać maszynom, i my właśnie tworzymy tego typu agenty, które biorą te 300 czy 500 klas i dla każdej z nich prowadzą dialog z Gen AI, który ma na celu napisać ten test.

Oczywiście Pierwsza odpowiedź od Gen AI bardzo często zawiera jakiś błąd, w ogóle się może nie kompilować, może być kompletną halucynacją, ale każda rzecz, która jest nie tak z tym outputem od Gen AI, jest bardzo łatwa do zdefiniowania technicznie, czyli jeśli to się nie kompiluje, to jest compilation error, prawda? Jeśli test nie przechodzi, no to on failuje, przepraszam za angielski, w konkretnej jakiejś linijce, czyli można wziąć sobie ten powód tego problemu i wrzucić go z powrotem do Gen AI i powiedzieć: ty mi dałeś takie coś, a tutaj to nie działa, bo mam ten error.

Jeśli pomyślimy o tym, co ja teraz mówię, to jest opis algorytmu, który wykonuje ten agent. Po prostu ten dialog prowadzi. Jeśli programista by się poddał po trzech, czterech razach, bo ile można się męczyć, to taki agent, on się nie męczy. Można mu 56 razy kazać gadać z Gen AI, On to zrobi, prawda?

Można użyć przeróżnych technik. Teraz bardzo modne są techniki prompt engineeringu. Czyli można używać Persony, Pattern, Chain of Thought itd., ale można też kazać coś Gen AI zrobić, a potem się nad tym zastanowić. Czyli dałeś mi to, a teraz jakbyś to usprawnił. I najlepsze jest to, że Gen AI wychodzi z usprawnieniami dla rzeczy, które sam stworzył, które naprawdę mają sens.

Oczywiście pytanie powstaje, dlaczego on nam nie dał tego od razu. Ale odpowiedź jest taka, że my go o to nie poprosiliśmy.

Można użyć przeróżnych technik. Teraz bardzo modne są techniki prompt engineeringu. Czyli można używać Persony, Pattern, Chain of Thought itd., ale można też kazać coś Gen AI zrobić, a potem się nad tym zastanowić. Czyli dałeś mi to, a teraz jakbyś to usprawnił. I najlepsze jest to, że Gen AI wychodzi z usprawnieniami dla rzeczy, które sam stworzył, które naprawdę mają sens.

Oczywiście pytanie powstaje, dlaczego on nam nie dał tego od razu. Ale odpowiedź jest taka, że my go o to nie poprosiliśmy.

 

Rozumiem, czyli ten przykład, który podałeś tutaj z testami jednostkowymi, myślę, że jest fajnym zaprezentowaniem tego, do czego można wykorzystać w tym obszarze właśnie legacy kodu Gen AI. Czy jeszcze jakieś inne obszary zastosowania byś widział?

 

Tak, to co my już robimy, to jeszcze są dwa obszary. Oczywiście patrzymy też na inne, czyli obszar drugi to jest refaktoryzacja, czyli walka z tym drugim problemem, czyli nieczytelnym kodem.

Te systemy bardzo często są bardzo skomplikowane. One są nieczytelne. Kod ma wszystkie te tzw. code smells, czyli po 30 parametrów, metody długie na trzy ekrany, wszystkie toole do statycznej analizy kodu się na tym gubią, w ogóle mówią, że one nie będą tego analizować. Jakiekolwiek nowe feature’y Java typu just-in-time compilation też się na tym gubią i nie są w stanie zoptymalizować tego kodu.

Czyli gdybyśmy ten kod jakoś usprawnili, to nie dość, że byłby bardziej czytelny dla człowieka, to jeszcze byłby szybszy, bo taki just-in-time compiler by sobie z nim mógł poradzić, bo działa dobrze na małych metodach, działa źle na dużych, skomplikowanych metodach, albo w ogóle się nie włącza.

Czyli my takie rzeczy staramy się robić, ale my nie mówimy Gen AI po prostu popraw to, bo to jest zbyt ogólne. Czyli my mówimy: sonar, sprawdź, co jest nie tak. Sonar znajduje te wszystkie code smells, czy np. duplikacja kodu, za dużo parametrów itd., bierzemy output Sonara i mówimy Gen AI, że Sonar powiedział, że ten kod jest zły, bo ta metoda jest za długa. I w tym przypadku Gen AI potrafi sobie bardzo elegancko poradzić, np. rozbić metodę na kilka małych metod.

Tego typu refactoring jest bardzo fajny, bo on nie wymaga zmiany testów. Czyli tylko tą jedną lokalną zmianę robimy, a już jest trochę lepiej. I nasze agenty mają taką zasadę, że poruszają się tylko w dobrym kierunku lub się nie ruszają. Czyli jeśli tzw. cyclomatic complexity, czyli miara skomplikowania tego kodu jest 10, a agent nam może dać coś jak 7, czyli lepiej, to okej, to proponujemy takie rozwiązanie. Natomiast jeśli on coś wygeneruje, co jest też dziesiątką lub gorzej, to my tego nie proponujemy. Czyli odrzucamy wszystkie gorsze rzeczy lub równe, natomiast sugerujemy tylko te lepsze.

I oczywiście pytanie, co to znaczy, sugerujemy, bo zawsze najbardziej wrażliwa i krytyczna jest ta granica między AI i człowiekiem. W przypadku naszych agentów to jest po prostu pull request, czyli nasz agent nie przychodzi do tych milionów linii kodu i nie zmienia ich tak, że one już są nie do poznania i wtedy programiści załamują ręce, tylko on tworzy pull requesty.

Czyli człowiek musi popatrzeć na ten pull request, nie spodziewam się, żeby ktoś czytał go w 100%, ale chociażby musiałby rzucić okiem i go odrzuca lub akceptuje. Czyli człowiek jest konieczny, żeby był jakikolwiek wynik działania tych agentów.

 

O to właśnie miałem pytać, bo te rozwiązania, o których tutaj mówisz, brzmią bardzo obiecująco. Z tego, co rozumiem jako core całego tego rozwiązania, mamy wielki model językowy, który sugeruje, czy też, można tak w cudzysłowie powiedzieć, pisze kod za nas. W związku z tym pojawia się taka swego rodzaju wątpliwość, że te halucynacje, które są jednak taką immanentną cechą tych modeli językowych, mogą nam się wślizgnąć na przysłowiową produkcję.

Czyli czy można, jednym słowem mówiąc, ufać tego typu rozwiązaniom, czy można je ślepo wpuszczać na systemy produkcyjne, czy też jednak ta kontrola ludzka tutaj musi być, można powiedzieć, zawarta, żeby właśnie nie zrobić sobie większej krzywdy niż pożytku?

 

Tak, tzn. to jest największe ryzyko, czyli przy dużej skali jest praktycznie pewne, że jakieś halucynacje czy głupoty, za przeproszeniem, będą wygenerowane przez Gen AI. Tylko jeśli chodzi o generowanie kodu, my jesteśmy w bardzo dobrej sytuacji, ponieważ kod, nie taki jak np. wiersze, czy poematy, czy eseje, można poddać bardzo wielu weryfikacjom.

Czyli oczywiście kod się musi kompilować, tak? Jeśli to jest test, to musi przejść. Jeśli to jest unit test, to musi oczywiście wykonać się w krótkim czasie, np. akceptujemy tylko poniżej 100 milisekund. Teraz, jeśli to jest kod, to musi mieć dobre wyniki Sonara, Checkstyle’a i tego typu tooli.

Dla testów odpalamy też zawsze, ja mówię, oczywiście to wszystko robi agent, człowiek tego nie dotyka, dla jakości mutation testing, a dla ilościowych sprawdzeń coverage, czyli pokrycie testowe powinno wzrosnąć przy dodaniu tego testu, a mutation testing, który sprawdza, czy asercje są dobrze rozłożone, też powinien nam dawać lepsze wyniki niż przed tym testem.

 

Rozumiem, czyli tym finalnym takim checkiem, finalnym sprawdzeniem jest faktycznie swego rodzaju code review wygenerowanego pull requestu, robione przez człowieka, bo to właśnie tutaj zaznaczyłeś, i to jest taka finalna bramka, która decyduje o tym, czy to wpuszczamy do naszego głównego brancha, czy też nie.

Wiesz, oprócz tego, czy to będzie działało, czy nie, to może się też pojawić taka wątpliwość, czy te rozwiązania są bezpieczne. Myślę tutaj o pewnych takich krytycznych, centralnych obszarach projektu, których jednak modyfikacja może mieć poważne implikacje dla biznesu. Chociażby tutaj przywołałeś systemy bankowe, no to oczywiście ten core jednak jest wrażliwy na różnego typu zmiany, jak również myślę tutaj o wszelkiego typu problemach z security, które mogą być efektem właśnie zmiany kodu w jakiś sposób wygenerowanego. Czy tego typu rozwiązaniom, o których mówisz, można ufać?

 

Tak, tzn. ja pracuję z klientami z branży investment banking i tam poziom obawy o security i bezpieczeństwo jest najwyższy możliwy. I teraz, w jaki sposób można w ogóle rozmawiać na ten temat, to z mojego doświadczenia jest tylko jeden, czyli instancje sztucznej inteligencji – trzeba mieć swoją własną.

Czyli jeśli mamy rozwiązanie, prawda, jak ten agent, którego pisałem, to on działa np. na jednym komputerze, na infrastrukturze klienta, a bierzemy na drugi komputer np. Llamę od Mety, który jest darmowym modelem, bardzo dobrym, który jak już będzie raz ściągnięty, więcej już ten komputer nie wymaga podłączenia do internetu i teraz A się łączy do B, B się łączy do A, wszystko inne jest obfirewallowane, tak że To nie jest tak, że my obiecujemy, że my się nie podłączymy do internetu, to jest po prostu fizycznie niemożliwe, bo nie ma kabla, mówiąc w ten sposób, i wtedy klient akceptuje to rozwiązanie i może kontynuować rozmowy.

Jeśli my byśmy powiedzieli: drugi kliencie, wyślemy Ci cały Twój kod w internet, bo my używamy Copilota albo używamy chata GPT-4, to klient by skończył rozmowę z nami i byśmy nawet nie mogli zainstalować próbnej wersji.

 

Czyli takie zapewnienie wręcz fizyczne, właściwie to chyba tak można byłoby nazwać, związane z tym, że te modele językowe są w jakiś sposób lokalne. Te dane nie wyciekają, nie wychodzą na zewnątrz po to, żeby ten model językowy mógł na nich operować i np. sugerować jakiś kod, tylko to się odbywa w ramach firmy, nazwijmy to w ten sposób.

W związku z tym zastanawiam się, czy to też nie jest pewne obciążenie dla takiej organizacji, bo żeby uruchomić taki model językowy, to raz, że trzeba jakąś może tam wiedzę posiadać, ale też pewnie trzeba dysponować mocą obliczeniową.

Tutaj do takiej powszechnej świadomości, myślę, dotarło już to, ile np. tych kart graficznych wielkie firmy musiały zakupić, żeby trenować swoje modele, te chociażby, o których tutaj powiedziałeś, i może się rodzić swego rodzaju obawa, że skoro ja jako firma, jako instytucja będę musiał ten model językowy u siebie uruchomić, to będę musiał też zainwestować w dużą moc obliczeniową u mnie. Czy tak faktycznie jest, czy to jest niezbędny krok i konsekwencja zdecydowania się na tego typu rozwiązanie?

 

Ja sądzę, że trzeba oddzielić dwie rzeczy. Jest uczenie modeli językowych, które wymaga, tak jak mówiłeś, milionów dolarów, farm GPU i trwa bardzo długo, może nie wyjść oczywiście i to jest bardzo drogie, kosztowne, wymaga data scientists, machine learningu itd.

I jest druga rzecz, czyli używanie gotowych modeli, czyli np. można teraz w trzy minuty ściągnąć sobie Ollamę z internetu za darmo, instaluje się ją dokładnie jak Skype’a, potem ściągnąć sobie jeden model, one mają różne wielkości, ale są modele dwugigowe na przykład, które działają nawet bez GPU, czyli można na najzwyklejszym laptopie, który nam służy do Outlooka i przeglądarki, sobie odpalić taki mały model i już mieć sztuczną inteligencję lokalną.

Oczywiście im większy model, tym większe możliwości, tylko tu jest sytuacja bardzo dynamiczna. Na początku tego roku, np. żeby ten mój agent dobrze działał, to używałem Llamy 2-70b i ona naprawdę wymagała jakiegoś tam troszkę lepszego hardware’u. Natomiast teraz, już parę miesięcy później, wyszła Llama 3, która ma 8 bilionów parametrów i jest to, pomimo że ma rozmiar prawie dziesięciokrotnie mniejszy, jest wielokrotnie bardziej wydajna.

Czyli teraz na moim laptopie jestem w stanie uruchamiać zarówno agenta, jak i sztuczną inteligencję, czyli koszt sprzętu jest naprawdę mały. Ostatnio właśnie podliczałem sobie te koszty, które używam na platformie Microsoft Azure i na miesiąc taki bardzo dobry serwer, który może nawet uciągnąć 4 czy 5 takich instancji sztucznej inteligencji naraz, kosztuje 300 euro na miesiąc.

Tak że te koszty teraz naprawdę są niewysokie, każdy klient sobie może na nie pozwolić, one są dużo mniejsze niż zatrudnienie na przykład jednego więcej programisty w projekcie, prawda?

Ja sądzę, że trzeba oddzielić dwie rzeczy. Jest uczenie modeli językowych, które wymaga, tak jak mówiłeś, milionów dolarów, farm GPU i trwa bardzo długo, może nie wyjść oczywiście i to jest bardzo drogie, kosztowne, wymaga data scientists, machine learningu itd.

I jest druga rzecz, czyli używanie gotowych modeli, czyli np. można teraz w trzy minuty ściągnąć sobie Ollamę z internetu za darmo, instaluje się ją dokładnie jak Skype’a, potem ściągnąć sobie jeden model, one mają różne wielkości, ale są modele dwugigowe na przykład, które działają nawet bez GPU, czyli można na najzwyklejszym laptopie, który nam służy do Outlooka i przeglądarki, sobie odpalić taki mały model i już mieć sztuczną inteligencję lokalną.

 

Rozumiem, czyli te koszty są akceptowalne bądź też pomijalne, myślę tutaj o mocy obliczeniowej, ale jeszcze taki inny rodzaj kosztu, który może się pojawić, jest związany ze znajomością tej technologii, prawda?

Mówimy tutaj o uruchomieniu modelu językowego. Mówimy tutaj o w jaki sposób wpleceniu w ten nasz proces wytwórczy, oprogramowania chociażby tego systemu agentowego, który opisujesz, to wszystko mimo wszystko wymaga jakiejś wiedzy, jakiegoś zrozumienia i rozeznania, być może dotknięcia pewnych rozwiązań DevOpsowych, MLOpsowych itd.

Czy według Ciebie ten próg wejścia w tego typu rozwiązania jest wysoki, niski? Jak to oceniasz?

 

Ja bym powiedział, że jest średni, ale sądzę, że ludziom wydaje się wysoki, ponieważ jak ludzie np. słuchają jakiejś prezentacji, to te prezentacje często skupiają się na tym, jak coś jest zrobione, prawda?

I one często mówią o jakichś wektorowych bazach danych, o embeddingsach, o tokenizacji itd., i ludzie myślą, że to będzie trzeba umieć np. napisać czy zrobić, czy coś w tym stylu, a te klocki Lego jeśli mogę używać takiego sformułowania, już są gotowe. Czyli jest mnóstwo frameworków typu LangChain, np. dlaJavowców jest LangChain4j itd., które mają gotowe klocki Lego, gotowe komponenty, które zazwyczaj bardziej trzeba po prostu pokleić jakimś klejem i połączyć ze sobą. I dlatego ta nazwa chain. Wyjście jednego klocka to wejście drugiego klocka.

Można sobie na YouTubie znaleźć filmiki, gdzie bardzo trudno wyglądające setupy typu Retrieval Augmented Generation ludzie są w stanie ustawić np. na swoim prywatnym komputerze w 10 minut, gdzie jeśli się słucha, co tam w środku jest użyte, to wydaje się strasznie trudnym statystyczno-matematycznym mechanizmem.

 

Tutaj faktycznie zachęcasz do tego typu rozwiązań, ja jednak podrążę jeszcze ten temat, ponieważ Ty dysponujesz już dużym doświadczeniem, robiłeś to już nieraz. Zastanawiam się, żeby powiedzmy uchronić jakoś albo wskazać pewne potencjalne pułapki dla tych, którzy będą chcieli się z tego typu rozwiązaniami zmierzyć, to co byś mógł tutaj wskazać, jakie potencjalne problemy, jakie potencjalne błędy możemy na swojej drodze właśnie tutaj spotkać?

 

Wydaje mi się, że największym błędem to jest przestraszyć się, czyli raczej to byłoby psychologiczne błędy, tak mi się wydaje. Przestraszyć się, że coś jest trudne, że coś wymaga jakiegoś zaplecza matematycznego, kiedy użycie tych rzeczy praktycznie nie wymaga żadnej wiedzy matematycznej, statystycznej czy sztucznej inteligencji. Każdy może pogadać z chatem GPT, nie wiedząc w ogóle co jest w środku, tak jak każdy używa systemu operacyjnego Windows, nie wiedząc co to jest kernel, to znaczy nie musimy wiedzieć, co to jest, żeby go poprawnie użyć. I to jest podobne.

Ja bym zachęcał wszystkich, żeby sobie spróbowali, zobaczyli, jak to jest łatwo. Zazwyczaj najłatwiej zacząć po prostu od YouTube’a, który w filmikach darmowych 5-10 minutowych tłumaczy, tu można sobie ściągnąć, ja bardzo dobrze znam i polecam platformę OpenLlama. Ściągnąć, zainstalować, odpalić, uruchomić i już czujemy się dużo bezpieczniej, pewniej i możemy przejść do kolejnych kroków, czyli tylko mając ten kontakt bezpośredni z tą technologią, zdobywamy pewność, że możemy więcej zrobić.

 

Czyli wówczas może nam się wydać, że nie taki diabeł straszny, prawda? Czy oprócz takich potencjalnych problemów właśnie natury psychologicznej, że się po prostu tego obawiamy, bo wydaje nam się to zbyt trudne na nasze możliwości, czy jeszcze z jakiegoś typu innymi problemami mamy szansę się zderzyć, technologicznymi, być może wydajnościowymi, coś, co ci jeszcze przychodzi do głowy?

 

Jeśli ktoś nie ma GPU na komputerze, najlepiej mieć właśnie komputer gamingowy, bo te komputery teraz dostały drugie życie i już niekoniecznie muszą być tylko maszynami do grania. Są bardzo dobrymi maszynami do uruchomienia sztucznej inteligencji na nich, ale jeśli ktoś ma laptopa właśnie typowo nie do gier i by chciał sobie uruchomić jakieś sztuczne inteligencje fajniejsze na nim, to mogą się nie załadować, czyli po prostu może błąd wystąpić w trakcie ładowania, bo jest ta sztuczna inteligencja akurat za duża, albo jak już zadziałają, to mogą działać bardzo powoli, co zniechęca nowoczesnych użytkowników, którzy są z natury bardzo niecierpliwi.

Tak że gdyby ktoś chciał to uruchamiać, ja bym jednak polecał mieć jakikolwiek GPU, nawet nieduży na maszynie, na której to się uruchamia. Tu możemy się naprawdę zniechęcić, jak źle trafimy. Natomiast to nie są też wymagania, że trzeba mieć jakiś GPU za parę tysięcy dolarów. To naprawdę średnia półka wystarcza.

 

Czy każdy projekt legacy nadaje się, żeby właśnie w jakiś sposób być wspomagany przez ten system agentowy, o którym mówisz? Czy też może są jakieś domeny, może jakieś technologie, które raczej byś odradzał?

 

Out of the box niestety nie każdy działa. Z prostego powodu: sztuczna inteligencja, która jest użyta jako mózg agenta, nie zna np. wewnętrznych frameworków klienta. Czyli bardzo często klient ma jakieś swoje frameworki, które użył dla wszystkich swoich platform tradingowych, ale one w internecie nie istnieją. Czyli taka sztuczna inteligencja nie mogła się o nich nauczyć, nie miała możliwości, bo to nie było częścią próbki uczącej.

W takich przypadkach kod wygenerowany do otestowania takiego kodu albo refaktoryzacji może w ogóle się nie kompilować. I w tym trudnym przypadku, kiedy to nie działa, że tak powiem, out of the box, wtedy mamy kilka opcji.

Czyli można, tak jak wcześniej wspomniałem, użyć Retrieval Augmented Generation, czyli to jest używanie zewnętrznej bazy wiedzy, aby wzbogacić swoje zapytanie do sztucznej inteligencji o więcej informacji i w ten sposób to można zrobić, wtedy sztuczna inteligencja nie jest douczona, tylko więcej dostaje na wejściu.

Natomiast drugą opcją, taką już bardziej zaawansowaną, trudną, która już troszkę więcej wymaga od ludzi, którzy by w nią szli, to jest tzw. fine-tuning. Fine-tuning to jest po prostu wysyłanie sztucznej inteligencji na trening. Czyli mamy, powiedzmy, programistę, który nie umie naszego wewnętrznego frameworku, to go wysyłamy na tygodniowy trening, żeby się nauczył. Jak wróci w poniedziałek, to już będzie przynajmniej podstawę znał i to jest odpowiednik fine-tuningu sztucznej inteligencji.

I to też nie wymaga zazwyczaj jakiegoś człowieka, który super się zna na sztucznej inteligencji. Są narzędzia, natomiast tutaj kłopot jest zazwyczaj ze znalezieniem próbki uczącej. Bo trzeba mieć tysiące przykładów, żeby nauczyć sztuczną inteligencję, czyli taki framework wewnętrzny od klienta musiałby mieć gotowych np. tysiące testów, które byśmy przekazali sztucznej inteligencji jako forma uczenia się, tak aby sztuczna inteligencja mogła napisać kolejne tysiące testów.

 

Coraz więcej, mam wrażenie, mówi się ostatnio o prawach autorskich właśnie w kontekście efektów działania sztucznej inteligencji. Jestem ciekawy, jak to wygląda w przypadku systemu agentowego, o którym tutaj rozmawiamy, w takim rozumieniu, że kto jest właścicielem tych praw do efektów działania systemu agentowego. Czy masz jakieś rozeznanie w tym temacie?

 

Tak, ja mam dedykowaną osobę w zespole, która zajmuje się tylko i wyłącznie compliance, intellectual property itd. i na tę chwilę sytuacja na szczęście jest bardzo prosta, gdyby nie była prosta, to by nam bardzo to skomplikowało sprawę, a mianowicie jak w infrastrukturze klienta instalujemy naszego agenta, uruchamiamy go, on działa ze sztuczną inteligencją, ta sztuczna inteligencja generuje coś, co my akceptujemy, czyli przechodzi przez nas proces weryfikacji, ten, o którym mówiłem, że to musicie kompilować, uruchamiać, mutation testing, pokrycie kodu itd., i to idzie do pull requestu, to ten pull request po zaakceptowaniu przez klienta staje się własnością klienta.

 

Rozumiem, no to faktycznie sytuacja jest prostsza, niż mi się wydawało, ale to tak jak powiedziałeś, to w sumie dobrze.

Wspomniałeś kilka razy o układaniu albo budowaniu rozwiązań z klocków. Jestem ciekaw, czy właśnie są już tego typu gotowe elementy, gotowe klocki i serwisy w różnych rozwiązaniach chmurowych, frameworki, coś, co moglibyśmy tak de facto wziąć i właśnie z tych klocków budować tego typu rozwiązania?

 

Tak, jak najbardziej. Czyli generalnie oczywista oczywistość, gotowe modele. Są darmowe, gotowe, otwarte modele typu Llama 3.1, jest Gemma 2 od Google’a, bardzo dobre, niewymagające wielkiego hardware’u, gotowe klocki, które po prostu bierzemy i uruchamiamy.

Druga rzecz to są frameworki, czyli najbardziej znany jest LangChain. Dla mnie, jako dla człowieka, który pisze wszystko w Javie, oczywiście langchain4j. I to też jest framework, który nam bardzo łatwo umożliwia albo zrobienie właśnie tego RAG-a, czyli Retrieval Augmented Generation, ma wsparcie dla 20 baz wektorowych albo w bardzo prosty sposób można dostać się z poziomu kodu Javy do AI pogadać, wysłać to zapytanie, dostać odpowiedź, ustawić temperaturę, wszystkie parametry itd. Nie trzeba się męczyć z niskopoziomowymi rzeczami typu jakiś tam HTTPS klient. To wszystko już jest ładnie opakowane w interfejsy, w klasy, czytelne, proste, wszystkie niepotrzebne technikalia są ukryte.

Oczywiście jak ktoś chce pogrzebać głębiej, to ma taką możliwość, ale dobre wartości domyślne to ukrywają. Także to polecam, oczywiście na tę chwilę. Wiadomo, za pół roku, za rok to będzie kompletnie co innego w tym świecie.

 

No tak, ciekawe. Właśnie, ten świat pod tym względem się bardzo szybko zmienia. Trzeba spodziewać się jeszcze sprytniejszych, jeszcze dokładniejszych, jeszcze atrakcyjniejszych rozwiązań. Nieśmiertelne pytanie, które chciałbym Ci, Adam, zadać na koniec, to czy to nie jest swego rodzaju zagrożenie dla programistów, tak? Czyli czy to Gen AI nie zabierze nam pracy?

 

Ja mam taką może kontrowersyjną odpowiedź, ale, tak czy siak, to powiem, czyli tak, ja uważam, że chat GPT nikomu nie zabierze pracy z prostego powodu, że chat GPT daje nam tekst na ekranie, a pracodawca, żaden, którego znam, nie chce zatrudnić człowieka, który mu da tekst na ekranie i koniec, prawda? Pracodawca zatrudnia pracownika, żeby pracownik wykonał jakieś akcje, najlepiej, żeby brał w ogóle całą odpowiedzialność na siebie.

Czyli w IT pracodawca zatrudnia pracownika, żeby mu pisał testy, albo żeby napisał nowe feature’y, albo żeby wrzucił nową wersję programu na produkcję. Chat GPT nic z tych rzeczy nie robi, on może dać jakąś część wejścia do tych rzeczy, natomiast sam chat GPT nie wykonuje akcji, czyli jest mózgiem, powiedzmy, w słoiku, przepraszam za porównanie, natomiast nie ma rąk.

Agenci to jest coś, co ma mózg i ma ręce i nogi, czyli agenci tacy jak nasz Code AI, który właśnie robi te testy unitowe i refactoring, potrafią wykonać te akcje, czyli idą do Gita, klonują repozytorium, przechodzą po wszystkich akcjach, prowadzą dialog z Gen AI, wybierają tylko te odpowiedzi, które spełniają ich wymagania, potem idą do GitHub’a, czy do jakiejkolwiek innej platformy typu GitLab, Bitbucket, cokolwiek tam klient ma, i tworzą, to jest kolejna akcja, pull request, który zawiera te zmiany. Chat GPT tego nie zrobi.

Czyli moja odpowiedź jest taka, że chat GPT nie zabierze na pewno nam pracy, natomiast dobry, mądry agent, wersja kolejna, przyszłościowa jakaś, już jest bliżej tego.

 

Ciekawe, jestem właśnie bardzo ciekawy, jak to się wszystko będzie zmieniało. Na pewno warto ten obszar IT obserwować, na pewno warto zerkać, jak inni wykorzystują tego typu rozwiązania. I to, o czym dzisiaj, Adam, mówiłeś, myślę, jest bardzo ciekawym, interesującym wprowadzeniem, które na pewno będzie miało swoje rozszerzenie na Tech Talku, o którym na początku mówiliśmy, 17 października we Wrocławiu. Tak że na to zapraszamy z Adamem tutaj serdecznie.

A ja, Adam, bardzo Ci dziękuję za poświęcony czas i za naszą rozmowę.

 

Również dziękuję i do zobaczenia na Tech Talku.

 

Dzięki wielkie. Na koniec powiedz jeszcze, proszę, gdzie Cię możemy znaleźć w sieci, bo gdzie słuchacze mogą się z Tobą skontaktować.

 

Ja, żeby zaoszczędzić kupę czasu, wyszedłem z Facebooka parę lat temu i to była dobra decyzja, natomiast jestem oczywiście na LinkedInie i na GitHubie, czyli tam bardzo łatwo mnie znaleźć, linki będą gdzieś tam pewnie udostępnione, tak że zapraszam do rozmowy, bardzo chętnie porozmawiam.

 

Oczywiście. Namiary na Adama, jak również link do wspomnianego wydarzenia znajdą się w notatce do odcinka. Ja za dzisiaj bardzo dziękuję. Do usłyszenia, Adam. Cześć!

 

Do widzenia.

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach.

Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak radzić sobie z legacy code przy pomocy Gen AI.

Do usłyszenia w następnym odcinku. Cześć!