To jest 192. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o wsparciu AI w wytwarzaniu oprogramowania. Przypominam, że w poprzednim odcinku rozmawiałem o informatyce kwantowej, czyli quantum computingu. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/192. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Zastanawiasz się nad zmianą pracy, ale gdy przeglądasz oferty na popularnych stronach, to nie jesteś przekonany, czy młody, dynamiczny zespół oraz owocowe środy są dla Ciebie? Na szczęście jest solid.jobs – portal z ofertami pracy dla ludzi, którzy chcą wiedzieć, ile będą zarabiać, z jakimi technologiami i nad jakim projektem będą pracować. Solidne oferty pracy znajdziesz na solid.jobs.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, dzieląc się tym odcinkiem w swoim kręgu lub feedbackiem na jego temat ze mną, pomagasz w realizacji tej misji. A teraz życzę Ci już miłego słuchania! 

Odpalamy!

 

Cześć! Dzisiaj moim gościem jest doświadczony machine learning engineer, prowadzący z Podcastu Nieliniowego i prelegent na konferencjach branżowych. Mam dzisiaj przyjemność gościć Michała Dulembę.

Cześć, Michał! Bardzo miło mi gościć Cię w podcaście.

 

Cześć, Krzysztofie! Dziękuję Ci bardzo za zaproszenie.

 

Dzisiaj z Michałem będziemy poruszać bardzo popularny temat, ale nie w tym mainstreamowym wydaniu, natomiast postaramy się rzeczowo podejść do tego, jak AI może nas wesprzeć nas jako programistów w wytwarzaniu oprogramowania. I spokojnie – nie będziemy tutaj wietrzyć zastąpienia programistów przez AI, nie taki jest cel tego podcastu, tej rozmowy. Postaramy się rzeczowo do tego podejść.

Po to, żeby słuchacz mógł wyciągnąć coś wartościowego; coś, co będzie w stanie wykorzystać w codziennej pracy. Zanim jednak do tego przejdziemy, to chciałbym Cię, Michał, zapytać, czy słuchasz podcastów. Jeżeli tak, to może masz jakieś fajne, o których warto tutaj wspomnieć?

 

Można powiedzieć, że słucham takimi falami, czyli zdarza się, że przez kilka miesięcy bardzo intensywnie szukam jakichś swoich ulubionych, bo np. zwiedzam jakiś obszar, który mnie w danym momencie interesuje, a potem znowu mam przerwę i odpoczywam od ładowania głowy wiedzą.

I teraz ostatnio przez to, że w machine learningu duża część to są jakieś procesy wokół tego, jak z innymi częściami firmy rozmawiać, jak patrzeć na to biznesowo, to zwiedzam bardziej takie podcasty wokół zarządzania. Tutaj przez długi czas Greg Albrecht był takim podcasterem polskim, który jednocześnie pokazywał nasze podwórko, ale i to, jak wewnątrz organizacji można poprawiać te różne rzeczy. Niestety jakiś miesiąc temu stwierdził, że to już koniec jego podcastu, więc mogę zareklamować jedynie tych 200 odcinków, które nagrał do tej pory.

A z innych ciekawych, które chciałem polecić, ten jest akurat po angielsku – Pet Line Live Lessons. Jest to podcast zupełnie nietypowy w teorii. Gość był wcześniej mechanikiem w Formule 1 i teraz swoje doświadczenie opakowuje jako podpowiedzi, jak budować efektywne zespoły. Coś wie na ten temat, walczą o setne czy tysięczne sekundy przy różnych rzeczach w trakcie tych wyścigów i to doświadczenie przekuwa, jak zbudować team, czy to biznesowy, czy IT. Bardzo ciekawe spojrzenie, serdecznie polecam.

Zdarzają się też oczywiście jakieś takie odcinki, które są typowo wokół Formuły 1, gdzie komentuje jakieś wydarzenia, ale dużo jest właśnie takiej części biznesowej. 

I to chyba te takie najciekawsze. Myślę, że taki podcast, który podejrzewam, że część programistów zna, to Huberman Lab. Tam ten te odcinki są tak gęste, że ja czasami słucham go na trzy razy, bo nie daję rady połknąć takiej pigułki wiedzy, jak tam Huberman tłumaczy jakieś skomplikowane zagadnienia, natomiast jak jest jakiś temat z cyklu poprawmy Focus albo cokolwiek w swojej głowie, to chyba warto do niego zajrzeć.

 

Całkiem fajna i różnorodna lista, ale myślę, że fajnie czasem wyskoczyć z tej bańki i posłuchać sobie o czymś innym, tak, żeby po prostu się odświeżyć albo żeby umysł odpoczął, ale też się zainspirował różnymi tematami.

Od tej bańki właśnie chciałbym zacząć, bo nam, jako osobom zajmującym się ogólnie rozumianym IT, może się wydawać, że AI jest właściwie już wszędzie, że to jest temat już tam mainstreamowy, że już prawie z lodówki wyskakuje, gdzie by nie spojrzeć, to jest coś na temat AI.

Chciałbym Cię zapytać, czy to jest tylko tego typu wrażenie, że rozpoczęliśmy taki rozdział rozwoju IT, gdzie AI będzie już zawsze z nami, w mniej lub bardziej zaawansowanej wersji, zastępując programistów, czy też tylko ich wspomagając, ale zostanie z nami już na zawsze?

Czy też może jest to pewien cykl i nadal pewna zima AI nam grozi, tak jak już to parę razy w historii było, gdzie na początku zachłysnęliśmy się tymi możliwościami teoretycznymi na początku, a potem okazało się, że jednak sprzęt nie do końca jest w stanie wspomóc algorytmy, które powstawały, zapanowała zima, która trwała ładnych naście lat?

Jak Ty do tego podchodzisz, co o tym myślisz? Czy jeszcze zobaczymy zimę AI?

 

Zacznę może od tego, czy żyjemy w takiej bańce. Tak sobie myślę, jak, powiedzmy, mieszkam w małej miejscowości i jak widzę taką starszą panią, która jedzie na rowerze pamiętającym jeszcze lata 60. i jest w chustce na głowie, to sobie myślę, że to AI ma trochę jeszcze do zrobienia, zanim dotrze do każdego możliwego domu i każdej zagrody, ale w tej naszej bańce jest to chyba taki moment przełomowy.

Czyli to, co się wydarzyło w zeszłym roku, do tej pory wydaje mi się, że nie miało miejsca. Wcześniej było tak, że hype wokół AI był, ale przeciętny użytkownik w najlepszym wypadku miał jakąś aplikację, która wspomagała coś w telefonie, typu to AI było użyte w jego translatorze albo w mapach, albo gdzieś, w taki sposób niewidzialny. Po czym w zeszłym roku modele generatywne moim zdaniem sztormem wzięły w zasadzie internet w ciągu kilku miesięcy całkowicie.

I tutaj są takie sprytne wykresy, które pokazują, jak czat GPT zdobywał kolejnych użytkowników w porównaniu na przykład do gigantów typu Netflix czy Spotify. I to są na przykład dwa rzędy wielkości szybciej. Czyli, powiedzmy, Netflix zdobywał coś trzy lata, a czat GPT kilka tygodni. Więc chyba to jest taki moment, który przejdzie do historii jako taki punkt zwrotny, że nagle ludzie zaczęli korzystać masowo, ale co do tej zimy, to ona może się wydarzyć z wielu innych powodów i myślę, że warto o nich też wspomnieć.

Pierwszy to jest na przykład zbyt drastyczne, drakońskie wręcz regulacje, które co jakiś czas pojawiają się jako temat. Unia pracuje dość intensywnie nad tą regulacją. Stany i Chiny, wiadomo, że ta otwartość, czy wręcz momentami może samowolka, jest znacznie większa, ale też te głosy cały czas idą w tę stronę, że nie powinna to być technologia, którą każdy może rozwijać bez jakiegokolwiek zahamowania.

Więc wystarczy nadmierne jakieś uregulowanie i skończymy w tym, że przez długi czas nikt nie będzie chciał wydawać na to pieniędzy, bo nie będzie widział szans zwrotu. To jest tylko taki jeden ze scenariuszy.

Inny – na przykład nacisk na ekologiczność rozwiązań. Czyli co jakiś czas pojawiają się głosy, że wytrenowanie takiego ogromnego modelu językowego to jest jak spalenie iluś wagonów węgla. Jak pomnożymy to razy to wszystko, co jest na Hugging Face i w innych miejscach, to branża nie jest jakaś super proekologiczna w tym momencie. I jest tak, że oczywiście mądre głowy pracują, jak to poprawić, jak korzystać z zielonych zasobów, jak poprawiać wydajność różnych centrów obliczeniowych, ale to jest wszystko w drodze i wystarczy jedna decyzja z cyklu: nie chcemy, jak w pewnym momencie te różne bitwy bitcoinowe toczyły się wokół tego, że bitcoin spala tyle prądu, co Norwegia, to wystarczy, że taka sama narracja się pojawi i AI może na jakiś czas mieć gruby problem.

Tak że jest chyba kilka takich rzeczy, które zupełnie niezależnie od rozwoju samej branży mogą się wydarzyć i ją zablokować. Przychodzi mi też do głowy jeszcze taki scenariusz, bo z jednej strony mamy bardzo dużą demokratyzację (całe szczęście), czyli większość tych różnych pakietów, frameworków i modeli jest ogólnodostępna, powiedzmy, 90%, ale jednak te modele robią się coraz większe, coraz większe zasoby są potrzebne, żeby je wytrenować. 

Można by sobie wyobrazić taką sytuację, w której jednak ostatecznie tych kilka największych firm kontroluje kluczowe modele, których używa cała reszta świata, i to też jest raczej przepis na zatrzymanie postępu niż jakiś dalszy rozwój. Tak że chyba tutaj wiele jest takich rzeczy, których do końca nie możemy przewidzieć, niezależnych od tego, czy naukowcy siedzą i wymyślają kolejne rzeczy, czy nie.

 

I tutaj są takie sprytne wykresy, które pokazują, jak czat GPT zdobywał kolejnych użytkowników w porównaniu na przykład do gigantów typu Netflix czy Spotify. I to są na przykład dwa rzędy wielkości szybciej. Czyli, powiedzmy, Netflix zdobywał coś trzy lata, a czat GPT kilka tygodni. Więc chyba to jest taki moment, który przejdzie do historii jako taki punkt zwrotny, że nagle ludzie zaczęli korzystać masowo, ale co do tej zimy, to ona może się wydarzyć z wielu innych powodów i myślę, że warto o nich też wspomnieć.

 

Ciekawe, z tego co mówiłeś, wyniosłem, że niekoniecznie może chodzić o rozwój algorytmu albo technologii, która napędza machine learning, ale bardziej z racji tego, że staje się coraz mocniej mainstreamowa rzecz, to różne oczy na ten rozwój patrzą – o to może być ten czynnik hamulcowy. Jestem bardzo ciekawy, w którym kierunku to się będzie rozwijało.

Teraz chciałbym bardziej skierować się w stronę naszego głównego tematu, mianowicie wsparcia AI w software developmencie. Myślę, że obaj zgadzamy się mniej więcej w temacie, że póki co nie grozi nam wyparcie programistów czy też innych specjalistów IT przez sztuczną inteligencję. Myślę, że takie zdrowe podejście do AI w tej chwili to traktowanie tej technologii jako wspomagającej i myślę, że zobaczymy jeszcze wiele ciekawych rzeczy w tym kierunku.

W tym temacie wsparcia w software developmencie świadczonego przez AI chciałbym Cię teraz zapytać, co Ty o tym myślisz i, czy według Ciebie znajomość tych narzędzi to jest już taka praca obowiązkowa, czy może nadal jeszcze dla chętnych?

 

Wydaje mi się, że tutaj przede wszystkim trzeba popatrzeć od takiej strony progresu w ogóle, który ktoś sobie zakłada w głowie. Czyli w teorii możesz wejść do branży, nauczyć się określonego języka i frameworku i tkwić w jakiejś tam jednej, określonej niszy, którą opanowałeś, i zostać tam na długie lata, bo często jest tak, że są jakieś legacy systems i trzeba je utrzymywać, więc w zasadzie nie musisz uczyć się niczego innego. Ale to ma określone konsekwencje, jeżeli po jakimś czasie chcesz zmienić tę pracę albo być może znudzi Cię ten fragment, to jest ten próg bólu przejścia do czegoś nowego. 

I z AI jest chyba trochę podobnie, czyli w teorii nie musisz, ale ja bym zaryzykował stwierdzenie, że warto. Po prostu, żeby otworzyć sobie jedną furtkę, jeśli chodzi o karierę, ale też jeśli chodzi o taką furtkę w głowie.

Wyjaśnię teraz, co mam na myśli, mówiąc furtkę w głowie. Rzecz, z którą się stykałem już wielokrotnie. Problematyczne jest wyjaśnienie na samym początku, dlaczego jakiś model jest niedetermistyczny, czyli jesteśmy przyzwyczajeni do tego, poza ludźmi, którzy piszą jakieś wielowątkowe oprogramowanie i tam walczą właśnie z takimi sytuacjami, które są trochę nieprzewidywalne, to jesteśmy przyzwyczajeni, że kod powinien działać mniej więcej powtarzalnie za każdym razem. Tutaj bywa, że tak nie jest, bo zdecydowana większość modeli jest oparta o prawdopodobieństwo. 

Możemy tutaj oczywiście dyskutować, jak wiele, i czy to na pewno jest prawdopodobieństwo, czy ufność tego modelu, ale nie wchodząc w szczegóły, chodzi o to, że możemy mieć opracowany jakiś temat, być pewni, że ten moduł działa sprawnie dla określonych rodzajów przypadków, po czym ktoś dostarcza zupełnie nowe dane i model rozsypuje się na naszych oczach jak domek z kart, co w przypadku takiego standardowego oprogramowania praktycznie nie ma miejsca. Być może jakieś testy pomagają tutaj zapobiegać, ale w tzw. ML-u bywa to trudne.

I sam ten fakt, że to działa inaczej niż tradycyjne programowania, prowadzi taką barierę, że trzeba się pogodzić z tym niedeterminizmem. Może nie trzeba, ale trzeba mieć go w głowie i pracować wokół tego, żeby to nie spowodowało jakichś poważnych konsekwencji. I tu są właśnie takie różne ciekawe dyskusje przy technologiach autonomicznych. 

Czyli co z tego, że samochód w 99% sytuacji jest w stanie bezproblemowo obsłużyć, nawet zjechać na bok, jeżeli widzi jakąś przeszkodę, skoro z tym 1% ciągle specjaliści nie potrafią sobie poradzić, bo nawet człowiek na drodze, widząc niektóre sytuacje, ma wątpliwości, czy powinien pojechać, zatrzymać się, czy w jakiś inny sposób zachować się na drodze.

To jest chyba taki pierwszy powód, dla którego warto według mnie byłoby na to spojrzeć, bo to zmienia trochę neuronów w głowie, że może nie wszystko jest takie twarde, jak standardowy kod.

Natomiast ta druga część, to myślę sobie, że będziemy szli w taką stronę, że wszystkie rzeczy, które są powtarzalne, i to widać już w ogóle w biznesie, że jak możemy coś zautomatyzować, to prędzej czy później ktoś spróbuje to zrobić. Moim zdaniem programiści piszą pewne rzeczy, tzw. boiler plate, którego nie lubią, stosunkowo często. 

I teraz, nie wyobrażam sobie, że te rzeczy będzie pisał automat bez jakiegokolwiek nadzoru, dlatego mówimy o tym, że raczej nie dojdzie do takiej sytuacji, w której bot pisze oprogramowanie bez jakiejkolwiek ingerencji człowieka, bo być może wyprodukuje 70% tego, co jest potrzebne, i człowiek przejrzy, czy to jest napisane zgodnie ze sztuką, czy są tam wszystkie rzeczy, które w tym kodzie miały się zmieścić.

Wydaje mi się, że tutaj znowu pojawia się ten wątek, dlaczego warto poznawać ten fragment technologii. Zupełnie niedawno czytałem taki wywiad z kobietą, która zarządza siecią szpitali w Indiach – można założyć, że jeżeli ktoś prowadzi sieć szpitali, mający przychód w milionach dolarów, to potencjalnie wie, o czym mówi – i powiedziała, że lekarze, którzy będą używać AI, zastąpią tych, którzy go nie używają. Czyli świadomie podkreśla, że to nie AI zastąpi lekarzy, tylko właśnie ta wiedza, jak z niego korzystać, może być kluczowa w najbliższym czasie. 

Część osób pewnie powie: Tak, ale mamy jeszcze systemy w COBOLU , ludzie piszą ogromne rzeczy w PHP-ie. Czyli te różne technologie będą jeszcze z nami latami, ale znowu to jest kwestia tego, czy sobie otwieramy tę furtkę na następne jakieś kroki.

 

Czyli warto poznać te narzędzia, ponieważ zwyczajnie mogą nam pomóc w codziennej pracy, w perspektywie jakiejś dłuższej może się okazać, że będą wręcz niezbędne w tej pracy, a ja lubię dołożyć do tego jeszcze taki jeden element: Obawiamy się tego, że ten boiler plate jest pisany przez sztuczną inteligencję, natomiast według mnie to jest jak najbardziej fajna rzecz, ponieważ my, jako osoby tworzące takie systemy, możemy się skupić na rzeczach ciekawszych, kreatywnych, niekoniecznie na pisaniu czegoś, co jest powtarzalne itd. Więc z tej perspektywy jest to raczej szansa niż zagrożenie.

Chciałbym się teraz skupić na pewnym szczególnym zastosowaniu AI, machine learningu, jakim jest hiperautomatyzacja. Wiadomo, o automatyzacji mówimy jako o trendzie już ładnych kilka lat, natomiast o hiperautomatyzacji od niedawna i to jest taka, powiedziałbym, automatyzacja na sterydach, wspomagana AI, machine learningiem, robotami RPA itd.

I właśnie, tutaj taki tradycyjny model zakłada, że jeżeli coś się w firmie, w procesach zmienia, to trzeba oczywiście to zebrać, jakoś opisać, potem siada do tego programista, zmienia coś w systemie, ewentualnie w konfiguracji, jakaś ta praca jest potrzebna programisty czy analityka. Natomiast w hiperautomatyzacji może się okazać, że już niekoniecznie, że tam jesteśmy w stanie się dostosowywać do procesów bez takiej literalnej zmiany w kodzie. 

Czy według Ciebie nie jest to takie trochę wypieranie programistów przez sztuczną inteligencję? Czy też może po prostu jest to kolejne narzędzie?

 

Zacznę może od tego, że trochę słuchałem ciekawych case’ów na konferencji o hiperautomatyzacji u prof. Sobczaka i tam dużo częściej podnoszono wątek, w którym programistami staje się każdy kolejny dział, który może coś zautomatyzować. Czyli był bodajże case Volvo, który pozwala kolejnym działom pracować nad tymi rzeczami, które ich na co dzień męczą i gnębią, pisać proste rzeczy, które pomogą im w tej pracy, a później IT przejmuje to jako kod to utrzymania, dopracowania czy zarządzania globalnego, żeby było w określonych repozytoriach, testowane i dbane w profesjonalny sposób.

I wyobrażam sobie, że to będzie chyba dużo większa presja na juniorów, którzy chcieliby wejść do tego legendarnego IT i mieć do razu stabilne zatrudnienie, benefity itp., a tutaj może się okazać, że dział księgowości, HR i ktoś tam jeszcze też robi takie małe programowanie, które w teorii często jest tą pracą taką juniorską. Więc myślę sobie, że może się okazać, że to jest dużo silniejsza presja niż samo AI.

Ale jeśli chodzi o hiperautomatyzowanie, procesowanie. Ja jestem związany z procesowaniem dokumentów, można tak powiedzieć, bo w zasadzie w trzeciej firmie tego dotykam, czy są to PDF-y, czy zdjęcia, to w sumie bez znaczenia. I tam to AI potrafi w skrajnej wersji, o której słyszałem, pozbawić 100 osób swojej pracy. Czyli ludzie, którzy codziennie przychodzili i wykonywali taką mrówczą pracę z cyklu ustawianie określonych zdjęć, przygotowywanie PDF-ów, redagowanie niektórych rzeczy, to ich pracę stosunkowo łatwo jest już powierzyć automatowi.

Natomiast to jest raczej, powiedziałbym, pozbywanie się tych stanowisk, które są może nie tak bardzo kreatywne, raczej powtarzalne, niż dotykanie tej pracy twardej, programistycznej. Ja tutaj nie widzę więc jakiegoś wielkiego zagrożenia. Raczej, jeżeli ktoś jest określany kolorem kołnierzyków, czyli trafił do tej pracy w kołnierzyku, ale jednak robi tę taką powtarzalną pracę, to jest ona mocno zagrożona. 

I wydaje mi się, że prof. Sobczak pokazywał kiedyś jakieś wykresy związane ze wzrostem zatrudnienia z w supporcie i to było tak, że przez wiele lat to była niemalże pionowa linia w górę, tak wiele osób było zatrudnianych do administracji, procesowania dokumentów itd. I ta linia zmierza do takiego kompletnego wypłaszczenia, więc tutaj chyba raczej bym się spodziewał, że ta automatyzacja raczej dotknie te osoby niż programistów. Przynajmniej na razie.

Oczywiście, np. w Ignifer, w którym pracuję, był team, który pisał regexy . Ale na taką ogromną skalę, gdzie to były tysiące tych wyrażeń, z różnych powodów były potrzebne, firma w określonym momencie postanowiła pójść w takie rozwiązanie i można sobie wyobrazić, że ten team już nie będzie potrzebny, bo teraz można to w znaczący sposób zautomatyzować i osoba znacznie mniej wykwalifikowana jest w stanie na tym pracować niż do tej pory programista z większym doświadczeniem, który pracował dotąd przy tego typu kodzie i przygotowaniu tych wyrażeń.

 

Oczywiście, np. w Ignifer, w którym pracuję, był team, który pisał regexy . Ale na taką ogromną skalę, gdzie to były tysiące tych wyrażeń, z różnych powodów były potrzebne, firma w określonym momencie postanowiła pójść w takie rozwiązanie i można sobie wyobrazić, że ten team już nie będzie potrzebny, bo teraz można to w znaczący sposób zautomatyzować i osoba znacznie mniej wykwalifikowana jest w stanie na tym pracować niż do tej pory programista z większym doświadczeniem, który pracował dotąd przy tego typu kodzie i przygotowaniu tych wyrażeń.

 

Ustaliliśmy już, że szeroko rozumiane AI jest wsparciem w procesie wytwarzania oprogramowania, więc na co byś jeszcze postawił w software developmencie, oprócz oczywiście znajomości języka programowania, co według Ciebie warto jest poznać, w co zerknąć, na czym się skupić, żeby w niedalekiej przyszłości, teraźniejszości tak naprawdę już teraz, być przydatnym, a też w dalszej perspektywie uniknąć trochę tego niebezpieczeństwa, że będziemy zastępowalni w jakiś sposób.

 

Tutaj chyba wróciłbym do czegoś takiego, o czym co jakiś czas rozmawiam z ludźmi z branży, że w sumie to legendarne AI ma tak naprawdę teraz wiele takich poziomów, na których możemy się nim zajmować, czyli możemy sobie wpisać w tytule AI engineer, a tak naprawdę znać Google Vision i kilka odpowiedników, które potrafią wydobyć różne rzeczy ze zdjęcia czy z dokumentu. I to jest juz i tak świetnie, że ktoś rozumie, że jest serwis, który używając AI, gdzieś tam pod spodem potrafi wiele rzeczy zrobić za nas i nie trzeba ich ręcznie zakodowywać od zera. 

Więc to jest taki level basic, ale w wielu wypadkach dalej bardzo przydatne jest, że nie traktujemy tego jako takiej magii, jak z tego PDF-a wyciągnąć, że faktura była wystawiona wtedy i wtedy. Podaję taki przykład, bo wiem, że w pewnym momencie to też nie było takie oczywiste, bo różne sposoby wydobywania takich w teorii prostych rzeczy już też widziałem. I to jest jakiś taki podstawowy poziom, bardzo praktyczny.

Idąc w głąb, na pewno, jeśli ktoś jest tym bardziej zainteresowany, to taki choćby legendarny kurs Anrew MG, który mówi o tych wszystkich podstawowych pojęciach w Data Science, może być przydatny choćby z takiego powodu, że jeżeli my nawet tego nie będziemy robić, ale powstanie w naszej firmie team Data Science, to prawdopodobnie w pewnym momencie ten team przyniesie jakieś magiczne pudełeczko i powie: proszę, zainstalujcie to na produkcji. I warto rozumieć, czy to, co jest dostarczone, jest dobre, jak rozmawiać o tej jakości, czy ta jakość od strony IT jest taka sama, jak widzi ją biznes i Data Science. 

Więc tutaj te skrzyżowania pomiędzy wiedzą wydaje mi się, że są kluczowe, żeby nie było znowu tak, jak było z silosu: my, programiści, powiedzmy, przykładowej Javy czy C Sharpa i oni, hipsterzy, którzy piszą w Pythonie jakieś dziwne rzeczy. Trochę żartuję, ale można powiedzieć, że spotykam się z tym w miarę często. Choć muszę też przyznać, że kulturowo się to z biegiem czasu poprawia. Czyli ta komunikacja się polepsza, to zrozumienie jest coraz większe. Dlatego tacy ludzie, łącznicy, są potrzebni. 

Więc jeżeli ktoś czuje, że chciałby być na tym froncie, ale nie na tym froncie View czy Reakcie, tylko na tym froncie współpracy z Data Science warto rozumieć też ich język, dlaczego mówią o jakichś określonych rzeczach może w mniej typowy sposób.

I kolejny level jest taki, że jeśli naprawdę chcemy mocno się w to zaangażować, to chyba następnym levelem jest już rozumienie tych wszystkich niuansów wokół różnych typów modeli. Które są szybsze, które wolniejsze, które, do czego służą. Bo wtedy możemy w ogóle zrobić taki lekki krok w tę stronę, jeżeli kogoś to w ogóle zaciekawi, a po drugie, jesteśmy takim pełnoprawnym rozmówcą przy wyborze rozwiązania. Bo to często nie jest oczywiste.

Podam przykład. Powiedzmy, że procesujemy jakieś dane i Data Science bardzo chce wykręcić dobre parametry, więc bierze dane np. z pół roku, to się proesuje ileś czasu, przychodzi z gotowym modelem i zaczyna się taka dyskusja, że słuchaj, ale na produkcji to jest niemożliwe, bo pobranie tych danych będzie trwało parę godzin, trenowanie modelu kilka dni i nie jesteśmy w stanie sobie pozwolić ani na taki koszt, ani na przepływ takich danych z różnych powodów albo nie możemy wygenerować takiego obciążenia na bazie. Są różne ograniczenia, które nie zawsze druga strona rozumie.

I jeżeli programista zna swój fach, ale teżrozumie bóle tej drugiej strony, to dużo łatwiej jest zaproponować jakieś alternatywne rozwiązanie, typu: w takim razie przepompujemy ci to do jakiejś innej bazy, w której będziesz mógł pracować; możesz przygotować trochę lżejszy model, który będziemy w stanie wykorzystywać. Czyli tutaj chyba te osoby, które są takie crossed in, czy jakiś lider, który współpracuje z tym zespołem Data Science to ogromna szansa; to skrzyżowanie między technologiami jest też bardzo ciekawe.

 

Zaciąłem się chwilę przy tych łącznikach, przy tych osobach, które wychodzą poza swoje silosy – oczywiście, gdyby pewnie spojrzeć na przeciętną firmę (przeciętną w rozumieniu średnią), to silosy to coś, na czym wiele zespołów nadal działa. Tak jest po prostu łatwiej to zorganizować, być może nie wynaleźliśmy jeszcze lepszego sposobu. 

Oczywiście taka kultura typu DevOps jakoś tam pomaga, można dyskutować, na ile jest to byt teoretyczny, na ile faktycznie da się to wdrożyć w firmie, ale faktycznie trzeba przyznać, że tam, gdzie w jakiś sposób ta kultura działa, to po prostu lepiej się wszystkim pracuje, ponieważ działy, które wcześniej były osobne, jakoś lepiej się komunikują.

Tutaj chciałbym Cię zapytać, czy to ma swoje przełożenie np. na machine learning, czy takie osoby, które są na co dzień inżynierami oprogramowania, programistami, software deweloperami, czy taka znajomość tematów związanych z Data Science, machine learning według Ciebie jest potrzebna, w czymś pomaga? Jak do tego podejść? Czy takie połączenie tych dwóch światów jest wartością?

 

Wspomniałeś to magiczne słówko DevOps, my też mamy kolejne opsy, czyli w tym momencie jest to legendarny MLOps, natomiast to jest trochę tak, jak w tym żarcie o Yeti, albo powiedziałbym, że w każdej firmie ten MLOps wygląda trochę inaczej, czyli jeżeli przeczytamy praktyki firmy, która ma tysiące osób i powiedzmy, 100 Data Scencistów, to ten MLOps jest często wręcz osobnym działem, który pomaga pracować Data Scientistom. Jest, powiedzmy, 10 osób, które wspomagają to przygotowanie danych, wdrażanie modeli itd. 

Natomiast często przy dużo mniejszej skali to jest właśnie albo osoba, która trochę jak Van Damme ma taki szeroki rozkrok pomiędzy dwoma ciężarówkami i próbuje łączyć te dwa światy, czyli nie pozwoli wrzucić niczego podejrzanego na produkcję, ale też musi rozumieć pragnienia Data Scientista i jeszcze pogodzić to od strony biznesowej, że to, co ostatecznie trafi na produkcję, będzie zarabiało albo oszczędzało. 

Bo to często jest pomijane w tej całej rozmowie, że fajnie jest wdrożyć model, który coś robi, ale w sumie, jeżeli nie daje tej wartości, choćby takiej marketingowej, że sprzedawca może opowiadać o tym, jakie AI świetne rzeczy robi w danej aplikacji, to często jest to spalanie pieniędzy, a nie realna wartość, czy to dla klienta, czy choćby właśnie taka marketingowa.

Więc ten MLOps też powstaje, ale w moim podcaście padło kiedyś takie stwierdzenie, że to jest na razie taka zupa pierwotna, w której dopiero pojawiają się różne fragmenty, to Kuba Czakon z Neptune AI wspomniał o tym i oni są jednym z takich fragmentów, czyli trackują to, jak dobry jest model. Ale tych komponentów często w tym procesie jest potrzebnych wiele, bo inne narzędzia, które są używane na co dzień, się nie sprawdzają.

Czyli np. legendarnym problemem jest monitorowanie. Można powiedzieć, że branża IT ma już opracowane jakieś standardy, oczywiście można to robić jakoś tam na kolanie, ale zgodnie ze sztuką jest, strzelam, pięć aplikacji, które obsługuje większość rynku, i używa się tej albo tej, bo tak jest. 

A tutaj z różnych powodów te aplikacje kompletnie się nie sprawdzają przy monitorowaniu modułów machine learningowych i powstają nowe startupy i dodatki do tamtych aplikacji, no różne pomysły, w jaki sposób sobie z tym poradzić. I tu chodzi i o nowy sposób myślenia o tym, ale też o skalę. 

Często, jeżeli chcemy popatrzeć np. na jakiś komponent na produkcji, to patrzymy, jak bardzo jest obciążony, jaki jest czas odpowiedzi i jakieś takie proste metryki. Tutaj często chcemy porównać, jak to się zachowywało tydzień temu, a jak miesiąc temu i czy te odpowiedzi się jakoś bardzo nie zmieniły. Takie rzeczy, które mając miliony eventów, często są bardzo skomplikowane w tych takich, nazwijmy to, standardowych narzędziach.

Więc w tej legendarnej zupie pojawiają się takie bardzo konkretne kawałki, natomiast branża jest tak moda, że po pierwsze jest wysyp tych narzędzi i jeszcze nie doszło do takiego procesu z cyklu: część firm wykupiła te mniejsze, część firm upadła, część pakietów zostało porzuconych na GitHubie i już są wygrani. Czyli mamy przysłowiowych pięć, które obsługują cały rynek i narzędzia, których używają mikrofirmy i studenci. Tutaj jeszcze jesteśmy na tym procesie takim ścigania się; jest wyścig budowania tych różnych elementów i to na pewno potrwa. 

I tak samo, jeżeli chodzi o te praktyki wewnątrz firmy. Tak jak wspomniałeś, DevOps z jednej strony jest kulturą, z drugiej strony ludzie czasami mają to przypisane przy nazwisku na wizytówce. Różnie to się sprawdza. 

Mogę podać taki przykład, że w pierwszym odruchu mieliśmy taki pomysł, żeby to był kolejny dział. Bardzo szybko okazało się, że to jest fatalny pomysł, bo to będzie kolejny dział, który chodzi z prośbą do innych działów, żeby coś dla nich zrobił, więc ostatecznie raczej więcej komunikacji i więcej kłopotów niż mniej.

I tutaj były takie różne ruchy i ostatecznie osoba z doświadczeniem DevOpsowym (tutaj pozdrawiam Mikołaja) będzie u nas w teamie ML-owym, czyli będziemy mieć takiego człowieka, który rozumie, co tam się dzieje, jak się spala te grube dolary na produkcji i jak trzeba dbać o te różne rzeczy, żeby w trakcie nie doszło do żadnych awarii, a jednocześnie będzie rozumiał naszą stronę, dlaczego wrzucamy te różne, wydziwiaste kontenery.

I tak sobie myślę, że jeszcze trochę to potrwa, ale raczej to będą takie osoby cross team niż osobny dział, tak to zobie wyobrażam.

 

Nie wiem, czy się ze mną zgodzisz, ale myślę, że mimo wszystko tych osób, które łączą te różne światy, niezależnie, czy to jest DeFi, ML, MLOps, czy w którąkolwiek stronę nie spojrzeć, tych osób będzie jednak mniejszość. 

Większość będzie mimo wszystko zajmowała się zadaniami w tym swoim silosie i jeśli ktoś jest takim tradycyjnym programistą, czyli po prostu interesuje go tworzenie kodu, a nie inne dodatki, to jak byś odpowiedział na pytanie, jak taka osoba może wykorzystać w swojej codziennej pracy AI? Nie chodzi mi tutaj o konkretne narzędzia, bo do tego jeszcze przejdziemy, ale raczej rodzaje zadań, jakieś odpowiedzialności, które z powodzeniem mogłyby być wspomagane przez AI.

 

Wyobrażam sobie, że przy pewnym poziomie kompilacji różnych heurystyk to jest często takie wskazanie, że jeśli w moim kodzie jest za dużo ifów, to być może powinno się tu pojawić AI. Oczywiście żartuję sobie trochę, ale to jest jakiś element, z którym ludzki mózg przestaje sobie radzić, czyli jeżeli mamy do sprawdzenia wiele warunków i dokładamy kolejne i po jakimś czasie wracamy w to miejsce i znowu zmieniamy tą logikę, to jest to jakiś taki moment, w którym może nie jesteśmy do końca pewni, jak to zadziała, jeżeli to drzewo jest za bardzo rozgałęzione i to jest taki moment, w którym można się zastanowić, że może chciałbym porozmawiać z kimś, czy można tutaj wstawić jakiś model albo samemu zbudować coś takiego.

Więc to jest jakiś jeden element, który warto mieć z tyłu głowy. Tak jak wspomniałem, w procesowaniu wszelkich danych często wystarcza tradycyjny kod, natomiast jeżeli wnioskujemy coś, co nie jest takie oczywiste, to tutaj podam przykład: Widziałem jakiś czas temu chyba kod, ale pod spodem był jakiś model, który procesował dane marketingowe, czyli mamy tam taki wiersz, który zawiera, kiedy nastąpiła wizyta, z jakiego urządzenia, jakiej przeglądarki, o której godzinie, z jakiego IP, jak długo trwała wizyta, różne tego typu drobiazgi. I jeżeli mamy takich informacji 5–10, to możemy to obejrzeć i na podstawie takiego wiersza możemy dodać jakiś kawałeczek kodu, który coś tam zrobi. 

Natomiast jeśli ten wiersz ma 100 pól, to jest to trudne, żeby podejść do tego w jakiś taki świadomy sposób. Tutaj jeszcze do chodzi do tego skala, czyli możemy przejrzeć 10–20 tych wierszy, może, jak ktoś jest cierpliwy 100 czy 1000, ale dopiero taka głębsza analiza, może milionów wierszy i wszystkich tych 100 pól da nam jakiś pogląd, co w danej sytuacji robić, albo właśnie już to AI przejmie decyzyjność.

Więc myślę, że to jest chyba taki wskaźnik do tego, że okej, w tym miejscu dotarłem do takiego poziomu komplikacji, że może warto byłoby tutaj kolejnego narzędzia użyć. I wracamy tutaj do tego miejsca, że jeżeli ktoś, tak jak mówisz, chce być tradycyjnym programistą, ale dotarł do czegoś, co go przerosło (choć mało kto przed sobą do tego się przyzna, ja bym chyba tego nie powiedział), że za często wraca do tego, żeby coś naprawiać, to jest to być może jakiś wyznacznik, że warto od takiej strony popatrzeć.

 

Musiała pojawić się w tej rozmowie taka chwila, w której powiemy coś o chat GPT, bo wszyscy o tym mówią. Więc jak ty widzisz to narzędzie w kontekście wspomożenia programistów w ich codziennych zadaniach? Bo jedni uwielbiają, drudzy się boją, trzeci podchodzą jak pies do jeża, różne są sentymenty związane z tym narzędziem. Ono cały czas się rozwija, cały czas słyszymy o różnych zastosowaniach. Jestem ciekawy, jak Ty ze swojego eksperckiego punktu widzenia widzisz to narzędzie i czy upatrujesz szanse w jego wykorzystaniu dla programistów.

 

Tak jak powiedziałeś, postawy są różne. To nawet zaobserwowałem ostatnio, miałem taki krótki wykład na temat chat GPT i Copilota i zaskoczyło mnie to, że ludzie z kilkukrotnie większym doświadczeniem ode mnie podchodzili do tego sceptycznie, na zasadzie, że znowu chcą nam to AI sprzedać, już było tyle prób i po raz kolejny chcą nas nabrać na to, po co mi jakieś tam AI, sam sobie to zakoduję. 

Więc to mnie trochę zaskoczyło, ale co ciekawe, po prezentacji, gdzie pokazałem od bardzo prostych do bardziej zaawansowanych przypadków użycia, pojawiły się takie głosy, że no to przynajmniej sobie to obejrzę, bo może to nie jest tylko do pisania wierszyków w określonym stylu albo jakichś takich wygłuptasów internetowych. Bo chyba większość tych newsów od chat GPT to są takie śmieszne generacje, które dobrze wyglądają jako mem internetowy, a nie jako realne użycie.

Plus oczywiście na pewno czeka nas zalew contentu marketingowego, który jest generowany na zasadzie jednego zdania i kliknięcia, ale z tym nie wygramy, a wróćmy do wykorzystania programistycznego. 

Więc wyobrażam sobie, że w zależności od zaawansowania i znudzenia swoją pracą, można różne rzeczy w tym chat GPT robić. Czyli zaskoczyło mnie np. to, już widziałem taki przypadek użycia, w którym ludzie uczą się programowania, używając chat GPT, bo jest to prawie idealny tutor, którego możesz zapytać, dlaczego ta linijka tak działa, dlaczego mój kod się nie kompiluje czy nie chce się uruchomić. 

Więc jak sobie tak pomyślę, że ta firma Repl.it podpięłaby chat GPT do swoich rzeczy, to wyobrażam sobie, że to byłoby niesamowite narzędzie do nauki programowania i w zasadzie można by płynnie przeskakiwać między językami, między tym, jak zaawansowany level chcesz mieć. Prędzej czy później ktoś coś takiego zbuduje, jakkolwiek to będzie się nazywało, czy to będzie ta firma, czy inna. 

Myślę, że to jest jakieś tam ryzyko dla tradycyjnych kursów, gdzie nie ma tej interakcji, a z drugiej strony pewnie nie wszyscy chcą pracować w taki sposób, że pytają o każdą rzecz tego nauczyciela. Może dla części osób jest wygodniej przeczytać coś czy obejrzeć. 

Zatem to sobie wyobrażam jako taki sposób na wejście do branży, ewentualnie na przejście do innej technologii, bo to się zdarza, że chcemy się nauczyć czegoś nowego i mamy do wyboru ileś tam sposobów, jak sobie z tym poradzić, czy kupić bootcamp, czy pięć książek, czy być może właśnie spędzić tydzień z chat GPT i pogadać z nim o tym programowaniu. To jest ten jeden przypadek.

Ale też mnóstwo sytuacji, w których mamy powtarzalne rzeczy, ale takie, które nie wymagają aż takiego kontekstu całego kodu. Mam na myśli przysłowiowe regexy. Można o nich rozmawiać w oderwaniu od całej aplikacji. Czyli nie musimy widzieć wielu klas wielu modułów, wystarczy, że widzimy przysłowiową funkcję i piszemy typowo pod to. I tutaj chat GPT do tego typu rzeczy nadaje się genialnie, rozumie to, potrafi napisać, potrafi wyjaśnić te elementy, które były użyte. 

I takich use case’ów będzie coraz więcej. Wczoraj w ogóle widziałem książkę na ten temat, więc ktoś naprawdę usiadł do tego błyskawicznie, zaraz jak tylko się pojawił ten model. Ale też mamy dużo takich rzeczy z cyklu: mam ten kod, wyjaśnij, jak on działa. Albo: mam ten kod, pomóż mi go zrefakturować, bo mnie przerósł i chciałbym go podzielić na mniejsze moduły czy np. przejść z jakiegoś trybu proceduralnego na ładne klasy.

To są takie w teorii proste rzeczy, ale jeżeli zamiast kilku godzin możemy na to poświęcić kilkanaście minut i potem debugować ten kod wyprodukowany przez chat GPT – są już takie memy, czy na pewno się to opłaca w porównaniu z napisaniem tego samemu. Myślę, że mimo wszystko tak.

Oszczędności tutaj mogą być bardzo duże, jeżeli mamy tego typu sytuację. I tu znowu taki realny przypadek, kumpel z pracy (pozdrawiam Kubę) wspomniał o tym, że miał do napisania jakieś skrypty w języku, w którym nie jest zbyt biegły, bo pisze na co dzień w czymś innym, i oszacował, że trzykrotnie mniej czasu mu to zajęło, bo dobrze tam spromptował, dostał jakąś podstawową wersję, potem zmodyfikował to dokładnie pod swoje użycie i stosunkowo krótko mu to zajęło, ale myślę też sobie, że tu jest taki faktor zmęczenia mózgowego. 

Nie wiem, może ktoś lubi takie dłubanie w Stack Overflow w języku, którego nie zna i szukanie, jak to zrobić, ale obstawiam, że część słuchaczy woli mieć to szybciej za sobą, więc to jest chyba kolejny jakiś taki use case tego, jak sobie pomóc chat GPT.

Ostatnie to legendarne wszelkie rzeczy wokół dokumentacji. Nie chcę powiedzieć, że nikt tego nie lubi, są ludzie, którzy bardzo dobrze piszą i lubią, ale też bym powiedział, że raczej to nie jest największy fun programowania, więc tutaj przeklejenie i zapytanie o Docstringa robi niesamowitą robotę. Polecam chociażby po to, żeby zobaczyć, o ile bardziej czytelny może być taki Docstring albo jak szybko może być wygenerowany.

 

Więc jak sobie tak pomyślę, że ta firma Repl.it podpięłaby chat GPT do swoich rzeczy, to wyobrażam sobie, że to byłoby niesamowite narzędzie do nauki programowania i w zasadzie można by płynnie przeskakiwać między językami, między tym, jak zaawansowany level chcesz mieć. Prędzej czy później ktoś coś takiego zbuduje, jakkolwiek to będzie się nazywało, czy to będzie ta firma, czy inna. 

 

Drugie takie narzędzie, które od razu przychodzi na myśl to GitHub Copilot. Myślę, że bardzo trafiona nazwa, jakby nie było, jako narzędzie, jako coś, co wspomaga nas w przetworzeniu kodu, a nie zastępuje. Narzędzie, które wyprzedziło chat GPT, na początku darmowe, teraz już płatne, ale też z licznymi gdzieś tam kontrowersjami wokoło, bo w sądach już się szykują pozwy z racji tego, że ten model był trenowany na teoretycznie tych repozytoriach , które nie są publiczne. Wiadomo, trochę kontrowersji wokoło tego jest. 

Mimo wszysrtko sam korzystałem i naprawdę byłem pod wrażeniem. Chciałbym Cię zapytać, jak programiści mogą wykorzystać Copilot. Czy Ty uznajesz to narzędzie jako warte uwagi?

 

Powiem tam, Microsoft ani Open AI mi nie zapłacili, ale bardzo lubię Copilota. Zacznę od takiego statementu. Wydaje mi się też, że tutaj warto powiedzieć o takich trudnych rzeczach wokół takich modeli, że one z biegiem czasu będą coraz lepiej obsługiwane. 

Czyli większość modeli językowych – bo trzeba rozumieć to, że to jest inny model językowy, który obejrzał zamiast Wikipedii i tysięcy książek miliony repozytoriów albo najpierw przeczytał Wikipedię, a później ten kod i zrozumiał, w jaki sposób ta składania działa – są uczone na wątkach z Twittera i później mówią różne obraźliwe rzeczy, bo takie dane trafiły do treningu.

Oczywiście firmy, którym zależy na rym bezpieczeństwie, i większość przynajmniej twierdzi, że tak jest, bardzo mocno pracuje nad tym, żeby takie rzeczy odfiltrowywać i po stronie danych treningowych, i po stronie potem tej odpowiedzi, którą dostajemy z danego serwisu. Bo jak działa Copiltot. Piszemy jakąś linijkę, ta linijka jest wysyłana do serwera, serwer na podstawie tego tworzy predykcję następnej linii kodu. I dlatego, jeżeli ten model widział zły kod czy cokolwiek, czego nie powinniśmy dostać, to może takie predykcje odesłać do naszego IDE.

Ale tutaj taka ważna informacja, że dwa tygodnie temu doszło do bardzo dużej aktualizacji Copilota, która adresuje połowę tych wszystkich różnych sytuacji, które były bardzo dyskusyjne do tej pory, m.in. np. komuś w podpowiedział pojawił się czyjś klucz do Api, więc był to jakiś security bridge, który mógł być bardzo poważny, bo być może to było np. hasło do last passa albo cokolwiek innego. I teraz Colpilot w zeszłym tygodniu dodał taką warstwę, która nie pozwoli tego wysłać, jeśli Ty wkleisz w swoim kodzie, ale też nie pozwoli odesłać, jeżeli oni by wygenerowali taką linijkę, to nie wyśle jej do Twojego IDE.

To jest jakaś jedna z tych różnych poprawek, które były wykonane. Zakładam, że oczywiście, może jakieś sprawy trafią do sądu, może ktoś będzie miał kłopot, bo użył kodu, który nie miał właściwej licencji, ale ostatecznie to zostanie naprawione. Być może w wersji 3.0 albo 4.0 i to jeszcze potrwa kolejny rok. Jestem przekonany, że większość tych sytuacji zostanie naprawiona, bo współczynniki, które pokazują zadowolenie programisty i czas pracy równają się miliony lub może miliardy dolarów za chwilę, więc na pewno firma nie zrezygnuje z tego, żeby rozwiązać tego typu problemy.

Więc nie bałbym się tego, czy rzeczywiście nam coś grozi. Jasne, nasze security też patrzy z dużą ostrożnością na to narzędzie i w pierwszym momencie było tak, że możemy korzystać, teraz jest kolejna edycja rozmyślań, jak bardzo jest bezpieczne,a le obstawiam, że po prostu z czasem te rzeczy zostaną zaadresowane. Tym bardziej, że pod spodem jest model Codex, który może być już teraz wrzucony na Azurze jako własny. Czyli można mieć swojego Codexa. Obstawiam, że to też jest kwestia miesięcy, że będziemy mogli to IDE skierować nie do Codexa oficjalnego na Open AI, tylko do własnego.

I w tym momencie rozwiązujemy znowu te problemy, komu my udostępniamy to, co piszemy. Bo tu jest kolejny taki case, dlaczego mam się chcieć dzielić moim kodem z jakąś firmą, która być może go zapisuje, być może nie. Oczywiście znowu tutaj Copilot już to zaadresował, dając licencję biznesową, gdzie w ogóle ten kod nie jest przechowywany, tylko jest użyty do pojedynczej predykcji i porzucany, ale część firm nawet z tym nie będzie się czuła komfortowo, więc za jakiś czas będzie można mieć swój model ze swoimi kluczami i znowu to ryzyko spadnie wielokrotnie. 

Więc obstawiam, że z biegiem czasu po prostu będzie to taki standard, trochę jak podpowiedzi w IDE. Są oczywiście ludzie, którzy chełpią się tym, że potrafią w Vimie kodować wielkie, skomplikowane rzeczy w Javie. Nie jestem pewien, czy robią to tak samo szybko, jak mają odpalone inteli J. I tu chyba będzie po prostu tak samo. To będzie kolejny level podpowiedzi, pomocy programiście.

 

Więc obstawiam, że z biegiem czasu po prostu będzie to taki standard, trochę jak podpowiedzi w IDE. Są oczywiście ludzie, którzy chełpią się tym, że potrafią w Vimie kodować wielkie, skomplikowane rzeczy w Javie. Nie jestem pewien, czy robią to tak samo szybko, jak mają odpalone inteli J. I tu chyba będzie po prostu tak samo. To będzie kolejny level podpowiedzi, pomocy programiście.

 

Wspomniałeś o kilku takich niebezpieczeństwach z wykorzystania tego typu narzędzi. Chciałbym Cię prosić, żebyś jeszcze trochę pogłębił ten temat, i też chciałbym Cię zapytać, jakie są wady (zbyt intensywnego) używania tego typu narzędzi przez programistów. Co nam grozi, jakie są ryzyka?

 

W ciekawych dyskusjach zaraz po tej mojej prezentacji najczęściej wymieniane było to, że narząd nieużywany zanika. Więc jak sobie będziemy radzić z tym, że w sumie już nie pamiętamy tych różnych kawałków, bo one TAB, TAB, TAB i mamy już ten fragment kodu napisany, w ogóle nie myśląc o tym.

Czyli ani nie ma tej takiej pamięci, że nasze palce to pamiętają, ani nasza głowa, tylko podpowiedzi wskakują i to wszystko. To jest na pewno jakaś część tego. Być może każdy będzie musiał odpowiedzieć sobie na pytanie, jak bardzo chce zautomatyzować to, co robi, i ile potrzebuje pamiętać, a ile chce oddać edytorowi. 

To jest o tyle ciekawy temat, że on dotyczy generowania wszystkiego. Czyli o tym samym piszą dziennikarze, którzy używają chat GPT do generowania jakichś swoich rzeczy, to samo mówią artyści, którzy używają Midjourney, czy teraz będą się uczyli malować, czy wystarczy pracować nad promptem i dostać ten określony efekt za darmo, bez tej pracy ręką. Więc chyba to będzie takie cywilizacyjne wyzwanie, czy chcemy, żeby AI w całości przejęło, czy chcemy je umieć i gdy trafimy na jakąś sytuację, że mamy mały edytor i potrzebujemy coś zdebugować i naprawić, to dalej potrafimy to zrobić, bo wiemy, jak to pod spodem działa.

To chyba taki najczęściej pojawiający się element w rozmowach. Drugi – wrócę znowu do danych treningowych, czyli jeżeli model widział 1000 źle napisanych klas i 1000 dobrze napisanych klas, to czasem będzie podpowiadał te złe. Niestety tak to działa. Dopóki znowu nie będzie tak, że np. firma, która uczy model, nie wymyśli jakichś kryteriów albo nie zatrudni programistów, którzy będą oceniać te rzeczy idące do setu treningowego, to model czasami będzie podpowiadał niewłaściwe rzeczy. I to jest jakieś ryzyko, z którym trzeba żyć.

Wczoraj miałem taką sytuację, że dostałem kod, to były halucynacje tego modelu, czyli one kompletnie nie miały nic wspólnego z rzeczywistością, bo dana paczka Pythonowa nie istniała, natomiast wyglądało to bardzo realistycznie, bo zachowywał konwencję innych pakietów, których w tym miejscu standardowo się używa. 

Więc trzeba mieć też taką świadomość, że to się może wydarzyć, bo te dane treningowe są różne i ten sposób predykcji następna linia, następna linia powoduje czasami takie zaburzenia, że model losową rzecz nam podpowiada. Tutaj ludzie z branży machine learningowej tak powtarzają, że w ciągu roku część tych problemów zostanie zaadresowana. 

Zupełnie niedawno była taka dyskusja, czy akcje Google przez właśnie taki błąd w podpowiedzi, że chyba zdjęcie planety nie było pierwsze, tylko drugie, w jakiejś pokazówce ich odpowiednika chat GPT, była zła odpowiedź i następnego dnia akcje spadły o 8%. Nie jestem pewny, czy to ma bezpośredni związek, ale taka była narracja. i znowu pojawiły się głosy, że to jest kwestia dodania kolejnej warstwy, która będzie potwierdzać te informacje. Czyli model podpowie coś, a potem będzie jeszcze inny model czy mechanizm, który zweryfikuje to, co mówi, powiedzmy, Wikipedia. Więc tu jest na pewno ryzyko tego halucynowania, ale powiedziałbym, że w krótkim czasie powinno to zostać rozwiązane.

 

A biorąc pod uwagę, że ta dziedzina, a właściwie takie jej praktyczne zastosowania w temacie wspierania wytwarzania oprogramowania są raczej efektem kilkunastu pewnie miesięcy, kiedy widzimy, jakie są możliwości, widzimy kolejne use case’y itd. Jednym słowem mówiąc, ta zupa gdzieś tam jeszcze się gotuje, jeszcze się nie okazało, co z niej wyjdzie. 

Gdybyś mógł spróbować przewidzieć, bazując na swoim doświadczeniu, jak uważasz, w którym kierunku będzie to zmierzało, jeśli chodzi o wykorzystanie wytwarzania oprogramowania. Czego się możemy spodziewać, jak będzie nas, programistów, wspierało w przyszłości?

 

Jak o tym wspomniałeś, to najpierw taki bardzo gruby disclaimer , że w tej branży tylko szaleńcy próbują przewidywać przyszłość, więc ja to raczej skieruję w stronę luźnych rozmyślań, próbując łączyć kropki, które są widoczne w świecie.

Wyobrażam sobie, że jeżeli za jakiś czas uda nam się odczytywać sygnały z mózgu, to możemy to jeszcze bardziej uprościć, czyli myślimy sobie o tym, co chcemy zakodować, nie musimy nawet pisać tego prompta, tylko odczytujemy sygnał i na podstawie tego powstaje jakiś pierwszy prototyp. Myślę, że teraz to brzmi jak science fiction, ale prędzej czy później być może będzie to możliwe.

Natomiast kiedyś przeczytałem takie ciekawe zdanie, że chciałbym żyć w takich czasach, że wstaję rano i mówię sobie: hmm, mam taki pomysł. I ktoś siada do mikrofonu i mówi: weź, Jarvis napisz mi twiterra. I za parę godzin na serwerze jest odpalony jakiś prototyp tego pomysłu; że tak wiele warstw już mamy gotowych, że w gruncie rzeczy za jakiś czas ten no code czy low code połączony z tymi komponentami, o których dzisiaj rozmawiamy, może w wielu przypadkach w zupełności wystarczyć. 

Czyli przeniesiemy się po prostu na jeszcze jedną warstwę wyżej; będziemy mieć mnóstwo klocków, tak jak jest ten serwis Zapier, który łączy różne elementy, to być może następnym krokiem będzie to, że możemy sobie zażyczyć połączenia różnych elementów i one zostaną wykonane.

I tak np. w rozmowie z Piotrem Grudniem, z Quick Chat, on wspomniał, że to jest bardzo skomplikowane, ale ludzie życzyliby sobie też np., żeby taki przysłowiowy chat potrafił bookować bilety. I tu pojawiają się pytania: ale w jakiej firmie, w których liniach, skąd ma mieć numer karty kredytowej – bo jesteśmy przyzwyczajeni, że AI w filmach potrafi wszystko na życzenie, ale tam pod spodem jest mnóstwo rzeczy, które muszą być rozwiązane. Natomiast zmierzamy w taką stronę, że jakby ktoś 20 lat temu zobaczył, ile płatności teraz obsługuje przysłowiowy procesor paymentu, to nie mógłby uwierzyć, że może być tak łatwo. I chyba w tę stronę idziemy. 

Tak że tak sobie myślę, że być może taki będzie kierunek, że coraz więcej będziemy mogli wymyślić i dostać, niż rozwiązywać takie problemy, które jak zostaną raz rozwiązane, to już po prostu będziemy mogli z nich korzystać. To jest taka moja, bardzo ostrożna predykcja.

 

Wygląda na to, że przyszłość rysuje się raczej w Twojej opinii w dobrych i jasnych barwach i tutaj kolejny raz można powiedzieć, że zastąpienie AI programistów to nie jest temat, na który się powinno rozmawiać, bo to będzie raczej współpraca.

Dzisiaj moim gościem był Michał Dulemba, rozmawialiśmy o tym, jak można wykorzystać AI w wytwarzaniu oprogramowania.

Michał, bardzo Ci dziękuję za rozmowę, za poświęcony czas.

 

Ja też dziękuję za zaproszenie i do następnego razu. Do usłyszenia!

 

Do usłyszenia! Ale zanim Cię jeszcze wypuszczę, to muszę Cię zapytać, gdzie Cię można znaleźć w internecie, jak się z Tobą skontaktować, gdyby ktoś chciał pogłębić sobie jeszcze tę wiedzę.

 

Oczywiście bezpośrednio na LinkedInie – proszę zaczepiać, pytać. Na Nieliniowym moje różne ciekawe rozmowy z ludźmi z branży na temat ML-a. I właśnie zaczynam pracować nad nowym projektem, który będzie nazywał się Code Buster, czyli tam będę mówił o tym, jak sobie pomóc w pracy programistycznej, korzystając z tych technologii AI, które m.in. dzisiaj omawialiśmy. Tak że zapraszam serdecznie, może coś ciekawego dla siebie znajdziecie.

 

Jestem przekonany. Oczywiście wszystkie linki będą w notatce do odcinka. Warto śledzić Michała, warto patrzeć, co tworzy. 

Michał, jeszcze raz bardzo Ci dziękuję. Udanego dnia! Cześć!

 

Dzięki! Do usłyszenia!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o wsparciu AI w wytwarzaniu oprogramowania. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!