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.
- Spisana wiedza organizacji plus agenci dają efekt kumulacji także w budowie: specyfikacje, słowniki i testy zostają w repozytorium, więc każdy kolejny sprint zaczyna się dalej, a zależność od jednego dostawcy maleje.
- 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ą działa: 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 opisów i feedów, ale też do kodu, z którego zbudowany jest Twój sklep. Ten rozdział zamyka główną ścieżkę, 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
Scena z projektu: sklep potrzebuje pola „numer partii” przy wariancie produktu. Brzmi jak godzina pracy i agent faktycznie wygeneruje ten kod w kilka minut. Tylko że 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.
- Koszyki: co z wariantami, które klienci mają już w koszykach?
- Feed: co z feedem do kanału, który takiego pola nie zna?
- Zwroty: co ze zwrotem całej partii?
Praca z agentami przesuwa wysiłek zespołu w obie te strony: więcej czasu na specyfikację przed kodem i na weryfikację po nim, mniej na klepanie w środku. 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 to 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, zwrotach albo integracji z magazynem, czyli dokładnie tam, gdzie mieszka eCommerce.
Spisana specyfikacja ma też skutek uboczny widoczny dopiero po miesiącach: to jedyne miejsce, 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ęść 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. 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ę, bo krótsza robi się droga od „napisane” do „można to wypuścić”. W typowym projekcie to ona zjada najwięcej: zmiana czeka w kolejce do przeglądu, ktoś ręcznie klika ją na środowisku testowym, wraca lista uwag, cykl się powtarza. Jeżeli generowanie kodu przyspieszy, a ta droga zostanie bez zmian, urośnie tylko kolejka. Dlatego inwestycja idzie w weryfikację:
- Testy: takie, które faktycznie łapią błędy istotne dla sprzedaży.
- Kontrola typów: wyłapuje niezgodności przed uruchomieniem.
- Środowisko podglądowe: dla każdej zmiany.
- Przegląd: niezależny od autora zmiany.
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 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 z tego ma właściciel sklepu
Z perspektywy osoby, która za to płaci i z tego żyje, liczą się cztery rzeczy:
- Tempo: pomysł z poniedziałku nie czeka do następnego kwartału, bo zmiany wchodzą szybciej.
- Kolejka poprawek: przestaje rosnąć, bo drobna poprawka przestaje kosztować jak mały projekt.
- Utrzymanie: tanieje, bo większość pracy utrzymaniowej to zadania powtarzalne i dobrze opisane, a właśnie takie najlepiej przechodzą przez ten proces.
- Zależność od dostawcy: maleje, 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ść pudełka: abonament plus ograniczenia w pakiecie. 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.
Platforma, która uczy się z każdym sprintem
Praca zrobiona porządnie zostaje. Moduł koszyka, integracja z magazynem, obsługa feedów, testy ścieżki zakupowej: raz opisane i sprawdzone, przenoszą się na kolejny projekt i kolejny rynek, zamiast powstawać od zera.
To samo dotyczy wiedzy. Specyfikacje, słowniki atrybutów, checklisty i spisane decyzje składają się na centrum wiedzy, z którego agent korzysta przy każdym kolejnym zadaniu, a każda poprawka recenzenta wraca do reguł zamiast ginąć w czyjejś głowie. Efekt kumulacji, który widzieliśmy przy workflow operacyjnych, działa więc także w budowie: drugi rynek startuje szybciej niż pierwszy, trzeci szybciej niż drugi. Warunek jest jeden: ktoś świadomie pilnuje, żeby części wspólne zostawały wspólne.
Z tego samego przekonania publikujemy otwarty zestaw skilli eCommerce dla agentów AI na licencji MIT: spisany kontekst branżowy, który nie musi powstawać od nowa w każdym projekcie. Dokładnie na tym materiale pracujemy sami.
Jak rozwijać to u siebie, etapami
Zacznij od podziału ról, bo to on decyduje, czy proces się utrzyma:
- Kto pisze specyfikacje: nie musi to być programista. Najlepiej robi to osoba, która zna asortyment, klienta i to, co ma się w sklepie wydarzyć.
- Kto mówi „to nie wchodzi”: zwykle jedna osoba po stronie technicznej, z wyraźnie wyznaczonym zakresem decyzji nieodwracalnych.
- Reszta zespołu: pracuje w środku, czyli 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.
Kolejność i dobór narzędzi
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 niczego pilnować. 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. 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ę.
Cała ścieżka w jednym akapicie
Droga, 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. Porządkujesz dane, bo bez nich każda automatyzacja skaluje wyłącznie bałagan. Uruchamiasz pierwszy 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 krok zakłada poprzedni i żaden nie jest jednorazowy. A jeśli chcesz zacząć u siebie już dziś, rozdział siódmy, bonusowy, to gotowy framework wdrożenia: Claude Code i centrum wiedzy firmy krok po kroku.
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.
