Samo generowanie nie jest problemem

Shopify wprowadziło AI Store Builder w ramach edycji Summer ’25 i opisuje go jako narzędzie, które na podstawie kilku słów generuje spersonalizowane projekty sklepów. To wygodny sposób na przygotowanie pierwszego projektu, ale Shopify nadal wskazuje sprzedawcy kolejne zadania: skonfigurowanie sklepu i rozpoczęcie sprzedaży. AI szybciej przygotowuje punkt wyjścia w motywie, lecz nie eliminuje dalszej pracy z nim.

Przewodniki po kreatorach sklepów wykorzystujących AI, także te przygotowane przez Shopify, zwykle wskazują te same ograniczenia: szablony bywają mało elastyczne, skuteczne formułowanie poleceń wymaga wprawy, bez dopracowania sklep może wyglądać jak wiele innych, a bardziej złożone funkcje nadal trzeba konfigurować ręcznie.

To przede wszystkim problemy z jakością, które z każdą kolejną wersją powinny tracić na znaczeniu. Ten artykuł dotyczy problemu, którego samo ulepszanie AI nie rozwiąże: kto zajmuje się tym, co generator po sobie zostawia?

Gdzie Shopify Magic dodaje kod do motywu

Każdy motyw ma określony zestaw sekcji i ustawień. W edytorze motywu Shopify Magic może na podstawie twoich instrukcji utworzyć niestandardowy blok. Zapisuje plik Liquid, który może zawierać także HTML, CSS, JSON i JavaScript, a następnie dodaje go do folderu blocks w twoim motywie.

Nie należy przy tym mylić dwóch odrębnych funkcji. Ten artykuł dotyczy niestandardowych bloków motywu generowanych przez Shopify Magic, a nie wstępnego projektu sklepu tworzonego przez AI Store Builder. Te dwie funkcje pozostawiają po stronie sprzedawcy różne zadania.

Blok, który działa dokładnie zgodnie z poleceniem, jest użytecznym skrótem. Trudniejsze pytanie brzmi: co się stanie, gdy kod zawiera błąd, nie spełnia wymogów dotyczących dostępności lub wydajności albo z czasem przestaje odpowiadać potrzebom sklepu?

Zakres wsparcia jest jasno określony

Dokumentacja Shopify dotycząca generowanych bloków motywu mówi wyjątkowo jasno: ani pomoc techniczna Shopify, ani zewnętrzni twórcy motywów nie rozwiązują problemów z takimi blokami. Według dokumentacji możesz przejrzeć kod, usunąć blok albo zatrudnić partnera Shopify.

Krótko mówiąc, funkcja może utworzyć kod, ale Shopify nie bierze odpowiedzialności za jego utrzymanie.

Zakres wsparcia jest udokumentowany. Związany z nim koszt utrzymania łatwo jednak przeoczyć, gdy więcej uwagi poświęca się obietnicy szybkiego generowania.

Jeden blok pomaga. Dwadzieścia bloków to już baza kodu.

Przy jednym bloku skala problemu jest niewielka: możesz go usunąć, wygenerować ponownie albo zlecić komuś jego sprawdzenie. Kłopot zaczyna się wtedy, gdy pierwszy blok nie pozostaje ostatnim.

Strona kampanii potrzebuje sekcji, której nie ma w motywie. Premiera produktu wymaga innej galerii. Świąteczna strona główna potrzebuje sezonowego elementu. Każda z tych potrzeb jest uzasadniona, ale każde rozwiązanie dodaje kolejny fragment kodu, za który odpowiadasz. Rok później nadal prowadzisz sklep, lecz równolegle utrzymujesz niewielki projekt programistyczny.

Na tym polega ukryty koszt: kod powstaje natychmiast, ale z każdą zmianą jest go coraz więcej. Każdy wygodny niestandardowy blok to kolejny fragment, który trzeba później sprawdzać i utrzymywać.

To problem sposobu pracy, nie jakości AI

Kod nie powstaje dlatego, że AI zawiodło. Powstaje dlatego, że AI działa wewnątrz systemu opartego na motywie. Gdy zmiana wykracza poza wbudowane opcje motywu, trzeba zmienić kod, który steruje wyglądem i działaniem sklepu.

Setka działa inaczej: sprzedawca nie dostaje motywu ani kodu, za którego utrzymanie musiałby odpowiadać. Platforma sama generuje i uruchamia witrynę sklepu. Możesz otworzyć stronę produktu i zwykłym językiem poprosić: „Nadaj tej stronie spokojniejszy charakter i zacznij od składników”. Potem samodzielnie poprawiasz konkretne sformułowania, oglądasz podgląd, publikujesz zmianę i w razie potrzeby wracasz do wcześniejszej wersji witryny. Nie dostajesz kodu motywu, który musisz później utrzymywać, bo w tym modelu taki kod nie powstaje.

To różnica między dodaniem AI do tradycyjnej pracy z motywem a całkowitym odejściem od tego modelu. Nasze pełne porównanie omawia oba podejścia, także sytuacje, w których dojrzały ekosystem motywów nadal sprawdza się lepiej.

Co sprawdzić przed uruchomieniem sklepu

Niezależnie od wybranej platformy te cztery pytania pokażą, jakie obowiązki związane z utrzymaniem bierzesz na siebie:

  1. Gdzie platforma zapisuje wygenerowany element? Czy trafia on do kodu motywu, który należy do ciebie, czy pozostaje częścią platformy? Poproś o konkretną odpowiedź na piśmie.
  2. Co się stanie, gdy wygenerowany element przestanie działać? Czy zespół wsparcia go naprawi, czy dokumentacja odeśle cię do przejrzenia kodu, usunięcia elementu albo zatrudnienia partnera?
  3. Ile niestandardowych zmian naprawdę wprowadzisz w pierwszym roku? Przy jednej wersji roboczej strony głównej łatwo zachować porządek. Dopiero kolejne kampanie, strony sezonowe i eksperymenty zwiększają liczbę niestandardowych bloków z jednego do dwudziestu.
  4. Jak w praktyce zmieniasz sklep? Zanim podejmiesz decyzję, wprowadź jedną istotną zmianę w wygenerowanym sklepie. Sprawdź, czy to ty decydujesz o efekcie, czy zamiast tego musisz szukać błędu w kodzie.

Najlepszy sklep nie musi być tym, który powstał najszybciej. To taki, który po roku nadal możesz bez obaw zmieniać, nie odkrywając przy okazji, że przejąłeś bazę kodu.