Łukasz Kałużny: Niestety, mimo że prompt jest bardzo precyzyjny, prawie za każdym zapytaniem odpowiedzi różnią się merytorycznie. Te wszystkie Chaty GPT, Copiloty, to jest no go do takich eksperymentów, które mają się przerodzić w coś faktycznie przydatnego potem od strony biznesowej. I czemu? Bo nagle, tak jak w moich przypadkach, okazuje się, że w trakcie PoC-a dowiadujemy się, że API jest, ale tej części danych nigdy nikt nie chciał z API, więc nie wystawiamy z systemu. I potem jest krzyk o ten dług technologiczny i inne rzeczy. Więc trzeba to napisać tak syfiaście, do czego zaraz przejdziemy jeszcze, żeby nie dało się tego użyć jako pilota czy produkcję. Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Linki do tego odcinka góra, dół, prawo, lewo, ogarniecie, wierzymy w Was. Albo na Patoarchitekci.io i tak dalej. Dobrze, mój drogi, zaczynamy w takim razie. Co jest z rzeczy ważnych? Po pierwsze, najważniejsze, czyli konferencje mamy.

Łukasz Kałużny: Tak, 16 czerwca, Warszawa. Szczegóły sobie znajdziecie, będziemy zaraz odkrywać więcej kart. O czym będziemy tam mówić? Co będzie? Dwóch pierwszych prelegentów - Oskar Dudycz i Mariusz Gil.

Szymon Warda: Wszystkie szczegóły chyba najszybciej będą się pojawiały na Discordzie, tak że tam zapraszamy. Dobrze, kolejne rzeczy parafialne, czyli będzie szkolenia moje. Zaczynamy sobie Observability na stosie Grafany, to już mówiliśmy wiele razy. Fajne, odnowione, przepisane właściwie. Będziemy się bawili głównie Loki, Tempo, Prometheusz, który może nie jest od Grafany, ale praktycznie przyjęli to pod swoje skrzydła i śmiga ładnie. Głównie jeżeli chodzi o składnię, jak to wszystko połączyć z Alloyem, czyli Open Telemetry Collectorem, jak ładnie pospinać, czemu właściwie to robić i jak do tego podejść sensownie, gdzie z czego korzystać. I też taka zapowiedź jak w ogóle to ugryźć architektonicznie i co się będzie działo na kolejnych szkoleniach, że tak powiem, bo to jest taka cała seria.

Łukasz Kałużny: Czyli 3 spotkania po 4 godziny od 16 do 18 lutego.

Szymon Warda: Dokładnie, z samego rana, więc idealnie takie można powiedzieć. Dobrze Łukaszu, a co tam Ty masz?

Łukasz Kałużny: Dobra, to pierwsze szkolenie to 24 lutego był Kubernetes The Hard Way, a teraz będzie Agentic AI The Hard Way, czyli jak napisać agenta bez żadnego frameworka. I po co? Żeby do diabła zrozumieć, jak to pod spodem działa. Bo to jest taki cel pokazać na gołym kodzie i gołym SDK w jaki sposób tą pętlę agentową i to wszystko zbudować samemu.

Szymon Warda: Dobrze, a co dalej masz?

Łukasz Kałużny: Dalej? Kontynuacja trochę tego Agentica, czyli MCP Masterclass, czyli jak nie być developerem Atlassiana i Giry i jak nie napisać skopanego MCP, czyli jak projektować swoje serwery MCP, ale nie do zabawy lokalnie czy wypchnięcia tego na GitHuba, tylko jak to MCP realnie zbudować i udostępnić, żeby miało sens, było bezpieczne i dało się z tego korzystać w Twojej organizacji albo udostępnić jako ze swojego produktu dalej w świat.

Szymon Warda: Ja bym powiedział, że to jest taki bardziej prequel.

Łukasz Kałużny: To w zależności jak właśnie… Miałem z tym problem, która kolejność szkoleń, ale stwierdziłem, że to agent musi wykorzystywać MCP, więc piszemy najpierw agenta, bo w sumie potem już wykorzystanie będzie wiadome po tym…

Szymon Warda: Dobrze.

Łukasz Kałużny: Jak to MCP wykorzystać. Jeszcze szybkie dodatkowe ogłoszenie. Do Protopii, czyli firmy, którą prowadzimy z Szymonem i stoi za Patoarchitektami i stąd słyszycie o naszych doświadczeniach, szukamy AI inżyniera. Czyli osoby, która pomoże nam w budowie rozwiązań agentowych, LLM-owych w tych projektach, którymi Wam się chwalimy, dzielimy doświadczeniami czy narzekamy na jakieś technologie. I od takiej osoby oczekujemy, że będzie mieć dobry background programistyczny. Preferowany jest Python, ale zupełnie nie jesteśmy zamknięci na inne języki, więc jak nie masz doświadczenia w Pythonie, to akurat nie jest problem. Liczy się tutaj mindset. Nie musisz też mieć doświadczenia komercyjnego z LLM-ami, w tym miejscu nauczymy Cię. Jeżeli masz jakieś pytania odnośnie tego stanowiska, jak to wygląda, to napisz do mnie na LinkedInie na priv bądź na Discordzie. Szczegóły znajdziesz w ogłoszeniu. Ogłoszenie oczywiście tak jak wszystkie inne linki tutaj znajdziesz na stronie odcinka i pod spodem.

Szymon Warda: Jaki dzisiaj temat? Bo to taki trochę z Twojego marudkowania trochę wynikł, więc przedstawiaj go.

Łukasz Kałużny: Tak, jak przygotować się do PoC, PoV agentowych rozwiązań, czyli Proof of Concept, Proof of Value.

Szymon Warda: Dobrze, to w takim razie motywacja Łukaszu, bo marudkowanie marudkowaniem, co Cię zmotywowało, żeby jednak siąść i sclaude’ować to?

Łukasz Kałużny: Zdenerwowanie, tudzież określiłbym to innym wulgarnym słowem. W pewnym feedbacku, tak przyleciało do mnie, na przykład tekst od osoby nietechnicznej: tutaj zrobiłem prompta, zmodyfikowałem. I potem jest taki ten: niestety, mimo że prompt jest bardzo precyzyjny, prawie za każdym zapytaniem odpowiedzi różnią się merytorycznie.

Szymon Warda: O, smuteczek.

Łukasz Kałużny: Smuteczek, tak, plus cały bullshit z LinkedIna, gangi kodziaków, gangbangi kodziaków czy armie agentów.

Szymon Warda: Stajemy się coraz mniej przyjaźni dla przedszkolaków.

Łukasz Kałużny: Dobra, i teraz zaczynając może w ogóle od tego, to pierwsza rzecz, jak wpuszczamy biznes do tych rozwiązań AI-owych i jeżeli mają coś tam eksperymentować, robić, żeby też pomóc w ogóle odkryć kierunek, bo to też powiedzmy, że są te fazy discovery, te wszystkie Chaty GPT, Copiloty, to jest no go do takich eksperymentów, które mają się przerodzić w coś faktycznie przydatnego potem od strony biznesowej. I czemu? Bo mają swoją całą logikę w postaci System Promptu, można zobaczyć jak teraz jest ten w Chat GPT ten switching auto, jak robi instant vs thinking na przykład, jak jest trudniejszy problem i zaczyna research agentowy automatycznie, tego w rozwiązaniach i API biznesowych nie będziecie mieli.

Szymon Warda: Są limitacje dość poważne.

Łukasz Kałużny: Tak, i tutaj będziemy potrzebowali kontroli nad całym flow. I jedna rzecz od razu, którą tak powiem, to wpuszczamy do tych playgroundów, które są, może Microsoft Foundry ma swój playground, OpenAI ma swój playground, czyli żeby korzystali na gołym API z gołego playground do takiego researchu na początku.

Szymon Warda: Dobra, tak żeby trochę to ułożyć generalnie. Czyli pierwsze to jest w ogóle zarządzanie oczekiwaniami. I mówimy sobie to, co w ogóle możemy zrobić. Pierwsza faza, czyli co, oceniamy co, jak, gdzie, eksperymenty robimy na realnych systemach, tych, które będą korzystały z API, a nie mówimy sobie, że teraz przeniesiemy wszystkie prompty, które mieliście, z Chata nagle na system wewnętrzny.

Łukasz Kałużny: To nie zadziała.

Szymon Warda: Tak, dokładnie.

Łukasz Kałużny: Raczej będzie mordęgą.

Szymon Warda: Kolejna rzecz to jest po prostu opisujemy, też zbieramy rzeczy, gdzie realnie możemy tego użyć, bo mówimy tutaj o agentach, czyli tam, gdzie nasz ten cały system, nazwijmy to AI-owy, może coś zrobić, a nie tylko odpowiedzieć na pytanie. Czyli szukamy flow biznesowego.

Łukasz Kałużny: Zastosowania, tak, ja bym to słuchaj zrobił, to w jaki sposób do tego podchodzę, to jest, że osoba, która w ogóle wykonuje tą pracę, to ona siada do Worda, dosłownie i spisuje krok po kroku co ona robi, jak wygląda ten proces, który chcemy zautomatyzować, jak on wygląda nie w rozumieniu jakiegoś managera, przepraszam za to, ale osoby końcowej, jak ona wykonuje ten proces krok po kroku, z jakiego systemu korzysta, do jakich ekranów wchodzi, gdzie jest ta praca manualna, bo może jest gdzieś copy/paste pomiędzy systemami, tak zwane ten transfer danych interfejsem białkowym pomiędzy systemami. Może jest gdzieś odpisanie na maila, gdzieś są decyzje. Czyli taki przykład: odpisuję na maila, przerzucam dane, robię to, to, to w tych systemach, na tych ekranach, stąd biorę dane. Czyli tak naprawdę zamapowanie tej wiedzy plemiennej na rzeczywistość.

Szymon Warda: Czyli realnie spisuje to operator, nazwijmy to, czyli osoba, która wcześniej to zadanie wykonywała, którą chcemy część odciążyć. Bo to jest bardzo ważne i też uświadomienie tego, że my część rzeczy odciążymy, ale tam dalej będzie człowiek, a szczególnie na wczesnych fazach.

Łukasz Kałużny: Tak i teraz można byłoby to zrobić, jeżeli bylibyśmy prawidłowi by the book powiedzieć sobie, że liczymy teraz, mamy wsad do liczenia kasy, liczymy ile czasu to zajmuje, jakie jest oczekiwane ROI i inne takie rzeczy. Realność przypadków pokazuje, że aktualnie tego, mimo, że proponujemy to, to nie robimy tego, o tak.

Szymon Warda: Kupujemy marzeniami.

Łukasz Kałużny: Kupujemy, tak, kupujemy. Ale teraz zobaczcie, na bazie tego powyżej mamy tak naprawdę dane wejściowe, czyli coś, co pozwoli nam dowiedzieć się, skąd użytkownik bierze dane i rozpoznać systemy. Dowiedzieć się, czy mamy API, jakąś bazę danych, czy to jest manualny input. Mamy następną rzecz w takim mapowaniu tego procesu - akcje wyjściowe, czyli co ma stać się na końcu oraz, co jest najbardziej kluczowe, ten human in the loop, czyli te punkty decyzyjne. Czyli to nam pozwala zobaczyć, jak wygląda cały proces. To jest istotny kawałek tego, co chcemy uzyskać potem.

Szymon Warda: Czyli mamy też flow, który musimy zaprogramować i wesprzeć go i zobaczyć, co będzie się działo, czyli cały input, jeżeli chodzi o w ogóle zakres całego projektu.

Łukasz Kałużny: Dokładnie. No dobra, i pora na krok drugi.

Szymon Warda: Ja bym tu, jeszcze jednej rzeczy mi brakowało. Ja bym jeszcze dorzucił jedną prostą rzecz - weryfikacja, czy my do tych systemów w ogóle możemy się dostać z poziomu API. Bo czasami jest, że mamy flow i te systemy wystawiają tylko i wyłącznie, powiedzmy interfejs, dlatego tam jest białkowy, i się do nich po prostu nie dostaniemy. Czyli określenie w ogóle dojrzałości tego systemu i jak możemy się do nich wpiąć.

Łukasz Kałużny: Tak, czy możemy się wpiąć do bazy danych. Zresztą to jest takie clue, które też tak, to tutaj w tym. Czyli jak możemy uzyskać dostęp? To jest taka weryfikacja tego, czy w ogóle możemy. Bo nagle, tak jak w moich przypadkach, okazuje się, że w trakcie PoC-a dowiadujemy się, że API jest, ale tej części danych nigdy nikt nie chciał z API, więc nie wystawiamy z systemu.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Inaczej, w Enterprise wystawimy to za pół roku może przy okazji następnego release’u.

Szymon Warda: Dokładnie, który jeszcze jest nieokreślony. Dobrze, czyli mamy powiedziane co właściwie robimy, jak to chcemy zrobić, z czym się łączymy. Co dalej?

Łukasz Kałużny: Dobra, projektujemy scope i granice PoC. Bo teraz to jest problem, że okej, wiemy jak wygląda cały proces, ale tak naprawdę trzeba wyznaczyć tak naprawdę co w PoC-ach albo w Proof of Value jest najbardziej krytyczne. Czyli trzeba sprawdzić te ścieżki krytyczne, których nie jesteśmy pewni, problematyczne. Czyli to jest, ładnie było określenie, to jest studium wykonalności czy w ogóle, czyli sprawdzić wszystkie fuck upy, które mogą się zdarzyć, że to się zawali nam.

Szymon Warda: To ja to wytłumaczę w inny sposób. Wpierw mieliśmy, co byśmy chcieli zrobić, a teraz określamy, co realnie zrobimy. Bo pamiętajmy, że jest to PoC, czyli udowadniamy, że technologia i podejście może działać. Więc nie wszystko co byśmy chcieli realnie zrobimy, bo to się nazywa już pełnowymiarowy produkt.

Łukasz Kałużny: Tak, więc trzeba sobie odpowiedzieć, określić granice automatyzacji przed rozpoczęciem. Co będzie w tym procesie agent robił sam? Gdzie musi być human in the loop? Gdzie agent coś na przykład zaproponuje, przygotuje, a człowiek wykona? I to trzeba wiedzieć przed. I teraz ważne, patrzymy sobie, że nie będziemy mieli tam, do tego dojdziemy potem, ale że tam nie ma być ładnego UI-a i innych rzeczy, tylko my sprawdzamy, tak jak powiedziałeś, czy to w ogóle będzie miało sens i czy uda nam się osiągnąć coś, co nas zadowoli. No i chyba pora na tym płynnie przechodząc na kryteria sukcesu.

Szymon Warda: Które są ciekawe. Określenie ich jest z reguły ciekawe, bo jak już jesteśmy w tym momencie, to już sporo organizacji chce, żeby się jednak udało.

Łukasz Kałużny: Tak i trzeba sobie powiedzieć z tym, jeżeli PoC zadziała, to trzeba powiedzieć sobie o dokładności. To jest chyba w ogóle największy przypadek i tą dokładność można na przykład: minimum 8 na 10 przypadków jest obsłużonych poprawnie.

Szymon Warda: Dewiza poprawnie jest też bardzo rozmyta. Ja tak wrzucam i wtedy można dorzuci dość ważnych, że to nie wyjdzie w formie Excela, nie zrobimy sobie tabelki, nie powiemy, że taka nam wyszła. To jednak jest przejście przez to jak ten PoC działał i czy odpowiedź albo akcje, które on wykonał, uznajemy za poprawne, uznajemy za akceptowalne. Czyli czy jeżeli by coś takiego zrobił człowiek, to byśmy stwierdzili, że jest ok?

Łukasz Kałużny: Tak. I teraz jest taka rzecz, że pamiętajmy, że w PoC-u nie obsłużymy wszystkiego i tam też mogą być lesson learn na pilota produkcje. Czyli możemy już teraz zastanowić się, jaki mógłby być pomysł na fall back, failure modes, czyli jak już zaprojektować sobie na przyszłość, co można byłoby zrobić, żeby poprawić. Ale sorry, nie testujemy tego, nie implementujemy w większości przypadków.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Bo to są wnioski z PoC-a, w tym, wnioski z PoC-a, a nie implementacja, bo mamy takie… To, czego nienawidzę u nas, w naszej branży to to, że PoC ma nagle stawać się, wszyscy piszą PoC-e i robią PoC-e tak, że zaraz staje się produkcją. I potem jest krzyk o ten dług technologiczny i inne rzeczy. Więc trzeba to napisać tak syfiaście, do czego zaraz przejdziemy jeszcze, żeby nie dało się tego użyć jako pilota czy produkcję.

Szymon Warda: Który będzie źródłem wniosków, niekoniecznie będzie bazą kodu do dalszego rozwoju, może tak to nazwijmy.

Łukasz Kałużny: Tak. To co, budujemy PoC-a? Dobra, to tutaj będzie tak. Jedna rzecz, którą Ci pewnie zaskarbiło Twoje, wrzucamy tam, przy PoC-u logów nigdy nie za dużo, żeby można było łatwo. W przypadku agentówki szczególnie te logi będą spuchnięte i tyle.

Szymon Warda: Tym bardziej, że większość tych systemów do agentów, mamy to prawie z pudełka praktycznie można powiedzieć w wielu sytuacjach, więc koszt dodania logów jest minimalny.

Łukasz Kałużny: Tak i teraz załóżmy sobie brzydki workflow, brzydka automatyzacja, brzydki hot, brzydki UI, to wszystko jest ok, bo skupiamy się na tym celu, co my sobie wyznaczyliśmy.

Szymon Warda: Ja bym jeszcze jedną rzecz dorzucił właśnie odnośnie UI-a. UI zawsze powoduje najwięcej dyskusji, najwięcej skupienia i najciężej jest ludziom pogodzić się z tym, że on nie jest ładny. Więc im więcej możemy zrobić bez UI-a, tym w sumie lepiej dla mnie.

Łukasz Kałużny: Tak, ja dam Wam przykład z jednego z dwóch ostatnich PoC-ów takich właśnie wykonywanych dla klientów jak to wygląda. To udostępnialiśmy, w jednym udostępnialiśmy Excela z przypadkami. Czyli tam było dosłownie Excel, jaką agent podjął decyzję, co zaproponował, jaki był reasoning i dlaczego plus tam linki do źródeł i innych takich rzeczy. Czyli był dosłownie Excel do oceny.

Szymon Warda: Idealne.

Łukasz Kałużny: Tak. Nie ma żadnego UI-a. Drugi, to żeby skończyć, to z agenta tak naprawdę generowaliśmy, z efektu wygenerowaliśmy markdown, który został wysłany jako PDF-y, czyli ileś przypadków testowych, które zostały zapisane do PDF-a i przekazane: oceńcie jakość wyników.

Szymon Warda: Znaczy ten krok jeszcze ma…

Łukasz Kałużny: Na przykład propozycje maila przykładowo.

Szymon Warda: Ten krok jeszcze ma jeden bardzo poważny plus, mianowicie ucina konieczność ilości integracji z tym, co klient ma u siebie. Czyli mniej deploymentu, mniej zabawy, mniej security jeżeli chodzi o to, co tam będzie stworzone. Batche są zawsze łatwiejsze.

Łukasz Kałużny: Tak, czyli ta wsadówka jest naprawdę pomaga. Więc czy inna rzecz, którą trzeba na przykład przy tych rzeczach trochę bardziej RAG-owych Szymon, gdzie jednak jest ten chat interface, to ma być on brzydki… Inaczej, nie ma być dopieszczony, najlepiej, żeby był brzydki, żeby nie dawał wrażenia produkcyjnego, nie miał uprawnień. Panel administracyjny, jakiś dashboard, nie, nie potrzebujecie tego. Dokumenty można ładować z kawałka narzędzia command line’owego i to też będzie zajebiste. Mimo, że prompting kusi, żeby zrobić to super ładnie, to miałem ostatnio rozmowę z klientem, nawet już rozumiał, że porzucamy, że na przykład robimy ładowanie danych, że wrzucimy go na Bloba, czy będzie CLI i jest okej. Testujemy jakość odpowiedzi, a nie podejście.

Szymon Warda: Dobrze, to śmigamy dalej w takim razie. Zrobiliśmy, działa, wystawione, brzydkie, bo brzydkie. Co dalej?

Łukasz Kałużny: Wiesz co, dwie rzeczy, jeszcze w trakcie tego to są testy i to jest bardziej cały development z naszej strony. Trzeba niestety wprowadzać małe zmiany i iteracyjnie je testować i patrzeć, czy w ogóle miało to wpływ. Tak powinno się robić na PoC-ach i pamiętać, że nie wprowadzamy, bo mi się też zdarza zrobić w tym, w pewnym momencie, prompty agentów dojechały do wersji v20 i zostałem zapędzony tak, że trzeba było to przepisać, bo nie miało to sensu już w pewnym momencie. Więc małe iteracyjne w pewnym momencie i zbierajcie wyniki z tego, co robicie, bo często gęsto jest to robione na czuja, więc warto takie coś uruchomić. Ja na przykład tam miałem próbkę przy tym, o którym przypadku jednym teraz mam na myśli, który mówiłem, tam miałem chyba próbkę pięćdziesięciu case’ów do testowania za każdym razem.

Szymon Warda: Okej, jedna rzecz odnośnie iteracji, jasne określenie granic, czego nie obsługujemy. Ponownie wracamy, bo łatwo ugotować żabę.

Łukasz Kałużny: Dobra, jak wygląda, że coś jest wystarczająco dobre, to warto zdokumentować, zostawić ślad pod… Błędów i edge case’ów wszystkich takich w trakcie powinno być, w trakcie testów powinniśmy sobie gdzieś to spisywać. Naprawdę to są bullety, ale jakieś właśnie wszystkie fuck upy i inne rzeczy. W szczególności, ja bym powiedział, że to są halucynacje i nie trzymanie się flow. To są takie rzeczy, o których trzeba pamiętać i widzieć. Na przykład teraz, mimo wniosków z PoC-a, nadal walczę w jednym miejscu teraz produkcyjnym z halucynacjami, bo nadal się gdzieś pojawiają, a ponoć nie powinny.

Szymon Warda: Ja bym jeszcze powiedział, że to się pojawia też tak naprawdę to jaką jakość danych te systemy udostępniają, że też wykryjemy ograniczenia tego, co agent dostanie i co agent w ogóle może zrobić. To czasami wychodzi na starcie, w tej fazie analizy, ale też bardzo często wychodzi w trakcie realnego działania i na realnych przypadkach, że no sorry, ale coś tu musimy zmienić. Czyli nam się tak naprawdę poza PoC-em nam się tworzą ograniczenia, ale też możliwości rozwojowe dalsze nie po stronie systemu agentowego, tylko systemów docelowych, systemów źródłowych.

Łukasz Kałużny: Dobra i teraz analiza i decyzja. I to jest kurde największa rzecz, bo trzeba sobie odpowiedzieć, czy jak popatrzymy, bo mamy sobie takie trzy decyzje, które możemy podjąć. Pierwsza, której wszyscy nienawidzą, czyli zabijamy PoC-a. Czyli operacja się udała, pacjent zmarł. I to jest też sukces PoC-a, dowiedliśmy, że się nie da. To jest, bo to jest, biznesowo to jest porażka. A po to robimy PoC, żeby nie wtopić dalej.

Szymon Warda: Ja bym powiedział inaczej.

Łukasz Kałużny: Za wszelką cenę.

Szymon Warda: Nie tyle się nie da, bo dać to powinien się zawsze da. Nie ma sensu biznesowo, albo nie jesteśmy na to jeszcze gotowi. Czyli mamy zbyt dużo roboty do wykonania na przykład z naszymi obecnymi systemami, z porządkami i tak dalej, żeby to ruszać teraz.

Łukasz Kałużny: Dobra, potem jest opcja najgorsza, czyli robimy kolejną iterację PoC-a.

Szymon Warda: Czemu?

Łukasz Kałużny: No właśnie, bo niektórzy chcieliby uzyskać i to jest taka rzecz, którą sobie trzeba wytłumaczyć, to jest ten cały problem, który jest razem z kill, czyli zazwyczaj zaczynamy iterować PoC z tego powodu, że w teorii zainwestowaliśmy już za dużo, żeby się wycofać.

Szymon Warda: Albo bardzo chcemy, żeby się udało.

Łukasz Kałużny: Albo chcemy, żeby się udało. I teraz trzeba sobie zobaczyć, czy w ogóle jest jedna rzecz, czy jest tam potencjał i tak naprawdę, co my chcemy poprawić i czy jest na to potencjał w ogóle do poprawy.

Szymon Warda: Znaczy wiesz, to czasami zmienia się też taka opcja generalnie, tu nam się nie sprawdziło, spróbujmy w innym systemie też. Jeżeli to jest po prostu (…) kontekstu, to jest to dobra opcja. I że to jest wyciąganie na siłę, że może jednak dopniemy coś kolanem, to już to jest ta zła opcja, żebyśmy też rozdzielili.

Łukasz Kałużny: Tak i to jest jedna rzecz. A ta pozytywna decyzja, która się zdarza, musi swoje odleżeć, to jest scale, czyli lecimy i robimy już z tego, zaczynamy implementować już coś faktycznego, faktyczny case.

Szymon Warda: Dobra, to jak wdrożenie, jak to wygląda?

Łukasz Kałużny: Czy wiesz co i teraz tak. Faza, jeżeli to pójdzie, to tak naprawdę to już jest taka rzecz, która mogłaby być oddzielnym odcinkiem, ale żeby też wyciągnąć, że udało nam się, to tak naprawdę to jest zwykły projekt software’owy. Jeżeli na to popatrzysz, to jest zwykły projekt software’owy, z tą różnicą, że musimy wiedzieć, że używamy niedeterministycznego klocka w deterministycznym świecie. Czyli to jest powiedzenie sobie elementy, gdzie jest człowiek albo fall back do człowieka i to jest chyba taka najważniejsza rzecz, która będzie. A druga rzecz, to monitoring tego success rate, monitoring sukcesu, dokładności. To będzie w ogóle taka rzecz, która będzie najbardziej istotna w całości.

Szymon Warda: Ja bym nie do końca nazywał to normalnym projektem IT, bo większość projektów IT mówimy o systemach i tak dalej, które wdrażamy, to one mają bardzo ograniczony zakres z kim mamy interakcję. Systemy agentowe mają to do siebie, że one z reguły dotykają wielu źródeł. Trzeba się z większą ilością organizacji tudzież stakeholderów dogadać, dorwać uprawnienia i to szczególnie załóżmy na przykład te działy data tam są często zaangażowane, to jest jeden obszar. Czyli mamy trochę, jak ta ośmiornica się rozchodzimy w poprzek. A druga rzecz, to jest tak, to jest trochę to, co mówiłeś wcześniej, to jest to, żeby też dotykamy elementu ludzkiego. Tutaj też te procesy, które wchodzą i też procesy, które zmieniamy, ludzkie, też będą dotykane, więc iterowanie razem z biznesem też jest dość ważne.

Łukasz Kałużny: Tak, ale to wiesz, to jest też, dlatego mówię, że… Inaczej Szymon, tylko z drugiej strony, który projekt, do diabła, się z tym nie spotyka tak realnie? Jeżeli masz w tym…

Szymon Warda: Oj zdziwiłbyś się, tych software’owych takich… Budujemy, wdrażamy jakiś system, tego trochę jest, takich, które po prostu zamykają się w piwnicy i jednak tam są odseparowane od tego bardzo mocno.

Łukasz Kałużny: A weź swojego dużego ten, jak podchodzisz, kawałki na przykład RP-ów. Pamiętasz ile tam było człowieka.

Szymon Warda: Tak, tylko że RPy to już teraz są SAP-y generalnie, a SAP-ów nie wdrażamy.

Łukasz Kałużny: Nie, dobra. Ale na poważnie to tak, to jest taka rzecz w tym, jedna, z którą ja się spotykam, teraz patrząc się o tym jak mówimy teraz, na przykład siedząc przy takim wdrożeniu, to jest przypomnienie o założeniach. Bo nagle się okazuje, że zaczynamy już testy nie POC, tylko testy tego, co ma zostać wdrożone. I teraz zbieram feedback po tym, zbieram, mam gdzieś spisane wymagania, mam feedback po tym, po PoC-u, ale to nie tak miało działać.

Szymon Warda: Znaczy Łukasz to jest to, co mówiliśmy chyba odnośnie każdego projektu. To też musi być jakiś marketing wewnętrzny, musi być umocowanie i musi być jasna komunikacja co właściwie tym możemy zrobić. Bo jak będzie hasło: wdrożyliśmy AI-a, to zbiór oczekiwań co on miał robić, osób, które nie były w projekcie, a zbiór tego, co miało być, są różne.

Łukasz Kałużny: Nie, ja mówię o osobach, które są w projekcie. Ja mówię o osobach, które są w projekcie, które uczestniczyły w tym od początku.

Szymon Warda: Ty też widziałeś, że tam fantazja płynie, wszystkie filmy science fiction się nagle włączają i jednak oczekiwania są wyższe niż to, co było ustalone. Jest nadzieja, że jednak nasze problemy rozwiąże, jak każdy projekt. Te akurat może trochę bardziej niż inne.

Łukasz Kałużny: Tak, więc podsumowując sobie chyba całość, to sprawdzenie, czy… Inaczej przed startem w ogóle, czy będziemy rozwiązywać realny problem, to jest chyba w ogóle must have, bo miałem teraz ten: Łukasz, a czy możemy z tego, to jest teraz dosłowny tekst, który miałem gdzieś na początku grudnia: Łukasz, a czy przy okazji tego możemy zrobić coś takiego, zespół developerski, bo nasz manager ma w celach wpisane, że musimy użyć czegoś agentowego. W sumie nic nie ma w naszej domenie sensu, ale zrobimy coś, żeby było chatem, gdzie mogłoby być formularzem.

Szymon Warda: Formularz sprawdzi się lepiej.

Łukasz Kałużny: Oczywiście, ale był w celach, więc to jest taka rzecz. Więc trzeba sobie, to jest taka weryfikacja całościowo, czy to będzie, faktycznie rozwiąże nasz problem. I chyba największa umiejętność to będzie powiedzenie sobie nie albo nie teraz.

Szymon Warda: Albo nie od tego.

Łukasz Kałużny: Tak, w tym, albo tak, ale. To jest w ogóle już w tym, bo wszyscy słyszą część tak i to jest to. Będzie masakryczne jak niedosłyszą reszty. Największa rzecz to jest problem, który będziecie mieli z tym wszystkim w moim, to jest jak wpleść human in the loop? To jest taka moja perspektywa w te procesy agentowe. Jeżeli robimy proces biznesowy, w którym miejscu je automatyzujemy, w którym miejscu wrzucimy człowieka, żeby nie rozbić się ze ścianą już od razu.

Szymon Warda: I uświadomić, że to jest w porządku, bo dalej część tych projektów prowadzi do tego, że po to wdrażamy AI-a, żeby człowieka w ogóle nie było, a to nie, to mamy odciążyć. To jest narzędzie, które ma pomagać.

Łukasz Kałużny: Z takich, ja teraz wezmę, przytoczę maila, ale jest na podstawie czegoś tam. Powiedzmy jest sobie skomplikowany proces biznesowy i na końcu człowiek dostaje w jakiejś formie, najlepiej właśnie nie chata, tylko jakiegoś formatki, podsumowania, jakie są rekomendacje przykładowo odnośnie tego procesu. I w tym co myślę tutaj było akurat, że klient wysyła jakiś wniosek do firmy i agent robi sobie research, mówi o wszystkim i przygotowuje też na przykład propozycję odpowiedzi, bo powiedzmy, że to jest proces, który weryfikuje, czy klient poprawnie wypełnił i czy ma do tego prawo i inne rzeczy, wniosek zgodnie z umową. I agent na przykład proponuje odpowiedź maila, co klient ma uzupełnić.

Szymon Warda: I słusznie.

Łukasz Kałużny: I wtedy na przykład, że to nie da się, nie robimy tego automatem, ale odciążamy człowieka, że przeprowadza tę weryfikację, mówił, co sprawdził i to też będzie taka rzecz UX-owa, wredna, bo trzeba to użytkownikowi tak pokazać, żeby wiedział tak naprawdę, jeżeli zna się na tym procesie, żeby wiedział czy agent na przykład sprawdził wszystko co powinien.

Szymon Warda: Znaczy jest jedna rzecz.

Łukasz Kałużny: I czy są wszystkie rzeczy wzięte pod uwagę.

Szymon Warda: To, co nawet też widzimy, że większość organizacji i tak nie jest przygotowana i nie jest okej z tym, żeby mieć w pełni agentowy system bez człowieka w pętli. Zacznie się panika, co tam się w ogóle wydarzyło?

Łukasz Kałużny: Słuchaj, jeszcze nie poruszyliśmy w ogóle kontekstu prawnego, bo to jest już w ogóle temat rzeka, jak on wygląda.

Szymon Warda: Inny.

Łukasz Kałużny: Tak, to jest temat rzeka i może to zostawmy nawet…

Szymon Warda: Ale nie teraz, nie ten odcinek.

Łukasz Kałużny: Nie teraz zostawmy, bo co organizacja, co kancelaria, która doradza, interpretacje są różne.

Szymon Warda: Dobra, kończymy.

Łukasz Kałużny: Kończymy. Na razie.

Szymon Warda: Na razie.