Automatyzacja z AI w e‑commerce: Kiedy ma sens i jak uniknąć pułapek?

Cześć. W dzisiejszym odcinku Manufaktury E‑commerce chciałem poruszyć temat związany z automatyzacjami z wykorzystaniem AI w e‑commerce, czyli tematem, który wraca do nas dość często wśród klientów. Jest związany z tym, że no zwyczajnie klienci po prostu skoro widzą ten wszechogarniający hype na na AI, no to zastanawiają się, czy po prostu sami własnymi siłami nie mogą doprowadzić do tego, żeby różne procesy czy różne rozwiązania, które pomysły, które mają w głowie, czy nie mogą tego po prostu sami urealnić i najzwyczajniej w świecie zrealizować sobie rozwiązania, które, o które do tej pory musieli prosić specjalistów.

No i dzisiaj jako osoba po tej drugiej stronie, która zajmuje się wytwarzaniem tego typu rozwiązań oraz konsultuje klientów i inne osoby w kontekście właśnie wykorzystania tej czy to sztucznej inteligencji, czy to rozwiązań e-commerceowych do budowania przewagi konkurencyjnej i do generalnie realizowania strategii sprzedaży, no to po prostu na podstawie tej wiedzy postaram się tutaj nakreślić trochę ten kontekst i pokazać, czy faktycznie korzystanie z AI ma sens. Jeśli ma, to kiedy, jeśli nie, to dlaczego i co z tym w praktyce można zrobić.

LLM jako średniozaawansowany programista

Pierwsza sprawa, która jest bardzo ważna, to taka, że jak myślimy o LLM-ach, bo o nich będziemy dzisiaj mówić, bo jakby tutaj już, żeby być też precyzyjnym, generalnie sztuczna inteligencja to nie są tylko te rozwiązania, o których teraz słyszymy na co dzień typu Chat GPT, typu typu te sieci właśnie LLM, tak zwane Large Language Models. To jest cały szereg różnych innych rozwiązań związanych z obszarem uczenia maszynowego czy jakiegoś rozumowania logicznego. Tych rzeczy dzisiaj nie będę poruszał, no bo tym najbardziej hypowym obecnie tematem są LLM-y, czyli te rozwiązania, które są obecnie dostępne i które pozwalają nam zarówno wspomagać nas w researchu, wspomagać nas jakby w rozwiązywaniu różnego rodzaju rzeczy, również wspomagają nas w tworzeniu kodu, tak? I tu nie ma co się czarować. Wykorzystanie czy pojawienie się tych rozwiązań typu Claude Code, Codex, Cursor i innych, no bez wątpienia sprawiły, że ten dostęp do kodu jest dużo łatwiejszy niż kiedykolwiek, czyli nastąpiła taka demokratyzacja trochę tego kodu. Więc nie dziwne, że pierwsze co przychodzi do głowy osobom, które prowadzą e‑commerce czy prowadzą swoje firmy, no to czy nie da się tego wykorzystać do tego, żeby zastąpić jeden z większych kosztów w rozwoju firmy ostatnich lat, czyli oprogramowanie.

I jeśli spojrzymy na to w ten sposób, to przede wszystkim dobrym pomysłem jest myślenie o takim LLM-ie jako takim programiście ze średnim poziomem doświadczenia, tak bym powiedział. Czyli jest co do zasady, jest to narzędzie, które faktycznie wytwarza nam kod całkiem dobrej jakości, jeśli zostanie dobrze pokierowane, ale o tym zaraz powiemy. Natomiast no wciąż to jest wciąż to jest ten poziom Junior Mid, tak? Czyli poziom taki, gdzie my musimy poinstruować jednak ten model, jak on pewne rozwiązania ma realizować, nadać mu kontekst, w szczególności kontekst biznesowy, żeby on po prostu wiedział co ma wytworzyć. Bo pamiętajmy, że te modele uczyły się na pewnych dużych zbiorach danych, no ale głównie opierając się, szczególnie te wytwarzające kod, na kodzie. W związku z tym te rozwiązania techniczne, architektoniczne są rzeczami, które LLM-y potrafią rozwiązywać całkiem dobrze. Natomiast w kontekście biznesowym one też są w stanie nam pomóc, tylko żeby rozwiązywać te procesy, te problemy biznesowe, no to na koniec dnia my musimy im nadać pewien kontekst, no bo to są najczęściej LLM-y są takie narzędziami takiego ogólnego przeznaczenia, więc musimy je trochę ukierunkować na potrzeby naszego biznesu, żeby one w sposób świadomy realizowały te rzeczy, a nie w taki generyczny, który nam na pewno na koniec dnia nie pomoże. Także to na pewno trzeba mieć na względzie. Bardzo dobra analogia to jest właśnie myślenie o LLM-ie w kategoriach tego, że jest to jakiś programista o średnim jakimś tam poziomie zaawansowania.

I jak będziemy mieli to pod weźmiemy to pod uwagę, no to wydawanie poleceń takiemu LLM-owi będzie dużo prostsze. No bo po prostu pomyślimy sobie, że przed nami siedzi jakiś programista, któremu musimy przekazać tę wiedzę. I to co jest ważne, to nie jest programista, który rozumie twój biznes. To jest super ważne, czyli to jest ten typ programisty, o którym często słyszę od klientów, że że oni zlecają mu coś do realizacji, no i on tak ślepo realizuje to co oni mówią, zapominając o tych różnych rzeczach dookoła tego o zapominając o tym kontekście biznesowym, który gdzieś tam krąży i my my jako właściciele, my oczywiście wiemy jak to wszystko funkcjonuje, po prostu w tym siedzimy i przez to paradoksalnie zapominamy bardzo często o tym, żeby przekazać komuś te informacje. Więc efekt na koniec dnia jest taki, że ten biedny LLM tworzy coś w ograniczonym kontekście, no bo po prostu nie rozumie twojego biznesu, no i na koniec dnia to rozwiązanie jest takie, że trzeba go później poprawiać.

Rola konsultanta i specyfikacji

I to prowadzi do tego drugiego wniosku, który bym wysnuł na bazie tego na bazie tej całej historii z LLM-ami. Pierwszy, traktujmy tego LLM-a jako takiego właśnie mida, takiego po prostu średnio rozgarniętego programistę, o tak powiedzmy, żeby było kulturalnie. To prowadzi z kolei do drugiego wniosku, to znaczy, że powinniśmy najlepiej tak by było, żeby mieć osobę, która jest takim specjalistą, konsultantem, osobą, która rozumie zarówno tą część biznesową jak i technologiczną, czyli działa na styku biznesu i technologii. Bo taka osoba z kolei będzie w stanie świadomie instruować tego tego LLM-a, rozumiejąc twój twój kontekst biznesowy, rozumiejąc jak łączyć biznes z technologią, gdzie są te punkty styku.

Dlaczego to jest ważne? Zazwyczaj jak posłuchacie osób, które jakby działają z z tymi LLM-ami, czyli z rozwiązaniami AI, to usłyszycie, że właśnie musicie instruować tego tego LLM-a, podać mu dobry kontekst, dobrze opisać, wyspecyfikować to co chcecie osiągnąć i przekazać mu tę wiedzę biznesową. I to jest prawda, bo to faktycznie jest rzecz, którą będziecie musieli wykonać i to jest coś, co zresztą zaraz przejdziemy do kolejnego tego kroku i sobie to troszeczkę pogłębimy, ale to jest coś co faktycznie realnie trzeba wykonać. To jest taka taki wkład pracy, który LLM tego za was nie załatwi. Czyli może o ile wcześniej jako programista trzeba było ten kod pisać, o tyle w dzisiejszych czasach przy LLM-ach programiści raczej są teraz, a raczej powinni być, powinni być takimi osobami, które opisują dość precyzyjnie to co ma wytworzyć LLM, łącząc aspekty biznesowe i aspekty techniczne. Czyli to jest tak zwane podejście Spec-Driven Development, czyli wytwarzanie zorientowane na specyfikację. Czyli to, czego większość programistów nie lubi, staje się standardem branżowym.

Tak naprawdę większość programistów woli siedzieć w kodzie i programować, tak, tworzyć, wytwarzać ten kod. Natomiast praktyka z LLM-ami jest zupełnie inna, to znaczy my powinniśmy teraz być takimi analitykami, którzy którzy analizują biznes klienta, analizują jakiś proces biznesowy, który chcielibyśmy zautomatyzować poprzez oprogramowanie, poprzez AI i powinni opisywać ten proces, przekładając te rzeczy biznesowe na rzeczy techniczne. No, smutna sprawa dla programistów, ale za to bardzo wesoła dla Product Ownerów czy dla właścicieli biznesu, no bo właśnie to oni musieli robić wcześniej, przekazując na przykład software house'om jakiś tam brief czy specyfikację tego co chcą osiągnąć. To oczywiście nie oznacza, że biznes tego ma nie robić i nie będzie tego robił. On będzie to robił cały czas, tylko teraz jest to po prostu łatwiejsze do przetransformowania w kod.

Więc to jest bardzo bardzo dobra informacja. No ale na koniec dnia oznacza to, że o ile biznes jest w stanie zbudować tę część specyfikacji biznesową bardzo dobrze, o tyle brakuje tutaj tego takiego punktu styku między biznesem i technologią, żeby dospecyfikować te rzeczy, które chce osiągnąć klient, tak żeby już LLM nie miał wątpliwości co do tego jak ma rzeczy realizować. W architekturze oprogramowania to się nazywa no właśnie architekturą, czyli w zasadzie w wytwarzaniu oprogramowania mówimy o architekturze oprogramowania, czyli o takich podstawowych zasadach, regułach, które muszą zostać spełnione w danym w danym oprogramowaniu, w danym systemie, żeby on realizował cele techniczne i biznesowe, tak żeby spełniał swoje no żeby wnieść po prostu wymierną korzyść drugiej stronie. Także zalecam, warto jest skorzystać, szczególnie na początku tej naszej drogi, jak w organizacji chcemy wytwarzać ten te rozwiązania AI, bo nie mówię tu zarówno o produktach, jak i o umieszczaniu, integrowaniu się tak naprawdę istniejących systemów z AI. Warto na początku skorzystać z takich konsultacji, nawet kilku, kilku, kilkunastogodzinnych konsultacji z taką osobą, żeby ona dospecyfikowała te wasze założenia biznesowe i żeby też was nauczyła tego, jak dokładać tego typu elementy, żeby później już po prostu w organizacji móc rozwijać się i pisać specyfikacje w taki sposób, żeby już nie był ten konsultant potrzebny, ale zarazem, żeby ten LLM rozumiał co ma wytworzyć. Więc warto z tego konsultanta skorzystać.

No i kolejna rzecz, czyli docieramy do tego trzeciego elementu, o którym mówiłem, czyli specyfikowania. Z waszego punktu widzenia ważne jest to, żeby opisywać jeszcze bardziej precyzyjnie niż wcześniej rzeczy, które chcecie osiągnąć pod kątem biznesowym. Bardzo fajnie by było, gdyby ten opis waszych wymagań biznesowych, ta specyfikacja, była ustrukturyzowana, czyli opisywała te procesy w jakichś sekwencjach, żeby te procesy były nie wiem na diagramie, żeby po prostu ubrać to w jakąś strukturę, bo im lepsza będzie struktura tej waszej specyfikacji, tym większa szansa na to, że LLM nie będzie się mylił i nie będzie robił pewnych rzeczy po swojemu. Także to jest bardzo ważna rzecz, czy tworzycie produkt z AI, czy tworzycie własne systemy do zastosowania wewnętrznego, tego typu dokumentację warto pisać, no i przede wszystkim w dzisiejszych czasach to powinien być właśnie ten wsad na wejściu dla LLM-a do wytworzenia oprogramowania. Także jeszcze bardziej istotne jest to niż wcześniej, żeby pisać takie specyfikacje. Te specyfikacje na koniec dnia wytworzą nam też dokumentację oprogramowania, także możemy jednocześnie tworząc produkt, możemy jednocześnie doprowadzić do tego, żeby tworzyła się równolegle dokumentacja podstawowa do tego produktu, do czego zresztą zachęcam, żeby tak robić, bo później na koniec dnia nawet do użytku wewnętrznego taka dokumentacja będzie przydatna zarówno użytkownikom, żeby wiedzieli jak korzystać z danego systemu, jak i potencjalnie programistom czy kolejnym agentom AI będzie przydatna do tego, żeby zawrzeć najważniejsze założenia, instrukcje czy jakieś zasady, którymi się powinno kierować przy korzystaniu z kolei z tego systemu.

No bo nietrudno wyobrazić sobie sytuację, gdzie po utworzeniu, wytworzeniu jednego narzędzia czy jakiegoś produktu AI, zaczynamy tworzyć kolejne w naszej organizacji, no po to, żeby wytworzyć już sobie taki ekosystem, który nam automatyzuje całe procesy albo zbiór procesów i te systemy zaczynają się ze sobą komunikować. I to też jest istotne, żeby każdy z tych agentów wiedział jak komunikować się z tym nowym oprogramowaniem. Także także tak na to patrzmy. Czyli w pierwszej kolejności jak tworzymy jakiś jakieś oprogramowanie z wykorzystaniem LLM-ów, tworzymy precyzyjną, wyspecyfikowaną i ustrukturyzowaną specyfikację taką biznesową. Następnie dorzucamy elementy techniczne do tego, jeśli sami nie jesteśmy w stanie tych elementów technicznych wyspecyfikować, korzystamy z pomocy konsultanta czy eksperta i pamiętamy, że dając to, wchodzimy w konwersację z LLM-em jak z ze średnio rozgarniętym programistą, tak? Czyli z programistą, który wie jak wytwarzać kod, ale niekoniecznie czuje biznes, więc tego kontekstu w trakcie rozmowy warto mu tu nadbudowywać i to no i to trzeba mieć na względzie.

Czy AI to tańsze i szybsze rozwiązanie?

No i teraz pytanie kolejne czy kolejne zagadnienie, które się pojawia często w kontekście tej automatyzacji, czyli czy to faktycznie jest taniej i szybciej? No i odpowiedź w dużym skrócie brzmi tak, to jest taniej i szybciej. Pytanie jest jeszcze jedno i jeszcze jedno kryterium bym to bym tu dorzucił, czy to jest odpowiedniej jakości? I tutaj już nie zawsze jest tak kolorowo, ale też, żeby nie było, z mojej z mojego punktu widzenia, ja nie jestem z tych co demonizują AI. Natomiast zaznaczę, że faktycznie może to być słabszej jakości, ale tylko i wyłącznie dlatego, że AI może dostać na na wejściu nieprecyzyjne instrukcje albo właśnie słabą specyfikację. Czyli tutaj zasada śmieci na wejściu i śmieci na wyjściu działa jak nigdy wcześniej, jeszcze bardziej, bo jak to się mówi, mówi się tak, jest taki slogan, że AI przyspiesza pracę dziesięciokrotnie. No więc jeżeli my mu wrzucimy jakieś śmieci na wejściu, to gwarantuję wam, że on 10 razy większy śmietnik zrobi niż gdybyśmy to dali programiście i gdyby on to to to zrealizował. Czyli krótko mówiąc, tak samo jak AI wzmacnia wartość biznesową, tak samo może wzmocnić wady czy niedoskonałości, które dostanie po prostu na wejściu. Dlatego to jest ważne, żeby te wszystkie rzeczy wyspecyfikować.

No i teraz w praktyce co znaczy co znaczy taniej i szybciej? No z mojej praktyki, jak tworzymy wewnętrzne narzędzia dla klientów albo właśnie jak tworzymy ten swój produkt Endora Commerce, no to wygląda to mniej więcej tak, że to przyspieszenie maleje oczywiście wraz ze złożonością produktu. Czyli im bardziej produkt jest rozbudowany, tym dłużej on będzie się wytwarzał przez LLM i tym drożej nas to będzie kosztowało, no bo spalamy tokeny. Wciąż będzie to szybciej wytworzone niż wytworzyłby to zespół programistów metodami standardowymi. Natomiast to przyspieszenie nie będzie takie, jak mówią, że tam dziesięciokrotne czy coś takiego. Więc taki najlepszy benchmark, jaki jaki widzimy na bazie tych projektów, gdybym miał to jakoś uśredniać, to bym powiedział, że koszt jesteśmy w stanie takiego oprogramowania zmniejszyć o o 30 do 50%. I podobnie o 30 do 50% jesteśmy w stanie skrócić czas wytwarzania rozwiązania. Przy czym ten ten procent idzie w dół ten procent idzie w dół wraz ze złożonością produktu. Czyli im bardziej złożony produkt, tym bardziej niestety zbliżamy się do tych 30% niż do tych 50%. No oczywiście możemy tam mówić o jakimś tam zrównolegleniu prac, czyli uruchomimy więcej agentów albo weźmiemy więcej subskrypcji, nie wiem, Claude'a, Codeksa i oni tam zaczną sobie dewelopować, ale osoby, które wytwarzają oprogramowanie wiedzą doskonale, że zrównoleglanie wytwarzania oprogramowania nie jest takie proste, intuicyjne, bo są różne też zależności, więc nie wszystko da się zrównoleglić, tak? Czyli ten przesławny przykład tego, że jeśli weźmiemy dziewięć kobiet i one będą w ciąży przez miesiąc, to nie urodzą dziecka po pół miesiącu, tylko no jednak biologia jest nieubłagana, tak? Więc na podobnej zasadzie funkcjonuje wytwarzanie oprogramowania. Są tam różne zależności, czasami między modułami, no więc po prostu dopóki jakiś moduł nie zostanie zbudowany, no to ten drugi nie może wylądować. Tego się wtedy nie da zrównoleglić. I to też trzeba mieć na względzie. No i największa szansa jest przy bardziej złożonym produkcie na tego typu zależności niż przy mniejszym. Trzeba to po prostu wziąć pod uwagę. Także jeśli ktoś wam mówi, że wytworzy wam produkt dziesięciokrotnie szybciej niż by to zrobiła jakaś agencja czy software house, to powinna wam się zapalić czerwona lampka, bo najprawdopodobniej skończy się to tak, że on to wytworzy faktycznie 10 razy szybciej, tylko to będzie totalnie nietrafiony produkt, który będzie czy czy narzędzie, które będziemy musieli zmodyfikować, a często ten sposób wytworzenia błędny będzie zakorzeniony tak głęboko u podstaw, że taniej wam z kolei będzie to wszystko porzucić i wybudować na nowo, co już wcale nie oznacza, że będzie to mniej kosztowało. Także warto mieć to na względzie i to jest kluczowy aspekt, który znowu cofa nas do tego sformułowania, o którym mówiłem wcześniej, czyli do sformułowania, że powinniśmy dobrze wyspecyfikować to co chcemy wytworzyć, że powinniśmy skonsultować to i wziąć pod uwagę ten aspekt technologiczny, no i wziąć pod uwagę to, że też ten programista w postaci LLM-a nie jest idealny i gdzieś tam z tyłu głowy mieć to, że trzeba będzie go koordynować.

Także tyle, jeśli chodzi o koszty i czas. Jakby oczywiście, jak najbardziej, dowód jakby w Endora Commerce jest dowodem na to, że jesteśmy w stanie wytworzyć takie rozwiązanie, bo cała cały framework, cała ta platforma, ten produkt powstał, zaczęliśmy pracę pod koniec kwietnia. No mamy końcówkę września i mamy tam już 60 modułów i 25 integracji. Czyli ten czas, w zasadzie pięć miesięcy, mamy produkt, który w pełni adresuje potrzeby rynku i ma jakieś tam integracje, tak? To jest produkt, który wciąż się rozwija, no ale tu pokazuje przykład złożonego produktu, który był tworzony z wykorzystaniem tego podejścia agentowego Spec-Driven Development. Także widzicie, to nie jest tak, że nagle projekty, nie wiem, półroczne staną się projektami tygodniowymi, aż tak to nie, przynajmniej na razie. No ale to przyspieszenie jest, tylko trzeba to robić z głową, trzeba to robić mądrze i musi być ktoś, kto faktycznie realnie koordynuje pracę tego pracę tych agentów, tak? Więc to jest to jest kolejna rzecz.

Rodzaje produktów a złożoność AI

Oczywiście całe te wszystkie rozważania, o których mówię, one troszeczkę się różnią, jeśli tworzymy produkt, który chcemy wydać na rynek. Inaczej to wygląda, jak chcemy dać produkt, który chcemy, żeby rynek rozwijał, a jeszcze inaczej wygląda to, jak tworzymy narzędzie do na potrzeby wewnętrzne. Dlatego, że przy narzędziu na potrzeby wewnętrzne my w prawie bezpośrednio implementujemy ten proces, który chcemy zautomatyzować. Nie musimy tam tworzyć jakiś rozwiązań generycznych, nie musimy tego jakoś generalizować, no bo nie ma takiej potrzeby, bo to jest tylko dla naszej organizacji, więc robimy to takie szyte, bardzo precyzyjnie na miarę. Nie musimy tego za bardzo uogólniać, łatwiej to będzie przystosować po prostu jak to będzie taki jeden konkretny proces. W przypadku produktów, które chcemy wypuścić, no tutaj już sprawa jest trochę bardziej skomplikowana, bo te rozwiązania, które wytwarzamy, no musimy założyć, że one ma muszą być trochę uogólnione, trochę generyczne, gdzieś tam musimy sobie przygotować na to przestrzeń, no bo zakładamy, że więcej organizacji będzie z tego korzystać, no i każda chce czerpać z tego korzyści i zawsze będzie jakieś tam lekkie dostosowanie, które przynajmniej takie lekkie dostosowanie, które musimy w naszym produkcie zapewnić, żeby po prostu inne organizacje mogły tego z tego skorzystać. Także to też wpływa na złożoność, to też powinno być zawarte w specyfikacji. Czyli istotne jest to, czy na przykład tworzymy produkt na własne potrzeby, czy tworzymy produkt jednorazowego użytku, czy tworzymy produkt, który chcemy rozwijać, który ma mieć swoją roadmapę i generalnie to ma być produkt rynkowy. To też powinno być zawarte w specyfikacji, bo to też wpływa na to, jak jakie LLM podejmuje decyzje podczas implementowania takich rzeczy czy czy tworzenia czy tworzenia tych narzędzi. Także miejmy też to na względzie.

Wady i vendor lock-in

Wady. No bo tutaj mówię o tym mówię o tym, jakie tu mamy korzyści, że możemy to szybko robić, tak, mamy taniej, szybciej, tak? Więc to to jest oczywiście sama zaleta. No ale są też i wady. No wada to jest ona część wad pośrednio wynika z tego, co mówiłem wcześniej, czyli, że musimy jednak przyłożyć większą wagę do specyfikacji, że to my musimy jakieś tam aspekty techniczne też zawrzeć w specyfikacji, żeby ten LLM nam nie odpłynął, a mimo to wciąż jest ryzyko tego, że on nas źle zrozumie i będziemy musieli to poprawiać. Oczywiście jak software house czy generalnie programista, freelancer, który ktokolwiek wytwarzał oprogramowanie, możemy doświadczyć tego samego, to znaczy on też może odpłynąć, bo źle zrozumie naszą specyfikację. Więc pod tym względem jest, powiedzmy, jeden do jednego dla jeden do jednego w przy przy zespole LLM kontra programiści. No ale jednak mimo wszystko LLM-y częściej halucynują, częściej potrafią właśnie pójść w złym kierunku, co wynika z tego, że po prostu ta specyfikacja często otwiera pole do różnych interpretacji. No i programista jakby ma doświadczenie branżowe, zrobił kilka takich systemów, więc czasami sobie dopowiada słusznie do rynku pewne rzeczy. No LLM nie zawsze to robi, więc to jest jakby taka taka rzecz. Natomiast jeśli chodzi o wady takie taką podstawową wadą, która nie jest ona do końca oczywista, to jest problem tak zwanego vendor lock-inu, czyli uzależnienia od rozwiązania czy od dostawcy. Bo pamiętajmy, że na koniec dnia jak wytworzymy sobie takie oprogramowanie czy agent wytworzy to oprogramowanie i będziemy chcieli je rozwijać, utrzymywać, to później dużo łatwiej będzie utrzymywać to i rozwijać, jeśli będzie to robił nadal agent AI. Ale to oznacza, że my musimy kupować subskrypcje albo kupować dostęp do API i spalać te przysłowiowe te te te tokeny. Będziemy musieli je spalać, co generuje koszty. Więc też trzeba wziąć pod uwagę, że tu tu oczywiście się generuje koszt, ale druga rzecz jest taka, że jesteśmy wtedy uzależnieni od tych subskrypcji. To znaczy, jeśli my anulujemy subskrypcję, no to wtedy nie mamy tego agenta dostępu do agenta, który będzie to oprogramowanie utrzymywał czy rozwijał. No i oczywiście możemy się pokusić o to, żeby to oddać wtedy do programisty, do software house'u, jeśli stwierdzimy, że to będzie bardziej efektywne kosztowo, ale to oznacza też, że ten kod, który tam został napisany, on jest pisany trochę mniej tak naturalnie, tak jakby to napisał programista. W związku z tym ten próg wejścia czy to agencji czy software house'u w modyfikację tego robi się wtedy troszkę wyższy. Czyli trzeba się liczyć z tym, że ten koszt wdrożenia się w rozwiązanie będzie jednak nieco wyższy niż gdybyśmy przejęli kod po kimś z innego projektu, tak? To to jest to. No i sam vendor lock-in też związany z tym, że jak już idziemy w agentów, to gdzieś tam ten koszt ten koszt, powiedzmy, tego GPT czy Claude'a od Anthropic'a czy Gemini musimy sobie uwzględnić w naszej organizacji, co patrząc na to, jak wygląda ta rewolucja AI, raczej wpisuje się już w standard każdej organizacji, że gdzieś te koszty są ponoszone. No ale żeby było sprawiedliwie, trzeba po prostu to zaznaczyć, więc to więc to zaznaczam, tak?

Podsumowanie i wnioski

Kolejna rzecz, która jest też ważna, czyli taki garść wniosków, taka garść wniosków na na zakończenie. Przede wszystkim LLM-y, te rozwiązania przesuwają nam te granice automatyzacji procesów. Czyli tak naprawdę no jesteśmy w stanie dużo szybciej sięgnąć po po rozwiązania, po agenta AI, żeby nam wytworzył jakieś jakiś program czy narzędzie czy produkt, który nam zautomatyzuje jakąś jakiś proces u nas. Natomiast pamiętajmy wciąż, że on nie te LLM-y nie eliminują tej granicy automatyzacji. Co to oznacza? No zmierzam do tego, że wciąż jest ten taki punkt w organizacjach, gdzie pewnych procesów czy pewnych elementów nie warto automatyzować. Więc nawet przy tym tanim dostępie do kodu wciąż zachęcam do tego, żeby zastanowić się przed ruszeniem do GPT, wpisaniem i wpisania prompta. Przed wpisaniem tego prompta zachęcam też do tego, żeby zastanowić się, czy warto jest ponieść koszt wytworzenia przez agenta tego oprogramowania, utrzymywania później tego oprogramowania i jego potencjalnego rozwijania, czy wciąż nie ma czy wciąż na przykład wybrany proces nie wychodzi na to, że taniej będzie obsłużyć automatycznie nie automatycznie, tylko manualnie albo innymi metodami. To wciąż jest element, który wymaga analizy, tak? Czyli to, że dużo łatwiej jest dostać teraz to oprogramowanie, które nam zautomatyzuje proces, nie zwalnia nas z tego, żeby pomyśleć o tym, czy czasem właśnie w tym momencie nie przepaliliśmy tokenów i robimy coś, co na przykład pójdzie do kosza za moment, albo się okaże, że w zasadzie przez człowieka jest bardzo dobrze obsługiwane, bezbłędnie i w sumie jakby porównać to z kosztem wytworzenia i utrzymywania, no to wychodzi na to, że w zasadzie wciąż to można by było robić manualnie i to by było efektywniejsze kosztowo i z mniejszym współczynnikiem błędu, na przykład, tak? Także gdzieś z tyłu głowy zawsze trzeba to mieć, że LLM nie jest receptą na wszystko. Agent AI i wytwarzane przez niego oprogramowanie nie jest receptą na wszystko, tak? Hurra optymizm, nie szalejmy też z tym i przede wszystkim, o to też jest ważne, przede wszystkim nie lećmy na fali hajp-u. To znaczy, jeśli z analizy czy intuicyjnie wychodzi nam, że nie ma potrzeby automatyzowania czegoś albo nie potrzebujemy AI, to nie wdrażajmy tego na siłę, bo wdrażanie rozwiązań sztucznej inteligencji czy uczenia maszynowego na siłę najczęściej kończy się tym, że przepalamy masę pieniędzy na pewną inwestycję, która nam się praktycznie nigdy nie zwróci. Idealnym przykładem to jest to, jak często w e‑commerce chcemy wykorzystywać chatboty AI albo jakieś wyszukiwarki, kreatory, asystentów, którzy będą nam podpowiadać, jakie to produkty mają zostać dodane do koszyka i tak dalej i tak dalej. A potem okazuje się, że jak chcemy w to zainwestować albo nie daj Bóg zainwestowaliśmy, to okazuje się, że na przykład dane produktowe są nieuporządkowane. I wtedy docieramy do tego do tego momentu, o którym wspominałem, czyli śmietnik na wejściu niesamowicie się multiplikuje na wyjściu w przypadku w przypadku LLM-a, czyli mamy asystenta, który po prostu będzie potężnie halucynował albo będzie źle podpowiadał, nie dlatego, że on w bebechach swoich w silniku jest źle zrobiony, tylko dlatego, że on ma na wejściu bardzo nieuporządkowane, nieprecyzyjne, a czasami wręcz błędne dane, które po prostu on przekazuje dalej klientowi, tak? Jeśli się okaże, że w PIM-ie nasza, nie wiem, golarka jest opisana, że ona strzyże trawę, tak? No bo ktoś tak napisał, no to asystent podpowie, że ona jest do strzyżenia trawy, tak? I nieważne, że to będzie golarka do zarostu czy czy czegoś innego, tak? Więc to też trzeba wziąć pod uwagę. To wciąż wciąż wbrew pozorom jest projekt systemu informatycznego. Czy trzeba przygotować do tego odpowiednią analizę, odpowiedni projekt, zanim zaczniemy realizować pewną implementację. I pamiętając o tym, że przez to, że można to wytworzyć szybciej i taniej, no to po prostu możemy dużo szybciej odczuć i mocniej odczuć efekty błędnych decyzji czy błędnych danych dostarczonych na wejściu. Także to też warto warto mieć na względzie. Nie lecimy z hajpem, lecimy ze strategią. Jak zbudowaliśmy strategię sprzedażową czy e‑commerce, która ma na celu zrobić to, to i to i okaże się, że przez AI czy przez narzędzia wytwarzane przez AI jesteśmy w stanie to osiągnąć, no to lecimy w to, tak? Po co czekać, lepiej po prostu zarabiać. Natomiast jeśli się okaże, że my mamy po prostu zainwestować, bo nam zarząd powiedział, że my musimy wydać 300 000 czy tam pół miliona na AI, no to pewnie lepiej po prostu to wziąć i spalić w kominku, bo mniej to będzie zajmowało czasu, mniej stresu zeżre, no i efekt będzie ten sam. Także to warto mieć też na względzie.

Kolejna rzecz to jest taka i to też jest taki wniosek już bardziej dla osób, które chciałyby tworzyć produkt z wykorzystaniem AI, to wiemy to jakby jest wniosek, który widzę sam z rynku, ale też fundusze VC i i w ogóle inwestorzy wskazują na ten element, że po pierwsze koszt tych tokenów potrafi być przy tworzeniu produktów, jeśli jeśli weźmiemy pod uwagę, że AI ma nam wytwarzać produkt, ale i obsługi robić obsługę klienta, czyli automatyzować nasze wewnętrzne procesy do tego, żeby ten produkt jakby dystrybuować i i i udostępniać klientom i go utrzymywać, no to te koszty potrafią też być spore. Także to jest jeden jedna ze składowych, w którą wręcz inwestorzy muszą wkładać teraz, żeby po prostu się produkt rozwijał szybko. Ale druga noga i drugi element jest jeszcze ważniejszy i jest ważniejszy niż kiedykolwiek wcześniej. Mianowicie przez to, że relatywnie łatwo jest teraz zbudować te produkty z wykorzystaniem AI, to przez to dystrybucja i marketing tego produktu kosztuje jak nigdy wcześniej i on waży dużo w strukturze kosztów. To znaczy, ponieważ tak naprawdę idealny przykład Endora Commerce, tak? Ten ta nasza platforma B2B. No rozwiązań na rynku obecnie jest co najmniej kilka. One różnią się pewnymi rzeczami, niektóre nie są open source, niektóre nie udostępniają pewnych modułów, które my udostępniamy i tak dalej. Dlatego super ważne jest teraz i to jest nasze wyzwanie jako firmy, jako zespołu produktowego Endory Commerce, jest super ważne to, żebyśmy my teraz odpowiednio to wypromowali w wysokiej skali, żeby to dotarło do jak największej liczby osób. No bo po prostu zginiemy w gąszczu pewnych rozwiązań, które wcale nie muszą być lepsze dla klienta, no ale mają wystarczające budżety marketingowe, żeby po prostu grupa docelowa nasza i i konkurencji i nie tylko zresztą dowiedziała się po prostu o tamtych rozwiązaniach. Także to jest super wyzwanie i ta dystrybucja jest czymś, o czym wiele osób w poprzednich latach, szczególnie w środowiskach startupowych niewiele osób o tym myślało. To znaczy niektórzy mówili, że produkt się obroni sam, tak? Jeśli produkt jest dobry, no to się on obroni sam i ludzie będą przychodzić. No niestety od wielu, wielu lat to nie jest prawdą. Zalew tych różnych rozwiązań na rynku sprawia, że po prostu trzeba się przebijać i udowadniać swoją wartość i swoją eksperckość, zanim klient będzie chciał w ogóle od nas kupić. Więc teraz jeszcze jak dodatkowo dorzucimy ten aspekt AI i tego, że możemy wytworzyć niektóre narzędzia wręcz w kilka godzin, no to no to musimy wziąć pod uwagę to, że jeśli chcemy to robić na poważnie i chcemy to sprzedawać, to musimy myśleć o zaalokowaniu dość dużych budżetów marketingowych.

Tak to mniej więcej wygląda, jeśli chodzi o tematy o tematy e‑commerce'owy i tego, jak można wykorzystać AI. Dajcie znać w komentarzu proszę, czy tego typu wskazówki też są dla was przydatne, bo tutaj trochę zahaczaliśmy o te o ten element taki AI-owy, mieszaliśmy te obszary, więc będę ciekaw tego i zresztą ciekaw jestem teraz tego również, czy tego typu tematy też są dla was interesujące. Ja ze swojej strony tyle na dzisiaj mam do przekazania. Gdybyście mieli jakieś pytania albo chcielibyście pogłębić to, to również również dawajcie znać. Zachęcam do dzielenia się odcinkiem, bo ta wiedza z tego odcinka, z poprzednich odcinków, generalnie ma sens tylko i wyłącznie wtedy, kiedy krąży jakby w ekosystemie. Zapraszam za tydzień na Endora Commerce nie na Endora Commerce, tam za dużo tej Endory Commerce. Na Manufakturę E‑commerce News, o newsach. Na pewno będziemy mówić o gali E‑commerce Awards i tym, kto wygrał, dlaczego, co i jak. A za dwa tygodnie na kolejny odcinek merytoryczny Manufaktury E‑commerce. Dzięki wielkie za uwagę i do zobaczenia. Cześć.

Partnerem audycji jest Endora, agencja e‑commerce B2B, specjalizująca się w modelu 360. Od budowania strategii sprzedaży online, po wdrażanie platform B2B i ich integrację z ekosystemem technologiczno-biznesowym. Wejdź na endora.pl i dowiedz się więcej.