Kluczowe wnioski
- Praca z agentami różni się od klepania promptami trzema rzeczami: specyfikacją przed kodem, bramkami, których nie da się ominąć, i przeglądem prowadzonym niezależnie od autora zmiany. Rzeczy nieodwracalne, czyli wdrożenie na produkcję, migracje danych i kasowanie, zatwierdza człowiek.
- Czas dowozu skraca się nie dlatego, że ktoś pisze kod szybciej, tylko dlatego, że skraca się droga od „napisane” do „można wypuścić”. Wąskim gardłem jest zaufanie do kodu, więc inwestycja idzie w weryfikację, nie w tempo pisania.
- Dla właściciela sklepu oznacza to szybsze zmiany, krótszą kolejkę drobnych poprawek, tańsze utrzymanie i mniejszą zależność od jednego dostawcy, bo kontekst projektu jest spisany w repozytorium, a nie w głowach dwóch osób.
- Rozwijaj to etapami: najpierw bramki (testy, build uruchamiany automatycznie, środowisko podglądowe), potem agenci przy zadaniach najlepiej opisanych, i od początku jasny podział na tego, kto pisze specyfikacje, i tego, kto akceptuje.
Nadzór nad automatyzacją jest już ustawiony: wiadomo, kto zatwierdza, na jakiej podstawie i co się dzieje, gdy automat się pomyli. To dobry moment, żeby pójść poziom wyżej. Ten sam sposób pracy, czyli jasna specyfikacja, twarda weryfikacja i człowiek przy decyzjach nieodwracalnych, stosuje się nie tylko do pracy operacyjnej w sklepie, ale też do tego, jak powstaje i jak jest rozwijana sama platforma. Ten rozdział jest ostatni, bo dla większości firm to konsekwencja poprzednich pięciu, a nie punkt wyjścia. Nie musisz przy tym umieć programować, żeby ocenić, czy ktoś buduje Twój sklep w sposób, który da się kontrolować.
Praca z agentami to nie pisanie dłuższych promptów
Różnica między poważną pracą z agentami a generowaniem kodu na skróty nie leży w narzędziu ani w długości polecenia. Leży w rygorze wokół narzędzia. Model potrafi napisać działający fragment kodu w kilka minut, ale samo pisanie kodu nigdy nie było najdroższą częścią projektu. Najdroższe jest ustalenie, co dokładnie ma powstać, i sprawdzenie, czy powstało to, co ustalono. Praca z agentami przesuwa więc wysiłek zespołu w obie te strony: więcej czasu idzie na specyfikację przed kodem i na weryfikację po kodzie, mniej na samo pisanie. Kto pomija oba końce i zostawia środek, dostaje szybciej dokładnie to, na co narzekał wcześniej, tylko w większej ilości.
Specyfikacja przed kodem znaczy tyle, że zanim ktokolwiek, człowiek czy agent, dotknie repozytorium, spisany jest zakres zmiany, przypadki brzegowe, wpływ na dane i kryterium „gotowe”. Bez tego powstaje kod, który działa na ścieżce podstawowej i rozsypuje się na wariantach produktowych, zwrotach albo integracji z magazynem, czyli dokładnie tam, gdzie mieszka eCommerce. Spisana specyfikacja ma też skutek uboczny, który widać dopiero po kilku miesiącach: jest jedynym miejscem, w którym zostało zapisane, dlaczego coś działa tak, a nie inaczej. Czym taki tryb pracy różni się od szybkiego generowania kodu bez struktury, rozpisaliśmy w tekście o tym, dlaczego AI native to nie vibe coding.
Bramki, przez które musi przejść każda zmiana
Rygor nie bierze się z dobrych intencji, tylko z bramek, których nie da się ominąć zmęczeniem albo terminem. Część z nich jest automatyczna i uruchamia się przy każdej zmianie: kontrola typów, build, testy, lint, sprawdzenie zależności. Część wymaga człowieka albo przeglądu prowadzonego przez kogoś innego niż autor zmiany. Poniższa tabela pokazuje, gdzie kończy się swoboda automatu.
| Etap | Co się dzieje | Co blokuje przejście dalej |
|---|---|---|
| Specyfikacja | Spisany zakres zmiany, przypadki brzegowe, wpływ na dane i kryterium „gotowe” | Niejasne kryterium akceptacji albo brak zgody na zakres |
| Implementacja | Agent pisze kod w małych krokach, każdy w granicach uzgodnionego zakresu | Zmiana wychodzi poza zakres albo dotyka obszarów spoza specyfikacji |
| Bramki automatyczne | Kontrola typów, build, testy, lint i zależności, przy każdej zmianie | Czerwony wynik dowolnej bramki, bez wyjątków „na dziś” |
| Przegląd | Zmianę ogląda ktoś inny niż jej autor, na tle specyfikacji | Uwagi nierozstrzygnięte albo rozjazd ze specyfikacją |
| Wdrożenie i migracje | Publikacja na produkcję, migracja danych, usunięcie zasobów | Brak wyraźnej zgody człowieka |
Pierwsze cztery wiersze może prowadzić automat. Ostatni zostaje przy człowieku i nie zmienia się to wraz z dojrzałością zespołu.
To, co nieodwracalne, zatwierdza człowiek. Wdrożenie na produkcję, migracja danych, usunięcie zasobów i zmiany w konfiguracji płatności to decyzje, których nie oddaje się automatowi niezależnie od tego, jak dobrze radzi sobie z resztą pracy. Kryterium nie brzmi „czy narzędzie sobie poradzi”, tylko „ile kosztuje cofnięcie, jeżeli się pomyli”.
Wąskim gardłem nie jest kod, tylko zaufanie do kodu
Czas dowozu skraca się nie dlatego, że ktoś pisze szybciej. Skraca się dlatego, że skraca się droga od „napisane” do „można to wypuścić”. W typowym projekcie właśnie ta droga zajmuje najwięcej: zmiana czeka w kolejce do przeglądu, ktoś klika ją ręcznie na środowisku testowym, wraca lista uwag, cykl się powtarza. Jeżeli generowanie kodu przyspieszy, a ta droga zostanie bez zmian, kolejka po prostu urośnie. Dlatego inwestycja idzie w weryfikację: testy, które faktycznie łapią błędy istotne dla sprzedaży, kontrola typów wyłapująca niezgodności przed uruchomieniem, środowisko podglądowe dla każdej zmiany i przegląd niezależny od autora.
To odwraca zwykłą intuicję o kosztach. Zespół, który przyspieszył pisanie kodu, a nie wzmocnił bramek, zwiększył wyłącznie tempo wpuszczania błędów na produkcję. Zespół, który najpierw postawił bramki, może pozwolić sobie na więcej zmian w tygodniu, bo każda z nich jest tania do sprawdzenia i tania do cofnięcia. Jakość nie jest tu ceną za tempo, tylko jego warunkiem. Jak to wygląda u nas krok po kroku, od specyfikacji przez bramki po wdrożenie, opisaliśmy w tekście o agentic engineering.
Co to zmienia dla właściciela sklepu
Z perspektywy osoby, która za to płaci i z tego żyje, liczą się cztery rzeczy. Pierwsza: zmiany wchodzą szybciej, więc pomysł z poniedziałku nie czeka do następnego kwartału. Druga: kolejka drobnych poprawek przestaje rosnąć, bo drobna poprawka przestaje kosztować jak mały projekt. Trzecia: utrzymanie tanieje, ponieważ większość pracy utrzymaniowej to zadania powtarzalne i dobrze opisane, a właśnie takie najlepiej przechodzą przez ten proces. Czwarta: maleje zależność od jednego dostawcy, bo kontekst projektu jest spisany w repozytorium, w specyfikacjach i testach, a nie w głowach dwóch osób, które akurat znają ten kod.
Jest jeszcze konsekwencja dalej idąca. Dopóki każda zmiana w platformie na własność kosztowała dużo i trwała długo, rachunek często wypadał na korzyść rozwiązania pudełkowego, w którym płaci się abonament i przyjmuje ograniczenia. Kiedy koszt zmiany spada, rachunek się przesuwa: własna platforma przestaje być pozycją, której trzeba bronić przed zarządem, a staje się miejscem, w którym można zbudować to, czego konkurencja na tym samym pudełku zbudować nie może. To wniosek, nie obietnica, i przesądza o nim jedna rzecz: czy Twój zespół ma pomysły warte zbudowania.
Reużywalność: kolejny projekt zaczyna się dalej
Praca zrobiona porządnie zostaje. Moduł koszyka, integracja z systemem magazynowym, obsługa feedów, zestaw testów dla ścieżki zakupowej: raz opisane i sprawdzone, przenoszą się na kolejny projekt i kolejny rynek, zamiast powstawać od zera. To samo dotyczy specyfikacji, słowników i checklist, bo one też są aktywem, tylko rzadziej się je tak traktuje. Efekt jest taki, że drugi rynek uruchamia się szybciej niż pierwszy, a trzeci szybciej niż drugi, pod warunkiem że ktoś świadomie pilnuje, żeby części wspólne zostawały wspólne. Z tego samego powodu publikujemy otwarty zestaw skilli eCommerce dla agentów AI na licencji MIT: to spisany kontekst branżowy, który nie musi powstawać na nowo w każdym projekcie.
Jak rozwijać to u siebie, etapami
Zacznij od podziału ról, bo to on decyduje, czy proces się utrzyma. Ktoś musi pisać specyfikacje i nie musi to być programista: najlepiej robi to osoba, która zna asortyment, klienta i to, co ma się w sklepie wydarzyć. Ktoś inny musi mieć prawo powiedzieć „to nie wchodzi”, zwykle jedna osoba po stronie technicznej, z wyraźnie wyznaczonym zakresem decyzji nieodwracalnych. Reszta zespołu pracuje w środku: opisuje, sprawdza, poprawia. Bez tego podziału każda zmiana kończy się dyskusją, kto tak naprawdę zdecydował, a odpowiedzialność rozmywa się dokładnie wtedy, kiedy jest potrzebna.
Druga rzecz to kolejność. Jeżeli dziś nie masz testów, buildu uruchamianego automatycznie ani środowiska podglądowego, pierwszym krokiem nie jest agent, tylko te trzy rzeczy, bo bez nich nie ma czym pilnować niczego. Dopiero potem dokładasz agentów do zadań najlepiej opisanych. Trzecia rzecz to wstrzemięźliwość w narzędziach: jedno narzędzie na etap, wymieniane wtedy, gdy realnie zawodzi, a nie wtedy, gdy pojawi się nowsze. Zespół, który co miesiąc zmienia zestaw narzędzi, nigdy nie dochodzi do momentu, w którym którekolwiek zaczyna zwracać włożoną pracę. Ten etap w naszym frameworku BEAM nazywa się AI Automation i obejmuje dokładnie to, co opisuje ten przewodnik: od automatyzacji pracy operacyjnej po sposób, w jaki rozwijamy samą platformę.
Sześć rozdziałów w jednym akapicie
Ścieżka, którą przeszliśmy, jest prosta i celowo ułożona w tej kolejności. Najpierw ustalasz, gdzie AI realnie zarabia w Twoim sklepie, zamiast zaczynać od czatbota, bo tak wypada. Potem audytujesz pracę operacyjną i wiesz, na co idą godziny. Następnie porządkujesz dane, bo bez nich każda automatyzacja skaluje wyłącznie bałagan. Uruchamiasz pierwsze workflow w wąskim zakresie i pilnujesz go próbką zamiast wrażenia. Ustawiasz nadzór, jakość i zgodność, żeby to, co działa, nie zaczęło działać przeciwko Tobie. I dopiero wtedy ten sam sposób pracy przenosisz na budowę oraz rozwój platformy. Każdy z tych kroków zakłada poprzedni i żaden nie jest jednorazowy.
Na koniec rzecz, o której warto pamiętać, kiedy narzędzia robią wrażenie. AI nie podejmie za Ciebie decyzji biznesowych: nie wybierze asortymentu, nie ustali pozycjonowania cenowego, nie powie, na którym rynku warto walczyć i z kim. Nie zna Twoich klientów lepiej niż Ty i nie ma dostępu do wiedzy, której nigdzie nie zapisałeś. Zdejmuje pracę powtarzalną i skraca drogę od decyzji do wykonania, ale wykonanie czego, to zostaje pytaniem do człowieka. I to pytanie jest ważniejsze niż wybór narzędzia.
Pytania
Czy to znaczy, że sklep może zbudować firma bez programistów?
Nie. Zmienia się rozkład pracy, a nie potrzeba kompetencji. Ktoś musi postawić bramki, zaprojektować architekturę, ocenić zmianę na tle specyfikacji i podjąć decyzje o wdrożeniach i migracjach. To są zadania inżynierskie i wymagają inżyniera. Rośnie za to rola osoby nietechnicznej po stronie sklepu, bo dobra specyfikacja pochodzi od kogoś, kto zna asortyment i klienta, a nie od kogoś, kto zna framework.
Jak sprawdzić, czy dostawca pracuje w ten sposób, skoro nie umiem czytać kodu?
Zapytaj o cztery rzeczy i poproś o pokazanie ich na przykładzie ostatniej zmiany. Czy przed zmianą powstaje spisana specyfikacja z kryterium akceptacji. Co uruchamia się automatycznie przy każdej zmianie i co się dzieje, gdy wynik jest czerwony. Kto ogląda zmianę niezależnie od autora. Kto zatwierdza wdrożenie na produkcję i migracje danych. Odpowiedzi da się zweryfikować bez czytania kodu: wystarczą raporty z bramek, historia zmian i działające środowisko podglądowe.
Czy kod tworzony z udziałem AI jest bezpieczny do wypuszczenia na produkcję?
Pytanie jest źle postawione, bo ryzyko nie zależy od autorstwa, tylko od tego, co dzieje się między napisaniem a wdrożeniem. Kod napisany ręcznie, bez testów i bez przeglądu, jest równie ryzykowny. Interesuje Cię więc nie to, kto pisał, ale czy zmiana przeszła przez bramki, czy ktoś obejrzał ją niezależnie i czy da się ją szybko cofnąć. Żaden proces nie sprowadza tego ryzyka do zera.
