Blog

Jak to zwykle na live był chat i były też pytania przez QuA.do (tu nagranie). I w efekcie tego, co tam się pojawiło nasunęły mi się dwie refleksje.

Po pierwsze było dużo obaw związanych z „dzieleniem się danymi” z modelami. Chodzi o obawę, czy te dane nie „wyciekną”, czy np. jakieś kawałki kodu źródłowego nie zostaną przez model zaserwowane komuś innemu, kto będzie miał podobny problem – czyli konkurencji.

Myślę, że te obawy są lekko przesadzone. Wynikają trochę z niezrozumienia tego w jaki sposób modele LLM w ogóle działają. To nie działa na takiej zasadzie, że zapamiętuje konkretne fragmenty tekstu – tu kodu – i potem szuka w pamięci gotowca i go zwraca. Model w odpowiedzi na prompt generuje na bieżąco bazując na zbudowanej na ogromnej bazie tekstów (tu: kodu) mapie, która pokazuje prawdopodobieństwa powiązań między elementami języka (tu: języka programowania). To m.in. dlatego model nie umie przewidzieć na przykład jak długie będzie to, co mu wyjdzie dopóki nie zakończy generowania tego.

Innymi słowy nawet jeśli model nakarmimy genialnym kawałkiem kodu zawierającym super-hiper-rewolucyjny algorytm to będzie to i tak z punktu widzenia modelu po prostu zestaw prawidłowego kodu umacniający pewne powiązania w jego mapie tego języka. Szanse, że model odda komuś dokładnie ten sam, nasz kod są mizerne.

Obawy te mają słabe uzasadnienie także dlatego, że w rzeczywistości bardzo niewiele z wymagań czy kodu aplikacji jest faktycznie odkrywcze i unikalne. Większość – zwłaszcza na poziomie kodu – to rzeczy powtarzalne, „stałe elementy gry”. Ewentualne zagrożenia wynikające z nakarmienia modelu czymś takim są naprawdę minimalne. Jedyne czego możemy się obawiać to to, że potencjalnie wszystkie „prompty” czyli to, co użytkownicy wysyłają do modelu, może przeglądać także jego ludzka obsługa. I w tym przypadku rzeczywiście obawy mogą być uzasadnione choć – jak już wspomniałem – dotyczy to raczej niewielkich i nielicznych fragmentów kodu.

Myślę jednak – o czym mówiłem już podczas live-a – że będzie to wyglądało dokładnie tak jak z chmurą. Coraz więcej firm – i to całkiem dużych – trzyma swoje dane w systemach Google, Amazon czy Microsoft bez specjalnych obaw o wycieki czy tajność. Jest to już właściwie powszechne. Konieczne było mentalne przejście od przekonania, że niezbędne są własne serwery we własnej piwnicy do otwartości na rozwiązania oparte na wirtualnej przestrzeni gdzieś w wielkich serwerowniach prowadzonych przez te giganty. Podobnie będzie z AI i to z tych samych powodów – po prostu jest to dużo tańsze i skuteczniejsze, a ci, którzy powodowani takim czy innym lękiem nie będą tych narzędzi stosować będą pozostawać w tyle.

Oczywiście, dla pewnej kategorii zastosowań nadal firmy wykorzystują własne serwerownie i maszyny, nie wszystko jest w chmurze. I podobnie firmy będą używać swoich własnych systemów AI, czyli własnych modeli. Trudność polega tylko na tym, że o ile będzie można stworzyć dobry własny model do jakichś wąskich zastosowań o tyle stworzenie własnego, wewnętrznego odpowiednika GPT4 czy GPT5 będzie trudne głównie ze względu na to ile danych wejściowych jest używanych do jego treningu. I nie chodzi tu o koszt przechowywania takiego wolumenu danych itp. ale przede wszystkim o to, że przeciętnej wielkości firmie trudno będzie uzyskać dostęp do dostatecznie dużego zbioru danych a także ponieść koszty treningu na tak dużej bazie.

Właśnie dlatego dla większości firm dużo atrakcyjniejsze będzie tworzenie własnych modeli na bazie już istniejących modeli ogólnych, poprzez ich „do-trenowanie” na specjalistycznych danych. To OpenAI już oferuje jako „fine tuning”, podobne oferty mają też inne firmy – są firmy oferujące AI jako API do własnego dotrenowania, których używają już twórcy produktów opartych o nie. Są one mniej znane, ale istnieją. Dobrym przykładem może być tu np.  Astria , model AI stojący za takimi produktami jak  Deep Agency  (przy okazji: produkt stworzony przez  jednego developera ).

Po drugie w dyskusji na live pojawiły się głosy, że zastosowania, które pokazywaliśmy na początku mogłyby być ciekawe dla Product Ownerów czy analityków, ale nie dla Scrum Mastera. Podobnie jak zastosowanie AI do analizy kodu i jego tworzenia, które również – choć bardzo skrótowo – pokazywałem. Coś mi tu od razu nie grało, ale dopiero wczoraj dotarło do mnie jak problematyczne jest takie nastawienie.

Słyszałem o pewnym programiście, który zmierzył (poprzez tempo przekładania tasków w Jirze) i wyszło mu, że ze wsparciem AI pracuje 4x (cztery razy) szybciej! Tak się składa, że rozmawiałem wczoraj z właścicielem średniej wielkości software-house i powiedział mi, że w jego firmie programiści korzystający z narzędzi AI pracują 5-6x razy szybciej. Dzieje się tak dlatego, że narzędzia AI czynią żmudne części pracy programisty mniej żmudnymi. Nie są w stanie (jeszcze?) zastąpić ludzkiej inwencji i szerszego spojrzenia, ale redukują potrzebę żmudnego klepania funkcji przenosząc programowanie poziom wyżej, na poziom właśnie koncepcji co chcę osiągnąć danym modułem czy klasą.

Na początku kwietnia w ramach zapoznawania się z tymi narzędziami zbudowałem sobie aplikację w Pythonie korzystając z GPT4 i Github Copilot. Pierwszy raz w życiu używałem tego języka, wcześniej raczej trzymałem się C/C++, ale aktywnie programowaniem nie zajmuję się od grubo ponad 20 lat. Mimo to w przeciągu kilku godzin stworzyłem całkiem sprawnie działającą aplikację do bardzo niszowego zastosowania (to był właśnie ten monitor DX-Cluster, którego kawałka użyłem podczas live do demonstracji). Na podstawie tego własnego doświadczenia całkowicie wierzę w te pomiary czy oszacowania wpływu tych narzędzi.

Piszę o tym moim doświadczeniu, bo myślę, że trzeba po prostu osobiście doświadczyć możliwości tych narzędzi by zrozumieć jak fundamentalną zmianą są one jeśli idzie o programowanie. To rewolucja w programowaniu porównywalna jedynie z tą jaką było wprowadzenie w latach pięćdziesiątych ubiegłego wieku abstrakcyjnych języków strukturalnych w miejsce bezpośredniego tworzenia instrukcji dla procesora.

Powtórzę, żeby to dobrze było zrozumiane: programista korzystający z narzędzi AI działa 4-6x efektywniej. Zatem, jeden ogarnięty programista, który wie jak z tych narzędzi korzystać tworzy tyle co cały zespół bez nich.

Scrum Master odpowiada za efektywność zespołu (tak, tak, to właśnie mówi Scrum Guide). Programiści i zespoły, które pracują ze wsparciem sztucznej inteligencji pracują dużo, dużo efektywniej. Dziś narzędzia AI są więc najważniejszym i najłatwiejszym zarazem sposobem na radykalną poprawę efektywności programistów. Zatem, to odpowiedzialność Scrum Mastera aby narzędzia AI jak najszybciej trafiły do developerów, a pierwszym krokiem do tego jest poznanie ich i rozumienie ich.

Jeżeli zatem Scrum Master czy Agile Coach uważa, że jest od „relacji”, od „atmosfery”, od „facylitacji” ale nie od tego, żeby ludzie w jego zespole pisali dobry kod korzystając z narzędzi, które pomogą im to robić dużo szybciej i wydajniej… no to słaby zeń Scrum Master czy Agile Coach. Innymi słowy, jeśli patrzysz na to przez pryzmat tego czy AI pomoże Ci zaplanować retrospekcję (pomoże!) albo zrobić grafiki na tablicę Mural (pomoże!), ale nie widzisz potencjału jaki narzędzia te dają programistom to… czym prędzej przyjrzyj się temu jeszcze raz. Masz patrzeć z perspektywy zespołu, a nie tylko własnej.

„Its not about me, its about the team” że tak przypomnę Scrum Mastera z  legendarnego filmiku sprzed lat .

W Code Sprinters przygotowaliśmy pierwsze w Polsce szkolenie warsztatowe na ten temat: „ Scrum Master i AI ”. Już 30 maja pierwsza edycja i 16-u Scrum Masterów nauczy się jak dobrze wykorzystać te narzędzia w ich pracy. Zapraszam!